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

patch "staging: comedi: fix comedi_nsamples_left." added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: comedi: fix comedi_nsamples_left. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From a42ae5905140c324362fe5036ae1dbb16e4d359c Mon Sep 17 00:00:00 2001 From: Frank Mori Hess <fmh6jj(a)gmail.com> Date: Thu, 15 Feb 2018 15:13:42 -0500 Subject: staging: comedi: fix comedi_nsamples_left. A rounding error was causing comedi_nsamples_left to return the wrong value when nsamples was not a multiple of the scan length. Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com> Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/comedi/drivers.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c index e618a87521a3..9d733471ca2e 100644 --- a/drivers/staging/comedi/drivers.c +++ b/drivers/staging/comedi/drivers.c @@ -475,8 +475,7 @@ unsigned int comedi_nsamples_left(struct comedi_subdevice *s, struct comedi_cmd *cmd = &async->cmd; if (cmd->stop_src == TRIG_COUNT) { - unsigned int nscans = nsamples / cmd->scan_end_arg; - unsigned int scans_left = __comedi_nscans_left(s, nscans); + unsigned int scans_left = __comedi_nscans_left(s, cmd->stop_arg); unsigned int scan_pos = comedi_bytes_to_samples(s, async->scan_progress); unsigned long long samples_left = 0; -- 2.16.2

7 years, 6 months

1
0
0 0

Re: [PATCH AUTOSEL for 4.9 002/219] spi/bcm63xx: make spi subsystem aware of message size limits

by Jonas Gorski

On 6 March 2018 at 15:20, Mark Brown <broonie(a)kernel.org> wrote: > On Tue, Mar 06, 2018 at 02:42:43PM +0100, Jonas Gorski wrote: >> On 5 March 2018 at 21:35, Mark Brown <broonie(a)kernel.org> wrote: > >> > It's exposing more capability information but it's in the "how did this >> > ever work without the fix" range, and I'd worry that this might cause us >> > to do something like start exercising handling code in client drivers >> > that had never been tested. Not that I can immediately see any client >> > drivers in mainline that actually pay attention... :/ > >> I would assume that most spi client drivers use short messages, so >> they aren't affected unless the max message size is really short. >> m25p80 on the other hand will do arbitrarily large transfers/reads, so >> there it was supported first. > > There's a bunch of SPI drivers that do firmware downloads which I'd > expect to be affected, the limit the device has is tiny so it's > relatively easy to bump into it. It's very rare for devices to be so > limited so unfortunately client drivers don't generally check though. Well, at least for bcm63xx it's very rare to have something other than a flash chip, a (broadcom) ethernet switch management interface, or a SLIC/SLAC attached to the SPI controller. And AFAICT of these three only the flash chip uses large SPI transfers. Furthermore, unless you have a development board, you won't be able to attach anything different to it. So the chance to bump into the limits with other drivers is rather low. I would assume that this is true for most systems with a limited SPI controller. I would hope that most board designers are sensible enough to not add devices that won't work ;-) Regards Jonas

7 years, 6 months

1
0
0 0

[PATCH] media: rc: oops in ir_timer_keyup after device unplug

by Sean Young

If there is IR in the raw kfifo when ir_raw_event_unregister() is called, then kthread_stop() causes ir_raw_event_thread to be scheduled, decode some scancodes and re-arm timer_keyup. The timer_keyup then fires when the rc device is long gone. Cc: stable(a)vger.kernel.org Signed-off-by: Sean Young <sean(a)mess.org> --- drivers/media/rc/rc-main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 4a952108ba1e..8621761a680f 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1932,12 +1932,12 @@ void rc_unregister_device(struct rc_dev *dev) if (!dev) return; - del_timer_sync(&dev->timer_keyup); - del_timer_sync(&dev->timer_repeat); - if (dev->driver_type == RC_DRIVER_IR_RAW) ir_raw_event_unregister(dev); + del_timer_sync(&dev->timer_keyup); + del_timer_sync(&dev->timer_repeat); + rc_free_rx_device(dev); mutex_lock(&dev->lock); -- 2.14.3

7 years, 6 months

1
0
0 0

[PATCH] 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

1
0
0 0

Re: [PATCH AUTOSEL for 4.9 002/219] spi/bcm63xx: make spi subsystem aware of message size limits

by Jonas Gorski

On 5 March 2018 at 21:35, Mark Brown <broonie(a)kernel.org> wrote: > On Mon, Mar 05, 2018 at 08:07:46PM +0000, Sasha Levin wrote: >> On Mon, Mar 05, 2018 at 10:23:10AM +0000, Mark Brown wrote: >> >On Sat, Mar 03, 2018 at 10:27:56PM +0000, Sasha Levin wrote: > >> >> The bcm63xx SPI controller does not allow manual control of the CS >> >> lines and will toggle it automatically before and after sending data, >> >> so we are limited to messages that fit in the FIFO buffer. Since the CS >> >> lines aren't available as GPIOs either, we will need to make slave >> >> drivers aware of this limitation so they can handle them accordingly. > >> >This seems really aggressive for stable... > >> Why so? > > It's exposing more capability information but it's in the "how did this > ever work without the fix" range, and I'd worry that this might cause us > to do something like start exercising handling code in client drivers > that had never been tested. Not that I can immediately see any client > drivers in mainline that actually pay attention... :/ I would assume that most spi client drivers use short messages, so they aren't affected unless the max message size is really short. m25p80 on the other hand will do arbitrarily large transfers/reads, so there it was supported first. m25p80 supports max_transfer_size since 4,9, and max_message_size since 4.11 with commit 9e276de6a367cde07c1a63522152985d4e5cca8b. So that one would need to be backported as well for the max_message_size being actually meaningful. tinydrm-helpers also observes max_transfers_size since 4.11 with commit 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b where it was added, but since this is a larger commit and not just a "bugfix" one, this doesn't seem like a candidate for backporting. Regards Jonas

7 years, 6 months

1
0
0 0

[PATCH resend] usb: quirks: add control message delay for 1b1c:1b20

by Danilo Krummrich

Corsair Strafe RGB keyboard does not respond to usb control messages sometimes and hence generates timeouts. Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard") tried to fix those timeouts by adding USB_QUIRK_DELAY_INIT. Unfortunately, even with this quirk timeouts of usb_control_msg() can still be seen, but with a lower frequency (approx. 1 out of 15): [ 29.103520] usb 1-8: string descriptor 0 read error: -110 [ 34.363097] usb 1-8: can't set config #1, error -110 Adding further delays to different locations where usb control messages are issued just moves the timeouts to other locations, e.g.: [ 35.400533] usbhid 1-8:1.0: can't add hid device: -110 [ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110 The only way to reliably avoid those issues is having a pause after each usb control message. In approx. 200 boot cycles no more timeouts were seen. Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary to have the delay in hub_port_connect() after hub_port_init(). The overall boot time seems not to be influenced by these additional delays, even on fast machines and lightweight distributions. Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard") Cc: stable(a)vger.kernel.org Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de> --- drivers/usb/core/message.c | 4 ++++ drivers/usb/core/quirks.c | 3 ++- include/linux/usb/quirks.h | 3 +++ 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index c64cf6c4a83d..0c11d40a12bc 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -151,6 +151,10 @@ int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request, ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout); + /* Linger a bit, prior to the next control message. */ + if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG) + msleep(200); + kfree(dr); return ret; diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index f4a548471f0f..54b019e267c5 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -230,7 +230,8 @@ static const struct usb_device_id usb_quirk_list[] = { { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT }, /* Corsair Strafe RGB */ - { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT }, + { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT | + USB_QUIRK_DELAY_CTRL_MSG }, /* Corsair K70 LUX */ { USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT }, diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h index f1fcec2fd5f8..b7a99ce56bc9 100644 --- a/include/linux/usb/quirks.h +++ b/include/linux/usb/quirks.h @@ -63,4 +63,7 @@ */ #define USB_QUIRK_DISCONNECT_SUSPEND BIT(12) +/* Device needs a pause after every control message. */ +#define USB_QUIRK_DELAY_CTRL_MSG BIT(13) + #endif /* __LINUX_USB_QUIRKS_H */ -- 2.16.2

7 years, 6 months

1
0
0 0

[PATCH] arm64: dts: ls208x: remove Freescale Erratum A008585 from LS2088A.

by Pankaj Bansal

Freescale Erratum A008585 affects A57 core cluster used in LS2085rev1. However this problem has been fixed in A72 core cluster used in LS2088. Therefore remove the erratum from LS2088A. Keeping it only in LS2085. Cc: <stable(a)vger.kernel.org> # 4.14 Signed-off-by: Pankaj Bansal <pankaj.bansal(a)nxp.com> Reviewed-by: Sandeep Malik <sandeep.malik(a)nxp.com> Acked-by: Priyanka Jain <priyanka.jain(a)nxp.com> --- arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 4 ++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 3 +-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi index 8d73930..f55cb3e 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi @@ -150,6 +150,10 @@ }; }; +&timer { + fsl,erratum-a008585; +}; + &pcie1 { reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */ 0x10 0x00000000 0x0 0x00002000>; /* configuration space */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..4f06676 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -111,13 +111,12 @@ mask = <0x2>; }; - timer { + timer: timer { compatible = "arm,armv8-timer"; interrupts = <1 13 4>, /* Physical Secure PPI, active-low */ <1 14 4>, /* Physical Non-Secure PPI, active-low */ <1 11 4>, /* Virtual PPI, active-low */ <1 10 4>; /* Hypervisor PPI, active-low */ - fsl,erratum-a008585; }; pmu { -- 2.7.4

7 years, 6 months

1
0
0 0

[PATCH v2 5/6] PCI: hv: hv_pci_devices_present(): only queue a new work when necessary

by Dexuan Cui

If there is a pending work, we just need to add the new dr into the dr_list. This is suggested by Michael Kelley. Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com> Cc: Jack Morgenstein <jackm(a)mellanox.com> Cc: stable(a)vger.kernel.org Cc: Stephen Hemminger <sthemmin(a)microsoft.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Michael Kelley (EOSG) <Michael.H.Kelley(a)microsoft.com> --- drivers/pci/host/pci-hyperv.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c index 3a385212f666..d3aa6736a9bb 100644 --- a/drivers/pci/host/pci-hyperv.c +++ b/drivers/pci/host/pci-hyperv.c @@ -1733,6 +1733,7 @@ static void hv_pci_devices_present(struct hv_pcibus_device *hbus, struct hv_dr_state *dr; struct hv_dr_work *dr_wrk; unsigned long flags; + bool pending_dr; dr_wrk = kzalloc(sizeof(*dr_wrk), GFP_NOWAIT); if (!dr_wrk) @@ -1756,11 +1757,23 @@ static void hv_pci_devices_present(struct hv_pcibus_device *hbus, } spin_lock_irqsave(&hbus->device_list_lock, flags); + + /* + * If pending_dr is true, we have already queued a work, + * which will see the new dr. Otherwise, we need to + * queue a new work. + */ + pending_dr = !list_empty(&hbus->dr_list); list_add_tail(&dr->list_entry, &hbus->dr_list); - spin_unlock_irqrestore(&hbus->device_list_lock, flags); - get_hvpcibus(hbus); - queue_work(hbus->wq, &dr_wrk->wrk); + if (pending_dr) { + kfree(dr_wrk); + } else { + get_hvpcibus(hbus); + queue_work(hbus->wq, &dr_wrk->wrk); + } + + spin_unlock_irqrestore(&hbus->device_list_lock, flags); } /** -- 2.7.4

7 years, 6 months

2
2
0 0

+ zboot-fix-stack-protector-in-compressed-boot-phase.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: zboot: fix stack protector in compressed boot phase has been added to the -mm tree. Its filename is zboot-fix-stack-protector-in-compressed-boot-phase.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/zboot-fix-stack-protector-in-compr… and later at http://ozlabs.org/~akpm/mmotm/broken-out/zboot-fix-stack-protector-in-compr… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Huacai Chen <chenhc(a)lemote.com> Subject: zboot: fix stack protector in compressed boot phase Calling __stack_chk_guard_setup() in decompress_kernel() is too late because stack checking always fails for decompress_kernel() itself. So remove __stack_chk_guard_setup() and initialize __stack_chk_guard at compile time. Original code comes from ARM but also used for MIPS and SH, so fix them together. Without this fix, compressed booting of these archs will fail because stack checking is enabled by default (>=4.16). Link: http://lkml.kernel.org/r/1520230721-1839-1-git-send-email-chenhc@lemote.com Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: James Hogan <james.hogan(a)mips.com> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp> Cc: Rich Felker <dalias(a)libc.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm/boot/compressed/misc.c | 9 +-------- arch/mips/boot/compressed/decompress.c | 9 +-------- arch/sh/boot/compressed/misc.c | 9 +-------- 3 files changed, 3 insertions(+), 24 deletions(-) diff -puN arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/arm/boot/compressed/misc.c --- a/arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase +++ a/arch/arm/boot/compressed/misc.c @@ -128,12 +128,7 @@ asmlinkage void __div0(void) error("Attempting division by 0!"); } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_s { int ret; - __stack_chk_guard_setup(); - output_data = (unsigned char *)output_start; free_mem_ptr = free_mem_ptr_p; free_mem_end_ptr = free_mem_ptr_end_p; diff -puN arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/mips/boot/compressed/decompress.c --- a/arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase +++ a/arch/mips/boot/compressed/decompress.c @@ -76,12 +76,7 @@ void error(char *x) #include "../../../../lib/decompress_unxz.c" #endif -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boo { unsigned long zimage_start, zimage_size; - __stack_chk_guard_setup(); - zimage_start = (unsigned long)(&__image_begin); zimage_size = (unsigned long)(&__image_end) - (unsigned long)(&__image_begin); diff -puN arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/sh/boot/compressed/misc.c --- a/arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase +++ a/arch/sh/boot/compressed/misc.c @@ -104,12 +104,7 @@ static void error(char *x) while(1); /* Halt */ } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -130,8 +125,6 @@ void decompress_kernel(void) { unsigned long output_addr; - __stack_chk_guard_setup(); - #ifdef CONFIG_SUPERH64 output_addr = (CONFIG_MEMORY_START + 0x2000); #else _ Patches currently in -mm which might be from chenhc(a)lemote.com are zboot-fix-stack-protector-in-compressed-boot-phase.patch

7 years, 6 months

1
0
0 0

[PATCH 2/2] bcache: don't attach backing with duplicate UUID

by Michael Lyle

This can happen e.g. during disk cloning. This is an incomplete fix: it does not catch duplicate UUIDs earlier when things are still unattached. It does not unregister the device. Further changes to cope better with this are planned but conflict with Coly's ongoing improvements to handling device errors. In the meantime, one can manually stop the device after this has happened. Attempts to attach a duplicate device result in: [ 136.372404] loop: module loaded [ 136.424461] bcache: register_bdev() registered backing device loop0 [ 136.424464] bcache: bch_cached_dev_attach() Tried to attach loop0 but duplicate UUID already attached My test procedure is: dd if=/dev/sdb1 of=imgfile bs=1024 count=262144 losetup -f imgfile Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Tang Junhui <tang.junhui(a)zte.com.cn> Cc: <stable(a)vger.kernel.org> --- drivers/md/bcache/super.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index 9c141a8aaacc..5cace6892958 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -963,6 +963,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c, uint32_t rtime = cpu_to_le32(get_seconds()); struct uuid_entry *u; char buf[BDEVNAME_SIZE]; + struct cached_dev *exist_dc, *t; bdevname(dc->bdev, buf); @@ -987,6 +988,16 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c, return -EINVAL; } + /* Check whether already attached */ + list_for_each_entry_safe(exist_dc, t, &c->cached_devs, list) { + if (!memcmp(dc->sb.uuid, exist_dc->sb.uuid, 16)) { + pr_err("Tried to attach %s but duplicate UUID already attached", + buf); + + return -EINVAL; + } + } + u = uuid_find(c, dc->sb.uuid); if (u && -- 2.14.1

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror