- Linux-stable-mirror - lists.linaro.org

Re: [PATCH 00/45] arm Spectre fix backport review for LTS 4.9

by Pali Rohár

On Thursday 08 March 2018 13:27:15 Pavel Machek wrote: > Hi! > > > Resent without non-upstream patches. > > > > This backport patchset fixed the spectre issue, it's original branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti > > A few dependency or fixingpatches are also picked up, if they are necessary > > and no functional changes. > > > > No bug found from kernelci.org and lkft testing. It also could be gotten from: > > > > git://git.linaro.org/kernel/linux-linaro-stable.git v4.9-spectre-upstream-only > > > > Comments are appreciated! > > Not entirely related to this patched, but... I have few older ARM > boards here, and Nokia N9000 I really care about. > > AFAICT Meltdown is arm64 only? IIRC ARMv7 is not affected by meltdown. > Spectre affects the older boards, too, right? Was there any work done > on that? cpuinfo says "ARMv7" for N900. I remember that I saw some spectre patches for ARMv7 on LKML. In general for ARMv7 it is problematic as mitigation needs to change IBE bit which is not possible on OMAP HS devices. But for Nokia N900 there is special code which do it via smc instruction (function rx51_secure_update_aux_cr(), see also nokia_n900_legacy_init()). -- Pali Rohár pali.rohar(a)gmail.com

7 years, 6 months

3
2
0 0

[PATCH resend] module: propagate error in modules_open()

by Leon Yu

otherwise kernel can oops later in seq_release() due to dereferencing null file->private_data which is only set if seq_open() succeeds. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: seq_release+0xc/0x30 Call Trace: close_pdeo+0x37/0xd0 proc_reg_release+0x5d/0x60 __fput+0x9d/0x1d0 ____fput+0x9/0x10 task_work_run+0x75/0x90 do_exit+0x252/0xa00 do_group_exit+0x36/0xb0 SyS_exit_group+0xf/0x10 Fixes: 516fb7f2e73d ("/proc/module: use the same logic as /proc/kallsyms for address exposure") Cc: Jessica Yu <jeyu(a)kernel.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # 4.15+ Signed-off-by: Leon Yu <chianglungyu(a)gmail.com> --- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index ad2d420024f6..e42764acedb4 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -4228,7 +4228,7 @@ static int modules_open(struct inode *inode, struct file *file) m->private = kallsyms_show_value() ? NULL : (void *)8ul; } - return 0; + return err; } static const struct file_operations proc_modules_operations = { -- 2.16.2

7 years, 6 months

2
1
0 0

[PATCH] staging: android: ashmem: Remove deadlock

by Paul Lawrence

Regression introduced in commit ce8a3a9e76d0193e2e8d74a06d275b3c324ca652 ("staging: android: ashmem: Fix a race condition in pin ioctls") causing deadlock. No need to hold ashmem_mutex while copying from user Stacks are: ashmem_mmap+0x53/0x400 drivers/staging/android/ashmem.c:379 mmap_region+0x7dd/0xfd0 mm/mmap.c:1694 do_mmap+0x57b/0xbe0 mm/mmap.c:1473 and lock_acquire+0x12e/0x410 kernel/locking/lockdep.c:3756 __might_fault+0x14a/0x1d0 mm/memory.c:4014 copy_from_user arch/x86/include/asm/uaccess.h:705 [inline] ashmem_pin_unpin drivers/staging/android/ashmem.c:719 [inline] Signed-off-by: Paul Lawrence <paullawrence(a)google.com> Cc: <stable(a)vger.kernel.org> # 4.9.x Cc: <stable(a)vger.kernel.org> # 4.4.x Cc: <stable(a)vger.kernel.org> # 3.18.x: ce8a3a9e76d01 Cc: <stable(a)vger.kernel.org> # 3.18.x Cc: Ben Hutchings <ben(a)decadent.org.uk> --- drivers/staging/android/ashmem.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 6dbba5aff191..8c55706c2cfa 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma, unsigned long cmd, size_t pgstart, pgend; int ret = -EINVAL; + if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) + return -EFAULT; + mutex_lock(&ashmem_mutex); if (unlikely(!asma->file)) goto out_unlock; - if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) { - ret = -EFAULT; - goto out_unlock; - } - /* per custom, you can pass zero for len to mean "everything onward" */ if (!pin.len) pin.len = PAGE_ALIGN(asma->size) - pin.offset; -- 2.16.2.395.g2e18187dfd-goog

7 years, 6 months

3
2
0 0

Re: 4.14.18 -> 4.14.24 - almost all guests hanged

by 王金浦

2018-03-07 21:29 GMT+01:00 Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>: > Hi, > >> > > I'd like to report that when upgrading our cluster from 4.14.18 to >> > > 4.14.24-rc1 (with live guests migration), almost none of guests survived.. >> > What's your hardware setup, intel with IBPB enabled microcode? >> Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz >> >> therefore I suppose no IBPB (at least meltdown checker reports so) >> >> >> > Does guests hang right after live migration? >> yes, just tried it. >> >> >> > >> > Are you able to reproduce the problem, does it work with latest upstream? >> yup, so I'm able to reproduce quickly. I'll revert the cluster to 4.14.18 now, >> but setup test system just afterwards, so and test the patch you've proposed. >> >> > >> > Not sure it helps, but following patch is missing in 4.14.24 >> > >> > commit 37b95951c58fdf08dc10afa9d02066ed9f176fb5 upstream. >> > >> > kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit >> > status rather than X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is >> > to fix it. >> > >> > Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set) >> > Reported-by: Jeremi Piotrowski <jeremi.piotrowski(a)gmail.com> >> > Cc: Paolo Bonzini <pbonzini(a)redhat.com> >> > Cc: Radim Krčmář <rkrcmar(a)redhat.com> >> > Signed-off-by: Tianyu Lan <Tianyu.Lan(a)microsoft.com> >> > Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> >> >> I'll test and report. > > so indeed, this one on top of 4.14.24-rc1 fixes the migration for me. > Greg, could you queue this one up please? > > Jack, thanks for the hint! > BR > nik Hi Nik, Thanks for testing and let we know, the patch is already queued in 4.14.25-rc1 by Greg. There're some other KVM fixes and performance enhancement. Regards, Jack > > > >> >> n. >> >> >> > >> > Regards, >> > Jack >> > > >> > > I noticed that most of them got stuck in "paused" state without >> > > possibility to resume (virsh just reported guest cannot be continued and >> > > needs to be rebooted). >> > > >> > > in dmesg, lots of following messages appeared: >> > > >> > > [ 116.593508] device vnet0 entered promiscuous mode >> > > [ 124.143532] *** Guest State *** >> > > [ 124.143594] CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 >> > > [ 124.143668] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871 >> > > [ 124.143871] CR3 = 0x00000000feffc000 >> > > [ 124.143984] RSP = 0xffffffff82003e98 RIP = 0xffffffff816df002 >> > > [ 124.144102] RFLAGS=0x00000246 DR7 = 0x0000000000000400 >> > > [ 124.144221] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >> > > [ 124.144341] CS: sel=0xf000, attr=0x0009b, limit=0x0000ffff, base=0x00000000ffff0000 >> > > [ 124.144516] DS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.144692] SS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.144907] ES: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145089] FS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145272] GS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145447] GDTR: limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145626] LDTR: sel=0x0000, attr=0x00082, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145814] IDTR: limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145995] TR: sel=0x0000, attr=0x0008b, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.146173] EFER = 0x0000000000000000 PAT = 0x0007040600070406 >> > > [ 124.146292] DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000 >> > > [ 124.146466] Interruptibility = 00000000 ActivityState = 00000000 >> > > [ 124.146579] *** Host State *** >> > > [ 124.146687] RIP = 0xffffffffa046a817 RSP = 0xffffc900200a7cb8 >> > > [ 124.146832] CS=0010 SS=0018 DS=0000 ES=0000 FS=0000 GS=0000 TR=0040 >> > > [ 124.146961] FSBase=00007fe82eff7700 GSBase=ffff881fffb40000 TRBase=fffffe00000df000 >> > > [ 124.147144] GDTBase=fffffe00000dd000 IDTBase=fffffe0000000000 >> > > [ 124.147262] CR0=0000000080050033 CR3=0000001f5b8fe004 CR4=00000000000626e0 >> > > [ 124.147381] Sysenter RSP=fffffe00000de200 CS:RIP=0010:ffffffff81801f60 >> > > [ 124.147499] EFER = 0x0000000000000d01 PAT = 0x0407050600070106 >> > > [ 124.147614] *** Control State *** >> > > [ 124.147734] PinBased=0000007f CPUBased=96a1e9fa SecondaryExec=000004f2 >> > > [ 124.147849] EntryControls=0000d1ff ExitControls=002fefff >> > > [ 124.147965] ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000 >> > > [ 124.148085] VMEntry: intr_info=80000081 errcode=00000000 ilen=00000000 >> > > [ 124.148201] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 >> > > [ 124.148318] reason=80000021 qualification=0000000000000000 >> > > [ 124.148432] IDTVectoring: info=00000000 errcode=00000000 >> > > [ 124.148545] TSC Offset = 0xffed7296fb06bc34 >> > > [ 124.148655] TPR Threshold = 0x00 >> > > [ 124.148770] EPT pointer = 0x0000001f1a0af01e >> > > [ 124.148882] PLE Gap=00000080 Window=00001000 >> > > [ 124.148995] Virtual processor ID = 0x0001 >> > > >> > > (never seen anything like that) >> > > >> > > I haven't yet went through all patches between those two versions, so don't >> > > have any suspicion yet.. If anyone recognizes this as known problem, please >> > > let me know.. >> > > >> > > I'm going to try whether I'm able to reproduce the problem. >> > > >> > > BR >> > > >> > > nik >> > >> >> -- >> ------------------------------------- >> Ing. Nikola CIPRICH >> LinuxBox.cz, s.r.o. >> 28.rijna 168, 709 00 Ostrava >> >> tel.: +420 591 166 214 >> fax: +420 596 621 273 >> mobil: +420 777 093 799 >> www.linuxbox.cz >> >> mobil servis: +420 737 238 656 >> email servis: servis(a)linuxbox.cz >> ------------------------------------- >> > > -- > ------------------------------------- > Ing. Nikola CIPRICH > LinuxBox.cz, s.r.o. > 28. rijna 168, 709 00 Ostrava > > tel.: +420 591 166 214 > fax: +420 596 621 273 > mobil: +420 777 093 799 > > www.linuxbox.cz > > mobil servis: +420 737 238 656 > email servis: servis(a)linuxbox.cz > -------------------------------------

7 years, 6 months

1
0
0 0

[stable-4.14 0/2] 2 kvm fix for 4.14

by Jack Wang

From: Jack Wang <jinpu.wang(a)profitbricks.com> Hi Greg, I noticed 2 fixes for kvm are missing in your queue-4.14, both are bugfix, can be cherry pick cleanly. The patch from Tianyu should close bug below, also included in 3.16 https://bugzilla.kernel.org/show_bug.cgi?id=198991 Eric Biggers (1): KVM/x86: remove WARN_ON() for when vm_munmap() fails Tianyu Lan (1): KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs() arch/x86/kvm/x86.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) -- 2.7.4

7 years, 6 months

3
4
0 0

[PATCH] kbuild: Handle builtin dtb files containing hyphens

by James Hogan

On dtb files which contain hyphens, the dt_S_dtb command to build the dtb.S files (which allow DTB files to be built into the kernel) results in errors like the following: bcm3368-netgear-cvg834g.dtb.S: Assembler messages: bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-' bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:' bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:' bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-' This is due to the hyphen being used in symbol names. Replace all hyphens with underscores in the dt_S_dtb command to avoid this problem. Quite a lot of dts files have hyphens, but its only a problem on MIPS where such files can be built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is used (in the latter case it admitedly shouldn't really build all the dtb.o files, but thats a separate issue). Fixes: 695835511f96 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Michal Marek <michal.lkml(a)markovi.net> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Kevin Cernekee <cernekee(a)gmail.com> Cc: devicetree(a)vger.kernel.org Cc: linux-kbuild(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.9+ --- scripts/Makefile.lib | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 5589bae34af6..a6f538b31ad6 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -297,11 +297,11 @@ cmd_dt_S_dtb= \ echo '\#include <asm-generic/vmlinux.lds.h>'; \ echo '.section .dtb.init.rodata,"a"'; \ echo '.balign STRUCT_ALIGNMENT'; \ - echo '.global __dtb_$(*F)_begin'; \ - echo '__dtb_$(*F)_begin:'; \ + echo '.global __dtb_$(subst -,_,$(*F))_begin'; \ + echo '__dtb_$(subst -,_,$(*F))_begin:'; \ echo '.incbin "$<" '; \ - echo '__dtb_$(*F)_end:'; \ - echo '.global __dtb_$(*F)_end'; \ + echo '__dtb_$(subst -,_,$(*F))_end:'; \ + echo '.global __dtb_$(subst -,_,$(*F))_end'; \ echo '.balign STRUCT_ALIGNMENT'; \ ) > $@ -- 2.13.6

7 years, 6 months

2
2
0 0

[PATCH AUTOSEL for 3.18 01/53] usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()

by Sasha Levin

From: Yuyang Du <yuyang.du(a)intel.com> [ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ] This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support"). In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yuyang Du <yuyang.du(a)intel.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index 783715a9e399..215441690d32 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -2001,16 +2001,13 @@ static int dummy_hub_control( } break; case USB_PORT_FEAT_POWER: - if (hcd->speed == HCD_USB3) { - if (dum_hcd->port_status & USB_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - } else - if (dum_hcd->port_status & - USB_SS_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - /* FALLS THROUGH */ + dev_dbg(dummy_dev(dum_hcd), "power-off\n"); + if (hcd->speed == HCD_USB3) + dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER; + else + dum_hcd->port_status &= ~USB_PORT_STAT_POWER; + set_link_state(dum_hcd); + break; default: dum_hcd->port_status &= ~(1 << wValue); set_link_state(dum_hcd); @@ -2181,14 +2178,13 @@ static int dummy_hub_control( if ((dum_hcd->port_status & USB_SS_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } } else if ((dum_hcd->port_status & USB_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } + set_link_state(dum_hcd); } break; case GetPortErrorCount: -- 2.14.1

7 years, 6 months

1
52
0 0

[PATCH AUTOSEL for 4.4 001/101] usb: dwc2: Make sure we disconnect the gadget state

by Sasha Levin

From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ] I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear. Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected. So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared. With it, the gadget interface initializes properly on every plug in. Cc: Wei Xu <xuwei5(a)hisilicon.com> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Amit Pundir <amit.pundir(a)linaro.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: John Youn <johnyoun(a)synopsys.com> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Chen Yu <chenyu56(a)huawei.com> Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Acked-by: John Youn <johnyoun(a)synopsys.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/usb/dwc2/hcd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index 571c21727ff9..88bd950665fa 100644 --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(struct work_struct *work) dwc2_core_init(hsotg, false, -1); dwc2_enable_global_interrupts(hsotg); spin_lock_irqsave(&hsotg->lock, flags); + dwc2_hsotg_disconnect(hsotg); dwc2_hsotg_core_init_disconnected(hsotg, false); spin_unlock_irqrestore(&hsotg->lock, flags); dwc2_hsotg_core_connect(hsotg); -- 2.14.1

7 years, 6 months

1
100
0 0

Patch "platform/x86: dell-laptop: fix kbd_get_state's request value" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: dell-laptop: fix kbd_get_state's request value to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-dell-laptop-fix-kbd_get_state-s-request-value.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From eca39e7f0cdb9bde4003a29149fa695e876c6f73 Mon Sep 17 00:00:00 2001 From: Laszlo Toth <laszlth(a)gmail.com> Date: Tue, 13 Feb 2018 21:43:43 +0100 Subject: platform/x86: dell-laptop: fix kbd_get_state's request value MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Laszlo Toth <laszlth(a)gmail.com> commit eca39e7f0cdb9bde4003a29149fa695e876c6f73 upstream. Commit 9862b43624a5 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally") broke one request, changed it back to the original value. Tested on a Dell E6540, backlight came back. Fixes: 9862b43624a5 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally") Signed-off-by: Laszlo Toth <laszlth(a)gmail.com> Reviewed-by: Pali Rohár <pali.rohar(a)gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)dell.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/dell-laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -1254,7 +1254,7 @@ static int kbd_get_state(struct kbd_stat struct calling_interface_buffer buffer; int ret; - dell_fill_request(&buffer, 0, 0, 0, 0); + dell_fill_request(&buffer, 0x1, 0, 0, 0); ret = dell_send_request(&buffer, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT); if (ret) Patches currently in stable-queue which might be from laszlth(a)gmail.com are queue-4.15/platform-x86-dell-laptop-fix-kbd_get_state-s-request-value.patch

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Pavel Machek

On Wed 2018-03-07 22:11:13, David Woodhouse wrote: > > > On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote: > > > > To clarify one thing: the reason for this is MLC has actually never > > been supported, nor worked properly. The fact that it kinda worked was > > incidental and the cause of major problems for people due to that not > > being clear. This patch only makes it explicit and avoids people > > mistakenly trying to use UBIFS on MLC flash and risking their data and > > products. To me, that's what's important. > > > > This is an important patch, even if all it does is keep people from > > loosing data. It also changes the conversation from "I have a > > corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get > > UBIFS to work on MLC". Well, for -stable I'd suggest printk(KERN_ALERT ...) but keep the system running. > This is a bug fix. > > UBI on MLC never worked. It was a bug that we ever permitted it. This > is now fixed. Yeah, well, so lets say I have a working hardware (maybe using read-only UBI on MLC), update to next stable kernel, and now kernel refuses to see the partition. I'll certainly not consider this patch a bug fix. Removing support for hardware that "only works by mistake" may be good idea, but maybe it is slightly too surprising for a -stable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

7 years, 6 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror