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

[Linux-stable-mirror] Patch "USB: UDC core: fix double-free in usb_add_gadget_udc_release" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: UDC core: fix double-free in usb_add_gadget_udc_release to the 4.14-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: usb-udc-core-fix-double-free-in-usb_add_gadget_udc_release.patch and it can be found in the queue-4.14 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 7ae2c3c280db183ca9ada2675c34ec2f7378abfa Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 3 Jan 2018 12:51:51 -0500 Subject: USB: UDC core: fix double-free in usb_add_gadget_udc_release From: Alan Stern <stern(a)rowland.harvard.edu> commit 7ae2c3c280db183ca9ada2675c34ec2f7378abfa upstream. The error-handling pathways in usb_add_gadget_udc_release() are messed up. Aside from the uninformative statement labels, they can deallocate the udc structure after calling put_device(), which is a double-free. This was observed by KASAN in automatic testing. This patch cleans up the routine. It preserves the requirement that when any failure occurs, we call put_device(&gadget->dev). Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Reviewed-by: Peter Chen <peter.chen(a)nxp.com> Acked-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/core.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -1158,11 +1158,7 @@ int usb_add_gadget_udc_release(struct de udc = kzalloc(sizeof(*udc), GFP_KERNEL); if (!udc) - goto err1; - - ret = device_add(&gadget->dev); - if (ret) - goto err2; + goto err_put_gadget; device_initialize(&udc->dev); udc->dev.release = usb_udc_release; @@ -1171,7 +1167,11 @@ int usb_add_gadget_udc_release(struct de udc->dev.parent = parent; ret = dev_set_name(&udc->dev, "%s", kobject_name(&parent->kobj)); if (ret) - goto err3; + goto err_put_udc; + + ret = device_add(&gadget->dev); + if (ret) + goto err_put_udc; udc->gadget = gadget; gadget->udc = udc; @@ -1181,7 +1181,7 @@ int usb_add_gadget_udc_release(struct de ret = device_add(&udc->dev); if (ret) - goto err4; + goto err_unlist_udc; usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED); udc->vbus = true; @@ -1189,27 +1189,25 @@ int usb_add_gadget_udc_release(struct de /* pick up one of pending gadget drivers */ ret = check_pending_gadget_drivers(udc); if (ret) - goto err5; + goto err_del_udc; mutex_unlock(&udc_lock); return 0; -err5: + err_del_udc: device_del(&udc->dev); -err4: + err_unlist_udc: list_del(&udc->list); mutex_unlock(&udc_lock); -err3: - put_device(&udc->dev); device_del(&gadget->dev); -err2: - kfree(udc); + err_put_udc: + put_device(&udc->dev); -err1: + err_put_gadget: put_device(&gadget->dev); return ret; } Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are queue-4.14/usb-udc-core-fix-double-free-in-usb_add_gadget_udc_release.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: cp210x: add new device ID ELV ALC 8xxx" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: cp210x: add new device ID ELV ALC 8xxx to the 4.14-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: usb-serial-cp210x-add-new-device-id-elv-alc-8xxx.patch and it can be found in the queue-4.14 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 d14ac576d10f865970bb1324d337e5e24d79aaf4 Mon Sep 17 00:00:00 2001 From: Christian Holl <cyborgx1(a)gmail.com> Date: Wed, 3 Jan 2018 19:53:02 +0100 Subject: USB: serial: cp210x: add new device ID ELV ALC 8xxx From: Christian Holl <cyborgx1(a)gmail.com> commit d14ac576d10f865970bb1324d337e5e24d79aaf4 upstream. This adds the ELV ALC 8xxx Battery Charging device to the list of USB IDs of drivers/usb/serial/cp210x.c Signed-off-by: Christian Holl <cyborgx1(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -178,6 +178,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */ { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */ { USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */ + { USB_DEVICE(0x18EF, 0xE030) }, /* ELV ALC 8xxx Battery Charger */ { USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */ { USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */ { USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */ Patches currently in stable-queue which might be from cyborgx1(a)gmail.com are queue-4.14/usb-serial-cp210x-add-new-device-id-elv-alc-8xxx.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: fix usbmon BUG trigger" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: fix usbmon BUG trigger to the 4.14-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: usb-fix-usbmon-bug-trigger.patch and it can be found in the queue-4.14 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 46eb14a6e1585d99c1b9f58d0e7389082a5f466b Mon Sep 17 00:00:00 2001 From: Pete Zaitcev <zaitcev(a)redhat.com> Date: Mon, 8 Jan 2018 15:46:41 -0600 Subject: USB: fix usbmon BUG trigger From: Pete Zaitcev <zaitcev(a)redhat.com> commit 46eb14a6e1585d99c1b9f58d0e7389082a5f466b upstream. Automated tests triggered this by opening usbmon and accessing the mmap while simultaneously resizing the buffers. This bug was with us since 2006, because typically applications only size the buffers once and thus avoid racing. Reported by Kirill A. Shutemov. Reported-by: <syzbot+f9831b881b3e849829fc(a)syzkaller.appspotmail.com> Signed-off-by: Pete Zaitcev <zaitcev(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/mon/mon_bin.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/drivers/usb/mon/mon_bin.c +++ b/drivers/usb/mon/mon_bin.c @@ -1004,7 +1004,9 @@ static long mon_bin_ioctl(struct file *f break; case MON_IOCQ_RING_SIZE: + mutex_lock(&rp->fetch_lock); ret = rp->b_size; + mutex_unlock(&rp->fetch_lock); break; case MON_IOCT_RING_SIZE: @@ -1231,12 +1233,16 @@ static int mon_bin_vma_fault(struct vm_f unsigned long offset, chunk_idx; struct page *pageptr; + mutex_lock(&rp->fetch_lock); offset = vmf->pgoff << PAGE_SHIFT; - if (offset >= rp->b_size) + if (offset >= rp->b_size) { + mutex_unlock(&rp->fetch_lock); return VM_FAULT_SIGBUS; + } chunk_idx = offset / CHUNK_SIZE; pageptr = rp->b_vec[chunk_idx].pg; get_page(pageptr); + mutex_unlock(&rp->fetch_lock); vmf->page = pageptr; return 0; } Patches currently in stable-queue which might be from zaitcev(a)redhat.com are queue-4.14/usb-fix-usbmon-bug-trigger.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: misc: usb3503: make sure reset is low for at least 100us" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: misc: usb3503: make sure reset is low for at least 100us to the 4.14-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: usb-misc-usb3503-make-sure-reset-is-low-for-at-least-100us.patch and it can be found in the queue-4.14 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 b8626f1dc29d3eee444bfaa92146ec7b291ef41c Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Thu, 11 Jan 2018 14:47:40 +0100 Subject: usb: misc: usb3503: make sure reset is low for at least 100us From: Stefan Agner <stefan(a)agner.ch> commit b8626f1dc29d3eee444bfaa92146ec7b291ef41c upstream. When using a GPIO which is high by default, and initialize the driver in USB Hub mode, initialization fails with: [ 111.757794] usb3503 0-0008: SP_ILOCK failed (-5) The reason seems to be that the chip is not properly reset. Probe does initialize reset low, however some lines later the code already set it back high, which is not long enouth. Make sure reset is asserted for at least 100us by inserting a delay after initializing the reset pin during probe. Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/usb3503.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -292,6 +292,8 @@ static int usb3503_probe(struct usb3503 if (gpio_is_valid(hub->gpio_reset)) { err = devm_gpio_request_one(dev, hub->gpio_reset, GPIOF_OUT_INIT_LOW, "usb3503 reset"); + /* Datasheet defines a hardware reset to be at least 100us */ + usleep_range(100, 10000); if (err) { dev_err(dev, "unable to request GPIO %d as reset pin (%d)\n", Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.14/usb-misc-usb3503-make-sure-reset-is-low-for-at-least-100us.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl to the 4.14-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: staging-android-ashmem-fix-a-race-condition-in-ashmem_set_size-ioctl.patch and it can be found in the queue-4.14 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 443064cb0b1fb4569fe0a71209da7625129fb760 Mon Sep 17 00:00:00 2001 From: Viktor Slavkovic <viktors(a)google.com> Date: Mon, 8 Jan 2018 10:43:03 -0800 Subject: staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl From: Viktor Slavkovic <viktors(a)google.com> commit 443064cb0b1fb4569fe0a71209da7625129fb760 upstream. A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a race condition when mmap is called. After the !asma->file check, before setting asma->size, asma->file can be set in mmap. That would result in having different asma->size than the mapped memory size. Combined with ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory corruption. Signed-off-by: Viktor Slavkovic <viktors(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/android/ashmem.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -765,10 +765,12 @@ static long ashmem_ioctl(struct file *fi break; case ASHMEM_SET_SIZE: ret = -EINVAL; + mutex_lock(&ashmem_mutex); if (!asma->file) { ret = 0; asma->size = (size_t)arg; } + mutex_unlock(&ashmem_mutex); break; case ASHMEM_GET_SIZE: ret = asma->size; Patches currently in stable-queue which might be from viktors(a)google.com are queue-4.14/staging-android-ashmem-fix-a-race-condition-in-ashmem_set_size-ioctl.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: remove kernel addresses from usb device and urb debug msgs" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: remove kernel addresses from usb device and urb debug msgs to the 3.18-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: usbip-remove-kernel-addresses-from-usb-device-and-urb-debug-msgs.patch and it can be found in the queue-3.18 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 e1346fd87c71a1f61de1fe476ec8df1425ac931c Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Fri, 22 Dec 2017 17:00:06 -0700 Subject: usbip: remove kernel addresses from usb device and urb debug msgs From: Shuah Khan <shuahkh(a)osg.samsung.com> commit e1346fd87c71a1f61de1fe476ec8df1425ac931c upstream. usbip_dump_usb_device() and usbip_dump_urb() print kernel addresses. Remove kernel addresses from usb device and urb debug msgs and improve the message content. Instead of printing parent device and bus addresses, print parent device and bus names. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/usbip/usbip_common.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) --- a/drivers/usb/usbip/usbip_common.c +++ b/drivers/usb/usbip/usbip_common.c @@ -103,7 +103,7 @@ static void usbip_dump_usb_device(struct dev_dbg(dev, " devnum(%d) devpath(%s) usb speed(%s)", udev->devnum, udev->devpath, usb_speed_string(udev->speed)); - pr_debug("tt %p, ttport %d\n", udev->tt, udev->ttport); + pr_debug("tt hub ttport %d\n", udev->ttport); dev_dbg(dev, " "); for (i = 0; i < 16; i++) @@ -136,12 +136,8 @@ static void usbip_dump_usb_device(struct } pr_debug("\n"); - dev_dbg(dev, "parent %p, bus %p\n", udev->parent, udev->bus); - - dev_dbg(dev, - "descriptor %p, config %p, actconfig %p, rawdescriptors %p\n", - &udev->descriptor, udev->config, - udev->actconfig, udev->rawdescriptors); + dev_dbg(dev, "parent %s, bus %s\n", dev_name(&udev->parent->dev), + udev->bus->bus_name); dev_dbg(dev, "have_langid %d, string_langid %d\n", udev->have_langid, udev->string_langid); @@ -249,9 +245,6 @@ void usbip_dump_urb(struct urb *urb) dev = &urb->dev->dev; - dev_dbg(dev, " urb :%p\n", urb); - dev_dbg(dev, " dev :%p\n", urb->dev); - usbip_dump_usb_device(urb->dev); dev_dbg(dev, " pipe :%08x ", urb->pipe); @@ -260,11 +253,9 @@ void usbip_dump_urb(struct urb *urb) dev_dbg(dev, " status :%d\n", urb->status); dev_dbg(dev, " transfer_flags :%08X\n", urb->transfer_flags); - dev_dbg(dev, " transfer_buffer :%p\n", urb->transfer_buffer); dev_dbg(dev, " transfer_buffer_length:%d\n", urb->transfer_buffer_length); dev_dbg(dev, " actual_length :%d\n", urb->actual_length); - dev_dbg(dev, " setup_packet :%p\n", urb->setup_packet); if (urb->setup_packet && usb_pipetype(urb->pipe) == PIPE_CONTROL) usbip_dump_usb_ctrlrequest( @@ -274,8 +265,6 @@ void usbip_dump_urb(struct urb *urb) dev_dbg(dev, " number_of_packets :%d\n", urb->number_of_packets); dev_dbg(dev, " interval :%d\n", urb->interval); dev_dbg(dev, " error_count :%d\n", urb->error_count); - dev_dbg(dev, " context :%p\n", urb->context); - dev_dbg(dev, " complete :%p\n", urb->complete); } EXPORT_SYMBOL_GPL(usbip_dump_urb); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-3.18/usbip-remove-kernel-addresses-from-usb-device-and-urb-debug-msgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: misc: usb3503: make sure reset is low for at least 100us" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: misc: usb3503: make sure reset is low for at least 100us to the 3.18-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: usb-misc-usb3503-make-sure-reset-is-low-for-at-least-100us.patch and it can be found in the queue-3.18 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 b8626f1dc29d3eee444bfaa92146ec7b291ef41c Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Thu, 11 Jan 2018 14:47:40 +0100 Subject: usb: misc: usb3503: make sure reset is low for at least 100us From: Stefan Agner <stefan(a)agner.ch> commit b8626f1dc29d3eee444bfaa92146ec7b291ef41c upstream. When using a GPIO which is high by default, and initialize the driver in USB Hub mode, initialization fails with: [ 111.757794] usb3503 0-0008: SP_ILOCK failed (-5) The reason seems to be that the chip is not properly reset. Probe does initialize reset low, however some lines later the code already set it back high, which is not long enouth. Make sure reset is asserted for at least 100us by inserting a delay after initializing the reset pin during probe. Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/usb3503.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -291,6 +291,8 @@ static int usb3503_probe(struct usb3503 if (gpio_is_valid(hub->gpio_reset)) { err = devm_gpio_request_one(dev, hub->gpio_reset, GPIOF_OUT_INIT_LOW, "usb3503 reset"); + /* Datasheet defines a hardware reset to be at least 100us */ + usleep_range(100, 10000); if (err) { dev_err(dev, "unable to request GPIO %d as reset pin (%d)\n", Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-3.18/usb-misc-usb3503-make-sure-reset-is-low-for-at-least-100us.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: cp210x: add new device ID ELV ALC 8xxx" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: cp210x: add new device ID ELV ALC 8xxx to the 3.18-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: usb-serial-cp210x-add-new-device-id-elv-alc-8xxx.patch and it can be found in the queue-3.18 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 d14ac576d10f865970bb1324d337e5e24d79aaf4 Mon Sep 17 00:00:00 2001 From: Christian Holl <cyborgx1(a)gmail.com> Date: Wed, 3 Jan 2018 19:53:02 +0100 Subject: USB: serial: cp210x: add new device ID ELV ALC 8xxx From: Christian Holl <cyborgx1(a)gmail.com> commit d14ac576d10f865970bb1324d337e5e24d79aaf4 upstream. This adds the ELV ALC 8xxx Battery Charging device to the list of USB IDs of drivers/usb/serial/cp210x.c Signed-off-by: Christian Holl <cyborgx1(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -169,6 +169,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */ { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */ { USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */ + { USB_DEVICE(0x18EF, 0xE030) }, /* ELV ALC 8xxx Battery Charger */ { USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */ { USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */ { USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */ Patches currently in stable-queue which might be from cyborgx1(a)gmail.com are queue-3.18/usb-serial-cp210x-add-new-device-id-elv-alc-8xxx.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ to the 3.18-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: usb-serial-cp210x-add-ids-for-lifescan-onetouch-verio-iq.patch and it can be found in the queue-3.18 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 4307413256ac1e09b8f53e8715af3df9e49beec3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Diego=20Elio=20Petten=C3=B2?= <flameeyes(a)flameeyes.eu> Date: Fri, 29 Dec 2017 09:54:25 +0000 Subject: USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Diego Elio Pettenò <flameeyes(a)flameeyes.eu> commit 4307413256ac1e09b8f53e8715af3df9e49beec3 upstream. Add IDs for the OneTouch Verio IQ that comes with an embedded USB-to-serial converter. Signed-off-by: Diego Elio Pettenò <flameeyes(a)flameeyes.eu> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -119,6 +119,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x10C4, 0x846E) }, /* BEI USB Sensor Interface (VCP) */ { USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */ { USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */ + { USB_DEVICE(0x10C4, 0x85A7) }, /* LifeScan OneTouch Verio IQ */ { USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */ { USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */ { USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */ Patches currently in stable-queue which might be from flameeyes(a)flameeyes.eu are queue-3.18/usb-serial-cp210x-add-ids-for-lifescan-onetouch-verio-iq.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: fix usbmon BUG trigger" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: fix usbmon BUG trigger to the 3.18-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: usb-fix-usbmon-bug-trigger.patch and it can be found in the queue-3.18 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 46eb14a6e1585d99c1b9f58d0e7389082a5f466b Mon Sep 17 00:00:00 2001 From: Pete Zaitcev <zaitcev(a)redhat.com> Date: Mon, 8 Jan 2018 15:46:41 -0600 Subject: USB: fix usbmon BUG trigger From: Pete Zaitcev <zaitcev(a)redhat.com> commit 46eb14a6e1585d99c1b9f58d0e7389082a5f466b upstream. Automated tests triggered this by opening usbmon and accessing the mmap while simultaneously resizing the buffers. This bug was with us since 2006, because typically applications only size the buffers once and thus avoid racing. Reported by Kirill A. Shutemov. Reported-by: <syzbot+f9831b881b3e849829fc(a)syzkaller.appspotmail.com> Signed-off-by: Pete Zaitcev <zaitcev(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/mon/mon_bin.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/drivers/usb/mon/mon_bin.c +++ b/drivers/usb/mon/mon_bin.c @@ -1000,7 +1000,9 @@ static long mon_bin_ioctl(struct file *f break; case MON_IOCQ_RING_SIZE: + mutex_lock(&rp->fetch_lock); ret = rp->b_size; + mutex_unlock(&rp->fetch_lock); break; case MON_IOCT_RING_SIZE: @@ -1227,12 +1229,16 @@ static int mon_bin_vma_fault(struct vm_a unsigned long offset, chunk_idx; struct page *pageptr; + mutex_lock(&rp->fetch_lock); offset = vmf->pgoff << PAGE_SHIFT; - if (offset >= rp->b_size) + if (offset >= rp->b_size) { + mutex_unlock(&rp->fetch_lock); return VM_FAULT_SIGBUS; + } chunk_idx = offset / CHUNK_SIZE; pageptr = rp->b_vec[chunk_idx].pg; get_page(pageptr); + mutex_unlock(&rp->fetch_lock); vmf->page = pageptr; return 0; } Patches currently in stable-queue which might be from zaitcev(a)redhat.com are queue-3.18/usb-fix-usbmon-bug-trigger.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl to the 3.18-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: staging-android-ashmem-fix-a-race-condition-in-ashmem_set_size-ioctl.patch and it can be found in the queue-3.18 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 443064cb0b1fb4569fe0a71209da7625129fb760 Mon Sep 17 00:00:00 2001 From: Viktor Slavkovic <viktors(a)google.com> Date: Mon, 8 Jan 2018 10:43:03 -0800 Subject: staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl From: Viktor Slavkovic <viktors(a)google.com> commit 443064cb0b1fb4569fe0a71209da7625129fb760 upstream. A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a race condition when mmap is called. After the !asma->file check, before setting asma->size, asma->file can be set in mmap. That would result in having different asma->size than the mapped memory size. Combined with ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory corruption. Signed-off-by: Viktor Slavkovic <viktors(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/android/ashmem.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -759,10 +759,12 @@ static long ashmem_ioctl(struct file *fi break; case ASHMEM_SET_SIZE: ret = -EINVAL; + mutex_lock(&ashmem_mutex); if (!asma->file) { ret = 0; asma->size = (size_t) arg; } + mutex_unlock(&ashmem_mutex); break; case ASHMEM_GET_SIZE: ret = asma->size; Patches currently in stable-queue which might be from viktors(a)google.com are queue-3.18/staging-android-ashmem-fix-a-race-condition-in-ashmem_set_size-ioctl.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] USB: UDC core: fix double-free in usb_add_gadget_udc_release" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 7ae2c3c280db183ca9ada2675c34ec2f7378abfa Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 3 Jan 2018 12:51:51 -0500 Subject: [PATCH] USB: UDC core: fix double-free in usb_add_gadget_udc_release The error-handling pathways in usb_add_gadget_udc_release() are messed up. Aside from the uninformative statement labels, they can deallocate the udc structure after calling put_device(), which is a double-free. This was observed by KASAN in automatic testing. This patch cleans up the routine. It preserves the requirement that when any failure occurs, we call put_device(&gadget->dev). Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> CC: <stable(a)vger.kernel.org> Reviewed-by: Peter Chen <peter.chen(a)nxp.com> Acked-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index 93eff7dec2f5..1b3efb14aec7 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -1147,11 +1147,7 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget, udc = kzalloc(sizeof(*udc), GFP_KERNEL); if (!udc) - goto err1; - - ret = device_add(&gadget->dev); - if (ret) - goto err2; + goto err_put_gadget; device_initialize(&udc->dev); udc->dev.release = usb_udc_release; @@ -1160,7 +1156,11 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget, udc->dev.parent = parent; ret = dev_set_name(&udc->dev, "%s", kobject_name(&parent->kobj)); if (ret) - goto err3; + goto err_put_udc; + + ret = device_add(&gadget->dev); + if (ret) + goto err_put_udc; udc->gadget = gadget; gadget->udc = udc; @@ -1170,7 +1170,7 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget, ret = device_add(&udc->dev); if (ret) - goto err4; + goto err_unlist_udc; usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED); udc->vbus = true; @@ -1178,27 +1178,25 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget, /* pick up one of pending gadget drivers */ ret = check_pending_gadget_drivers(udc); if (ret) - goto err5; + goto err_del_udc; mutex_unlock(&udc_lock); return 0; -err5: + err_del_udc: device_del(&udc->dev); -err4: + err_unlist_udc: list_del(&udc->list); mutex_unlock(&udc_lock); -err3: - put_device(&udc->dev); device_del(&gadget->dev); -err2: - kfree(udc); + err_put_udc: + put_device(&udc->dev); -err1: + err_put_gadget: put_device(&gadget->dev); return ret; }

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Yet another KPTI regression with 4.14.x series in a VM

by Laura Abbott

Hi, Fedora got a bug report on 4.14.11 of a panic when booting a Fedora guest in a CentOS 6 VM, not reproducible with nopti. The issue is still present as of 4.14.13 as well. The only report is a panic screenshot https://bugzilla.redhat.com/show_bug.cgi?id=1532458 I've lost track of all the fixes that have been flying around, is this a new issue or has a fix not yet made it to stable? Thanks, Laura

7 years, 5 months

6
11
0 0

[Linux-stable-mirror] [PATCH 4.4-stable 0/6] bpf: prevent out-of-bounds speculation

by Jiri Slaby

Hi, this is a backport of these patches which I did for our kernels: c237ee5eb33b bpf: add bpf_patch_insn_single helper 3df126f35f88 bpf: don't (ab)use instructions to store state e245c5c6a565 bpf: move fixup_bpf_calls() function 79741b3bdec0 bpf: refactor fixup_bpf_calls() 8041902dae52 bpf: adjust insn_aux_data when patching insns b2157399cc98 bpf: prevent out-of-bounds speculation I offer it here for use in stable 4.4, if there is no better/simpler backport available yet. Alexei Starovoitov (4): bpf: move fixup_bpf_calls() function bpf: refactor fixup_bpf_calls() bpf: adjust insn_aux_data when patching insns bpf: prevent out-of-bounds speculation Daniel Borkmann (1): bpf: add bpf_patch_insn_single helper Jakub Kicinski (1): bpf: don't (ab)use instructions to store state include/linux/bpf.h | 2 + include/linux/filter.h | 3 + kernel/bpf/arraymap.c | 24 ++++-- kernel/bpf/core.c | 71 ++++++++++++++++ kernel/bpf/syscall.c | 54 ------------ kernel/bpf/verifier.c | 217 +++++++++++++++++++++++++++++++++++-------------- 6 files changed, 252 insertions(+), 119 deletions(-) -- 2.15.1

7 years, 5 months

5
11
0 0

[Linux-stable-mirror] Patch "bpf: prevent out-of-bounds speculation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: prevent out-of-bounds speculation to the 4.9-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: bpf-prevent-out-of-bounds-speculation.patch and it can be found in the queue-4.9 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 b2157399cc9898260d6031c5bfe45fe137c1fbe7 Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)kernel.org> Date: Sun, 7 Jan 2018 17:33:02 -0800 Subject: bpf: prevent out-of-bounds speculation From: Alexei Starovoitov <ast(a)kernel.org> commit b2157399cc9898260d6031c5bfe45fe137c1fbe7 upstream. Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. To avoid leaking kernel data round up array-based maps and mask the index after bounds check, so speculated load with out of bounds index will load either valid value from the array or zero from the padded area. Unconditionally mask index for all array types even when max_entries are not rounded to power of 2 for root user. When map is created by unpriv user generate a sequence of bpf insns that includes AND operation to make sure that JITed code includes the same 'index & index_mask' operation. If prog_array map is created by unpriv user replace bpf_tail_call(ctx, map, index); with if (index >= max_entries) { index &= map->index_mask; bpf_tail_call(ctx, map, index); } (along with roundup to power 2) to prevent out-of-bounds speculation. There is secondary redundant 'if (index >= max_entries)' in the interpreter and in all JITs, but they can be optimized later if necessary. Other array-like maps (cpumap, devmap, sockmap, perf_event_array, cgroup_array) cannot be used by unpriv, so no changes there. That fixes bpf side of "Variant 1: bounds check bypass (CVE-2017-5753)" on all architectures with and without JIT. v2->v3: Daniel noticed that attack potentially can be crafted via syscall commands without loading the program, so add masking to those paths as well. Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Jiri Slaby <jslaby(a)suse.cz> [ Backported to 4.9 - gregkh ] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/bpf.h | 2 ++ include/linux/bpf_verifier.h | 5 ++++- kernel/bpf/arraymap.c | 31 ++++++++++++++++++++++--------- kernel/bpf/verifier.c | 42 +++++++++++++++++++++++++++++++++++++++--- 4 files changed, 67 insertions(+), 13 deletions(-) --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -43,6 +43,7 @@ struct bpf_map { u32 max_entries; u32 map_flags; u32 pages; + bool unpriv_array; struct user_struct *user; const struct bpf_map_ops *ops; struct work_struct work; @@ -189,6 +190,7 @@ struct bpf_prog_aux { struct bpf_array { struct bpf_map map; u32 elem_size; + u32 index_mask; /* 'ownership' of prog_array is claimed by the first program that * is going to use this map or by the first program which FD is stored * in the map to make sure that all callers and callees have the same --- a/include/linux/bpf_verifier.h +++ b/include/linux/bpf_verifier.h @@ -67,7 +67,10 @@ struct bpf_verifier_state_list { }; struct bpf_insn_aux_data { - enum bpf_reg_type ptr_type; /* pointer type for load/store insns */ + union { + enum bpf_reg_type ptr_type; /* pointer type for load/store insns */ + struct bpf_map *map_ptr; /* pointer for call insn into lookup_elem */ + }; bool seen; /* this insn was processed by the verifier */ }; --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -46,9 +46,10 @@ static int bpf_array_alloc_percpu(struct static struct bpf_map *array_map_alloc(union bpf_attr *attr) { bool percpu = attr->map_type == BPF_MAP_TYPE_PERCPU_ARRAY; + u32 elem_size, index_mask, max_entries; + bool unpriv = !capable(CAP_SYS_ADMIN); struct bpf_array *array; u64 array_size; - u32 elem_size; /* check sanity of attributes */ if (attr->max_entries == 0 || attr->key_size != 4 || @@ -63,11 +64,20 @@ static struct bpf_map *array_map_alloc(u elem_size = round_up(attr->value_size, 8); + max_entries = attr->max_entries; + index_mask = roundup_pow_of_two(max_entries) - 1; + + if (unpriv) + /* round up array size to nearest power of 2, + * since cpu will speculate within index_mask limits + */ + max_entries = index_mask + 1; + array_size = sizeof(*array); if (percpu) - array_size += (u64) attr->max_entries * sizeof(void *); + array_size += (u64) max_entries * sizeof(void *); else - array_size += (u64) attr->max_entries * elem_size; + array_size += (u64) max_entries * elem_size; /* make sure there is no u32 overflow later in round_up() */ if (array_size >= U32_MAX - PAGE_SIZE) @@ -77,6 +87,8 @@ static struct bpf_map *array_map_alloc(u array = bpf_map_area_alloc(array_size); if (!array) return ERR_PTR(-ENOMEM); + array->index_mask = index_mask; + array->map.unpriv_array = unpriv; /* copy mandatory map attributes */ array->map.map_type = attr->map_type; @@ -110,7 +122,7 @@ static void *array_map_lookup_elem(struc if (unlikely(index >= array->map.max_entries)) return NULL; - return array->value + array->elem_size * index; + return array->value + array->elem_size * (index & array->index_mask); } /* Called from eBPF program */ @@ -122,7 +134,7 @@ static void *percpu_array_map_lookup_ele if (unlikely(index >= array->map.max_entries)) return NULL; - return this_cpu_ptr(array->pptrs[index]); + return this_cpu_ptr(array->pptrs[index & array->index_mask]); } int bpf_percpu_array_copy(struct bpf_map *map, void *key, void *value) @@ -142,7 +154,7 @@ int bpf_percpu_array_copy(struct bpf_map */ size = round_up(map->value_size, 8); rcu_read_lock(); - pptr = array->pptrs[index]; + pptr = array->pptrs[index & array->index_mask]; for_each_possible_cpu(cpu) { bpf_long_memcpy(value + off, per_cpu_ptr(pptr, cpu), size); off += size; @@ -190,10 +202,11 @@ static int array_map_update_elem(struct return -EEXIST; if (array->map.map_type == BPF_MAP_TYPE_PERCPU_ARRAY) - memcpy(this_cpu_ptr(array->pptrs[index]), + memcpy(this_cpu_ptr(array->pptrs[index & array->index_mask]), value, map->value_size); else - memcpy(array->value + array->elem_size * index, + memcpy(array->value + + array->elem_size * (index & array->index_mask), value, map->value_size); return 0; } @@ -227,7 +240,7 @@ int bpf_percpu_array_update(struct bpf_m */ size = round_up(map->value_size, 8); rcu_read_lock(); - pptr = array->pptrs[index]; + pptr = array->pptrs[index & array->index_mask]; for_each_possible_cpu(cpu) { bpf_long_memcpy(per_cpu_ptr(pptr, cpu), value + off, size); off += size; --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -1187,7 +1187,7 @@ static void clear_all_pkt_pointers(struc } } -static int check_call(struct bpf_verifier_env *env, int func_id) +static int check_call(struct bpf_verifier_env *env, int func_id, int insn_idx) { struct bpf_verifier_state *state = &env->cur_state; const struct bpf_func_proto *fn = NULL; @@ -1238,6 +1238,13 @@ static int check_call(struct bpf_verifie err = check_func_arg(env, BPF_REG_2, fn->arg2_type, &meta); if (err) return err; + if (func_id == BPF_FUNC_tail_call) { + if (meta.map_ptr == NULL) { + verbose("verifier bug\n"); + return -EINVAL; + } + env->insn_aux_data[insn_idx].map_ptr = meta.map_ptr; + } err = check_func_arg(env, BPF_REG_3, fn->arg3_type, &meta); if (err) return err; @@ -3019,7 +3026,7 @@ static int do_check(struct bpf_verifier_ return -EINVAL; } - err = check_call(env, insn->imm); + err = check_call(env, insn->imm, insn_idx); if (err) return err; @@ -3372,7 +3379,11 @@ static int fixup_bpf_calls(struct bpf_ve struct bpf_insn *insn = prog->insnsi; const struct bpf_func_proto *fn; const int insn_cnt = prog->len; - int i; + struct bpf_insn insn_buf[16]; + struct bpf_prog *new_prog; + struct bpf_map *map_ptr; + int i, cnt, delta = 0; + for (i = 0; i < insn_cnt; i++, insn++) { if (insn->code != (BPF_JMP | BPF_CALL)) @@ -3390,6 +3401,31 @@ static int fixup_bpf_calls(struct bpf_ve */ insn->imm = 0; insn->code |= BPF_X; + + /* instead of changing every JIT dealing with tail_call + * emit two extra insns: + * if (index >= max_entries) goto out; + * index &= array->index_mask; + * to avoid out-of-bounds cpu speculation + */ + map_ptr = env->insn_aux_data[i + delta].map_ptr; + if (!map_ptr->unpriv_array) + continue; + insn_buf[0] = BPF_JMP_IMM(BPF_JGE, BPF_REG_3, + map_ptr->max_entries, 2); + insn_buf[1] = BPF_ALU32_IMM(BPF_AND, BPF_REG_3, + container_of(map_ptr, + struct bpf_array, + map)->index_mask); + insn_buf[2] = *insn; + cnt = 3; + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); + if (!new_prog) + return -ENOMEM; + + delta += cnt - 1; + env->prog = prog = new_prog; + insn = new_prog->insnsi + i + delta; continue; } Patches currently in stable-queue which might be from ast(a)kernel.org are queue-4.9/bpf-refactor-fixup_bpf_calls.patch queue-4.9/bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch queue-4.9/bpf-prevent-out-of-bounds-speculation.patch queue-4.9/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf, array: fix overflow in max_entries and undefined behavior in index_mask" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf, array: fix overflow in max_entries and undefined behavior in index_mask to the 4.9-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: bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch and it can be found in the queue-4.9 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 bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 10 Jan 2018 23:25:05 +0100 Subject: bpf, array: fix overflow in max_entries and undefined behavior in index_mask From: Daniel Borkmann <daniel(a)iogearbox.net> commit bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1 upstream. syzkaller tried to alloc a map with 0xfffffffd entries out of a userns, and thus unprivileged. With the recently added logic in b2157399cc98 ("bpf: prevent out-of-bounds speculation") we round this up to the next power of two value for max_entries for unprivileged such that we can apply proper masking into potentially zeroed out map slots. However, this will generate an index_mask of 0xffffffff, and therefore a + 1 will let this overflow into new max_entries of 0. This will pass allocation, etc, and later on map access we still enforce on the original attr->max_entries value which was 0xfffffffd, therefore triggering GPF all over the place. Thus bail out on overflow in such case. Moreover, on 32 bit archs roundup_pow_of_two() can also not be used, since fls_long(max_entries - 1) can result in 32 and 1UL << 32 in 32 bit space is undefined. Therefore, do this by hand in a 64 bit variable. This fixes all the issues triggered by syzkaller's reproducers. Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation") Reported-by: syzbot+b0efb8e572d01bce1ae0(a)syzkaller.appspotmail.com Reported-by: syzbot+6c15e9744f75f2364773(a)syzkaller.appspotmail.com Reported-by: syzbot+d2f5524fb46fd3b312ee(a)syzkaller.appspotmail.com Reported-by: syzbot+61d23c95395cc90dbc2b(a)syzkaller.appspotmail.com Reported-by: syzbot+0d363c942452cca68c01(a)syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/arraymap.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -49,7 +49,7 @@ static struct bpf_map *array_map_alloc(u u32 elem_size, index_mask, max_entries; bool unpriv = !capable(CAP_SYS_ADMIN); struct bpf_array *array; - u64 array_size; + u64 array_size, mask64; /* check sanity of attributes */ if (attr->max_entries == 0 || attr->key_size != 4 || @@ -65,13 +65,25 @@ static struct bpf_map *array_map_alloc(u elem_size = round_up(attr->value_size, 8); max_entries = attr->max_entries; - index_mask = roundup_pow_of_two(max_entries) - 1; - if (unpriv) + /* On 32 bit archs roundup_pow_of_two() with max_entries that has + * upper most bit set in u32 space is undefined behavior due to + * resulting 1U << 32, so do it manually here in u64 space. + */ + mask64 = fls_long(max_entries - 1); + mask64 = 1ULL << mask64; + mask64 -= 1; + + index_mask = mask64; + if (unpriv) { /* round up array size to nearest power of 2, * since cpu will speculate within index_mask limits */ max_entries = index_mask + 1; + /* Check for overflows. */ + if (max_entries < attr->max_entries) + return ERR_PTR(-E2BIG); + } array_size = sizeof(*array); if (percpu) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.9/bpf-refactor-fixup_bpf_calls.patch queue-4.9/bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch queue-4.9/bpf-prevent-out-of-bounds-speculation.patch queue-4.9/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo

by Kirill A. Shutemov

Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '&mem_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") Cc: stable(a)vger.kernel.org Acked-by: Baoquan He <bhe(a)redhat.com> Acked-by: Dave Young <dyoung(a)redhat.com> --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index 06097ef30449..b511f6d24b42 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name) +#define VMCOREINFO_SYMBOL_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index b3663896278e..4f63597c824d 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_SYMBOL_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); -- 2.15.1

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] Patch "[PATCH] Revert "can: kvaser_usb: free buf in error paths"" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [PATCH] Revert "can: kvaser_usb: free buf in error paths" to the 3.18-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: revert-can-kvaser_usb-free-buf-in-error-paths.patch and it can be found in the queue-3.18 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 66d409a60bcf1504ba6f0021cd0be58d93491197 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Sat, 13 Jan 2018 18:45:25 +0100 Subject: [PATCH] Revert "can: kvaser_usb: free buf in error paths" From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> This reverts commit 70d9dccf50152b0d7bfb2697d8c51e9fab9f782c which was commit 435019b48033138581a6171093b181fc6b4d3d30 upstream. Jimmy Assarsson asks that it be reverted as it's not correct there. Reported-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com> Cc: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/usb/kvaser_usb.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/net/can/usb/kvaser_usb.c +++ b/drivers/net/can/usb/kvaser_usb.c @@ -602,7 +602,6 @@ static int kvaser_usb_simple_msg_async(s if (err) { netdev_err(netdev, "Error transmitting URB\n"); usb_unanchor_urb(urb); - kfree(buf); usb_free_urb(urb); kfree(buf); return err; @@ -1389,7 +1388,6 @@ static netdev_tx_t kvaser_usb_start_xmit atomic_dec(&priv->active_tx_urbs); usb_unanchor_urb(urb); - kfree(buf); stats->tx_dropped++; Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-3.18/kvm-vmx-scrub-hardware-gprs-at-vm-exit.patch queue-3.18/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-3.18/8021q-fix-a-memory-leak-for-vlan-0-device.patch queue-3.18/crypto-n2-cure-use-after-free.patch queue-3.18/kernel-signal.c-remove-the-no-longer-needed-signal_unkillable-check-in-complete_signal.patch queue-3.18/x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch queue-3.18/kernel-signal.c-protect-the-signal_unkillable-tasks-from-sig_kernel_only-signals.patch queue-3.18/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch queue-3.18/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-3.18/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch queue-3.18/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-3.18/ib-srpt-disable-rdma-access-by-the-initiator.patch queue-3.18/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-3.18/fscache-fix-the-default-for-fscache_maybe_release_page.patch queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-3.18/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-3.18/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-3.18/rds-heap-oob-write-in-rds_message_alloc_sgs.patch queue-3.18/can-gs_usb-fix-return-value-of-the-set_bittiming-callback.patch queue-3.18/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch queue-3.18/kernel-acct.c-fix-the-acct-needcheck-check-in-check_free_space.patch queue-3.18/sh_eth-fix-sh7757-gether-initialization.patch queue-3.18/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch queue-3.18/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch queue-3.18/revert-can-kvaser_usb-free-buf-in-error-paths.patch queue-3.18/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch queue-3.18/input-elantech-add-new-icbody-type-15.patch queue-3.18/kernel-signal.c-protect-the-traced-signal_unkillable-tasks-from-sigkill.patch queue-3.18/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch queue-3.18/perf-core-fix-concurrent-sys_perf_event_open-vs.-move_group-race.patch queue-3.18/sh_eth-fix-tsu-resource-handling.patch queue-3.18/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch queue-3.18/x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch queue-3.18/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch queue-3.18/alsa-aloop-fix-racy-hw-constraints-adjustment.patch queue-3.18/alsa-aloop-release-cable-upon-open-error-path.patch queue-3.18/crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3.18 v2 0/5] MIPS: NT_PRFPREG regset handling fixes

by Maciej W. Rozycki

Hi, This is a repost of my recent 3.18 backports of NT_PRFPREG regset handling fixes, sent as a series for patch ordering clarity. I've added `v2' annotation for patch management purposes, retaining original headings. The patches themselves are unchanged. Maciej

7 years, 5 months

2
6
0 0

[Linux-stable-mirror] Patch "MIPS: Guard against any partial write attempt with PTRACE_SETREGSET" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Guard against any partial write attempt with PTRACE_SETREGSET to the 3.18-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: mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch and it can be found in the queue-3.18 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 dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:52:15 +0000 Subject: MIPS: Guard against any partial write attempt with PTRACE_SETREGSET From: Maciej W. Rozycki <macro(a)mips.com> commit dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 upstream. Complement commit d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") and ensure that no partial register write attempt is made with PTRACE_SETREGSET, as we do not preinitialize any temporaries used to hold incoming register data and consequently random data could be written. It is the responsibility of the caller, such as `ptrace_regset', to arrange for writes to span whole registers only, so here we only assert that it has indeed happened. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: James Hogan <james.hogan(a)mips.com> Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Alex Smith <alex(a)alex-smith.me.uk> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17926/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -497,7 +497,15 @@ static int fpr_set_msa(struct task_struc return 0; } -/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */ +/* + * Copy the supplied NT_PRFPREG buffer to the floating-point context. + * + * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0', + * which is supposed to have been guaranteed by the kernel before + * calling us, e.g. in `ptrace_regset'. We enforce that requirement, + * so that we can safely avoid preinitializing temporaries for + * partial register writes. + */ static int fpr_set(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, @@ -505,6 +513,8 @@ static int fpr_set(struct task_struct *t { int err; + BUG_ON(count % sizeof(elf_fpreg_t)); + /* XXX fcr31 */ if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) Patches currently in stable-queue which might be from macro(a)mips.com are queue-3.18/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-3.18/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-3.18/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-3.18/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-3.18/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA to the 3.18-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: mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch and it can be found in the queue-3.18 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 be07a6a1188372b6d19a3307ec33211fc9c9439d Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:54:33 +0000 Subject: MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA From: Maciej W. Rozycki <macro(a)mips.com> commit be07a6a1188372b6d19a3307ec33211fc9c9439d upstream. Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") public API regression, then activated by commit 1db1af84d6df ("MIPS: Basic MSA context switching support"), that caused the FCSR register not to be read or written for CONFIG_CPU_HAS_MSA kernel configurations (regardless of actual presence or absence of the MSA feature in a given processor) with ptrace(2) PTRACE_GETREGSET and PTRACE_SETREGSET requests nor recorded in core dumps. This is because with !CONFIG_CPU_HAS_MSA configurations the whole of `elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA configurations array elements are copied individually, and then only the leading 32 FGR slots while the remaining slot is ignored. Correct the code then such that only FGR slots are copied in the respective !MSA and MSA helpers an then the FCSR slot is handled separately in common code. Use `ptrace_setfcr31' to update the FCSR too, so that the read-only mask is respected. Retrieving a correct value of FCSR is important in debugging not only for the human to be able to get the right interpretation of the situation, but for correct operation of GDB as well. This is because the condition code bits in FSCR are used by GDB to determine the location to place a breakpoint at when single-stepping through an FPU branch instruction. If such a breakpoint is placed incorrectly (i.e. with the condition reversed), then it will be missed, likely causing the debuggee to run away from the control of GDB and consequently breaking the process of investigation. Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2) request which is unaffected, so the regression only really hits with post-mortem debug sessions using a core dump file, in which case execution, and consequently single-stepping through branches is not possible. Of course core files created by buggy kernels out there will have the value of FCSR recorded clobbered, but such core files cannot be corrected and the person using them simply will have to be aware that the value of FCSR retrieved is not reliable. Which also means we can likely get away without defining a replacement API which would ensure a correct value of FSCR to be retrieved, or none at all. This is based on previous work by Alex Smith, extensively rewritten. Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk> Signed-off-by: James Hogan <james.hogan(a)mips.com> Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17928/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 47 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 11 deletions(-) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -403,7 +403,7 @@ static int gpr64_set(struct task_struct /* * Copy the floating-point context to the supplied NT_PRFPREG buffer, * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots - * correspond 1:1 to buffer slots. + * correspond 1:1 to buffer slots. Only general registers are copied. */ static int fpr_get_fpa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -411,13 +411,14 @@ static int fpr_get_fpa(struct task_struc { return user_regset_copyout(pos, count, kbuf, ubuf, &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); + 0, NUM_FPU_REGS * sizeof(elf_fpreg_t)); } /* * Copy the floating-point context to the supplied NT_PRFPREG buffer, * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's - * general register slots are copied to buffer slots. + * general register slots are copied to buffer slots. Only general + * registers are copied. */ static int fpr_get_msa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -439,20 +440,29 @@ static int fpr_get_msa(struct task_struc return 0; } -/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */ +/* + * Copy the floating-point context to the supplied NT_PRFPREG buffer. + * Choose the appropriate helper for general registers, and then copy + * the FCSR register separately. + */ static int fpr_get(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, void *kbuf, void __user *ubuf) { + const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t); int err; - /* XXX fcr31 */ - if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf); else err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf); + if (err) + return err; + + err = user_regset_copyout(&pos, &count, &kbuf, &ubuf, + &target->thread.fpu.fcr31, + fcr31_pos, fcr31_pos + sizeof(u32)); return err; } @@ -460,7 +470,7 @@ static int fpr_get(struct task_struct *t /* * Copy the supplied NT_PRFPREG buffer to the floating-point context, * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP - * context's general register slots. + * context's general register slots. Only general registers are copied. */ static int fpr_set_fpa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -468,13 +478,14 @@ static int fpr_set_fpa(struct task_struc { return user_regset_copyin(pos, count, kbuf, ubuf, &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); + 0, NUM_FPU_REGS * sizeof(elf_fpreg_t)); } /* * Copy the supplied NT_PRFPREG buffer to the floating-point context, * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64 - * bits only of FP context's general register slots. + * bits only of FP context's general register slots. Only general + * registers are copied. */ static int fpr_set_msa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -499,6 +510,8 @@ static int fpr_set_msa(struct task_struc /* * Copy the supplied NT_PRFPREG buffer to the floating-point context. + * Choose the appropriate helper for general registers, and then copy + * the FCSR register separately. * * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0', * which is supposed to have been guaranteed by the kernel before @@ -511,16 +524,28 @@ static int fpr_set(struct task_struct *t unsigned int pos, unsigned int count, const void *kbuf, const void __user *ubuf) { + const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t); + u32 fcr31; int err; BUG_ON(count % sizeof(elf_fpreg_t)); - /* XXX fcr31 */ - if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf); else err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf); + if (err) + return err; + + if (count > 0) { + err = user_regset_copyin(&pos, &count, &kbuf, &ubuf, + &fcr31, + fcr31_pos, fcr31_pos + sizeof(u32)); + if (err) + return err; + + target->thread.fpu.fcr31 = fcr31 & ~FPU_CSR_ALL_X; + } return err; } Patches currently in stable-queue which might be from macro(a)mips.com are queue-3.18/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-3.18/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-3.18/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-3.18/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-3.18/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Factor out NT_PRFPREG regset access helpers" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Factor out NT_PRFPREG regset access helpers to the 3.18-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: mips-factor-out-nt_prfpreg-regset-access-helpers.patch and it can be found in the queue-3.18 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 a03fe72572c12e98f4173f8a535f32468e48b6ec Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:51:35 +0000 Subject: MIPS: Factor out NT_PRFPREG regset access helpers From: Maciej W. Rozycki <macro(a)mips.com> commit a03fe72572c12e98f4173f8a535f32468e48b6ec upstream. In preparation to fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") FCSR access regression factor out NT_PRFPREG regset access helpers for the non-MSA and the MSA variants respectively, to avoid having to deal with excessive indentation in the actual fix. No functional change, however use `target->thread.fpu.fpr[0]' rather than `target->thread.fpu.fpr[i]' for FGR holding type size determination as there's no `i' variable to refer to anymore, and for the factored out `i' variable declaration use `unsigned int' rather than `unsigned' as its type, following the common style. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: James Hogan <james.hogan(a)mips.com> Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Alex Smith <alex(a)alex-smith.me.uk> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17925/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 106 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 82 insertions(+), 24 deletions(-) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -400,25 +400,36 @@ static int gpr64_set(struct task_struct #endif /* CONFIG_64BIT */ -static int fpr_get(struct task_struct *target, - const struct user_regset *regset, - unsigned int pos, unsigned int count, - void *kbuf, void __user *ubuf) +/* + * Copy the floating-point context to the supplied NT_PRFPREG buffer, + * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots + * correspond 1:1 to buffer slots. + */ +static int fpr_get_fpa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + void **kbuf, void __user **ubuf) { - unsigned i; - int err; - u64 fpr_val; - - /* XXX fcr31 */ + return user_regset_copyout(pos, count, kbuf, ubuf, + &target->thread.fpu, + 0, sizeof(elf_fpregset_t)); +} - if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t)) - return user_regset_copyout(&pos, &count, &kbuf, &ubuf, - &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); +/* + * Copy the floating-point context to the supplied NT_PRFPREG buffer, + * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's + * general register slots are copied to buffer slots. + */ +static int fpr_get_msa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + void **kbuf, void __user **ubuf) +{ + unsigned int i; + u64 fpr_val; + int err; for (i = 0; i < NUM_FPU_REGS; i++) { fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0); - err = user_regset_copyout(&pos, &count, &kbuf, &ubuf, + err = user_regset_copyout(pos, count, kbuf, ubuf, &fpr_val, i * sizeof(elf_fpreg_t), (i + 1) * sizeof(elf_fpreg_t)); if (err) @@ -428,25 +439,54 @@ static int fpr_get(struct task_struct *t return 0; } -static int fpr_set(struct task_struct *target, +/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */ +static int fpr_get(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, - const void *kbuf, const void __user *ubuf) + void *kbuf, void __user *ubuf) { - unsigned i; int err; - u64 fpr_val; /* XXX fcr31 */ - if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t)) - return user_regset_copyin(&pos, &count, &kbuf, &ubuf, - &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); + if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) + err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf); + else + err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf); + + return err; +} + +/* + * Copy the supplied NT_PRFPREG buffer to the floating-point context, + * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP + * context's general register slots. + */ +static int fpr_set_fpa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + const void **kbuf, const void __user **ubuf) +{ + return user_regset_copyin(pos, count, kbuf, ubuf, + &target->thread.fpu, + 0, sizeof(elf_fpregset_t)); +} + +/* + * Copy the supplied NT_PRFPREG buffer to the floating-point context, + * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64 + * bits only of FP context's general register slots. + */ +static int fpr_set_msa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + const void **kbuf, const void __user **ubuf) +{ + unsigned int i; + u64 fpr_val; + int err; BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t)); - for (i = 0; i < NUM_FPU_REGS && count >= sizeof(elf_fpreg_t); i++) { - err = user_regset_copyin(&pos, &count, &kbuf, &ubuf, + for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) { + err = user_regset_copyin(pos, count, kbuf, ubuf, &fpr_val, i * sizeof(elf_fpreg_t), (i + 1) * sizeof(elf_fpreg_t)); if (err) @@ -457,6 +497,24 @@ static int fpr_set(struct task_struct *t return 0; } +/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */ +static int fpr_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int err; + + /* XXX fcr31 */ + + if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) + err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf); + else + err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf); + + return err; +} + enum mips_regset { REGSET_GPR, REGSET_FPR, Patches currently in stable-queue which might be from macro(a)mips.com are queue-3.18/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-3.18/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-3.18/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-3.18/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-3.18/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses to the 3.18-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: mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch and it can be found in the queue-3.18 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 c8c5a3a24d395b14447a9a89d61586a913840a3b Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:56:54 +0000 Subject: MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses From: Maciej W. Rozycki <macro(a)mips.com> commit c8c5a3a24d395b14447a9a89d61586a913840a3b upstream. Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout") and also reject outsized PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the NT_PRSTATUS regset. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout") Cc: James Hogan <james.hogan(a)mips.com> Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Alex Smith <alex(a)alex-smith.me.uk> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17930/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -530,6 +530,9 @@ static int fpr_set(struct task_struct *t BUG_ON(count % sizeof(elf_fpreg_t)); + if (pos + count > sizeof(elf_fpregset_t)) + return -EIO; + if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf); else Patches currently in stable-queue which might be from macro(a)mips.com are queue-3.18/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-3.18/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-3.18/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-3.18/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-3.18/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Consistently handle buffer counter with PTRACE_SETREGSET" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Consistently handle buffer counter with PTRACE_SETREGSET to the 3.18-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: mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch and it can be found in the queue-3.18 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 80b3ffce0196ea50068885d085ff981e4b8396f4 Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:53:14 +0000 Subject: MIPS: Consistently handle buffer counter with PTRACE_SETREGSET From: Maciej W. Rozycki <macro(a)mips.com> commit 80b3ffce0196ea50068885d085ff981e4b8396f4 upstream. Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") bug and consistently consume all data supplied to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that a zero data buffer counter is returned where insufficient data has been given to fill a whole number of FP general registers. In reality this is not going to happen, as the caller is supposed to only supply data covering a whole number of registers and it is verified in `ptrace_regset' and again asserted in `fpr_set', however structuring code such that the presence of trailing partial FP general register data causes `fpr_set_msa' to return with a non-zero data buffer counter makes it appear that this trailing data will be used if there are subsequent writes made to FP registers, which is going to be the case with the FCSR once the missing write to that register has been fixed. Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Cc: James Hogan <james.hogan(a)mips.com> Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Alex Smith <alex(a)alex-smith.me.uk> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v4.11+ Patchwork: https://patchwork.linux-mips.org/patch/17927/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -485,7 +485,7 @@ static int fpr_set_msa(struct task_struc int err; BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t)); - for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) { + for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) { err = user_regset_copyin(pos, count, kbuf, ubuf, &fpr_val, i * sizeof(elf_fpreg_t), (i + 1) * sizeof(elf_fpreg_t)); Patches currently in stable-queue which might be from macro(a)mips.com are queue-3.18/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-3.18/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-3.18/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-3.18/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-3.18/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-3.18/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK to the 4.9-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: target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch and it can be found in the queue-4.9 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 1c21a48055a67ceb693e9c2587824a8de60a217c Mon Sep 17 00:00:00 2001 From: Nicholas Bellinger <nab(a)linux-iscsi.org> Date: Fri, 27 Oct 2017 22:19:26 -0800 Subject: target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK From: Nicholas Bellinger <nab(a)linux-iscsi.org> commit 1c21a48055a67ceb693e9c2587824a8de60a217c upstream. This patch fixes bug where early se_cmd exceptions that occur before backend execution can result in use-after-free if/when a subsequent ABORT_TASK occurs for the same tag. Since an early se_cmd exception will have had se_cmd added to se_session->sess_cmd_list via target_get_sess_cmd(), it will not have CMD_T_COMPLETE set by the usual target_complete_cmd() backend completion path. This causes a subsequent ABORT_TASK + __target_check_io_state() to signal ABORT_TASK should proceed. As core_tmr_abort_task() executes, it will bring the outstanding se_cmd->cmd_kref count down to zero releasing se_cmd, after se_cmd has already been queued with error status into fabric driver response path code. To address this bug, introduce a CMD_T_PRE_EXECUTE bit that is set at target_get_sess_cmd() time, and cleared immediately before backend driver dispatch in target_execute_cmd() once CMD_T_ACTIVE is set. Then, check CMD_T_PRE_EXECUTE within __target_check_io_state() to determine when an early exception has occured, and avoid aborting this se_cmd since it will have already been queued into fabric driver response path code. Reported-by: Donald White <dew(a)datera.io> Cc: Donald White <dew(a)datera.io> Cc: Mike Christie <mchristi(a)redhat.com> Cc: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 3 files changed, 12 insertions(+) --- a/drivers/target/target_core_tmr.c +++ b/drivers/target/target_core_tmr.c @@ -133,6 +133,15 @@ static bool __target_check_io_state(stru spin_unlock(&se_cmd->t_state_lock); return false; } + if (se_cmd->transport_state & CMD_T_PRE_EXECUTE) { + if (se_cmd->scsi_status) { + pr_debug("Attempted to abort io tag: %llu early failure" + " status: 0x%02x\n", se_cmd->tag, + se_cmd->scsi_status); + spin_unlock(&se_cmd->t_state_lock); + return false; + } + } if (sess->sess_tearing_down || se_cmd->cmd_wait_set) { pr_debug("Attempted to abort io tag: %llu already shutdown," " skipping\n", se_cmd->tag); --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -1939,6 +1939,7 @@ void target_execute_cmd(struct se_cmd *c } cmd->t_state = TRANSPORT_PROCESSING; + cmd->transport_state &= ~CMD_T_PRE_EXECUTE; cmd->transport_state |= CMD_T_ACTIVE|CMD_T_BUSY|CMD_T_SENT; spin_unlock_irq(&cmd->t_state_lock); @@ -2592,6 +2593,7 @@ int target_get_sess_cmd(struct se_cmd *s ret = -ESHUTDOWN; goto out; } + se_cmd->transport_state |= CMD_T_PRE_EXECUTE; list_add_tail(&se_cmd->se_cmd_list, &se_sess->sess_cmd_list); out: spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags); --- a/include/target/target_core_base.h +++ b/include/target/target_core_base.h @@ -493,6 +493,7 @@ struct se_cmd { #define CMD_T_BUSY (1 << 9) #define CMD_T_TAS (1 << 10) #define CMD_T_FABRIC_STOP (1 << 11) +#define CMD_T_PRE_EXECUTE (1 << 12) spinlock_t t_state_lock; struct kref cmd_kref; struct completion t_transport_stop_comp; Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are queue-4.9/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-4.9/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref to the 4.9-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: iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch and it can be found in the queue-4.9 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 ae072726f6109bb1c94841d6fb3a82dde298ea85 Mon Sep 17 00:00:00 2001 From: Nicholas Bellinger <nab(a)linux-iscsi.org> Date: Fri, 27 Oct 2017 12:32:59 -0700 Subject: iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref From: Nicholas Bellinger <nab(a)linux-iscsi.org> commit ae072726f6109bb1c94841d6fb3a82dde298ea85 upstream. Since commit 59b6986dbf fixed a potential NULL pointer dereference by allocating a se_tmr_req for ISCSI_TM_FUNC_TASK_REASSIGN, the se_tmr_req is currently leaked by iscsit_free_cmd() because no iscsi_cmd->se_cmd.se_tfo was associated. To address this, treat ISCSI_TM_FUNC_TASK_REASSIGN like any other TMR and call transport_init_se_cmd() + target_get_sess_cmd() to setup iscsi_cmd->se_cmd.se_tfo with se_cmd->cmd_kref of 2. This will ensure normal release operation once se_cmd->cmd_kref reaches zero and target_release_cmd_kref() is invoked, se_tmr_req will be released via existing target_free_cmd_mem() and core_tmr_release_req() code. Reported-by: Donald White <dew(a)datera.io> Cc: Donald White <dew(a)datera.io> Cc: Mike Christie <mchristi(a)redhat.com> Cc: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -1940,7 +1940,6 @@ iscsit_handle_task_mgt_cmd(struct iscsi_ struct iscsi_tmr_req *tmr_req; struct iscsi_tm *hdr; int out_of_order_cmdsn = 0, ret; - bool sess_ref = false; u8 function, tcm_function = TMR_UNKNOWN; hdr = (struct iscsi_tm *) buf; @@ -1982,18 +1981,17 @@ iscsit_handle_task_mgt_cmd(struct iscsi_ buf); } + transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops, + conn->sess->se_sess, 0, DMA_NONE, + TCM_SIMPLE_TAG, cmd->sense_buffer + 2); + + target_get_sess_cmd(&cmd->se_cmd, true); + /* * TASK_REASSIGN for ERL=2 / connection stays inside of * LIO-Target $FABRIC_MOD */ if (function != ISCSI_TM_FUNC_TASK_REASSIGN) { - transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops, - conn->sess->se_sess, 0, DMA_NONE, - TCM_SIMPLE_TAG, cmd->sense_buffer + 2); - - target_get_sess_cmd(&cmd->se_cmd, true); - sess_ref = true; - switch (function) { case ISCSI_TM_FUNC_ABORT_TASK: tcm_function = TMR_ABORT_TASK; @@ -2132,12 +2130,8 @@ attach: * For connection recovery, this is also the default action for * TMR TASK_REASSIGN. */ - if (sess_ref) { - pr_debug("Handle TMR, using sess_ref=true check\n"); - target_put_sess_cmd(&cmd->se_cmd); - } - iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state); + target_put_sess_cmd(&cmd->se_cmd); return 0; } EXPORT_SYMBOL(iscsit_handle_task_mgt_cmd); Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are queue-4.9/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-4.9/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH-4.9.y 0/2] target: stable backports

by Nicholas A. Bellinger

From: Nicholas Bellinger <nab(a)linux-iscsi.org> Hi Greg-KH, Here are two target patches for v4.9.y stable, which did not apply due to minor context changes. The series has been cut against v4.9.76. Please apply at your earliest convenience. Thank you, --nab Nicholas Bellinger (2): iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK drivers/target/iscsi/iscsi_target.c | 20 +++++++------------- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 4 files changed, 19 insertions(+), 13 deletions(-) -- 1.8.5.3

7 years, 5 months

2
3
0 0

[Linux-stable-mirror] Patch "target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK to the 4.4-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: target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch and it can be found in the queue-4.4 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 1c21a48055a67ceb693e9c2587824a8de60a217c Mon Sep 17 00:00:00 2001 From: Nicholas Bellinger <nab(a)linux-iscsi.org> Date: Fri, 27 Oct 2017 22:19:26 -0800 Subject: target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK From: Nicholas Bellinger <nab(a)linux-iscsi.org> commit 1c21a48055a67ceb693e9c2587824a8de60a217c upstream. This patch fixes bug where early se_cmd exceptions that occur before backend execution can result in use-after-free if/when a subsequent ABORT_TASK occurs for the same tag. Since an early se_cmd exception will have had se_cmd added to se_session->sess_cmd_list via target_get_sess_cmd(), it will not have CMD_T_COMPLETE set by the usual target_complete_cmd() backend completion path. This causes a subsequent ABORT_TASK + __target_check_io_state() to signal ABORT_TASK should proceed. As core_tmr_abort_task() executes, it will bring the outstanding se_cmd->cmd_kref count down to zero releasing se_cmd, after se_cmd has already been queued with error status into fabric driver response path code. To address this bug, introduce a CMD_T_PRE_EXECUTE bit that is set at target_get_sess_cmd() time, and cleared immediately before backend driver dispatch in target_execute_cmd() once CMD_T_ACTIVE is set. Then, check CMD_T_PRE_EXECUTE within __target_check_io_state() to determine when an early exception has occured, and avoid aborting this se_cmd since it will have already been queued into fabric driver response path code. Reported-by: Donald White <dew(a)datera.io> Cc: Donald White <dew(a)datera.io> Cc: Mike Christie <mchristi(a)redhat.com> Cc: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 3 files changed, 12 insertions(+) --- a/drivers/target/target_core_tmr.c +++ b/drivers/target/target_core_tmr.c @@ -133,6 +133,15 @@ static bool __target_check_io_state(stru spin_unlock(&se_cmd->t_state_lock); return false; } + if (se_cmd->transport_state & CMD_T_PRE_EXECUTE) { + if (se_cmd->scsi_status) { + pr_debug("Attempted to abort io tag: %llu early failure" + " status: 0x%02x\n", se_cmd->tag, + se_cmd->scsi_status); + spin_unlock(&se_cmd->t_state_lock); + return false; + } + } if (sess->sess_tearing_down || se_cmd->cmd_wait_set) { pr_debug("Attempted to abort io tag: %llu already shutdown," " skipping\n", se_cmd->tag); --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -1933,6 +1933,7 @@ void target_execute_cmd(struct se_cmd *c } cmd->t_state = TRANSPORT_PROCESSING; + cmd->transport_state &= ~CMD_T_PRE_EXECUTE; cmd->transport_state |= CMD_T_ACTIVE|CMD_T_BUSY|CMD_T_SENT; spin_unlock_irq(&cmd->t_state_lock); @@ -2572,6 +2573,7 @@ int target_get_sess_cmd(struct se_cmd *s ret = -ESHUTDOWN; goto out; } + se_cmd->transport_state |= CMD_T_PRE_EXECUTE; list_add_tail(&se_cmd->se_cmd_list, &se_sess->sess_cmd_list); out: spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags); --- a/include/target/target_core_base.h +++ b/include/target/target_core_base.h @@ -496,6 +496,7 @@ struct se_cmd { #define CMD_T_BUSY (1 << 9) #define CMD_T_TAS (1 << 10) #define CMD_T_FABRIC_STOP (1 << 11) +#define CMD_T_PRE_EXECUTE (1 << 12) spinlock_t t_state_lock; struct kref cmd_kref; struct completion t_transport_stop_comp; Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are queue-4.4/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-4.4/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref to the 4.4-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: iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch and it can be found in the queue-4.4 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 ae072726f6109bb1c94841d6fb3a82dde298ea85 Mon Sep 17 00:00:00 2001 From: Nicholas Bellinger <nab(a)linux-iscsi.org> Date: Fri, 27 Oct 2017 12:32:59 -0700 Subject: iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref From: Nicholas Bellinger <nab(a)linux-iscsi.org> commit ae072726f6109bb1c94841d6fb3a82dde298ea85 upstream. Since commit 59b6986dbf fixed a potential NULL pointer dereference by allocating a se_tmr_req for ISCSI_TM_FUNC_TASK_REASSIGN, the se_tmr_req is currently leaked by iscsit_free_cmd() because no iscsi_cmd->se_cmd.se_tfo was associated. To address this, treat ISCSI_TM_FUNC_TASK_REASSIGN like any other TMR and call transport_init_se_cmd() + target_get_sess_cmd() to setup iscsi_cmd->se_cmd.se_tfo with se_cmd->cmd_kref of 2. This will ensure normal release operation once se_cmd->cmd_kref reaches zero and target_release_cmd_kref() is invoked, se_tmr_req will be released via existing target_free_cmd_mem() and core_tmr_release_req() code. Reported-by: Donald White <dew(a)datera.io> Cc: Donald White <dew(a)datera.io> Cc: Mike Christie <mchristi(a)redhat.com> Cc: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -1759,7 +1759,6 @@ iscsit_handle_task_mgt_cmd(struct iscsi_ struct iscsi_tmr_req *tmr_req; struct iscsi_tm *hdr; int out_of_order_cmdsn = 0, ret; - bool sess_ref = false; u8 function, tcm_function = TMR_UNKNOWN; hdr = (struct iscsi_tm *) buf; @@ -1801,18 +1800,17 @@ iscsit_handle_task_mgt_cmd(struct iscsi_ buf); } + transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops, + conn->sess->se_sess, 0, DMA_NONE, + TCM_SIMPLE_TAG, cmd->sense_buffer + 2); + + target_get_sess_cmd(&cmd->se_cmd, true); + /* * TASK_REASSIGN for ERL=2 / connection stays inside of * LIO-Target $FABRIC_MOD */ if (function != ISCSI_TM_FUNC_TASK_REASSIGN) { - transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops, - conn->sess->se_sess, 0, DMA_NONE, - TCM_SIMPLE_TAG, cmd->sense_buffer + 2); - - target_get_sess_cmd(&cmd->se_cmd, true); - sess_ref = true; - switch (function) { case ISCSI_TM_FUNC_ABORT_TASK: tcm_function = TMR_ABORT_TASK; @@ -1951,12 +1949,8 @@ attach: * For connection recovery, this is also the default action for * TMR TASK_REASSIGN. */ - if (sess_ref) { - pr_debug("Handle TMR, using sess_ref=true check\n"); - target_put_sess_cmd(&cmd->se_cmd); - } - iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state); + target_put_sess_cmd(&cmd->se_cmd); return 0; } EXPORT_SYMBOL(iscsit_handle_task_mgt_cmd); Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are queue-4.4/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-4.4/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH-4.4.y 0/2] target: stable backports

by Nicholas A. Bellinger

From: Nicholas Bellinger <nab(a)linux-iscsi.org> Hi Greg-KH, Here are two target patches for v4.4.y stable, which did not apply due to minor context changes. The series has been cut against v4.4.111. Please apply at your earliest convenience. Thank you, --nab Nicholas Bellinger (2): iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK drivers/target/iscsi/iscsi_target.c | 20 +++++++------------- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 4 files changed, 19 insertions(+), 13 deletions(-) -- 1.8.5.3

7 years, 5 months

2
3
0 0

[Linux-stable-mirror] [PATCH-3.18.y 0/2] target: stable backports

by Nicholas A. Bellinger

From: Nicholas Bellinger <nab(a)linux-iscsi.org> Hi Greg-KH, Here are two target patches for v3.18.y stable, which did not apply due to minor context changes. The series has been cut against v3.18.91. Please apply at your earliest convenience. Thank you, --nab Nicholas Bellinger (2): iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK drivers/target/iscsi/iscsi_target.c | 21 +++++++-------------- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 4 files changed, 19 insertions(+), 14 deletions(-) -- 1.8.5.3

7 years, 5 months

2
3
0 0

[Linux-stable-mirror] Patch "target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK to the 3.18-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: target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch and it can be found in the queue-3.18 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 1c21a48055a67ceb693e9c2587824a8de60a217c Mon Sep 17 00:00:00 2001 From: Nicholas Bellinger <nab(a)linux-iscsi.org> Date: Fri, 27 Oct 2017 22:19:26 -0800 Subject: target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK From: Nicholas Bellinger <nab(a)linux-iscsi.org> commit 1c21a48055a67ceb693e9c2587824a8de60a217c upstream. This patch fixes bug where early se_cmd exceptions that occur before backend execution can result in use-after-free if/when a subsequent ABORT_TASK occurs for the same tag. Since an early se_cmd exception will have had se_cmd added to se_session->sess_cmd_list via target_get_sess_cmd(), it will not have CMD_T_COMPLETE set by the usual target_complete_cmd() backend completion path. This causes a subsequent ABORT_TASK + __target_check_io_state() to signal ABORT_TASK should proceed. As core_tmr_abort_task() executes, it will bring the outstanding se_cmd->cmd_kref count down to zero releasing se_cmd, after se_cmd has already been queued with error status into fabric driver response path code. To address this bug, introduce a CMD_T_PRE_EXECUTE bit that is set at target_get_sess_cmd() time, and cleared immediately before backend driver dispatch in target_execute_cmd() once CMD_T_ACTIVE is set. Then, check CMD_T_PRE_EXECUTE within __target_check_io_state() to determine when an early exception has occured, and avoid aborting this se_cmd since it will have already been queued into fabric driver response path code. Reported-by: Donald White <dew(a)datera.io> Cc: Donald White <dew(a)datera.io> Cc: Mike Christie <mchristi(a)redhat.com> Cc: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 3 files changed, 12 insertions(+) --- a/drivers/target/target_core_tmr.c +++ b/drivers/target/target_core_tmr.c @@ -137,6 +137,15 @@ static bool __target_check_io_state(stru spin_unlock(&se_cmd->t_state_lock); return false; } + if (se_cmd->transport_state & CMD_T_PRE_EXECUTE) { + if (se_cmd->scsi_status) { + pr_debug("Attempted to abort io tag: %u early failure" + " status: 0x%02x\n", se_cmd->se_tfo->get_task_tag(se_cmd), + se_cmd->scsi_status); + spin_unlock(&se_cmd->t_state_lock); + return false; + } + } if (sess->sess_tearing_down || se_cmd->cmd_wait_set) { pr_debug("Attempted to abort io tag: %u already shutdown," " skipping\n", se_cmd->se_tfo->get_task_tag(se_cmd)); --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -1796,6 +1796,7 @@ void target_execute_cmd(struct se_cmd *c } cmd->t_state = TRANSPORT_PROCESSING; + cmd->transport_state &= ~CMD_T_PRE_EXECUTE; cmd->transport_state |= CMD_T_ACTIVE|CMD_T_BUSY|CMD_T_SENT; spin_unlock_irq(&cmd->t_state_lock); /* @@ -2436,6 +2437,7 @@ int target_get_sess_cmd(struct se_cmd *s ret = -ESHUTDOWN; goto out; } + se_cmd->transport_state |= CMD_T_PRE_EXECUTE; list_add_tail(&se_cmd->se_cmd_list, &se_sess->sess_cmd_list); out: spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags); --- a/include/target/target_core_base.h +++ b/include/target/target_core_base.h @@ -538,6 +538,7 @@ struct se_cmd { #define CMD_T_BUSY (1 << 9) #define CMD_T_TAS (1 << 10) #define CMD_T_FABRIC_STOP (1 << 11) +#define CMD_T_PRE_EXECUTE (1 << 12) spinlock_t t_state_lock; struct completion t_transport_stop_comp; Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are queue-3.18/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-3.18/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref to the 3.18-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: iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch and it can be found in the queue-3.18 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 ae072726f6109bb1c94841d6fb3a82dde298ea85 Mon Sep 17 00:00:00 2001 From: Nicholas Bellinger <nab(a)linux-iscsi.org> Date: Fri, 27 Oct 2017 12:32:59 -0700 Subject: iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref From: Nicholas Bellinger <nab(a)linux-iscsi.org> commit ae072726f6109bb1c94841d6fb3a82dde298ea85 upstream. Since commit 59b6986dbf fixed a potential NULL pointer dereference by allocating a se_tmr_req for ISCSI_TM_FUNC_TASK_REASSIGN, the se_tmr_req is currently leaked by iscsit_free_cmd() because no iscsi_cmd->se_cmd.se_tfo was associated. To address this, treat ISCSI_TM_FUNC_TASK_REASSIGN like any other TMR and call transport_init_se_cmd() + target_get_sess_cmd() to setup iscsi_cmd->se_cmd.se_tfo with se_cmd->cmd_kref of 2. This will ensure normal release operation once se_cmd->cmd_kref reaches zero and target_release_cmd_kref() is invoked, se_tmr_req will be released via existing target_free_cmd_mem() and core_tmr_release_req() code. Reported-by: Donald White <dew(a)datera.io> Cc: Donald White <dew(a)datera.io> Cc: Mike Christie <mchristi(a)redhat.com> Cc: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -1750,7 +1750,6 @@ iscsit_handle_task_mgt_cmd(struct iscsi_ struct iscsi_tmr_req *tmr_req; struct iscsi_tm *hdr; int out_of_order_cmdsn = 0, ret; - bool sess_ref = false; u8 function, tcm_function = TMR_UNKNOWN; hdr = (struct iscsi_tm *) buf; @@ -1792,19 +1791,17 @@ iscsit_handle_task_mgt_cmd(struct iscsi_ buf); } + transport_init_se_cmd(&cmd->se_cmd, &lio_target_fabric_configfs->tf_ops, + conn->sess->se_sess, 0, DMA_NONE, + MSG_SIMPLE_TAG, cmd->sense_buffer + 2); + + target_get_sess_cmd(&cmd->se_cmd, true); + /* * TASK_REASSIGN for ERL=2 / connection stays inside of * LIO-Target $FABRIC_MOD */ if (function != ISCSI_TM_FUNC_TASK_REASSIGN) { - transport_init_se_cmd(&cmd->se_cmd, - &lio_target_fabric_configfs->tf_ops, - conn->sess->se_sess, 0, DMA_NONE, - MSG_SIMPLE_TAG, cmd->sense_buffer + 2); - - target_get_sess_cmd(&cmd->se_cmd, true); - sess_ref = true; - switch (function) { case ISCSI_TM_FUNC_ABORT_TASK: tcm_function = TMR_ABORT_TASK; @@ -1943,12 +1940,8 @@ attach: * For connection recovery, this is also the default action for * TMR TASK_REASSIGN. */ - if (sess_ref) { - pr_debug("Handle TMR, using sess_ref=true check\n"); - target_put_sess_cmd(&cmd->se_cmd); - } - iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state); + target_put_sess_cmd(&cmd->se_cmd); return 0; } EXPORT_SYMBOL(iscsit_handle_task_mgt_cmd); Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are queue-3.18/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch queue-3.18/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf, array: fix overflow in max_entries and undefined behavior in index_mask" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf, array: fix overflow in max_entries and undefined behavior in index_mask to the 4.14-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: bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch and it can be found in the queue-4.14 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 bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 10 Jan 2018 23:25:05 +0100 Subject: bpf, array: fix overflow in max_entries and undefined behavior in index_mask From: Daniel Borkmann <daniel(a)iogearbox.net> commit bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1 upstream. syzkaller tried to alloc a map with 0xfffffffd entries out of a userns, and thus unprivileged. With the recently added logic in b2157399cc98 ("bpf: prevent out-of-bounds speculation") we round this up to the next power of two value for max_entries for unprivileged such that we can apply proper masking into potentially zeroed out map slots. However, this will generate an index_mask of 0xffffffff, and therefore a + 1 will let this overflow into new max_entries of 0. This will pass allocation, etc, and later on map access we still enforce on the original attr->max_entries value which was 0xfffffffd, therefore triggering GPF all over the place. Thus bail out on overflow in such case. Moreover, on 32 bit archs roundup_pow_of_two() can also not be used, since fls_long(max_entries - 1) can result in 32 and 1UL << 32 in 32 bit space is undefined. Therefore, do this by hand in a 64 bit variable. This fixes all the issues triggered by syzkaller's reproducers. Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation") Reported-by: syzbot+b0efb8e572d01bce1ae0(a)syzkaller.appspotmail.com Reported-by: syzbot+6c15e9744f75f2364773(a)syzkaller.appspotmail.com Reported-by: syzbot+d2f5524fb46fd3b312ee(a)syzkaller.appspotmail.com Reported-by: syzbot+61d23c95395cc90dbc2b(a)syzkaller.appspotmail.com Reported-by: syzbot+0d363c942452cca68c01(a)syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Eric Dumazet <eric.dumazet(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/arraymap.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -53,7 +53,7 @@ static struct bpf_map *array_map_alloc(u u32 elem_size, index_mask, max_entries; bool unpriv = !capable(CAP_SYS_ADMIN); struct bpf_array *array; - u64 array_size; + u64 array_size, mask64; /* check sanity of attributes */ if (attr->max_entries == 0 || attr->key_size != 4 || @@ -70,13 +70,25 @@ static struct bpf_map *array_map_alloc(u elem_size = round_up(attr->value_size, 8); max_entries = attr->max_entries; - index_mask = roundup_pow_of_two(max_entries) - 1; - if (unpriv) + /* On 32 bit archs roundup_pow_of_two() with max_entries that has + * upper most bit set in u32 space is undefined behavior due to + * resulting 1U << 32, so do it manually here in u64 space. + */ + mask64 = fls_long(max_entries - 1); + mask64 = 1ULL << mask64; + mask64 -= 1; + + index_mask = mask64; + if (unpriv) { /* round up array size to nearest power of 2, * since cpu will speculate within index_mask limits */ max_entries = index_mask + 1; + /* Check for overflows. */ + if (max_entries < attr->max_entries) + return ERR_PTR(-E2BIG); + } array_size = sizeof(*array); if (percpu) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.14/bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch queue-4.14/bpf-prevent-out-of-bounds-speculation.patch queue-4.14/bpf-arsh-is-not-supported-in-32-bit-alu-thus-reject-it.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: arsh is not supported in 32 bit alu thus reject it" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: arsh is not supported in 32 bit alu thus reject it to the 4.14-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: bpf-arsh-is-not-supported-in-32-bit-alu-thus-reject-it.patch and it can be found in the queue-4.14 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 7891a87efc7116590eaba57acc3c422487802c6f Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 10 Jan 2018 20:04:37 +0100 Subject: bpf: arsh is not supported in 32 bit alu thus reject it From: Daniel Borkmann <daniel(a)iogearbox.net> commit 7891a87efc7116590eaba57acc3c422487802c6f upstream. The following snippet was throwing an 'unknown opcode cc' warning in BPF interpreter: 0: (18) r0 = 0x0 2: (7b) *(u64 *)(r10 -16) = r0 3: (cc) (u32) r0 s>>= (u32) r0 4: (95) exit Although a number of JITs do support BPF_ALU | BPF_ARSH | BPF_{K,X} generation, not all of them do and interpreter does neither. We can leave existing ones and implement it later in bpf-next for the remaining ones, but reject this properly in verifier for the time being. Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)") Reported-by: syzbot+93c4904c5c70348a6890(a)syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/verifier.c | 5 +++ tools/testing/selftests/bpf/test_verifier.c | 40 ++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2493,6 +2493,11 @@ static int check_alu_op(struct bpf_verif return -EINVAL; } + if (opcode == BPF_ARSH && BPF_CLASS(insn->code) != BPF_ALU64) { + verbose("BPF_ARSH not supported for 32 bit ALU\n"); + return -EINVAL; + } + if ((opcode == BPF_LSH || opcode == BPF_RSH || opcode == BPF_ARSH) && BPF_SRC(insn->code) == BPF_K) { int size = BPF_CLASS(insn->code) == BPF_ALU64 ? 64 : 32; --- a/tools/testing/selftests/bpf/test_verifier.c +++ b/tools/testing/selftests/bpf/test_verifier.c @@ -273,6 +273,46 @@ static struct bpf_test tests[] = { .result = REJECT, }, { + "arsh32 on imm", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, 1), + BPF_ALU32_IMM(BPF_ARSH, BPF_REG_0, 5), + BPF_EXIT_INSN(), + }, + .result = REJECT, + .errstr = "BPF_ARSH not supported for 32 bit ALU", + }, + { + "arsh32 on reg", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, 1), + BPF_MOV64_IMM(BPF_REG_1, 5), + BPF_ALU32_REG(BPF_ARSH, BPF_REG_0, BPF_REG_1), + BPF_EXIT_INSN(), + }, + .result = REJECT, + .errstr = "BPF_ARSH not supported for 32 bit ALU", + }, + { + "arsh64 on imm", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, 1), + BPF_ALU64_IMM(BPF_ARSH, BPF_REG_0, 5), + BPF_EXIT_INSN(), + }, + .result = ACCEPT, + }, + { + "arsh64 on reg", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, 1), + BPF_MOV64_IMM(BPF_REG_1, 5), + BPF_ALU64_REG(BPF_ARSH, BPF_REG_0, BPF_REG_1), + BPF_EXIT_INSN(), + }, + .result = ACCEPT, + }, + { "no bpf_exit", .insns = { BPF_ALU64_REG(BPF_MOV, BPF_REG_0, BPF_REG_2), Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.14/bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch queue-4.14/bpf-prevent-out-of-bounds-speculation.patch queue-4.14/bpf-arsh-is-not-supported-in-32-bit-alu-thus-reject-it.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: refactor fixup_bpf_calls()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: refactor fixup_bpf_calls() to the 4.9-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: bpf-refactor-fixup_bpf_calls.patch and it can be found in the queue-4.9 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 79741b3bdec01a8628368fbcfccc7d189ed606cb Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)fb.com> Date: Wed, 15 Mar 2017 18:26:40 -0700 Subject: bpf: refactor fixup_bpf_calls() From: Alexei Starovoitov <ast(a)fb.com> commit 79741b3bdec01a8628368fbcfccc7d189ed606cb upstream. reduce indent and make it iterate over instructions similar to convert_ctx_accesses(). Also convert hard BUG_ON into soft verifier error. Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Cc: Jiri Slaby <jslaby(a)suse.cz> [Backported to 4.9.y - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/verifier.c | 75 +++++++++++++++++++++++--------------------------- 1 file changed, 35 insertions(+), 40 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3362,55 +3362,50 @@ static int convert_ctx_accesses(struct b return 0; } -/* fixup insn->imm field of bpf_call instructions: - * if (insn->imm == BPF_FUNC_map_lookup_elem) - * insn->imm = bpf_map_lookup_elem - __bpf_call_base; - * else if (insn->imm == BPF_FUNC_map_update_elem) - * insn->imm = bpf_map_update_elem - __bpf_call_base; - * else ... +/* fixup insn->imm field of bpf_call instructions * * this function is called after eBPF program passed verification */ -static void fixup_bpf_calls(struct bpf_prog *prog) +static int fixup_bpf_calls(struct bpf_verifier_env *env) { + struct bpf_prog *prog = env->prog; + struct bpf_insn *insn = prog->insnsi; const struct bpf_func_proto *fn; + const int insn_cnt = prog->len; int i; - for (i = 0; i < prog->len; i++) { - struct bpf_insn *insn = &prog->insnsi[i]; - - if (insn->code == (BPF_JMP | BPF_CALL)) { - /* we reach here when program has bpf_call instructions - * and it passed bpf_check(), means that - * ops->get_func_proto must have been supplied, check it - */ - BUG_ON(!prog->aux->ops->get_func_proto); - - if (insn->imm == BPF_FUNC_get_route_realm) - prog->dst_needed = 1; - if (insn->imm == BPF_FUNC_get_prandom_u32) - bpf_user_rnd_init_once(); - if (insn->imm == BPF_FUNC_tail_call) { - /* mark bpf_tail_call as different opcode - * to avoid conditional branch in - * interpeter for every normal call - * and to prevent accidental JITing by - * JIT compiler that doesn't support - * bpf_tail_call yet - */ - insn->imm = 0; - insn->code |= BPF_X; - continue; - } + for (i = 0; i < insn_cnt; i++, insn++) { + if (insn->code != (BPF_JMP | BPF_CALL)) + continue; + + if (insn->imm == BPF_FUNC_get_route_realm) + prog->dst_needed = 1; + if (insn->imm == BPF_FUNC_get_prandom_u32) + bpf_user_rnd_init_once(); + if (insn->imm == BPF_FUNC_tail_call) { + /* mark bpf_tail_call as different opcode to avoid + * conditional branch in the interpeter for every normal + * call and to prevent accidental JITing by JIT compiler + * that doesn't support bpf_tail_call yet + */ + insn->imm = 0; + insn->code |= BPF_X; + continue; + } - fn = prog->aux->ops->get_func_proto(insn->imm); - /* all functions that have prototype and verifier allowed - * programs to call them, must be real in-kernel functions - */ - BUG_ON(!fn->func); - insn->imm = fn->func - __bpf_call_base; + fn = prog->aux->ops->get_func_proto(insn->imm); + /* all functions that have prototype and verifier allowed + * programs to call them, must be real in-kernel functions + */ + if (!fn->func) { + verbose("kernel subsystem misconfigured func %d\n", + insn->imm); + return -EFAULT; } + insn->imm = fn->func - __bpf_call_base; } + + return 0; } static void free_states(struct bpf_verifier_env *env) @@ -3515,7 +3510,7 @@ skip_full_check: ret = convert_ctx_accesses(env); if (ret == 0) - fixup_bpf_calls(env->prog); + ret = fixup_bpf_calls(env); if (log_level && log_len >= log_size - 1) { BUG_ON(log_len >= log_size); Patches currently in stable-queue which might be from ast(a)fb.com are queue-4.9/bpf-refactor-fixup_bpf_calls.patch queue-4.9/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: move fixup_bpf_calls() function" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: move fixup_bpf_calls() function to the 4.9-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: bpf-move-fixup_bpf_calls-function.patch and it can be found in the queue-4.9 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 e245c5c6a5656e4d61aa7bb08e9694fd6e5b2b9d Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)fb.com> Date: Wed, 15 Mar 2017 18:26:39 -0700 Subject: bpf: move fixup_bpf_calls() function From: Alexei Starovoitov <ast(a)fb.com> commit e245c5c6a5656e4d61aa7bb08e9694fd6e5b2b9d upstream. no functional change. move fixup_bpf_calls() to verifier.c it's being refactored in the next patch Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Cc: Jiri Slaby <jslaby(a)suse.cz> [backported to 4.9 - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/syscall.c | 54 -------------------------------------------------- kernel/bpf/verifier.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 54 deletions(-) --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -565,57 +565,6 @@ void bpf_register_prog_type(struct bpf_p list_add(&tl->list_node, &bpf_prog_types); } -/* fixup insn->imm field of bpf_call instructions: - * if (insn->imm == BPF_FUNC_map_lookup_elem) - * insn->imm = bpf_map_lookup_elem - __bpf_call_base; - * else if (insn->imm == BPF_FUNC_map_update_elem) - * insn->imm = bpf_map_update_elem - __bpf_call_base; - * else ... - * - * this function is called after eBPF program passed verification - */ -static void fixup_bpf_calls(struct bpf_prog *prog) -{ - const struct bpf_func_proto *fn; - int i; - - for (i = 0; i < prog->len; i++) { - struct bpf_insn *insn = &prog->insnsi[i]; - - if (insn->code == (BPF_JMP | BPF_CALL)) { - /* we reach here when program has bpf_call instructions - * and it passed bpf_check(), means that - * ops->get_func_proto must have been supplied, check it - */ - BUG_ON(!prog->aux->ops->get_func_proto); - - if (insn->imm == BPF_FUNC_get_route_realm) - prog->dst_needed = 1; - if (insn->imm == BPF_FUNC_get_prandom_u32) - bpf_user_rnd_init_once(); - if (insn->imm == BPF_FUNC_tail_call) { - /* mark bpf_tail_call as different opcode - * to avoid conditional branch in - * interpeter for every normal call - * and to prevent accidental JITing by - * JIT compiler that doesn't support - * bpf_tail_call yet - */ - insn->imm = 0; - insn->code |= BPF_X; - continue; - } - - fn = prog->aux->ops->get_func_proto(insn->imm); - /* all functions that have prototype and verifier allowed - * programs to call them, must be real in-kernel functions - */ - BUG_ON(!fn->func); - insn->imm = fn->func - __bpf_call_base; - } - } -} - /* drop refcnt on maps used by eBPF program and free auxilary data */ static void free_used_maps(struct bpf_prog_aux *aux) { @@ -808,9 +757,6 @@ static int bpf_prog_load(union bpf_attr if (err < 0) goto free_used_maps; - /* fixup BPF_CALL->imm field */ - fixup_bpf_calls(prog); - /* eBPF program is ready to be JITed */ prog = bpf_prog_select_runtime(prog, &err); if (err < 0) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3362,6 +3362,57 @@ static int convert_ctx_accesses(struct b return 0; } +/* fixup insn->imm field of bpf_call instructions: + * if (insn->imm == BPF_FUNC_map_lookup_elem) + * insn->imm = bpf_map_lookup_elem - __bpf_call_base; + * else if (insn->imm == BPF_FUNC_map_update_elem) + * insn->imm = bpf_map_update_elem - __bpf_call_base; + * else ... + * + * this function is called after eBPF program passed verification + */ +static void fixup_bpf_calls(struct bpf_prog *prog) +{ + const struct bpf_func_proto *fn; + int i; + + for (i = 0; i < prog->len; i++) { + struct bpf_insn *insn = &prog->insnsi[i]; + + if (insn->code == (BPF_JMP | BPF_CALL)) { + /* we reach here when program has bpf_call instructions + * and it passed bpf_check(), means that + * ops->get_func_proto must have been supplied, check it + */ + BUG_ON(!prog->aux->ops->get_func_proto); + + if (insn->imm == BPF_FUNC_get_route_realm) + prog->dst_needed = 1; + if (insn->imm == BPF_FUNC_get_prandom_u32) + bpf_user_rnd_init_once(); + if (insn->imm == BPF_FUNC_tail_call) { + /* mark bpf_tail_call as different opcode + * to avoid conditional branch in + * interpeter for every normal call + * and to prevent accidental JITing by + * JIT compiler that doesn't support + * bpf_tail_call yet + */ + insn->imm = 0; + insn->code |= BPF_X; + continue; + } + + fn = prog->aux->ops->get_func_proto(insn->imm); + /* all functions that have prototype and verifier allowed + * programs to call them, must be real in-kernel functions + */ + BUG_ON(!fn->func); + insn->imm = fn->func - __bpf_call_base; + } + } +} + static void free_states(struct bpf_verifier_env *env) { struct bpf_verifier_state_list *sl, *sln; @@ -3463,6 +3514,9 @@ skip_full_check: /* program is valid, convert *(u32*)(ctx + off) accesses */ ret = convert_ctx_accesses(env); + if (ret == 0) + fixup_bpf_calls(env->prog); + if (log_level && log_len >= log_size - 1) { BUG_ON(log_len >= log_size); /* verifier log exceeded user supplied buffer */ Patches currently in stable-queue which might be from ast(a)fb.com are queue-4.9/bpf-refactor-fixup_bpf_calls.patch queue-4.9/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] patch "USB: serial: io_edgeport: fix possible sleep-in-atomic" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: io_edgeport: fix possible sleep-in-atomic to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From c7b8f77872c73f69a16528a9eb87afefcccdc18b Mon Sep 17 00:00:00 2001 From: Jia-Ju Bai <baijiaju1990(a)gmail.com> Date: Wed, 13 Dec 2017 20:34:36 +0800 Subject: USB: serial: io_edgeport: fix possible sleep-in-atomic According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/io_edgeport.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c index 219265ce3711..17283f4b4779 100644 --- a/drivers/usb/serial/io_edgeport.c +++ b/drivers/usb/serial/io_edgeport.c @@ -2282,7 +2282,6 @@ static int write_cmd_usb(struct edgeport_port *edge_port, /* something went wrong */ dev_err(dev, "%s - usb_submit_urb(write command) failed, status = %d\n", __func__, status); - usb_kill_urb(urb); usb_free_urb(urb); atomic_dec(&CmdUrbs); return status; -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: refactor fixup_bpf_calls()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: refactor fixup_bpf_calls() to the 4.4-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: bpf-refactor-fixup_bpf_calls.patch and it can be found in the queue-4.4 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 79741b3bdec01a8628368fbcfccc7d189ed606cb Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)fb.com> Date: Wed, 15 Mar 2017 18:26:40 -0700 Subject: bpf: refactor fixup_bpf_calls() From: Alexei Starovoitov <ast(a)fb.com> commit 79741b3bdec01a8628368fbcfccc7d189ed606cb upstream. reduce indent and make it iterate over instructions similar to convert_ctx_accesses(). Also convert hard BUG_ON into soft verifier error. Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/verifier.c | 74 ++++++++++++++++++++++---------------------------- 1 file changed, 34 insertions(+), 40 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2158,57 +2158,51 @@ static int convert_ctx_accesses(struct v return 0; } -/* fixup insn->imm field of bpf_call instructions: - * if (insn->imm == BPF_FUNC_map_lookup_elem) - * insn->imm = bpf_map_lookup_elem - __bpf_call_base; - * else if (insn->imm == BPF_FUNC_map_update_elem) - * insn->imm = bpf_map_update_elem - __bpf_call_base; - * else ... +/* fixup insn->imm field of bpf_call instructions * * this function is called after eBPF program passed verification */ -static void fixup_bpf_calls(struct bpf_prog *prog) +static int fixup_bpf_calls(struct verifier_env *env) { + struct bpf_prog *prog = env->prog; + struct bpf_insn *insn = prog->insnsi; const struct bpf_func_proto *fn; + const int insn_cnt = prog->len; int i; - for (i = 0; i < prog->len; i++) { - struct bpf_insn *insn = &prog->insnsi[i]; - - if (insn->code == (BPF_JMP | BPF_CALL)) { - /* we reach here when program has bpf_call instructions - * and it passed bpf_check(), means that - * ops->get_func_proto must have been supplied, check it + for (i = 0; i < insn_cnt; i++, insn++) { + if (insn->code != (BPF_JMP | BPF_CALL)) + continue; + + if (insn->imm == BPF_FUNC_get_route_realm) + prog->dst_needed = 1; + if (insn->imm == BPF_FUNC_get_prandom_u32) + bpf_user_rnd_init_once(); + if (insn->imm == BPF_FUNC_tail_call) { + /* mark bpf_tail_call as different opcode to avoid + * conditional branch in the interpeter for every normal + * call and to prevent accidental JITing by JIT compiler + * that doesn't support bpf_tail_call yet */ - BUG_ON(!prog->aux->ops->get_func_proto); - - if (insn->imm == BPF_FUNC_get_route_realm) - prog->dst_needed = 1; - if (insn->imm == BPF_FUNC_get_prandom_u32) - bpf_user_rnd_init_once(); - if (insn->imm == BPF_FUNC_tail_call) { - /* mark bpf_tail_call as different opcode - * to avoid conditional branch in - * interpeter for every normal call - * and to prevent accidental JITing by - * JIT compiler that doesn't support - * bpf_tail_call yet - */ - insn->imm = 0; - insn->code |= BPF_X; - continue; - } + insn->imm = 0; + insn->code |= BPF_X; + continue; + } - fn = prog->aux->ops->get_func_proto(insn->imm); - /* all functions that have prototype and verifier allowed - * programs to call them, must be real in-kernel functions - */ - BUG_ON(!fn->func); - insn->imm = fn->func - __bpf_call_base; + fn = prog->aux->ops->get_func_proto(insn->imm); + /* all functions that have prototype and verifier allowed + * programs to call them, must be real in-kernel functions + */ + if (!fn->func) { + verbose("kernel subsystem misconfigured func %d\n", + insn->imm); + return -EFAULT; } + insn->imm = fn->func - __bpf_call_base; } -} + return 0; +} static void free_states(struct verifier_env *env) { @@ -2309,7 +2303,7 @@ skip_full_check: ret = convert_ctx_accesses(env); if (ret == 0) - fixup_bpf_calls(env->prog); + ret = fixup_bpf_calls(env); if (log_level && log_len >= log_size - 1) { BUG_ON(log_len >= log_size); Patches currently in stable-queue which might be from ast(a)fb.com are queue-4.4/bpf-adjust-insn_aux_data-when-patching-insns.patch queue-4.4/bpf-refactor-fixup_bpf_calls.patch queue-4.4/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: prevent out-of-bounds speculation" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: prevent out-of-bounds speculation to the 4.4-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: bpf-prevent-out-of-bounds-speculation.patch and it can be found in the queue-4.4 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 b2157399cc9898260d6031c5bfe45fe137c1fbe7 Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)kernel.org> Date: Sun, 7 Jan 2018 17:33:02 -0800 Subject: bpf: prevent out-of-bounds speculation From: Alexei Starovoitov <ast(a)kernel.org> commit b2157399cc9898260d6031c5bfe45fe137c1fbe7 upstream. Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. To avoid leaking kernel data round up array-based maps and mask the index after bounds check, so speculated load with out of bounds index will load either valid value from the array or zero from the padded area. Unconditionally mask index for all array types even when max_entries are not rounded to power of 2 for root user. When map is created by unpriv user generate a sequence of bpf insns that includes AND operation to make sure that JITed code includes the same 'index & index_mask' operation. If prog_array map is created by unpriv user replace bpf_tail_call(ctx, map, index); with if (index >= max_entries) { index &= map->index_mask; bpf_tail_call(ctx, map, index); } (along with roundup to power 2) to prevent out-of-bounds speculation. There is secondary redundant 'if (index >= max_entries)' in the interpreter and in all JITs, but they can be optimized later if necessary. Other array-like maps (cpumap, devmap, sockmap, perf_event_array, cgroup_array) cannot be used by unpriv, so no changes there. That fixes bpf side of "Variant 1: bounds check bypass (CVE-2017-5753)" on all architectures with and without JIT. v2->v3: Daniel noticed that attack potentially can be crafted via syscall commands without loading the program, so add masking to those paths as well. Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/bpf.h | 2 ++ kernel/bpf/arraymap.c | 24 +++++++++++++++++++----- kernel/bpf/verifier.c | 46 ++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 63 insertions(+), 9 deletions(-) --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -37,6 +37,7 @@ struct bpf_map { u32 value_size; u32 max_entries; u32 pages; + bool unpriv_array; struct user_struct *user; const struct bpf_map_ops *ops; struct work_struct work; @@ -141,6 +142,7 @@ struct bpf_prog_aux { struct bpf_array { struct bpf_map map; u32 elem_size; + u32 index_mask; /* 'ownership' of prog_array is claimed by the first program that * is going to use this map or by the first program which FD is stored * in the map to make sure that all callers and callees have the same --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -20,8 +20,9 @@ /* Called from syscall */ static struct bpf_map *array_map_alloc(union bpf_attr *attr) { + u32 elem_size, array_size, index_mask, max_entries; + bool unpriv = !capable(CAP_SYS_ADMIN); struct bpf_array *array; - u32 elem_size, array_size; /* check sanity of attributes */ if (attr->max_entries == 0 || attr->key_size != 4 || @@ -36,12 +37,21 @@ static struct bpf_map *array_map_alloc(u elem_size = round_up(attr->value_size, 8); + max_entries = attr->max_entries; + index_mask = roundup_pow_of_two(max_entries) - 1; + + if (unpriv) + /* round up array size to nearest power of 2, + * since cpu will speculate within index_mask limits + */ + max_entries = index_mask + 1; + /* check round_up into zero and u32 overflow */ if (elem_size == 0 || - attr->max_entries > (U32_MAX - PAGE_SIZE - sizeof(*array)) / elem_size) + max_entries > (U32_MAX - PAGE_SIZE - sizeof(*array)) / elem_size) return ERR_PTR(-ENOMEM); - array_size = sizeof(*array) + attr->max_entries * elem_size; + array_size = sizeof(*array) + max_entries * elem_size; /* allocate all map elements and zero-initialize them */ array = kzalloc(array_size, GFP_USER | __GFP_NOWARN); @@ -50,6 +60,8 @@ static struct bpf_map *array_map_alloc(u if (!array) return ERR_PTR(-ENOMEM); } + array->index_mask = index_mask; + array->map.unpriv_array = unpriv; /* copy mandatory map attributes */ array->map.key_size = attr->key_size; @@ -70,7 +82,7 @@ static void *array_map_lookup_elem(struc if (index >= array->map.max_entries) return NULL; - return array->value + array->elem_size * index; + return array->value + array->elem_size * (index & array->index_mask); } /* Called from syscall */ @@ -111,7 +123,9 @@ static int array_map_update_elem(struct /* all elements already exist */ return -EEXIST; - memcpy(array->value + array->elem_size * index, value, map->value_size); + memcpy(array->value + + array->elem_size * (index & array->index_mask), + value, map->value_size); return 0; } --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -187,7 +187,10 @@ struct verifier_stack_elem { }; struct bpf_insn_aux_data { - enum bpf_reg_type ptr_type; /* pointer type for load/store insns */ + union { + enum bpf_reg_type ptr_type; /* pointer type for load/store insns */ + struct bpf_map *map_ptr; /* pointer for call insn into lookup_elem */ + }; }; #define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */ @@ -950,7 +953,7 @@ error: return -EINVAL; } -static int check_call(struct verifier_env *env, int func_id) +static int check_call(struct verifier_env *env, int func_id, int insn_idx) { struct verifier_state *state = &env->cur_state; const struct bpf_func_proto *fn = NULL; @@ -986,6 +989,13 @@ static int check_call(struct verifier_en err = check_func_arg(env, BPF_REG_2, fn->arg2_type, &map); if (err) return err; + if (func_id == BPF_FUNC_tail_call) { + if (map == NULL) { + verbose("verifier bug\n"); + return -EINVAL; + } + env->insn_aux_data[insn_idx].map_ptr = map; + } err = check_func_arg(env, BPF_REG_3, fn->arg3_type, &map); if (err) return err; @@ -1911,7 +1921,7 @@ static int do_check(struct verifier_env return -EINVAL; } - err = check_call(env, insn->imm); + err = check_call(env, insn->imm, insn_idx); if (err) return err; @@ -2202,7 +2212,10 @@ static int fixup_bpf_calls(struct verifi struct bpf_insn *insn = prog->insnsi; const struct bpf_func_proto *fn; const int insn_cnt = prog->len; - int i; + struct bpf_insn insn_buf[16]; + struct bpf_prog *new_prog; + struct bpf_map *map_ptr; + int i, cnt, delta = 0; for (i = 0; i < insn_cnt; i++, insn++) { if (insn->code != (BPF_JMP | BPF_CALL)) @@ -2220,6 +2233,31 @@ static int fixup_bpf_calls(struct verifi */ insn->imm = 0; insn->code |= BPF_X; + + /* instead of changing every JIT dealing with tail_call + * emit two extra insns: + * if (index >= max_entries) goto out; + * index &= array->index_mask; + * to avoid out-of-bounds cpu speculation + */ + map_ptr = env->insn_aux_data[i + delta].map_ptr; + if (!map_ptr->unpriv_array) + continue; + insn_buf[0] = BPF_JMP_IMM(BPF_JGE, BPF_REG_3, + map_ptr->max_entries, 2); + insn_buf[1] = BPF_ALU32_IMM(BPF_AND, BPF_REG_3, + container_of(map_ptr, + struct bpf_array, + map)->index_mask); + insn_buf[2] = *insn; + cnt = 3; + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); + if (!new_prog) + return -ENOMEM; + + delta += cnt - 1; + env->prog = prog = new_prog; + insn = new_prog->insnsi + i + delta; continue; } Patches currently in stable-queue which might be from ast(a)kernel.org are queue-4.4/bpf-adjust-insn_aux_data-when-patching-insns.patch queue-4.4/bpf-refactor-fixup_bpf_calls.patch queue-4.4/bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch queue-4.4/bpf-don-t-ab-use-instructions-to-store-state.patch queue-4.4/bpf-prevent-out-of-bounds-speculation.patch queue-4.4/bpf-add-bpf_patch_insn_single-helper.patch queue-4.4/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: move fixup_bpf_calls() function" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: move fixup_bpf_calls() function to the 4.4-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: bpf-move-fixup_bpf_calls-function.patch and it can be found in the queue-4.4 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 e245c5c6a5656e4d61aa7bb08e9694fd6e5b2b9d Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)fb.com> Date: Wed, 15 Mar 2017 18:26:39 -0700 Subject: bpf: move fixup_bpf_calls() function From: Alexei Starovoitov <ast(a)fb.com> commit e245c5c6a5656e4d61aa7bb08e9694fd6e5b2b9d upstream. no functional change. move fixup_bpf_calls() to verifier.c it's being refactored in the next patch Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/syscall.c | 54 ------------------------------------------------- kernel/bpf/verifier.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 54 deletions(-) --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -447,57 +447,6 @@ void bpf_register_prog_type(struct bpf_p list_add(&tl->list_node, &bpf_prog_types); } -/* fixup insn->imm field of bpf_call instructions: - * if (insn->imm == BPF_FUNC_map_lookup_elem) - * insn->imm = bpf_map_lookup_elem - __bpf_call_base; - * else if (insn->imm == BPF_FUNC_map_update_elem) - * insn->imm = bpf_map_update_elem - __bpf_call_base; - * else ... - * - * this function is called after eBPF program passed verification - */ -static void fixup_bpf_calls(struct bpf_prog *prog) -{ - const struct bpf_func_proto *fn; - int i; - - for (i = 0; i < prog->len; i++) { - struct bpf_insn *insn = &prog->insnsi[i]; - - if (insn->code == (BPF_JMP | BPF_CALL)) { - /* we reach here when program has bpf_call instructions - * and it passed bpf_check(), means that - * ops->get_func_proto must have been supplied, check it - */ - BUG_ON(!prog->aux->ops->get_func_proto); - - if (insn->imm == BPF_FUNC_get_route_realm) - prog->dst_needed = 1; - if (insn->imm == BPF_FUNC_get_prandom_u32) - bpf_user_rnd_init_once(); - if (insn->imm == BPF_FUNC_tail_call) { - /* mark bpf_tail_call as different opcode - * to avoid conditional branch in - * interpeter for every normal call - * and to prevent accidental JITing by - * JIT compiler that doesn't support - * bpf_tail_call yet - */ - insn->imm = 0; - insn->code |= BPF_X; - continue; - } - - fn = prog->aux->ops->get_func_proto(insn->imm); - /* all functions that have prototype and verifier allowed - * programs to call them, must be real in-kernel functions - */ - BUG_ON(!fn->func); - insn->imm = fn->func - __bpf_call_base; - } - } -} - /* drop refcnt on maps used by eBPF program and free auxilary data */ static void free_used_maps(struct bpf_prog_aux *aux) { @@ -680,9 +629,6 @@ static int bpf_prog_load(union bpf_attr if (err < 0) goto free_used_maps; - /* fixup BPF_CALL->imm field */ - fixup_bpf_calls(prog); - /* eBPF program is ready to be JITed */ err = bpf_prog_select_runtime(prog); if (err < 0) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2158,6 +2158,58 @@ static int convert_ctx_accesses(struct v return 0; } +/* fixup insn->imm field of bpf_call instructions: + * if (insn->imm == BPF_FUNC_map_lookup_elem) + * insn->imm = bpf_map_lookup_elem - __bpf_call_base; + * else if (insn->imm == BPF_FUNC_map_update_elem) + * insn->imm = bpf_map_update_elem - __bpf_call_base; + * else ... + * + * this function is called after eBPF program passed verification + */ +static void fixup_bpf_calls(struct bpf_prog *prog) +{ + const struct bpf_func_proto *fn; + int i; + + for (i = 0; i < prog->len; i++) { + struct bpf_insn *insn = &prog->insnsi[i]; + + if (insn->code == (BPF_JMP | BPF_CALL)) { + /* we reach here when program has bpf_call instructions + * and it passed bpf_check(), means that + * ops->get_func_proto must have been supplied, check it + */ + BUG_ON(!prog->aux->ops->get_func_proto); + + if (insn->imm == BPF_FUNC_get_route_realm) + prog->dst_needed = 1; + if (insn->imm == BPF_FUNC_get_prandom_u32) + bpf_user_rnd_init_once(); + if (insn->imm == BPF_FUNC_tail_call) { + /* mark bpf_tail_call as different opcode + * to avoid conditional branch in + * interpeter for every normal call + * and to prevent accidental JITing by + * JIT compiler that doesn't support + * bpf_tail_call yet + */ + insn->imm = 0; + insn->code |= BPF_X; + continue; + } + + fn = prog->aux->ops->get_func_proto(insn->imm); + /* all functions that have prototype and verifier allowed + * programs to call them, must be real in-kernel functions + */ + BUG_ON(!fn->func); + insn->imm = fn->func - __bpf_call_base; + } + } +} + + static void free_states(struct verifier_env *env) { struct verifier_state_list *sl, *sln; @@ -2256,6 +2308,9 @@ skip_full_check: /* program is valid, convert *(u32*)(ctx + off) accesses */ ret = convert_ctx_accesses(env); + if (ret == 0) + fixup_bpf_calls(env->prog); + if (log_level && log_len >= log_size - 1) { BUG_ON(log_len >= log_size); /* verifier log exceeded user supplied buffer */ Patches currently in stable-queue which might be from ast(a)fb.com are queue-4.4/bpf-adjust-insn_aux_data-when-patching-insns.patch queue-4.4/bpf-refactor-fixup_bpf_calls.patch queue-4.4/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: don't (ab)use instructions to store state" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: don't (ab)use instructions to store state to the 4.4-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: bpf-don-t-ab-use-instructions-to-store-state.patch and it can be found in the queue-4.4 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 3df126f35f88dc76eea33769f85a3c3bb8ce6c6b Mon Sep 17 00:00:00 2001 From: Jakub Kicinski <jakub.kicinski(a)netronome.com> Date: Wed, 21 Sep 2016 11:43:56 +0100 Subject: bpf: don't (ab)use instructions to store state From: Jakub Kicinski <jakub.kicinski(a)netronome.com> commit 3df126f35f88dc76eea33769f85a3c3bb8ce6c6b upstream. Storing state in reserved fields of instructions makes it impossible to run verifier on programs already marked as read-only. Allocate and use an array of per-instruction state instead. While touching the error path rename and move existing jump target. Suggested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Jakub Kicinski <jakub.kicinski(a)netronome.com> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/verifier.c | 67 +++++++++++++++++++++++++++++--------------------- 1 file changed, 39 insertions(+), 28 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -186,6 +186,10 @@ struct verifier_stack_elem { struct verifier_stack_elem *next; }; +struct bpf_insn_aux_data { + enum bpf_reg_type ptr_type; /* pointer type for load/store insns */ +}; + #define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */ /* single container for all structs @@ -200,6 +204,7 @@ struct verifier_env { struct bpf_map *used_maps[MAX_USED_MAPS]; /* array of map's used by eBPF program */ u32 used_map_cnt; /* number of used maps */ bool allow_ptr_leaks; + struct bpf_insn_aux_data *insn_aux_data; /* array of per-insn state */ }; /* verbose verifier prints what it's seeing @@ -1784,7 +1789,7 @@ static int do_check(struct verifier_env return err; } else if (class == BPF_LDX) { - enum bpf_reg_type src_reg_type; + enum bpf_reg_type *prev_src_type, src_reg_type; /* check for reserved fields is already done */ @@ -1813,16 +1818,18 @@ static int do_check(struct verifier_env continue; } - if (insn->imm == 0) { + prev_src_type = &env->insn_aux_data[insn_idx].ptr_type; + + if (*prev_src_type == NOT_INIT) { /* saw a valid insn * dst_reg = *(u32 *)(src_reg + off) - * use reserved 'imm' field to mark this insn + * save type to validate intersecting paths */ - insn->imm = src_reg_type; + *prev_src_type = src_reg_type; - } else if (src_reg_type != insn->imm && + } else if (src_reg_type != *prev_src_type && (src_reg_type == PTR_TO_CTX || - insn->imm == PTR_TO_CTX)) { + *prev_src_type == PTR_TO_CTX)) { /* ABuser program is trying to use the same insn * dst_reg = *(u32*) (src_reg + off) * with different pointer types: @@ -1835,7 +1842,7 @@ static int do_check(struct verifier_env } } else if (class == BPF_STX) { - enum bpf_reg_type dst_reg_type; + enum bpf_reg_type *prev_dst_type, dst_reg_type; if (BPF_MODE(insn->code) == BPF_XADD) { err = check_xadd(env, insn); @@ -1863,11 +1870,13 @@ static int do_check(struct verifier_env if (err) return err; - if (insn->imm == 0) { - insn->imm = dst_reg_type; - } else if (dst_reg_type != insn->imm && + prev_dst_type = &env->insn_aux_data[insn_idx].ptr_type; + + if (*prev_dst_type == NOT_INIT) { + *prev_dst_type = dst_reg_type; + } else if (dst_reg_type != *prev_dst_type && (dst_reg_type == PTR_TO_CTX || - insn->imm == PTR_TO_CTX)) { + *prev_dst_type == PTR_TO_CTX)) { verbose("same insn cannot be used with different pointers\n"); return -EINVAL; } @@ -2104,17 +2113,17 @@ static void convert_pseudo_ld_imm64(stru static int convert_ctx_accesses(struct verifier_env *env) { struct bpf_insn *insn = env->prog->insnsi; - int insn_cnt = env->prog->len; + const int insn_cnt = env->prog->len; struct bpf_insn insn_buf[16]; struct bpf_prog *new_prog; enum bpf_access_type type; - int i; + int i, delta = 0; if (!env->prog->aux->ops->convert_ctx_access) return 0; for (i = 0; i < insn_cnt; i++, insn++) { - u32 insn_delta, cnt; + u32 cnt; if (insn->code == (BPF_LDX | BPF_MEM | BPF_W)) type = BPF_READ; @@ -2123,11 +2132,8 @@ static int convert_ctx_accesses(struct v else continue; - if (insn->imm != PTR_TO_CTX) { - /* clear internal mark */ - insn->imm = 0; + if (env->insn_aux_data[i].ptr_type != PTR_TO_CTX) continue; - } cnt = env->prog->aux->ops-> convert_ctx_access(type, insn->dst_reg, insn->src_reg, @@ -2137,18 +2143,16 @@ static int convert_ctx_accesses(struct v return -EINVAL; } - new_prog = bpf_patch_insn_single(env->prog, i, insn_buf, cnt); + new_prog = bpf_patch_insn_single(env->prog, i + delta, insn_buf, + cnt); if (!new_prog) return -ENOMEM; - insn_delta = cnt - 1; + delta += cnt - 1; /* keep walking new program and skip insns we just inserted */ env->prog = new_prog; - insn = new_prog->insnsi + i + insn_delta; - - insn_cnt += insn_delta; - i += insn_delta; + insn = new_prog->insnsi + i + delta; } return 0; @@ -2192,6 +2196,11 @@ int bpf_check(struct bpf_prog **prog, un if (!env) return -ENOMEM; + env->insn_aux_data = vzalloc(sizeof(struct bpf_insn_aux_data) * + (*prog)->len); + ret = -ENOMEM; + if (!env->insn_aux_data) + goto err_free_env; env->prog = *prog; /* grab the mutex to protect few globals used by verifier */ @@ -2210,12 +2219,12 @@ int bpf_check(struct bpf_prog **prog, un /* log_* values have to be sane */ if (log_size < 128 || log_size > UINT_MAX >> 8 || log_level == 0 || log_ubuf == NULL) - goto free_env; + goto err_unlock; ret = -ENOMEM; log_buf = vmalloc(log_size); if (!log_buf) - goto free_env; + goto err_unlock; } else { log_level = 0; } @@ -2284,14 +2293,16 @@ skip_full_check: free_log_buf: if (log_level) vfree(log_buf); -free_env: if (!env->prog->aux->used_maps) /* if we didn't copy map pointers into bpf_prog_info, release * them now. Otherwise free_bpf_prog_info() will release them. */ release_maps(env); *prog = env->prog; - kfree(env); +err_unlock: mutex_unlock(&bpf_verifier_lock); + vfree(env->insn_aux_data); +err_free_env: + kfree(env); return ret; } Patches currently in stable-queue which might be from jakub.kicinski(a)netronome.com are queue-4.4/bpf-don-t-ab-use-instructions-to-store-state.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: adjust insn_aux_data when patching insns" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: adjust insn_aux_data when patching insns to the 4.4-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: bpf-adjust-insn_aux_data-when-patching-insns.patch and it can be found in the queue-4.4 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 8041902dae5299c1f194ba42d14383f734631009 Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)fb.com> Date: Wed, 15 Mar 2017 18:26:41 -0700 Subject: bpf: adjust insn_aux_data when patching insns From: Alexei Starovoitov <ast(a)fb.com> commit 8041902dae5299c1f194ba42d14383f734631009 upstream. convert_ctx_accesses() replaces single bpf instruction with a set of instructions. Adjust corresponding insn_aux_data while patching. It's needed to make sure subsequent 'for(all insn)' loops have matching insn and insn_aux_data. Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/verifier.c | 40 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 3 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2107,6 +2107,41 @@ static void convert_pseudo_ld_imm64(stru insn->src_reg = 0; } +/* single env->prog->insni[off] instruction was replaced with the range + * insni[off, off + cnt). Adjust corresponding insn_aux_data by copying + * [0, off) and [off, end) to new locations, so the patched range stays zero + */ +static int adjust_insn_aux_data(struct verifier_env *env, u32 prog_len, + u32 off, u32 cnt) +{ + struct bpf_insn_aux_data *new_data, *old_data = env->insn_aux_data; + + if (cnt == 1) + return 0; + new_data = vzalloc(sizeof(struct bpf_insn_aux_data) * prog_len); + if (!new_data) + return -ENOMEM; + memcpy(new_data, old_data, sizeof(struct bpf_insn_aux_data) * off); + memcpy(new_data + off + cnt - 1, old_data + off, + sizeof(struct bpf_insn_aux_data) * (prog_len - off - cnt + 1)); + env->insn_aux_data = new_data; + vfree(old_data); + return 0; +} + +static struct bpf_prog *bpf_patch_insn_data(struct verifier_env *env, u32 off, + const struct bpf_insn *patch, u32 len) +{ + struct bpf_prog *new_prog; + + new_prog = bpf_patch_insn_single(env->prog, off, patch, len); + if (!new_prog) + return NULL; + if (adjust_insn_aux_data(env, new_prog->len, off, len)) + return NULL; + return new_prog; +} + /* convert load instructions that access fields of 'struct __sk_buff' * into sequence of instructions that access fields of 'struct sk_buff' */ @@ -2132,7 +2167,7 @@ static int convert_ctx_accesses(struct v else continue; - if (env->insn_aux_data[i].ptr_type != PTR_TO_CTX) + if (env->insn_aux_data[i + delta].ptr_type != PTR_TO_CTX) continue; cnt = env->prog->aux->ops-> @@ -2143,8 +2178,7 @@ static int convert_ctx_accesses(struct v return -EINVAL; } - new_prog = bpf_patch_insn_single(env->prog, i + delta, insn_buf, - cnt); + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); if (!new_prog) return -ENOMEM; Patches currently in stable-queue which might be from ast(a)fb.com are queue-4.4/bpf-adjust-insn_aux_data-when-patching-insns.patch queue-4.4/bpf-refactor-fixup_bpf_calls.patch queue-4.4/bpf-move-fixup_bpf_calls-function.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: prevent out-of-bounds speculation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: prevent out-of-bounds speculation to the 4.14-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: bpf-prevent-out-of-bounds-speculation.patch and it can be found in the queue-4.14 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 b2157399cc9898260d6031c5bfe45fe137c1fbe7 Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov <ast(a)kernel.org> Date: Sun, 7 Jan 2018 17:33:02 -0800 Subject: bpf: prevent out-of-bounds speculation From: Alexei Starovoitov <ast(a)kernel.org> commit b2157399cc9898260d6031c5bfe45fe137c1fbe7 upstream. Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. To avoid leaking kernel data round up array-based maps and mask the index after bounds check, so speculated load with out of bounds index will load either valid value from the array or zero from the padded area. Unconditionally mask index for all array types even when max_entries are not rounded to power of 2 for root user. When map is created by unpriv user generate a sequence of bpf insns that includes AND operation to make sure that JITed code includes the same 'index & index_mask' operation. If prog_array map is created by unpriv user replace bpf_tail_call(ctx, map, index); with if (index >= max_entries) { index &= map->index_mask; bpf_tail_call(ctx, map, index); } (along with roundup to power 2) to prevent out-of-bounds speculation. There is secondary redundant 'if (index >= max_entries)' in the interpreter and in all JITs, but they can be optimized later if necessary. Other array-like maps (cpumap, devmap, sockmap, perf_event_array, cgroup_array) cannot be used by unpriv, so no changes there. That fixes bpf side of "Variant 1: bounds check bypass (CVE-2017-5753)" on all architectures with and without JIT. v2->v3: Daniel noticed that attack potentially can be crafted via syscall commands without loading the program, so add masking to those paths as well. Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/bpf.h | 2 ++ kernel/bpf/arraymap.c | 47 ++++++++++++++++++++++++++++++++++++----------- kernel/bpf/verifier.c | 36 ++++++++++++++++++++++++++++++++++++ 3 files changed, 74 insertions(+), 11 deletions(-) --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -51,6 +51,7 @@ struct bpf_map { u32 pages; u32 id; int numa_node; + bool unpriv_array; struct user_struct *user; const struct bpf_map_ops *ops; struct work_struct work; @@ -195,6 +196,7 @@ struct bpf_prog_aux { struct bpf_array { struct bpf_map map; u32 elem_size; + u32 index_mask; /* 'ownership' of prog_array is claimed by the first program that * is going to use this map or by the first program which FD is stored * in the map to make sure that all callers and callees have the same --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -50,9 +50,10 @@ static struct bpf_map *array_map_alloc(u { bool percpu = attr->map_type == BPF_MAP_TYPE_PERCPU_ARRAY; int numa_node = bpf_map_attr_numa_node(attr); + u32 elem_size, index_mask, max_entries; + bool unpriv = !capable(CAP_SYS_ADMIN); struct bpf_array *array; u64 array_size; - u32 elem_size; /* check sanity of attributes */ if (attr->max_entries == 0 || attr->key_size != 4 || @@ -68,11 +69,20 @@ static struct bpf_map *array_map_alloc(u elem_size = round_up(attr->value_size, 8); + max_entries = attr->max_entries; + index_mask = roundup_pow_of_two(max_entries) - 1; + + if (unpriv) + /* round up array size to nearest power of 2, + * since cpu will speculate within index_mask limits + */ + max_entries = index_mask + 1; + array_size = sizeof(*array); if (percpu) - array_size += (u64) attr->max_entries * sizeof(void *); + array_size += (u64) max_entries * sizeof(void *); else - array_size += (u64) attr->max_entries * elem_size; + array_size += (u64) max_entries * elem_size; /* make sure there is no u32 overflow later in round_up() */ if (array_size >= U32_MAX - PAGE_SIZE) @@ -82,6 +92,8 @@ static struct bpf_map *array_map_alloc(u array = bpf_map_area_alloc(array_size, numa_node); if (!array) return ERR_PTR(-ENOMEM); + array->index_mask = index_mask; + array->map.unpriv_array = unpriv; /* copy mandatory map attributes */ array->map.map_type = attr->map_type; @@ -117,12 +129,13 @@ static void *array_map_lookup_elem(struc if (unlikely(index >= array->map.max_entries)) return NULL; - return array->value + array->elem_size * index; + return array->value + array->elem_size * (index & array->index_mask); } /* emit BPF instructions equivalent to C code of array_map_lookup_elem() */ static u32 array_map_gen_lookup(struct bpf_map *map, struct bpf_insn *insn_buf) { + struct bpf_array *array = container_of(map, struct bpf_array, map); struct bpf_insn *insn = insn_buf; u32 elem_size = round_up(map->value_size, 8); const int ret = BPF_REG_0; @@ -131,7 +144,12 @@ static u32 array_map_gen_lookup(struct b *insn++ = BPF_ALU64_IMM(BPF_ADD, map_ptr, offsetof(struct bpf_array, value)); *insn++ = BPF_LDX_MEM(BPF_W, ret, index, 0); - *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 3); + if (map->unpriv_array) { + *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 4); + *insn++ = BPF_ALU32_IMM(BPF_AND, ret, array->index_mask); + } else { + *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 3); + } if (is_power_of_2(elem_size)) { *insn++ = BPF_ALU64_IMM(BPF_LSH, ret, ilog2(elem_size)); @@ -153,7 +171,7 @@ static void *percpu_array_map_lookup_ele if (unlikely(index >= array->map.max_entries)) return NULL; - return this_cpu_ptr(array->pptrs[index]); + return this_cpu_ptr(array->pptrs[index & array->index_mask]); } int bpf_percpu_array_copy(struct bpf_map *map, void *key, void *value) @@ -173,7 +191,7 @@ int bpf_percpu_array_copy(struct bpf_map */ size = round_up(map->value_size, 8); rcu_read_lock(); - pptr = array->pptrs[index]; + pptr = array->pptrs[index & array->index_mask]; for_each_possible_cpu(cpu) { bpf_long_memcpy(value + off, per_cpu_ptr(pptr, cpu), size); off += size; @@ -221,10 +239,11 @@ static int array_map_update_elem(struct return -EEXIST; if (array->map.map_type == BPF_MAP_TYPE_PERCPU_ARRAY) - memcpy(this_cpu_ptr(array->pptrs[index]), + memcpy(this_cpu_ptr(array->pptrs[index & array->index_mask]), value, map->value_size); else - memcpy(array->value + array->elem_size * index, + memcpy(array->value + + array->elem_size * (index & array->index_mask), value, map->value_size); return 0; } @@ -258,7 +277,7 @@ int bpf_percpu_array_update(struct bpf_m */ size = round_up(map->value_size, 8); rcu_read_lock(); - pptr = array->pptrs[index]; + pptr = array->pptrs[index & array->index_mask]; for_each_possible_cpu(cpu) { bpf_long_memcpy(per_cpu_ptr(pptr, cpu), value + off, size); off += size; @@ -609,6 +628,7 @@ static void *array_of_map_lookup_elem(st static u32 array_of_map_gen_lookup(struct bpf_map *map, struct bpf_insn *insn_buf) { + struct bpf_array *array = container_of(map, struct bpf_array, map); u32 elem_size = round_up(map->value_size, 8); struct bpf_insn *insn = insn_buf; const int ret = BPF_REG_0; @@ -617,7 +637,12 @@ static u32 array_of_map_gen_lookup(struc *insn++ = BPF_ALU64_IMM(BPF_ADD, map_ptr, offsetof(struct bpf_array, value)); *insn++ = BPF_LDX_MEM(BPF_W, ret, index, 0); - *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 5); + if (map->unpriv_array) { + *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 6); + *insn++ = BPF_ALU32_IMM(BPF_AND, ret, array->index_mask); + } else { + *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 5); + } if (is_power_of_2(elem_size)) *insn++ = BPF_ALU64_IMM(BPF_LSH, ret, ilog2(elem_size)); else --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -1701,6 +1701,13 @@ static int check_call(struct bpf_verifie err = check_func_arg(env, BPF_REG_2, fn->arg2_type, &meta); if (err) return err; + if (func_id == BPF_FUNC_tail_call) { + if (meta.map_ptr == NULL) { + verbose(env, "verifier bug\n"); + return -EINVAL; + } + env->insn_aux_data[insn_idx].map_ptr = meta.map_ptr; + } err = check_func_arg(env, BPF_REG_3, fn->arg3_type, &meta); if (err) return err; @@ -4315,6 +4322,35 @@ static int fixup_bpf_calls(struct bpf_ve */ insn->imm = 0; insn->code = BPF_JMP | BPF_TAIL_CALL; + + /* instead of changing every JIT dealing with tail_call + * emit two extra insns: + * if (index >= max_entries) goto out; + * index &= array->index_mask; + * to avoid out-of-bounds cpu speculation + */ + map_ptr = env->insn_aux_data[i + delta].map_ptr; + if (map_ptr == BPF_MAP_PTR_POISON) { + verbose(env, "tail_call obusing map_ptr\n"); + return -EINVAL; + } + if (!map_ptr->unpriv_array) + continue; + insn_buf[0] = BPF_JMP_IMM(BPF_JGE, BPF_REG_3, + map_ptr->max_entries, 2); + insn_buf[1] = BPF_ALU32_IMM(BPF_AND, BPF_REG_3, + container_of(map_ptr, + struct bpf_array, + map)->index_mask); + insn_buf[2] = *insn; + cnt = 3; + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); + if (!new_prog) + return -ENOMEM; + + delta += cnt - 1; + env->prog = prog = new_prog; + insn = new_prog->insnsi + i + delta; continue; } Patches currently in stable-queue which might be from ast(a)kernel.org are queue-4.14/bpf-prevent-out-of-bounds-speculation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading with a revision check" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading with a revision check to the 4.9-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: x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch and it can be found in the queue-4.9 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 b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001 From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Date: Mon, 1 Jan 2018 10:04:47 +0800 Subject: x86/microcode/intel: Extend BDW late-loading with a revision check From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> commit b94b7373317164402ff7728d10f7023127a02b60 upstream. Instead of blacklisting all model 79 CPUs when attempting a late microcode loading, limit that only to CPUs with microcode revisions < 0x0b000021 because only on those late loading may cause a system hang. For such processors either: a) a BIOS update which might contain a newer microcode revision or b) the early microcode loading method should be considered. Processors with revisions 0x0b000021 or higher will not experience such hangs. For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. [ bp: Heavily massage commit message and pr_* statements. ] Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79") Signed-off-by: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Cc: x86-ml <x86(a)kernel.org> Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@aliba… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -1051,8 +1051,17 @@ static bool is_blacklisted(unsigned int { struct cpuinfo_x86 *c = &cpu_data(cpu); - if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X) { - pr_err_once("late loading on model 79 is disabled.\n"); + /* + * Late loading on model 79 with microcode revision less than 0x0b000021 + * may result in a system hang. This behavior is documented in item + * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + */ + if (c->x86 == 6 && + c->x86_model == INTEL_FAM6_BROADWELL_X && + c->x86_mask == 0x01 && + c->microcode < 0x0b000021) { + pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); + pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); return true; } Patches currently in stable-queue which might be from qianyue.zj(a)alibaba-inc.com are queue-4.9/x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "rbd: set max_segments to USHRT_MAX" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rbd: set max_segments to USHRT_MAX to the 4.9-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: rbd-set-max_segments-to-ushrt_max.patch and it can be found in the queue-4.9 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 21acdf45f4958135940f0b4767185cf911d4b010 Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Thu, 21 Dec 2017 15:35:11 +0100 Subject: rbd: set max_segments to USHRT_MAX From: Ilya Dryomov <idryomov(a)gmail.com> commit 21acdf45f4958135940f0b4767185cf911d4b010 upstream. Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped max_segments (unsigned short) to max_hw_sectors (unsigned int). max_hw_sectors is set to the number of 512-byte sectors in an object and overflows unsigned short for 32M (largest possible) objects, making the block layer resort to handing us single segment (i.e. single page or even smaller) bios in that case. Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments") Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: Alex Elder <elder(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -4511,7 +4511,7 @@ static int rbd_init_disk(struct rbd_devi segment_size = rbd_obj_bytes(&rbd_dev->header); blk_queue_max_hw_sectors(q, segment_size / SECTOR_SIZE); q->limits.max_sectors = queue_max_hw_sectors(q); - blk_queue_max_segments(q, segment_size / SECTOR_SIZE); + blk_queue_max_segments(q, USHRT_MAX); blk_queue_max_segment_size(q, segment_size); blk_queue_io_min(q, segment_size); blk_queue_io_opt(q, segment_size); Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.9/rbd-set-max_segments-to-ushrt_max.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: Add memory barrier on vmcs field lookup" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Add memory barrier on vmcs field lookup to the 4.9-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: kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch and it can be found in the queue-4.9 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 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 Mon Sep 17 00:00:00 2001 From: Andrew Honig <ahonig(a)google.com> Date: Wed, 10 Jan 2018 10:12:03 -0800 Subject: KVM: x86: Add memory barrier on vmcs field lookup From: Andrew Honig <ahonig(a)google.com> commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 upstream. This adds a memory barrier when performing a lookup into the vmcs_field_to_offset_table. This is related to CVE-2017-5753. Signed-off-by: Andrew Honig <ahonig(a)google.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -857,8 +857,16 @@ static inline short vmcs_field_to_offset { BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX); - if (field >= ARRAY_SIZE(vmcs_field_to_offset_table) || - vmcs_field_to_offset_table[field] == 0) + if (field >= ARRAY_SIZE(vmcs_field_to_offset_table)) + return -ENOENT; + + /* + * FIXME: Mitigation for CVE-2017-5753. To be replaced with a + * generic mechanism. + */ + asm("lfence"); + + if (vmcs_field_to_offset_table[field] == 0) return -ENOENT; return vmcs_field_to_offset_table[field]; Patches currently in stable-queue which might be from ahonig(a)google.com are queue-4.9/kvm-vmx-scrub-hardware-gprs-at-vm-exit.patch queue-4.9/kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Potential off by one in vmw_view_add()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vmwgfx: Potential off by one in vmw_view_add() to the 4.9-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: drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch and it can be found in the queue-4.9 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 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 10 Jan 2018 12:40:04 +0300 Subject: drm/vmwgfx: Potential off by one in vmw_view_add() From: Dan Carpenter <dan.carpenter(a)oracle.com> commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 upstream. The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error. It's one element beyond the end of the vmw_view_cotables[] table. My read on this is that it's possible to hit this failure. header->id comes from vmw_cmd_check() and it's a user controlled number between 1040 and 1225 so we can hit that error. But I don't have the hardware to test this code. Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -2729,6 +2729,8 @@ static int vmw_cmd_dx_view_define(struct } view_type = vmw_view_cmd_to_type(header->id); + if (view_type == vmw_view_max) + return -EINVAL; cmd = container_of(header, typeof(*cmd), header); ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface, user_surface_converter, Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.9/drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: algapi - fix NULL dereference in crypto_remove_spawns()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: algapi - fix NULL dereference in crypto_remove_spawns() to the 4.9-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: crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch and it can be found in the queue-4.9 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 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 29 Dec 2017 14:30:19 -0600 Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns() From: Eric Biggers <ebiggers(a)google.com> commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream. syzkaller triggered a NULL pointer dereference in crypto_remove_spawns() via a program that repeatedly and concurrently requests AEADs "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)" through AF_ALG, where the hashes are requested as "untested" (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this causes the template to be instantiated for every request). Although AF_ALG users really shouldn't be able to request an "untested" algorithm, the NULL pointer dereference is actually caused by a longstanding race condition where crypto_remove_spawns() can encounter an instance which has had spawn(s) "grabbed" but hasn't yet been registered, resulting in ->cra_users still being NULL. We probably should properly initialize ->cra_users earlier, but that would require updating many templates individually. For now just fix the bug in a simple way that can easily be backported: make crypto_remove_spawns() treat a NULL ->cra_users list as empty. Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/algapi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/crypto/algapi.c +++ b/crypto/algapi.c @@ -167,6 +167,18 @@ void crypto_remove_spawns(struct crypto_ spawn->alg = NULL; spawns = &inst->alg.cra_users; + + /* + * We may encounter an unregistered instance here, since + * an instance's spawns are set up prior to the instance + * being registered. An unregistered instance will have + * NULL ->cra_users.next, since ->cra_users isn't + * properly initialized until registration. But an + * unregistered instance cannot have any users, so treat + * it the same as ->cra_users being empty. + */ + if (spawns->next == NULL) + break; } } while ((spawns = crypto_more_spawns(alg, &stack, &top, &secondary_spawns))); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading with a revision check" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading with a revision check to the 4.4-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: x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch and it can be found in the queue-4.4 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 b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001 From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Date: Mon, 1 Jan 2018 10:04:47 +0800 Subject: x86/microcode/intel: Extend BDW late-loading with a revision check From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> commit b94b7373317164402ff7728d10f7023127a02b60 upstream. Instead of blacklisting all model 79 CPUs when attempting a late microcode loading, limit that only to CPUs with microcode revisions < 0x0b000021 because only on those late loading may cause a system hang. For such processors either: a) a BIOS update which might contain a newer microcode revision or b) the early microcode loading method should be considered. Processors with revisions 0x0b000021 or higher will not experience such hangs. For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. [ bp: Heavily massage commit message and pr_* statements. ] Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79") Signed-off-by: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Cc: x86-ml <x86(a)kernel.org> Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@aliba… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -994,9 +994,17 @@ static bool is_blacklisted(unsigned int { struct cpuinfo_x86 *c = &cpu_data(cpu); - if (c->x86 == 6 && c->x86_model == 79) { - pr_err_once("late loading on model 79 is disabled.\n"); - return true; + /* + * Late loading on model 79 with microcode revision less than 0x0b000021 + * may result in a system hang. This behavior is documented in item + * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + */ + if (c->x86 == 6 && + c->x86_model == 79 && + c->x86_mask == 0x01 && + c->microcode < 0x0b000021) { + pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); + pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); } return false; Patches currently in stable-queue which might be from qianyue.zj(a)alibaba-inc.com are queue-4.4/x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "rbd: set max_segments to USHRT_MAX" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rbd: set max_segments to USHRT_MAX to the 4.4-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: rbd-set-max_segments-to-ushrt_max.patch and it can be found in the queue-4.4 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 21acdf45f4958135940f0b4767185cf911d4b010 Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Thu, 21 Dec 2017 15:35:11 +0100 Subject: rbd: set max_segments to USHRT_MAX From: Ilya Dryomov <idryomov(a)gmail.com> commit 21acdf45f4958135940f0b4767185cf911d4b010 upstream. Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped max_segments (unsigned short) to max_hw_sectors (unsigned int). max_hw_sectors is set to the number of 512-byte sectors in an object and overflows unsigned short for 32M (largest possible) objects, making the block layer resort to handing us single segment (i.e. single page or even smaller) bios in that case. Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments") Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: Alex Elder <elder(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -3767,7 +3767,7 @@ static int rbd_init_disk(struct rbd_devi segment_size = rbd_obj_bytes(&rbd_dev->header); blk_queue_max_hw_sectors(q, segment_size / SECTOR_SIZE); q->limits.max_sectors = queue_max_hw_sectors(q); - blk_queue_max_segments(q, segment_size / SECTOR_SIZE); + blk_queue_max_segments(q, USHRT_MAX); blk_queue_max_segment_size(q, segment_size); blk_queue_io_min(q, segment_size); blk_queue_io_opt(q, segment_size); Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.4/rbd-set-max_segments-to-ushrt_max.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: Add memory barrier on vmcs field lookup" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Add memory barrier on vmcs field lookup to the 4.4-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: kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch and it can be found in the queue-4.4 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 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 Mon Sep 17 00:00:00 2001 From: Andrew Honig <ahonig(a)google.com> Date: Wed, 10 Jan 2018 10:12:03 -0800 Subject: KVM: x86: Add memory barrier on vmcs field lookup From: Andrew Honig <ahonig(a)google.com> commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 upstream. This adds a memory barrier when performing a lookup into the vmcs_field_to_offset_table. This is related to CVE-2017-5753. Signed-off-by: Andrew Honig <ahonig(a)google.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -828,8 +828,16 @@ static inline short vmcs_field_to_offset { BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX); - if (field >= ARRAY_SIZE(vmcs_field_to_offset_table) || - vmcs_field_to_offset_table[field] == 0) + if (field >= ARRAY_SIZE(vmcs_field_to_offset_table)) + return -ENOENT; + + /* + * FIXME: Mitigation for CVE-2017-5753. To be replaced with a + * generic mechanism. + */ + asm("lfence"); + + if (vmcs_field_to_offset_table[field] == 0) return -ENOENT; return vmcs_field_to_offset_table[field]; Patches currently in stable-queue which might be from ahonig(a)google.com are queue-4.4/kvm-vmx-scrub-hardware-gprs-at-vm-exit.patch queue-4.4/kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Potential off by one in vmw_view_add()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vmwgfx: Potential off by one in vmw_view_add() to the 4.4-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: drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch and it can be found in the queue-4.4 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 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 10 Jan 2018 12:40:04 +0300 Subject: drm/vmwgfx: Potential off by one in vmw_view_add() From: Dan Carpenter <dan.carpenter(a)oracle.com> commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 upstream. The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error. It's one element beyond the end of the vmw_view_cotables[] table. My read on this is that it's possible to hit this failure. header->id comes from vmw_cmd_check() and it's a user controlled number between 1040 and 1225 so we can hit that error. But I don't have the hardware to test this code. Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -2678,6 +2678,8 @@ static int vmw_cmd_dx_view_define(struct } view_type = vmw_view_cmd_to_type(header->id); + if (view_type == vmw_view_max) + return -EINVAL; cmd = container_of(header, typeof(*cmd), header); ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface, user_surface_converter, Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.4/drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: algapi - fix NULL dereference in crypto_remove_spawns()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: algapi - fix NULL dereference in crypto_remove_spawns() to the 4.4-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: crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch and it can be found in the queue-4.4 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 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 29 Dec 2017 14:30:19 -0600 Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns() From: Eric Biggers <ebiggers(a)google.com> commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream. syzkaller triggered a NULL pointer dereference in crypto_remove_spawns() via a program that repeatedly and concurrently requests AEADs "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)" through AF_ALG, where the hashes are requested as "untested" (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this causes the template to be instantiated for every request). Although AF_ALG users really shouldn't be able to request an "untested" algorithm, the NULL pointer dereference is actually caused by a longstanding race condition where crypto_remove_spawns() can encounter an instance which has had spawn(s) "grabbed" but hasn't yet been registered, resulting in ->cra_users still being NULL. We probably should properly initialize ->cra_users earlier, but that would require updating many templates individually. For now just fix the bug in a simple way that can easily be backported: make crypto_remove_spawns() treat a NULL ->cra_users list as empty. Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/algapi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/crypto/algapi.c +++ b/crypto/algapi.c @@ -168,6 +168,18 @@ void crypto_remove_spawns(struct crypto_ spawn->alg = NULL; spawns = &inst->alg.cra_users; + + /* + * We may encounter an unregistered instance here, since + * an instance's spawns are set up prior to the instance + * being registered. An unregistered instance will have + * NULL ->cra_users.next, since ->cra_users isn't + * properly initialized until registration. But an + * unregistered instance cannot have any users, so treat + * it the same as ->cra_users being empty. + */ + if (spawns->next == NULL) + break; } } while ((spawns = crypto_more_spawns(alg, &stack, &top, &secondary_spawns))); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.4/crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: add bpf_patch_insn_single helper" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: add bpf_patch_insn_single helper to the 4.4-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: bpf-add-bpf_patch_insn_single-helper.patch and it can be found in the queue-4.4 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 c237ee5eb33bf19fe0591c04ff8db19da7323a83 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Fri, 13 May 2016 19:08:30 +0200 Subject: bpf: add bpf_patch_insn_single helper From: Daniel Borkmann <daniel(a)iogearbox.net> commit c237ee5eb33bf19fe0591c04ff8db19da7323a83 upstream. Move the functionality to patch instructions out of the verifier code and into the core as the new bpf_patch_insn_single() helper will be needed later on for blinding as well. No changes in functionality. Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/include/linux/filter.h b/include/linux/filter.h index 4ff0e647598f..c4aae496f376 100644 --- a/include/linux/filter.h +++ b/include/linux/filter.h @@ -495,6 +495,9 @@ u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5); void bpf_int_jit_compile(struct bpf_prog *fp); bool bpf_helper_changes_skb_data(void *func); +struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off, + const struct bpf_insn *patch, u32 len); + #ifdef CONFIG_BPF_JIT extern int bpf_jit_enable; diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index 5313d09d4b62..49b5538a5301 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -136,6 +136,77 @@ void __bpf_prog_free(struct bpf_prog *fp) vfree(fp); } +static bool bpf_is_jmp_and_has_target(const struct bpf_insn *insn) +{ + return BPF_CLASS(insn->code) == BPF_JMP && + /* Call and Exit are both special jumps with no + * target inside the BPF instruction image. + */ + BPF_OP(insn->code) != BPF_CALL && + BPF_OP(insn->code) != BPF_EXIT; +} + +static void bpf_adj_branches(struct bpf_prog *prog, u32 pos, u32 delta) +{ + struct bpf_insn *insn = prog->insnsi; + u32 i, insn_cnt = prog->len; + + for (i = 0; i < insn_cnt; i++, insn++) { + if (!bpf_is_jmp_and_has_target(insn)) + continue; + + /* Adjust offset of jmps if we cross boundaries. */ + if (i < pos && i + insn->off + 1 > pos) + insn->off += delta; + else if (i > pos + delta && i + insn->off + 1 <= pos + delta) + insn->off -= delta; + } +} + +struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off, + const struct bpf_insn *patch, u32 len) +{ + u32 insn_adj_cnt, insn_rest, insn_delta = len - 1; + struct bpf_prog *prog_adj; + + /* Since our patchlet doesn't expand the image, we're done. */ + if (insn_delta == 0) { + memcpy(prog->insnsi + off, patch, sizeof(*patch)); + return prog; + } + + insn_adj_cnt = prog->len + insn_delta; + + /* Several new instructions need to be inserted. Make room + * for them. Likely, there's no need for a new allocation as + * last page could have large enough tailroom. + */ + prog_adj = bpf_prog_realloc(prog, bpf_prog_size(insn_adj_cnt), + GFP_USER); + if (!prog_adj) + return NULL; + + prog_adj->len = insn_adj_cnt; + + /* Patching happens in 3 steps: + * + * 1) Move over tail of insnsi from next instruction onwards, + * so we can patch the single target insn with one or more + * new ones (patching is always from 1 to n insns, n > 0). + * 2) Inject new instructions at the target location. + * 3) Adjust branch offsets if necessary. + */ + insn_rest = insn_adj_cnt - off - len; + + memmove(prog_adj->insnsi + off + len, prog_adj->insnsi + off + 1, + sizeof(*patch) * insn_rest); + memcpy(prog_adj->insnsi + off, patch, sizeof(*patch) * len); + + bpf_adj_branches(prog_adj, off, insn_delta); + + return prog_adj; +} + #ifdef CONFIG_BPF_JIT struct bpf_binary_header * bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr, diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 84bff68cf80e..a08d66215245 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2587,26 +2587,6 @@ static void convert_pseudo_ld_imm64(struct verifier_env *env) insn->src_reg = 0; } -static void adjust_branches(struct bpf_prog *prog, int pos, int delta) -{ - struct bpf_insn *insn = prog->insnsi; - int insn_cnt = prog->len; - int i; - - for (i = 0; i < insn_cnt; i++, insn++) { - if (BPF_CLASS(insn->code) != BPF_JMP || - BPF_OP(insn->code) == BPF_CALL || - BPF_OP(insn->code) == BPF_EXIT) - continue; - - /* adjust offset of jmps if necessary */ - if (i < pos && i + insn->off + 1 > pos) - insn->off += delta; - else if (i > pos + delta && i + insn->off + 1 <= pos + delta) - insn->off -= delta; - } -} - /* convert load instructions that access fields of 'struct __sk_buff' * into sequence of instructions that access fields of 'struct sk_buff' */ @@ -2616,14 +2596,15 @@ static int convert_ctx_accesses(struct verifier_env *env) int insn_cnt = env->prog->len; struct bpf_insn insn_buf[16]; struct bpf_prog *new_prog; - u32 cnt; - int i; enum bpf_access_type type; + int i; if (!env->prog->aux->ops->convert_ctx_access) return 0; for (i = 0; i < insn_cnt; i++, insn++) { + u32 insn_delta, cnt; + if (insn->code == (BPF_LDX | BPF_MEM | BPF_W)) type = BPF_READ; else if (insn->code == (BPF_STX | BPF_MEM | BPF_W)) @@ -2645,34 +2626,18 @@ static int convert_ctx_accesses(struct verifier_env *env) return -EINVAL; } - if (cnt == 1) { - memcpy(insn, insn_buf, sizeof(*insn)); - continue; - } - - /* several new insns need to be inserted. Make room for them */ - insn_cnt += cnt - 1; - new_prog = bpf_prog_realloc(env->prog, - bpf_prog_size(insn_cnt), - GFP_USER); + new_prog = bpf_patch_insn_single(env->prog, i, insn_buf, cnt); if (!new_prog) return -ENOMEM; - new_prog->len = insn_cnt; - - memmove(new_prog->insnsi + i + cnt, new_prog->insns + i + 1, - sizeof(*insn) * (insn_cnt - i - cnt)); - - /* copy substitute insns in place of load instruction */ - memcpy(new_prog->insnsi + i, insn_buf, sizeof(*insn) * cnt); - - /* adjust branches in the whole program */ - adjust_branches(new_prog, i, cnt - 1); + insn_delta = cnt - 1; /* keep walking new program and skip insns we just inserted */ env->prog = new_prog; - insn = new_prog->insnsi + i + cnt - 1; - i += cnt - 1; + insn = new_prog->insnsi + i + insn_delta; + + insn_cnt += insn_delta; + i += insn_delta; } return 0; Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.4/bpf-add-bpf_patch_insn_single-helper.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading with a revision check" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading with a revision check to the 4.14-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: x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch and it can be found in the queue-4.14 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 b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001 From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Date: Mon, 1 Jan 2018 10:04:47 +0800 Subject: x86/microcode/intel: Extend BDW late-loading with a revision check From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> commit b94b7373317164402ff7728d10f7023127a02b60 upstream. Instead of blacklisting all model 79 CPUs when attempting a late microcode loading, limit that only to CPUs with microcode revisions < 0x0b000021 because only on those late loading may cause a system hang. For such processors either: a) a BIOS update which might contain a newer microcode revision or b) the early microcode loading method should be considered. Processors with revisions 0x0b000021 or higher will not experience such hangs. For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. [ bp: Heavily massage commit message and pr_* statements. ] Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79") Signed-off-by: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Cc: x86-ml <x86(a)kernel.org> Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@aliba… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -910,8 +910,17 @@ static bool is_blacklisted(unsigned int { struct cpuinfo_x86 *c = &cpu_data(cpu); - if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X) { - pr_err_once("late loading on model 79 is disabled.\n"); + /* + * Late loading on model 79 with microcode revision less than 0x0b000021 + * may result in a system hang. This behavior is documented in item + * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + */ + if (c->x86 == 6 && + c->x86_model == INTEL_FAM6_BROADWELL_X && + c->x86_mask == 0x01 && + c->microcode < 0x0b000021) { + pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); + pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); return true; } Patches currently in stable-queue which might be from qianyue.zj(a)alibaba-inc.com are queue-4.14/x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "rbd: set max_segments to USHRT_MAX" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rbd: set max_segments to USHRT_MAX to the 4.14-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: rbd-set-max_segments-to-ushrt_max.patch and it can be found in the queue-4.14 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 21acdf45f4958135940f0b4767185cf911d4b010 Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Thu, 21 Dec 2017 15:35:11 +0100 Subject: rbd: set max_segments to USHRT_MAX From: Ilya Dryomov <idryomov(a)gmail.com> commit 21acdf45f4958135940f0b4767185cf911d4b010 upstream. Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped max_segments (unsigned short) to max_hw_sectors (unsigned int). max_hw_sectors is set to the number of 512-byte sectors in an object and overflows unsigned short for 32M (largest possible) objects, making the block layer resort to handing us single segment (i.e. single page or even smaller) bios in that case. Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments") Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: Alex Elder <elder(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -4421,7 +4421,7 @@ static int rbd_init_disk(struct rbd_devi segment_size = rbd_obj_bytes(&rbd_dev->header); blk_queue_max_hw_sectors(q, segment_size / SECTOR_SIZE); q->limits.max_sectors = queue_max_hw_sectors(q); - blk_queue_max_segments(q, segment_size / SECTOR_SIZE); + blk_queue_max_segments(q, USHRT_MAX); blk_queue_max_segment_size(q, segment_size); blk_queue_io_min(q, segment_size); blk_queue_io_opt(q, segment_size); Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.14/rbd-reacquire-lock-should-update-lock-owner-client-id.patch queue-4.14/rbd-set-max_segments-to-ushrt_max.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "rbd: reacquire lock should update lock owner client id" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rbd: reacquire lock should update lock owner client id to the 4.14-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: rbd-reacquire-lock-should-update-lock-owner-client-id.patch and it can be found in the queue-4.14 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 edd8ca8015800b354453b891d38960f3a474b7e4 Mon Sep 17 00:00:00 2001 From: Florian Margaine <florian(a)platform.sh> Date: Wed, 13 Dec 2017 16:43:59 +0100 Subject: rbd: reacquire lock should update lock owner client id From: Florian Margaine <florian(a)platform.sh> commit edd8ca8015800b354453b891d38960f3a474b7e4 upstream. Otherwise, future operations on this RBD using exclusive-lock are going to require the lock from a non-existent client id. Fixes: 14bb211d324d ("rbd: support updating the lock cookie without releasing the lock") Link: http://tracker.ceph.com/issues/19929 Signed-off-by: Florian Margaine <florian(a)platform.sh> [idryomov(a)gmail.com: rbd_set_owner_cid() call, __rbd_lock() helper] Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -3074,13 +3074,21 @@ static void format_lock_cookie(struct rb mutex_unlock(&rbd_dev->watch_mutex); } +static void __rbd_lock(struct rbd_device *rbd_dev, const char *cookie) +{ + struct rbd_client_id cid = rbd_get_cid(rbd_dev); + + strcpy(rbd_dev->lock_cookie, cookie); + rbd_set_owner_cid(rbd_dev, &cid); + queue_work(rbd_dev->task_wq, &rbd_dev->acquired_lock_work); +} + /* * lock_rwsem must be held for write */ static int rbd_lock(struct rbd_device *rbd_dev) { struct ceph_osd_client *osdc = &rbd_dev->rbd_client->client->osdc; - struct rbd_client_id cid = rbd_get_cid(rbd_dev); char cookie[32]; int ret; @@ -3095,9 +3103,7 @@ static int rbd_lock(struct rbd_device *r return ret; rbd_dev->lock_state = RBD_LOCK_STATE_LOCKED; - strcpy(rbd_dev->lock_cookie, cookie); - rbd_set_owner_cid(rbd_dev, &cid); - queue_work(rbd_dev->task_wq, &rbd_dev->acquired_lock_work); + __rbd_lock(rbd_dev, cookie); return 0; } @@ -3883,7 +3889,7 @@ static void rbd_reacquire_lock(struct rb queue_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); } else { - strcpy(rbd_dev->lock_cookie, cookie); + __rbd_lock(rbd_dev, cookie); } } Patches currently in stable-queue which might be from florian(a)platform.sh are queue-4.14/rbd-reacquire-lock-should-update-lock-owner-client-id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mmc: renesas_sdhi: Add MODULE_LICENSE" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: renesas_sdhi: Add MODULE_LICENSE to the 4.14-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: mmc-renesas_sdhi-add-module_license.patch and it can be found in the queue-4.14 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 967a6a07e95c58eb9c1581d22a1d9c2d1929843f Mon Sep 17 00:00:00 2001 From: Masaharu Hayakawa <masaharu.hayakawa.ry(a)renesas.com> Date: Wed, 13 Dec 2017 11:33:00 +0900 Subject: mmc: renesas_sdhi: Add MODULE_LICENSE From: Masaharu Hayakawa <masaharu.hayakawa.ry(a)renesas.com> commit 967a6a07e95c58eb9c1581d22a1d9c2d1929843f upstream. The following error occurs when loading renesas_sdhi_core.c module, so add MODULE_LICENSE("GPL v2"). renesas_sdhi_core: module license 'unspecified' taints kernel. Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry(a)renesas.com> Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module file") [Shimoda: Added Fixes tag and Cc to the stable ML] Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Reviewed-by: Simon Horman <horms+renesas(a)verge.net.au> Acked-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/renesas_sdhi_core.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/mmc/host/renesas_sdhi_core.c +++ b/drivers/mmc/host/renesas_sdhi_core.c @@ -24,6 +24,7 @@ #include <linux/kernel.h> #include <linux/clk.h> #include <linux/slab.h> +#include <linux/module.h> #include <linux/of_device.h> #include <linux/platform_device.h> #include <linux/mmc/host.h> @@ -667,3 +668,5 @@ int renesas_sdhi_remove(struct platform_ return 0; } EXPORT_SYMBOL_GPL(renesas_sdhi_remove); + +MODULE_LICENSE("GPL v2"); Patches currently in stable-queue which might be from masaharu.hayakawa.ry(a)renesas.com are queue-4.14/mmc-renesas_sdhi-add-module_license.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: Add memory barrier on vmcs field lookup" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Add memory barrier on vmcs field lookup to the 4.14-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: kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch and it can be found in the queue-4.14 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 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 Mon Sep 17 00:00:00 2001 From: Andrew Honig <ahonig(a)google.com> Date: Wed, 10 Jan 2018 10:12:03 -0800 Subject: KVM: x86: Add memory barrier on vmcs field lookup From: Andrew Honig <ahonig(a)google.com> commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 upstream. This adds a memory barrier when performing a lookup into the vmcs_field_to_offset_table. This is related to CVE-2017-5753. Signed-off-by: Andrew Honig <ahonig(a)google.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -888,8 +888,16 @@ static inline short vmcs_field_to_offset { BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX); - if (field >= ARRAY_SIZE(vmcs_field_to_offset_table) || - vmcs_field_to_offset_table[field] == 0) + if (field >= ARRAY_SIZE(vmcs_field_to_offset_table)) + return -ENOENT; + + /* + * FIXME: Mitigation for CVE-2017-5753. To be replaced with a + * generic mechanism. + */ + asm("lfence"); + + if (vmcs_field_to_offset_table[field] == 0) return -ENOENT; return vmcs_field_to_offset_table[field]; Patches currently in stable-queue which might be from ahonig(a)google.com are queue-4.14/kvm-vmx-scrub-hardware-gprs-at-vm-exit.patch queue-4.14/kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: PPC: Book3S PR: Fix WIMG handling under pHyp" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S PR: Fix WIMG handling under pHyp to the 4.14-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: kvm-ppc-book3s-pr-fix-wimg-handling-under-phyp.patch and it can be found in the queue-4.14 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 6c7d47c33ed323f14f2a3b8de925e831dbaa4e69 Mon Sep 17 00:00:00 2001 From: Alexey Kardashevskiy <aik(a)ozlabs.ru> Date: Wed, 22 Nov 2017 14:42:21 +1100 Subject: KVM: PPC: Book3S PR: Fix WIMG handling under pHyp From: Alexey Kardashevskiy <aik(a)ozlabs.ru> commit 6c7d47c33ed323f14f2a3b8de925e831dbaa4e69 upstream. Commit 96df226 ("KVM: PPC: Book3S PR: Preserve storage control bits") added code to preserve WIMG bits but it missed 2 special cases: - a magic page in kvmppc_mmu_book3s_64_xlate() and - guest real mode in kvmppc_handle_pagefault(). For these ptes, WIMG was 0 and pHyp failed on these causing a guest to stop in the very beginning at NIP=0x100 (due to bd9166ffe "KVM: PPC: Book3S PR: Exit KVM on failed mapping"). According to LoPAPR v1.1 14.5.4.1.2 H_ENTER: The hypervisor checks that the WIMG bits within the PTE are appropriate for the physical page number else H_Parameter return. (For System Memory pages WIMG=0010, or, 1110 if the SAO option is enabled, and for IO pages WIMG=01**.) This hence initializes WIMG to non-zero value HPTE_R_M (0x10), as expected by pHyp. [paulus(a)ozlabs.org - fix compile for 32-bit] Fixes: 96df226 "KVM: PPC: Book3S PR: Preserve storage control bits" Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Tested-by: Ruediger Oertel <ro(a)suse.de> Reviewed-by: Greg Kurz <groug(a)kaod.org> Tested-by: Greg Kurz <groug(a)kaod.org> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_64_mmu.c | 1 + arch/powerpc/kvm/book3s_pr.c | 2 ++ 2 files changed, 3 insertions(+) --- a/arch/powerpc/kvm/book3s_64_mmu.c +++ b/arch/powerpc/kvm/book3s_64_mmu.c @@ -235,6 +235,7 @@ static int kvmppc_mmu_book3s_64_xlate(st gpte->may_read = true; gpte->may_write = true; gpte->page_size = MMU_PAGE_4K; + gpte->wimg = HPTE_R_M; return 0; } --- a/arch/powerpc/kvm/book3s_pr.c +++ b/arch/powerpc/kvm/book3s_pr.c @@ -60,6 +60,7 @@ static void kvmppc_giveup_fac(struct kvm #define MSR_USER32 MSR_USER #define MSR_USER64 MSR_USER #define HW_PAGE_SIZE PAGE_SIZE +#define HPTE_R_M _PAGE_COHERENT #endif static bool kvmppc_is_split_real(struct kvm_vcpu *vcpu) @@ -557,6 +558,7 @@ int kvmppc_handle_pagefault(struct kvm_r pte.eaddr = eaddr; pte.vpage = eaddr >> 12; pte.page_size = MMU_PAGE_64K; + pte.wimg = HPTE_R_M; } switch (kvmppc_get_msr(vcpu) & (MSR_DR|MSR_IR)) { Patches currently in stable-queue which might be from aik(a)ozlabs.ru are queue-4.14/kvm-ppc-book3s-pr-fix-wimg-handling-under-phyp.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: PPC: Book3S HV: Fix use after free in case of multiple resize requests" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S HV: Fix use after free in case of multiple resize requests to the 4.14-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: kvm-ppc-book3s-hv-fix-use-after-free-in-case-of-multiple-resize-requests.patch and it can be found in the queue-4.14 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 4ed11aeefda439c76ddae3ceebcfa4fad111f149 Mon Sep 17 00:00:00 2001 From: Serhii Popovych <spopovyc(a)redhat.com> Date: Mon, 4 Dec 2017 09:36:42 -0500 Subject: KVM: PPC: Book3S HV: Fix use after free in case of multiple resize requests From: Serhii Popovych <spopovyc(a)redhat.com> commit 4ed11aeefda439c76ddae3ceebcfa4fad111f149 upstream. When serving multiple resize requests following could happen: CPU0 CPU1 ---- ---- kvm_vm_ioctl_resize_hpt_prepare(1); -> schedule_work() /* system_rq might be busy: delay */ kvm_vm_ioctl_resize_hpt_prepare(2); mutex_lock(); if (resize) { ... release_hpt_resize(); } ... resize_hpt_prepare_work() -> schedule_work() { mutex_unlock() /* resize->kvm could be wrong */ struct kvm *kvm = resize->kvm; mutex_lock(&kvm->lock); <<<< UAF ... } i.e. a second resize request with different order could be started by kvm_vm_ioctl_resize_hpt_prepare(), causing the previous request to be free()d when there's still an active worker thread which will try to access it. This leads to a use after free in point marked with UAF on the diagram above. To prevent this from happening, instead of unconditionally releasing a pre-existing resize structure from the prepare ioctl(), we check if the existing structure has an in-progress worker. We do that by checking if the resize->error == -EBUSY, which is safe because the resize->error field is protected by the kvm->lock. If there is an active worker, instead of releasing, we mark the structure as stale by unlinking it from kvm_struct. In the worker thread we check for a stale structure (with kvm->lock held), and in that case abort, releasing the stale structure ourself. We make the check both before and the actual allocation. Strictly, only the check afterwards is needed, the check before is an optimization: if the structure happens to become stale before the worker thread is dispatched, rather than during the allocation, it means we can avoid allocating then immediately freeing a potentially substantial amount of memory. This fixes following or similar host kernel crash message: [ 635.277361] Unable to handle kernel paging request for data at address 0x00000000 [ 635.277438] Faulting instruction address: 0xc00000000052f568 [ 635.277446] Oops: Kernel access of bad area, sig: 11 [#1] [ 635.277451] SMP NR_CPUS=2048 NUMA PowerNV [ 635.277470] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter nfsv3 nfs_acl nfs lockd grace fscache kvm_hv kvm rpcrdma sunrpc ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ext4 ib_srp scsi_transport_srp ib_ipoib mbcache jbd2 rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ocrdma(T) ib_core ses enclosure scsi_transport_sas sg shpchp leds_powernv ibmpowernv i2c_opal i2c_core powernv_rng ipmi_powernv ipmi_devintf ipmi_msghandler ip_tables xfs libcrc32c sr_mod sd_mod cdrom lpfc nvme_fc(T) nvme_fabrics nvme_core ipr nvmet_fc(T) tg3 nvmet libata be2net crc_t10dif crct10dif_generic scsi_transport_fc ptp scsi_tgt pps_core crct10dif_common dm_mirror dm_region_hash dm_log dm_mod [ 635.278687] CPU: 40 PID: 749 Comm: kworker/40:1 Tainted: G ------------ T 3.10.0.bz1510771+ #1 [ 635.278782] Workqueue: events resize_hpt_prepare_work [kvm_hv] [ 635.278851] task: c0000007e6840000 ti: c0000007e9180000 task.ti: c0000007e9180000 [ 635.278919] NIP: c00000000052f568 LR: c0000000009ea310 CTR: c0000000009ea4f0 [ 635.278988] REGS: c0000007e91837f0 TRAP: 0300 Tainted: G ------------ T (3.10.0.bz1510771+) [ 635.279077] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002022 XER: 00000000 [ 635.279248] CFAR: c000000000009368 DAR: 0000000000000000 DSISR: 40000000 SOFTE: 1 GPR00: c0000000009ea310 c0000007e9183a70 c000000001250b00 c0000007e9183b10 GPR04: 0000000000000000 0000000000000000 c0000007e9183650 0000000000000000 GPR08: c0000007ffff7b80 00000000ffffffff 0000000080000028 d00000000d2529a0 GPR12: 0000000000002200 c000000007b56800 c000000000120028 c0000007f135bb40 GPR16: 0000000000000000 c000000005c1e018 c000000005c1e018 0000000000000000 GPR20: 0000000000000001 c0000000011bf778 0000000000000001 fffffffffffffef7 GPR24: 0000000000000000 c000000f1e262e50 0000000000000002 c0000007e9180000 GPR28: c000000f1e262e4c c000000f1e262e50 0000000000000000 c0000007e9183b10 [ 635.280149] NIP [c00000000052f568] __list_add+0x38/0x110 [ 635.280197] LR [c0000000009ea310] __mutex_lock_slowpath+0xe0/0x2c0 [ 635.280253] Call Trace: [ 635.280277] [c0000007e9183af0] [c0000000009ea310] __mutex_lock_slowpath+0xe0/0x2c0 [ 635.280356] [c0000007e9183b70] [c0000000009ea554] mutex_lock+0x64/0x70 [ 635.280426] [c0000007e9183ba0] [d00000000d24da04] resize_hpt_prepare_work+0xe4/0x1c0 [kvm_hv] [ 635.280507] [c0000007e9183c40] [c000000000113c0c] process_one_work+0x1dc/0x680 [ 635.280587] [c0000007e9183ce0] [c000000000114250] worker_thread+0x1a0/0x520 [ 635.280655] [c0000007e9183d80] [c00000000012010c] kthread+0xec/0x100 [ 635.280724] [c0000007e9183e30] [c00000000000a4b8] ret_from_kernel_thread+0x5c/0xa4 [ 635.280814] Instruction dump: [ 635.280880] 7c0802a6 fba1ffe8 fbc1fff0 7cbd2b78 fbe1fff8 7c9e2378 7c7f1b78 f8010010 [ 635.281099] f821ff81 e8a50008 7fa52040 40de00b8 <e8be0000> 7fbd2840 40de008c 7fbff040 [ 635.281324] ---[ end trace b628b73449719b9d ]--- Fixes: b5baa6877315 ("KVM: PPC: Book3S HV: KVM-HV HPT resizing implementation") Signed-off-by: Serhii Popovych <spopovyc(a)redhat.com> [dwg: Replaced BUG_ON()s with WARN_ONs() and reworded commit message for clarity] Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 54 ++++++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 17 deletions(-) --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c @@ -1430,16 +1430,20 @@ static void resize_hpt_pivot(struct kvm_ static void resize_hpt_release(struct kvm *kvm, struct kvm_resize_hpt *resize) { - BUG_ON(kvm->arch.resize_hpt != resize); + if (WARN_ON(!mutex_is_locked(&kvm->lock))) + return; if (!resize) return; - if (resize->hpt.virt) - kvmppc_free_hpt(&resize->hpt); + if (resize->error != -EBUSY) { + if (resize->hpt.virt) + kvmppc_free_hpt(&resize->hpt); + kfree(resize); + } - kvm->arch.resize_hpt = NULL; - kfree(resize); + if (kvm->arch.resize_hpt == resize) + kvm->arch.resize_hpt = NULL; } static void resize_hpt_prepare_work(struct work_struct *work) @@ -1448,26 +1452,42 @@ static void resize_hpt_prepare_work(stru struct kvm_resize_hpt, work); struct kvm *kvm = resize->kvm; - int err; + int err = 0; if (WARN_ON(resize->error != -EBUSY)) return; - resize_hpt_debug(resize, "resize_hpt_prepare_work(): order = %d\n", - resize->order); - - err = resize_hpt_allocate(resize); - - /* We have strict assumption about -EBUSY - * when preparing for HPT resize. - */ - if (WARN_ON(err == -EBUSY)) - err = -EINPROGRESS; - mutex_lock(&kvm->lock); + /* Request is still current? */ + if (kvm->arch.resize_hpt == resize) { + /* We may request large allocations here: + * do not sleep with kvm->lock held for a while. + */ + mutex_unlock(&kvm->lock); + + resize_hpt_debug(resize, "resize_hpt_prepare_work(): order = %d\n", + resize->order); + + err = resize_hpt_allocate(resize); + + /* We have strict assumption about -EBUSY + * when preparing for HPT resize. + */ + if (WARN_ON(err == -EBUSY)) + err = -EINPROGRESS; + + mutex_lock(&kvm->lock); + /* It is possible that kvm->arch.resize_hpt != resize + * after we grab kvm->lock again. + */ + } + resize->error = err; + if (kvm->arch.resize_hpt != resize) + resize_hpt_release(kvm, resize); + mutex_unlock(&kvm->lock); } Patches currently in stable-queue which might be from spopovyc(a)redhat.com are queue-4.14/kvm-ppc-book3s-hv-drop-prepare_done-from-struct-kvm_resize_hpt.patch queue-4.14/kvm-ppc-book3s-hv-fix-use-after-free-in-case-of-multiple-resize-requests.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: PPC: Book3S HV: Drop prepare_done from struct kvm_resize_hpt" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S HV: Drop prepare_done from struct kvm_resize_hpt to the 4.14-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: kvm-ppc-book3s-hv-drop-prepare_done-from-struct-kvm_resize_hpt.patch and it can be found in the queue-4.14 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 3073774e638ef18d222465fe92bfc8fccb90d288 Mon Sep 17 00:00:00 2001 From: Serhii Popovych <spopovyc(a)redhat.com> Date: Mon, 4 Dec 2017 09:36:41 -0500 Subject: KVM: PPC: Book3S HV: Drop prepare_done from struct kvm_resize_hpt From: Serhii Popovych <spopovyc(a)redhat.com> commit 3073774e638ef18d222465fe92bfc8fccb90d288 upstream. Currently the kvm_resize_hpt structure has two fields relevant to the state of an ongoing resize: 'prepare_done', which indicates whether the worker thread has completed or not, and 'error' which indicates whether it was successful or not. Since the success/failure isn't known until completion, this is confusingly redundant. This patch consolidates the information into just the 'error' value: -EBUSY indicates the worked is still in progress, other negative values indicate (completed) failure, 0 indicates successful completion. As a bonus this reduces size of struct kvm_resize_hpt by __alignof__(struct kvm_hpt_info) and saves few bytes of code. While there correct comment in struct kvm_resize_hpt which references a non-existent semaphore (leftover from an early draft). Assert with WARN_ON() in case of HPT allocation thread work runs more than once for resize request or resize_hpt_allocate() returns -EBUSY that is treated specially. Change comparison against zero to make checkpatch.pl happy. Signed-off-by: Serhii Popovych <spopovyc(a)redhat.com> [dwg: Changed BUG_ON()s to WARN_ON()s and altered commit message for clarity] Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 44 ++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 17 deletions(-) --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c @@ -65,11 +65,17 @@ struct kvm_resize_hpt { u32 order; /* These fields protected by kvm->lock */ + + /* Possible values and their usage: + * <0 an error occurred during allocation, + * -EBUSY allocation is in the progress, + * 0 allocation made successfuly. + */ int error; - bool prepare_done; - /* Private to the work thread, until prepare_done is true, - * then protected by kvm->resize_hpt_sem */ + /* Private to the work thread, until error != -EBUSY, + * then protected by kvm->lock. + */ struct kvm_hpt_info hpt; }; @@ -1444,15 +1450,23 @@ static void resize_hpt_prepare_work(stru struct kvm *kvm = resize->kvm; int err; + if (WARN_ON(resize->error != -EBUSY)) + return; + resize_hpt_debug(resize, "resize_hpt_prepare_work(): order = %d\n", resize->order); err = resize_hpt_allocate(resize); + /* We have strict assumption about -EBUSY + * when preparing for HPT resize. + */ + if (WARN_ON(err == -EBUSY)) + err = -EINPROGRESS; + mutex_lock(&kvm->lock); resize->error = err; - resize->prepare_done = true; mutex_unlock(&kvm->lock); } @@ -1477,14 +1491,12 @@ long kvm_vm_ioctl_resize_hpt_prepare(str if (resize) { if (resize->order == shift) { - /* Suitable resize in progress */ - if (resize->prepare_done) { - ret = resize->error; - if (ret != 0) - resize_hpt_release(kvm, resize); - } else { + /* Suitable resize in progress? */ + ret = resize->error; + if (ret == -EBUSY) ret = 100; /* estimated time in ms */ - } + else if (ret) + resize_hpt_release(kvm, resize); goto out; } @@ -1504,6 +1516,8 @@ long kvm_vm_ioctl_resize_hpt_prepare(str ret = -ENOMEM; goto out; } + + resize->error = -EBUSY; resize->order = shift; resize->kvm = kvm; INIT_WORK(&resize->work, resize_hpt_prepare_work); @@ -1558,16 +1572,12 @@ long kvm_vm_ioctl_resize_hpt_commit(stru if (!resize || (resize->order != shift)) goto out; - ret = -EBUSY; - if (!resize->prepare_done) - goto out; - ret = resize->error; - if (ret != 0) + if (ret) goto out; ret = resize_hpt_rehash(resize); - if (ret != 0) + if (ret) goto out; resize_hpt_pivot(resize); Patches currently in stable-queue which might be from spopovyc(a)redhat.com are queue-4.14/kvm-ppc-book3s-hv-drop-prepare_done-from-struct-kvm_resize_hpt.patch queue-4.14/kvm-ppc-book3s-hv-fix-use-after-free-in-case-of-multiple-resize-requests.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: PPC: Book3S HV: Always flush TLB in kvmppc_alloc_reset_hpt()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S HV: Always flush TLB in kvmppc_alloc_reset_hpt() to the 4.14-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: kvm-ppc-book3s-hv-always-flush-tlb-in-kvmppc_alloc_reset_hpt.patch and it can be found in the queue-4.14 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 ecba8297aafd50db6ae867e90844eead1611ef1c Mon Sep 17 00:00:00 2001 From: David Gibson <david(a)gibson.dropbear.id.au> Date: Wed, 10 Jan 2018 17:04:39 +1100 Subject: KVM: PPC: Book3S HV: Always flush TLB in kvmppc_alloc_reset_hpt() From: David Gibson <david(a)gibson.dropbear.id.au> commit ecba8297aafd50db6ae867e90844eead1611ef1c upstream. The KVM_PPC_ALLOCATE_HTAB ioctl(), implemented by kvmppc_alloc_reset_hpt() is supposed to completely clear and reset a guest's Hashed Page Table (HPT) allocating or re-allocating it if necessary. In the case where an HPT of the right size already exists and it just zeroes it, it forces a TLB flush on all guest CPUs, to remove any stale TLB entries loaded from the old HPT. However, that situation can arise when the HPT is resizing as well - or even when switching from an RPT to HPT - so those cases need a TLB flush as well. So, move the TLB flush to trigger in all cases except for errors. Fixes: f98a8bf9ee20 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB ioctl() to change HPT size") Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c @@ -165,8 +165,6 @@ long kvmppc_alloc_reset_hpt(struct kvm * * Reset all the reverse-mapping chains for all memslots */ kvmppc_rmap_reset(kvm); - /* Ensure that each vcpu will flush its TLB on next entry. */ - cpumask_setall(&kvm->arch.need_tlb_flush); err = 0; goto out; } @@ -182,6 +180,10 @@ long kvmppc_alloc_reset_hpt(struct kvm * kvmppc_set_hpt(kvm, &info); out: + if (err == 0) + /* Ensure that each vcpu will flush its TLB on next entry. */ + cpumask_setall(&kvm->arch.need_tlb_flush); + mutex_unlock(&kvm->lock); return err; } Patches currently in stable-queue which might be from david(a)gibson.dropbear.id.au are queue-4.14/kvm-ppc-book3s-hv-always-flush-tlb-in-kvmppc_alloc_reset_hpt.patch queue-4.14/kvm-ppc-book3s-hv-drop-prepare_done-from-struct-kvm_resize_hpt.patch queue-4.14/kvm-ppc-book3s-hv-fix-use-after-free-in-case-of-multiple-resize-requests.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: pcie: fix DMA memory mapping / unmapping" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iwlwifi: pcie: fix DMA memory mapping / unmapping to the 4.14-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: iwlwifi-pcie-fix-dma-memory-mapping-unmapping.patch and it can be found in the queue-4.14 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 943309d4aad6732b905f3f500e6e17e33c211494 Mon Sep 17 00:00:00 2001 From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Date: Thu, 4 Jan 2018 09:19:13 +0200 Subject: iwlwifi: pcie: fix DMA memory mapping / unmapping From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> commit 943309d4aad6732b905f3f500e6e17e33c211494 upstream. 22000 devices (previously referenced as A000) can support short transmit queues. This means that we have less DMA descriptors (TFD) for those shorter queues. Previous devices must still have 256 TFDs for each queue even if those 256 TFDs point to fewer buffers. When I introduced support for the short queues for 22000 I broke older devices by assuming that they can also have less TFDs in their queues. This led to several problems: 1) the payload of the commands weren't unmapped properly which caused the SWIOTLB to complain at some point. 2) the hardware could get confused and we get hardware crashes. The corresponding bugzilla entries are: https://bugzilla.kernel.org/show_bug.cgi?id=198201 https://bugzilla.kernel.org/show_bug.cgi?id=198265 Fixes: 4ecab5616023 ("iwlwifi: pcie: support short Tx queues for A000 device family") Reviewed-by: Sharon, Sara <sara.sharon(a)intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 10 +++++++--- drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 11 +++-------- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 8 ++++---- 3 files changed, 14 insertions(+), 15 deletions(-) --- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h +++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h @@ -666,11 +666,15 @@ static inline u8 iwl_pcie_get_cmd_index( return index & (q->n_window - 1); } -static inline void *iwl_pcie_get_tfd(struct iwl_trans_pcie *trans_pcie, +static inline void *iwl_pcie_get_tfd(struct iwl_trans *trans, struct iwl_txq *txq, int idx) { - return txq->tfds + trans_pcie->tfd_size * iwl_pcie_get_cmd_index(txq, - idx); + struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans); + + if (trans->cfg->use_tfh) + idx = iwl_pcie_get_cmd_index(txq, idx); + + return txq->tfds + trans_pcie->tfd_size * idx; } static inline void iwl_enable_rfkill_int(struct iwl_trans *trans) --- a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c @@ -171,8 +171,6 @@ static void iwl_pcie_gen2_tfd_unmap(stru static void iwl_pcie_gen2_free_tfd(struct iwl_trans *trans, struct iwl_txq *txq) { - struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans); - /* rd_ptr is bounded by TFD_QUEUE_SIZE_MAX and * idx is bounded by n_window */ @@ -181,7 +179,7 @@ static void iwl_pcie_gen2_free_tfd(struc lockdep_assert_held(&txq->lock); iwl_pcie_gen2_tfd_unmap(trans, &txq->entries[idx].meta, - iwl_pcie_get_tfd(trans_pcie, txq, idx)); + iwl_pcie_get_tfd(trans, txq, idx)); /* free SKB */ if (txq->entries) { @@ -367,11 +365,9 @@ struct iwl_tfh_tfd *iwl_pcie_gen2_build_ struct sk_buff *skb, struct iwl_cmd_meta *out_meta) { - struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans); struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; int idx = iwl_pcie_get_cmd_index(txq, txq->write_ptr); - struct iwl_tfh_tfd *tfd = - iwl_pcie_get_tfd(trans_pcie, txq, idx); + struct iwl_tfh_tfd *tfd = iwl_pcie_get_tfd(trans, txq, idx); dma_addr_t tb_phys; bool amsdu; int i, len, tb1_len, tb2_len, hdr_len; @@ -568,8 +564,7 @@ static int iwl_pcie_gen2_enqueue_hcmd(st u8 group_id = iwl_cmd_groupid(cmd->id); const u8 *cmddata[IWL_MAX_CMD_TBS_PER_TFD]; u16 cmdlen[IWL_MAX_CMD_TBS_PER_TFD]; - struct iwl_tfh_tfd *tfd = - iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr); + struct iwl_tfh_tfd *tfd = iwl_pcie_get_tfd(trans, txq, txq->write_ptr); memset(tfd, 0, sizeof(*tfd)); --- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c @@ -373,7 +373,7 @@ static void iwl_pcie_tfd_unmap(struct iw { struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans); int i, num_tbs; - void *tfd = iwl_pcie_get_tfd(trans_pcie, txq, index); + void *tfd = iwl_pcie_get_tfd(trans, txq, index); /* Sanity check on number of chunks */ num_tbs = iwl_pcie_tfd_get_num_tbs(trans, tfd); @@ -1999,7 +1999,7 @@ static int iwl_fill_data_tbs(struct iwl_ } trace_iwlwifi_dev_tx(trans->dev, skb, - iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr), + iwl_pcie_get_tfd(trans, txq, txq->write_ptr), trans_pcie->tfd_size, &dev_cmd->hdr, IWL_FIRST_TB_SIZE + tb1_len, hdr_len); @@ -2073,7 +2073,7 @@ static int iwl_fill_data_tbs_amsdu(struc IEEE80211_CCMP_HDR_LEN : 0; trace_iwlwifi_dev_tx(trans->dev, skb, - iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr), + iwl_pcie_get_tfd(trans, txq, txq->write_ptr), trans_pcie->tfd_size, &dev_cmd->hdr, IWL_FIRST_TB_SIZE + tb1_len, 0); @@ -2406,7 +2406,7 @@ int iwl_trans_pcie_tx(struct iwl_trans * memcpy(&txq->first_tb_bufs[txq->write_ptr], &dev_cmd->hdr, IWL_FIRST_TB_SIZE); - tfd = iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr); + tfd = iwl_pcie_get_tfd(trans, txq, txq->write_ptr); /* Set up entry for this TFD in Tx byte-count array */ iwl_pcie_txq_update_byte_cnt_tbl(trans, txq, le16_to_cpu(tx_cmd->len), iwl_pcie_tfd_get_num_tbs(trans, tfd)); Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are queue-4.14/iwlwifi-pcie-fix-dma-memory-mapping-unmapping.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Potential off by one in vmw_view_add()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vmwgfx: Potential off by one in vmw_view_add() to the 4.14-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: drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch and it can be found in the queue-4.14 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 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 10 Jan 2018 12:40:04 +0300 Subject: drm/vmwgfx: Potential off by one in vmw_view_add() From: Dan Carpenter <dan.carpenter(a)oracle.com> commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 upstream. The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error. It's one element beyond the end of the vmw_view_cotables[] table. My read on this is that it's possible to hit this failure. header->id comes from vmw_cmd_check() and it's a user controlled number between 1040 and 1225 so we can hit that error. But I don't have the hardware to test this code. Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -2731,6 +2731,8 @@ static int vmw_cmd_dx_view_define(struct } view_type = vmw_view_cmd_to_type(header->id); + if (view_type == vmw_view_max) + return -EINVAL; cmd = container_of(header, typeof(*cmd), header); ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface, user_surface_converter, Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.14/drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Don't cache framebuffer maps" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vmwgfx: Don't cache framebuffer maps to the 4.14-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: drm-vmwgfx-don-t-cache-framebuffer-maps.patch and it can be found in the queue-4.14 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 98648ae6ef6bdcdcb88c46cad963906ab452e96d Mon Sep 17 00:00:00 2001 From: Thomas Hellstrom <thellstrom(a)vmware.com> Date: Tue, 9 Jan 2018 15:33:42 +0100 Subject: drm/vmwgfx: Don't cache framebuffer maps From: Thomas Hellstrom <thellstrom(a)vmware.com> commit 98648ae6ef6bdcdcb88c46cad963906ab452e96d upstream. Buffer objects need to be either pinned or reserved while a map is active, that's not the case here, so avoid caching the framebuffer map. This will cause increasing mapping activity mainly when we don't do page flipping. This fixes occasional garbage filled screens when the framebuffer has been evicted after the map. Since in-kernel mapping of whole buffer objects is error-prone on 32-bit architectures and also quite inefficient, we will revisit this later. Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> Reviewed-by: Sinclair Yeh <syeh(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 ----- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 - drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 41 ++++++++++------------------------- 3 files changed, 13 insertions(+), 36 deletions(-) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -697,7 +697,6 @@ vmw_du_plane_duplicate_state(struct drm_ vps->pinned = 0; /* Mapping is managed by prepare_fb/cleanup_fb */ - memset(&vps->guest_map, 0, sizeof(vps->guest_map)); memset(&vps->host_map, 0, sizeof(vps->host_map)); vps->cpp = 0; @@ -760,11 +759,6 @@ vmw_du_plane_destroy_state(struct drm_pl /* Should have been freed by cleanup_fb */ - if (vps->guest_map.virtual) { - DRM_ERROR("Guest mapping not freed\n"); - ttm_bo_kunmap(&vps->guest_map); - } - if (vps->host_map.virtual) { DRM_ERROR("Host mapping not freed\n"); ttm_bo_kunmap(&vps->host_map); --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h @@ -175,7 +175,7 @@ struct vmw_plane_state { int pinned; /* For CPU Blit */ - struct ttm_bo_kmap_obj host_map, guest_map; + struct ttm_bo_kmap_obj host_map; unsigned int cpp; }; --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c @@ -114,7 +114,7 @@ struct vmw_screen_target_display_unit { bool defined; /* For CPU Blit */ - struct ttm_bo_kmap_obj host_map, guest_map; + struct ttm_bo_kmap_obj host_map; unsigned int cpp; }; @@ -695,7 +695,8 @@ static void vmw_stdu_dmabuf_cpu_commit(s s32 src_pitch, dst_pitch; u8 *src, *dst; bool not_used; - + struct ttm_bo_kmap_obj guest_map; + int ret; if (!dirty->num_hits) return; @@ -706,6 +707,13 @@ static void vmw_stdu_dmabuf_cpu_commit(s if (width == 0 || height == 0) return; + ret = ttm_bo_kmap(&ddirty->buf->base, 0, ddirty->buf->base.num_pages, + &guest_map); + if (ret) { + DRM_ERROR("Failed mapping framebuffer for blit: %d\n", + ret); + goto out_cleanup; + } /* Assume we are blitting from Host (display_srf) to Guest (dmabuf) */ src_pitch = stdu->display_srf->base_size.width * stdu->cpp; @@ -713,7 +721,7 @@ static void vmw_stdu_dmabuf_cpu_commit(s src += ddirty->top * src_pitch + ddirty->left * stdu->cpp; dst_pitch = ddirty->pitch; - dst = ttm_kmap_obj_virtual(&stdu->guest_map, &not_used); + dst = ttm_kmap_obj_virtual(&guest_map, &not_used); dst += ddirty->fb_top * dst_pitch + ddirty->fb_left * stdu->cpp; @@ -772,6 +780,7 @@ static void vmw_stdu_dmabuf_cpu_commit(s vmw_fifo_commit(dev_priv, sizeof(*cmd)); } + ttm_bo_kunmap(&guest_map); out_cleanup: ddirty->left = ddirty->top = ddirty->fb_left = ddirty->fb_top = S32_MAX; ddirty->right = ddirty->bottom = S32_MIN; @@ -1109,9 +1118,6 @@ vmw_stdu_primary_plane_cleanup_fb(struct { struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state); - if (vps->guest_map.virtual) - ttm_bo_kunmap(&vps->guest_map); - if (vps->host_map.virtual) ttm_bo_kunmap(&vps->host_map); @@ -1277,33 +1283,11 @@ vmw_stdu_primary_plane_prepare_fb(struct */ if (vps->content_fb_type == SEPARATE_DMA && !(dev_priv->capabilities & SVGA_CAP_3D)) { - - struct vmw_framebuffer_dmabuf *new_vfbd; - - new_vfbd = vmw_framebuffer_to_vfbd(new_fb); - - ret = ttm_bo_reserve(&new_vfbd->buffer->base, false, false, - NULL); - if (ret) - goto out_srf_unpin; - - ret = ttm_bo_kmap(&new_vfbd->buffer->base, 0, - new_vfbd->buffer->base.num_pages, - &vps->guest_map); - - ttm_bo_unreserve(&new_vfbd->buffer->base); - - if (ret) { - DRM_ERROR("Failed to map content buffer to CPU\n"); - goto out_srf_unpin; - } - ret = ttm_bo_kmap(&vps->surf->res.backup->base, 0, vps->surf->res.backup->base.num_pages, &vps->host_map); if (ret) { DRM_ERROR("Failed to map display buffer to CPU\n"); - ttm_bo_kunmap(&vps->guest_map); goto out_srf_unpin; } @@ -1350,7 +1334,6 @@ vmw_stdu_primary_plane_atomic_update(str stdu->display_srf = vps->surf; stdu->content_fb_type = vps->content_fb_type; stdu->cpp = vps->cpp; - memcpy(&stdu->guest_map, &vps->guest_map, sizeof(vps->guest_map)); memcpy(&stdu->host_map, &vps->host_map, sizeof(vps->host_map)); if (!stdu->defined) Patches currently in stable-queue which might be from thellstrom(a)vmware.com are queue-4.14/drm-vmwgfx-don-t-cache-framebuffer-maps.patch queue-4.14/drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. to the 4.14-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: drm-i915-whitelist-slice_common_eco_chicken1-on-geminilake.patch and it can be found in the queue-4.14 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 4636bda86aa1f34f45c629477476a0dcfa04e597 Mon Sep 17 00:00:00 2001 From: Kenneth Graunke <kenneth(a)whitecape.org> Date: Fri, 5 Jan 2018 00:59:05 -0800 Subject: drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. From: Kenneth Graunke <kenneth(a)whitecape.org> commit 4636bda86aa1f34f45c629477476a0dcfa04e597 upstream. Geminilake requires the 3D driver to select whether barriers are intended for compute shaders, or tessellation control shaders, by whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when switching pipelines. Failure to do this properly can result in GPU hangs. Unfortunately, this means it needs to switch mid-batch, so only userspace can properly set it. To facilitate this, the kernel needs to whitelist the register. The workarounds page currently tags this as applying to Broxton only, but that doesn't make sense. The documentation for the register it references says the bit userspace is supposed to toggle only exists on Geminilake. Empirically, the Mesa patch to toggle this bit appears to fix intermittent GPU hangs in tessellation control shader barrier tests on Geminilake; we haven't seen those hangs on Broxton. v2: Mention WA #0862 in the comment (it doesn't have a name). Signed-off-by: Kenneth Graunke <kenneth(a)whitecape.org> Acked-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180105085905.9298-1-kenneth… (cherry picked from commit ab062639edb0412daf6de540725276b9a5d217f9) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++ 2 files changed, 7 insertions(+) --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6987,6 +6987,8 @@ enum { #define GEN9_SLICE_COMMON_ECO_CHICKEN0 _MMIO(0x7308) #define DISABLE_PIXEL_MASK_CAMMING (1<<14) +#define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c) + #define GEN7_L3SQCREG1 _MMIO(0xB010) #define VLV_B0_WA_L3SQCREG1_VALUE 0x00D30000 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1125,6 +1125,11 @@ static int glk_init_workarounds(struct i if (ret) return ret; + /* WA #0862: Userspace has to set "Barrier Mode" to avoid hangs. */ + ret = wa_ring_whitelist_reg(engine, GEN9_SLICE_COMMON_ECO_CHICKEN1); + if (ret) + return ret; + /* WaToEnableHwFixForPushConstHWBug:glk */ WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2, GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION); Patches currently in stable-queue which might be from kenneth(a)whitecape.org are queue-4.14/drm-i915-whitelist-slice_common_eco_chicken1-on-geminilake.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Move init_clock_gating() back to where it was" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Move init_clock_gating() back to where it was to the 4.14-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: drm-i915-move-init_clock_gating-back-to-where-it-was.patch and it can be found in the queue-4.14 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 6ac43272768ca901daac4076a66c2c4e3c7b9321 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Wed, 8 Nov 2017 15:35:55 +0200 Subject: drm/i915: Move init_clock_gating() back to where it was MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 6ac43272768ca901daac4076a66c2c4e3c7b9321 upstream. Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Oscar Mateo <oscar.mateo(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Reported-by: Mark Janes <mark.a.janes(a)intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.… Tested-by: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit f72b84c677d61f201b869223a8d6e389c7bb7d3d) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_display.c | 14 +++++++++-- drivers/gpu/drm/i915/intel_pm.c | 44 ++++++++++++++--------------------- 2 files changed, 30 insertions(+), 28 deletions(-) --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3800,6 +3800,7 @@ void intel_finish_reset(struct drm_i915_ intel_pps_unlock_regs_wa(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup) @@ -14406,8 +14407,6 @@ void intel_modeset_init_hw(struct drm_de intel_update_cdclk(dev_priv); dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw; - - intel_init_clock_gating(dev_priv); } /* @@ -15124,6 +15123,15 @@ intel_modeset_setup_hw_state(struct drm_ struct intel_encoder *encoder; int i; + if (IS_HASWELL(dev_priv)) { + /* + * WaRsPkgCStateDisplayPMReq:hsw + * System hang if this isn't done before disabling all planes! + */ + I915_WRITE(CHICKEN_PAR1_1, + I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); + } + intel_modeset_readout_hw_state(dev); /* HW state is read out, now we need to sanitize this mess. */ @@ -15220,6 +15228,8 @@ void intel_modeset_gem_init(struct drm_d intel_init_gt_powersave(dev_priv); + intel_init_clock_gating(dev_priv); + intel_setup_overlay(dev_priv); } --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5669,12 +5669,30 @@ void vlv_wm_sanitize(struct drm_i915_pri mutex_unlock(&dev_priv->wm.wm_mutex); } +/* + * FIXME should probably kill this and improve + * the real watermark readout/sanitation instead + */ +static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) +{ + I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); + + /* + * Don't touch WM1S_LP_EN here. + * Doing so could cause underruns. + */ +} + void ilk_wm_get_hw_state(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); struct ilk_wm_values *hw = &dev_priv->wm.hw; struct drm_crtc *crtc; + ilk_init_lp_watermarks(dev_priv); + for_each_crtc(dev, crtc) ilk_pipe_wm_get_hw_state(crtc); @@ -7959,18 +7977,6 @@ static void g4x_disable_trickle_feed(str } } -static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) -{ - I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); - - /* - * Don't touch WM1S_LP_EN here. - * Doing so could cause underruns. - */ -} - static void ironlake_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; @@ -8004,8 +8010,6 @@ static void ironlake_init_clock_gating(s (I915_READ(DISP_ARB_CTL) | DISP_FBC_WM_DIS)); - ilk_init_lp_watermarks(dev_priv); - /* * Based on the document from hardware guys the following bits * should be set unconditionally in order to enable FBC. @@ -8118,8 +8122,6 @@ static void gen6_init_clock_gating(struc I915_WRITE(GEN6_GT_MODE, _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4)); - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB)); @@ -8293,8 +8295,6 @@ static void broadwell_init_clock_gating( { enum pipe pipe; - ilk_init_lp_watermarks(dev_priv); - /* WaSwitchSolVfFArbitrationPriority:bdw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); @@ -8349,8 +8349,6 @@ static void broadwell_init_clock_gating( static void haswell_init_clock_gating(struct drm_i915_private *dev_priv) { - ilk_init_lp_watermarks(dev_priv); - /* L3 caching of data atomics doesn't work -- disable it. */ I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE); I915_WRITE(HSW_ROW_CHICKEN3, @@ -8394,10 +8392,6 @@ static void haswell_init_clock_gating(st /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); - /* WaRsPkgCStateDisplayPMReq:hsw */ - I915_WRITE(CHICKEN_PAR1_1, - I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); - lpt_init_clock_gating(dev_priv); } @@ -8405,8 +8399,6 @@ static void ivybridge_init_clock_gating( { uint32_t snpcr; - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE); /* WaDisableEarlyCull:ivb */ Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.14/drm-i915-move-init_clock_gating-back-to-where-it-was.patch queue-4.14/drm-i915-fix-init_clock_gating-for-resume.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915/gvt: Clear the shadow page table entry after post-sync" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915/gvt: Clear the shadow page table entry after post-sync to the 4.14-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: drm-i915-gvt-clear-the-shadow-page-table-entry-after-post-sync.patch and it can be found in the queue-4.14 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 121d760d0788f95619049c63449d977065cab69d Mon Sep 17 00:00:00 2001 From: Zhi Wang <zhi.a.wang(a)intel.com> Date: Fri, 29 Dec 2017 02:50:08 +0800 Subject: drm/i915/gvt: Clear the shadow page table entry after post-sync From: Zhi Wang <zhi.a.wang(a)intel.com> commit 121d760d0788f95619049c63449d977065cab69d upstream. A shadow page table entry needs to be cleared after being set as post-sync. This patch fixes the recent error reported in Win7-32 test. Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: Zhi Wang <zhi.a.wang(a)intel.com> Signed-off-by: Zhenyu Wang <zhenyuw(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/gvt/gtt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -1359,12 +1359,15 @@ static int ppgtt_handle_guest_write_page return ret; } else { if (!test_bit(index, spt->post_shadow_bitmap)) { + int type = spt->shadow_page.type; + ppgtt_get_shadow_entry(spt, &se, index); ret = ppgtt_handle_guest_entry_removal(gpt, &se, index); if (ret) return ret; + ops->set_pfn(&se, vgpu->gtt.scratch_pt[type].page_mfn); + ppgtt_set_shadow_entry(spt, &se, index); } - ppgtt_set_post_shadow(spt, index); } Patches currently in stable-queue which might be from zhi.a.wang(a)intel.com are queue-4.14/drm-i915-gvt-clear-the-shadow-page-table-entry-after-post-sync.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Fix init_clock_gating for resume" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Fix init_clock_gating for resume to the 4.14-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: drm-i915-fix-init_clock_gating-for-resume.patch and it can be found in the queue-4.14 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 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 16 Nov 2017 18:02:15 +0200 Subject: drm/i915: Fix init_clock_gating for resume MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 3572f04c69ed4369da5d3c65d84fb18774aa60b6 upstream. Moving the init_clock_gating() call from intel_modeset_init_hw() to intel_modeset_gem_init() had an unintended effect of not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS screen after hibernation. Fix the problem by explicitly calling init_clock_gating() from the resume path. I really hope this doesn't break something else again. At least the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549 didn't make a comeback, even after a hibernate cycle. v2: Reorder the init_clock_gating vs. modeset_init_hw to match the display reset path (Rodrigo) Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was") Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171116160215.25715-1-ville.… Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> (cherry picked from commit 675f7ff35bd256e65d3d0f52718d8babf5d1002a) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/i915_drv.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1693,6 +1693,7 @@ static int i915_drm_resume(struct drm_de intel_guc_resume(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup) Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.14/drm-i915-move-init_clock_gating-back-to-where-it-was.patch queue-4.14/drm-i915-fix-init_clock_gating-for-resume.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: algapi - fix NULL dereference in crypto_remove_spawns()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: algapi - fix NULL dereference in crypto_remove_spawns() to the 4.14-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: crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch and it can be found in the queue-4.14 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 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 29 Dec 2017 14:30:19 -0600 Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns() From: Eric Biggers <ebiggers(a)google.com> commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream. syzkaller triggered a NULL pointer dereference in crypto_remove_spawns() via a program that repeatedly and concurrently requests AEADs "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)" through AF_ALG, where the hashes are requested as "untested" (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this causes the template to be instantiated for every request). Although AF_ALG users really shouldn't be able to request an "untested" algorithm, the NULL pointer dereference is actually caused by a longstanding race condition where crypto_remove_spawns() can encounter an instance which has had spawn(s) "grabbed" but hasn't yet been registered, resulting in ->cra_users still being NULL. We probably should properly initialize ->cra_users earlier, but that would require updating many templates individually. For now just fix the bug in a simple way that can easily be backported: make crypto_remove_spawns() treat a NULL ->cra_users list as empty. Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/algapi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/crypto/algapi.c +++ b/crypto/algapi.c @@ -167,6 +167,18 @@ void crypto_remove_spawns(struct crypto_ spawn->alg = NULL; spawns = &inst->alg.cra_users; + + /* + * We may encounter an unregistered instance here, since + * an instance's spawns are set up prior to the instance + * being registered. An unregistered instance will have + * NULL ->cra_users.next, since ->cra_users isn't + * properly initialized until registration. But an + * unregistered instance cannot have any users, so treat + * it the same as ->cra_users being empty. + */ + if (spawns->next == NULL) + break; } } while ((spawns = crypto_more_spawns(alg, &stack, &top, &secondary_spawns))); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.14/crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/intel: Extend BDW late-loading with a revision check" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/intel: Extend BDW late-loading with a revision check to the 3.18-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: x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch and it can be found in the queue-3.18 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 b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001 From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Date: Mon, 1 Jan 2018 10:04:47 +0800 Subject: x86/microcode/intel: Extend BDW late-loading with a revision check From: Jia Zhang <qianyue.zj(a)alibaba-inc.com> commit b94b7373317164402ff7728d10f7023127a02b60 upstream. Instead of blacklisting all model 79 CPUs when attempting a late microcode loading, limit that only to CPUs with microcode revisions < 0x0b000021 because only on those late loading may cause a system hang. For such processors either: a) a BIOS update which might contain a newer microcode revision or b) the early microcode loading method should be considered. Processors with revisions 0x0b000021 or higher will not experience such hangs. For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. [ bp: Heavily massage commit message and pr_* statements. ] Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79") Signed-off-by: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Cc: x86-ml <x86(a)kernel.org> Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@aliba… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/intel.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -271,8 +271,17 @@ static bool is_blacklisted(unsigned int { struct cpuinfo_x86 *c = &cpu_data(cpu); - if (c->x86 == 6 && c->x86_model == 79) { - pr_err_once("late loading on model 79 is disabled.\n"); + /* + * Late loading on model 79 with microcode revision less than 0x0b000021 + * may result in a system hang. This behavior is documented in item + * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). + */ + if (c->x86 == 6 && + c->x86_model == 79 && + c->x86_mask == 0x01 && + c->microcode < 0x0b000021) { + pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode); + pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); return true; } Patches currently in stable-queue which might be from qianyue.zj(a)alibaba-inc.com are queue-3.18/x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix TSU resource handling" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix TSU resource handling to the 3.18-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: sh_eth-fix-tsu-resource-handling.patch and it can be found in the queue-3.18 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 foo@baz Sat Jan 13 15:16:15 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Wed, 3 Jan 2018 20:09:49 +0300 Subject: sh_eth: fix TSU resource handling From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ] When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -2890,10 +2890,29 @@ static int sh_eth_drv_probe(struct platf /* ioremap the TSU registers */ if (mdp->cd->tsu) { struct resource *rtsu; + rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1); - mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu); - if (IS_ERR(mdp->tsu_addr)) { - ret = PTR_ERR(mdp->tsu_addr); + if (!rtsu) { + dev_err(&pdev->dev, "no TSU resource\n"); + ret = -ENODEV; + goto out_release; + } + /* We can only request the TSU region for the first port + * of the two sharing this TSU for the probe to succeed... + */ + if (devno % 2 == 0 && + !devm_request_mem_region(&pdev->dev, rtsu->start, + resource_size(rtsu), + dev_name(&pdev->dev))) { + dev_err(&pdev->dev, "can't request TSU resource.\n"); + ret = -EBUSY; + goto out_release; + } + mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start, + resource_size(rtsu)); + if (!mdp->tsu_addr) { + dev_err(&pdev->dev, "TSU region ioremap() failed.\n"); + ret = -ENOMEM; goto out_release; } mdp->port = devno % 2; Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-3.18/sh_eth-fix-sh7757-gether-initialization.patch queue-3.18/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix SH7757 GEther initialization" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix SH7757 GEther initialization to the 3.18-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: sh_eth-fix-sh7757-gether-initialization.patch and it can be found in the queue-3.18 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 foo@baz Sat Jan 13 15:16:15 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Thu, 4 Jan 2018 21:06:49 +0300 Subject: sh_eth: fix SH7757 GEther initialization From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ] Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the 'sh_eth' driver can only reset and initialize TSU of the first controller pair. Shimoda-san tried to solve that adding the 'needs_init' member to the 'struct sh_eth_plat_data', however the platform code still never sets this flag. I think that we can infer this information from the 'devno' variable (set to 'platform_device::id') and reset/init the Ether controller pair only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be removed... Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization") Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 4 ++-- include/linux/sh_eth.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -2919,8 +2919,8 @@ static int sh_eth_drv_probe(struct platf ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER; } - /* initialize first or needed device */ - if (!devno || pd->needs_init) { + /* Need to init only the first port of the two sharing a TSU */ + if (devno % 2 == 0) { if (mdp->cd->chip_reset) mdp->cd->chip_reset(ndev); --- a/include/linux/sh_eth.h +++ b/include/linux/sh_eth.h @@ -16,7 +16,6 @@ struct sh_eth_plat_data { unsigned char mac_addr[ETH_ALEN]; unsigned no_ether_link:1; unsigned ether_link_active_low:1; - unsigned needs_init:1; }; #endif Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-3.18/sh_eth-fix-sh7757-gether-initialization.patch queue-3.18/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: null pointer dereference in rds_atomic_free_op" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: null pointer dereference in rds_atomic_free_op to the 3.18-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: rds-null-pointer-dereference-in-rds_atomic_free_op.patch and it can be found in the queue-3.18 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 foo@baz Sat Jan 13 15:16:15 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Wed, 3 Jan 2018 21:06:06 +0000 Subject: RDS: null pointer dereference in rds_atomic_free_op From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ] set rm->atomic.op_active to 0 when rds_pin_pages() fails or the user supplied address is invalid, this prevents a NULL pointer usage in rds_atomic_free_op() Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -866,6 +866,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, err: if (page) put_page(page); + rm->atomic.op_active = 0; kfree(rm->atomic.op_notifier); return ret; Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-3.18/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-3.18/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: Heap OOB write in rds_message_alloc_sgs()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: Heap OOB write in rds_message_alloc_sgs() to the 3.18-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: rds-heap-oob-write-in-rds_message_alloc_sgs.patch and it can be found in the queue-3.18 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 foo@baz Sat Jan 13 15:16:15 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Tue, 2 Jan 2018 19:44:34 +0000 Subject: RDS: Heap OOB write in rds_message_alloc_sgs() From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ] When args->nr_local is 0, nr_pages gets also 0 due some size calculation via rds_rm_size(), which is later used to allocate pages for DMA, this bug produces a heap Out-Of-Bound write access to a specific memory region. Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -516,6 +516,9 @@ int rds_rdma_extra_size(struct rds_rdma_ local_vec = (struct rds_iovec __user *)(unsigned long) args->local_vec_addr; + if (args->nr_local == 0) + return -EINVAL; + /* figure out the number of pages in the vector */ for (i = 0; i < args->nr_local; i++) { if (copy_from_user(&vec, &local_vec[i], Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-3.18/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-3.18/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: stmmac: enable EEE in MII, GMII or RGMII only" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: stmmac: enable EEE in MII, GMII or RGMII only to the 3.18-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: net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch and it can be found in the queue-3.18 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 foo@baz Sat Jan 13 15:16:15 CET 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Wed, 3 Jan 2018 16:46:29 +0100 Subject: net: stmmac: enable EEE in MII, GMII or RGMII only From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 879626e3a52630316d817cbda7cec9a5446d1d82 ] Note in the databook - Section 4.4 - EEE : " The EEE feature is not supported when the MAC is configured to use the TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC supports multiple PHY interfaces, you should activate the EEE mode only when the MAC is operating with GMII, MII, or RGMII interface." Applying this restriction solves a stability issue observed on Amlogic gxl platforms operating with RMII interface and the internal PHY. Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Tested-by: Arnaud Patard <arnaud.patard(a)rtp-net.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++ include/linux/phy.h | 11 +++++++++++ 2 files changed, 17 insertions(+) --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -277,8 +277,14 @@ bool stmmac_eee_init(struct stmmac_priv { char *phy_bus_name = priv->plat->phy_bus_name; unsigned long flags; + int interface = priv->plat->interface; bool ret = false; + if ((interface != PHY_INTERFACE_MODE_MII) && + (interface != PHY_INTERFACE_MODE_GMII) && + !phy_interface_mode_is_rgmii(interface)) + goto out; + /* Using PCS we cannot dial with the phy registers at this stage * so we do not support extra feature like EEE. */ --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -678,6 +678,17 @@ static inline int phy_write_mmd(struct p } /** + * phy_interface_mode_is_rgmii - Convenience function for testing if a + * PHY interface mode is RGMII (all variants) + * @mode: the phy_interface_t enum + */ +static inline bool phy_interface_mode_is_rgmii(phy_interface_t mode) +{ + return mode >= PHY_INTERFACE_MODE_RGMII && + mode <= PHY_INTERFACE_MODE_RGMII_TXID; +}; + +/** * phy_write_mmd_indirect - writes data to the MMD registers * @phydev: The PHY device * @prtad: MMD Address Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-3.18/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: algapi - fix NULL dereference in crypto_remove_spawns()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: algapi - fix NULL dereference in crypto_remove_spawns() to the 3.18-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: crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch and it can be found in the queue-3.18 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 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 29 Dec 2017 14:30:19 -0600 Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns() From: Eric Biggers <ebiggers(a)google.com> commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream. syzkaller triggered a NULL pointer dereference in crypto_remove_spawns() via a program that repeatedly and concurrently requests AEADs "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)" through AF_ALG, where the hashes are requested as "untested" (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this causes the template to be instantiated for every request). Although AF_ALG users really shouldn't be able to request an "untested" algorithm, the NULL pointer dereference is actually caused by a longstanding race condition where crypto_remove_spawns() can encounter an instance which has had spawn(s) "grabbed" but hasn't yet been registered, resulting in ->cra_users still being NULL. We probably should properly initialize ->cra_users earlier, but that would require updating many templates individually. For now just fix the bug in a simple way that can easily be backported: make crypto_remove_spawns() treat a NULL ->cra_users list as empty. Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/algapi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/crypto/algapi.c +++ b/crypto/algapi.c @@ -159,6 +159,18 @@ void crypto_remove_spawns(struct crypto_ spawn->alg = NULL; spawns = &inst->alg.cra_users; + + /* + * We may encounter an unregistered instance here, since + * an instance's spawns are set up prior to the instance + * being registered. An unregistered instance will have + * NULL ->cra_users.next, since ->cra_users isn't + * properly initialized until registration. But an + * unregistered instance cannot have any users, so treat + * it the same as ->cra_users being empty. + */ + if (spawns->next == NULL) + break; } } while ((spawns = crypto_more_spawns(alg, &stack, &top, &secondary_spawns))); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-3.18/crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "8021q: fix a memory leak for VLAN 0 device" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 8021q: fix a memory leak for VLAN 0 device to the 3.18-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: 8021q-fix-a-memory-leak-for-vlan-0-device.patch and it can be found in the queue-3.18 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 foo@baz Sat Jan 13 15:16:15 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Tue, 9 Jan 2018 13:40:41 -0800 Subject: 8021q: fix a memory leak for VLAN 0 device From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ] A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi vlan_gvrp_uninit_applicant(real_dev); } - /* Take it out of our own structures, but be sure to interlock with - * HW accelerating devices or SW vlan input packet processing if - * VLAN is not 0 (leave it there for 802.1p). - */ - if (vlan_id) - vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); + vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev); Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-3.18/8021q-fix-a-memory-leak-for-vlan-0-device.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] patch "USB: serial: io_edgeport: fix possible sleep-in-atomic" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: io_edgeport: fix possible sleep-in-atomic to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing 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 be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From c7b8f77872c73f69a16528a9eb87afefcccdc18b Mon Sep 17 00:00:00 2001 From: Jia-Ju Bai <baijiaju1990(a)gmail.com> Date: Wed, 13 Dec 2017 20:34:36 +0800 Subject: USB: serial: io_edgeport: fix possible sleep-in-atomic According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/io_edgeport.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c index 219265ce3711..17283f4b4779 100644 --- a/drivers/usb/serial/io_edgeport.c +++ b/drivers/usb/serial/io_edgeport.c @@ -2282,7 +2282,6 @@ static int write_cmd_usb(struct edgeport_port *edge_port, /* something went wrong */ dev_err(dev, "%s - usb_submit_urb(write command) failed, status = %d\n", __func__, status); - usb_kill_urb(urb); usb_free_urb(urb); atomic_dec(&CmdUrbs); return status; -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix TSU resource handling" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix TSU resource handling to the 4.4-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: sh_eth-fix-tsu-resource-handling.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Wed, 3 Jan 2018 20:09:49 +0300 Subject: sh_eth: fix TSU resource handling From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ] When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3176,10 +3176,29 @@ static int sh_eth_drv_probe(struct platf /* ioremap the TSU registers */ if (mdp->cd->tsu) { struct resource *rtsu; + rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1); - mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu); - if (IS_ERR(mdp->tsu_addr)) { - ret = PTR_ERR(mdp->tsu_addr); + if (!rtsu) { + dev_err(&pdev->dev, "no TSU resource\n"); + ret = -ENODEV; + goto out_release; + } + /* We can only request the TSU region for the first port + * of the two sharing this TSU for the probe to succeed... + */ + if (devno % 2 == 0 && + !devm_request_mem_region(&pdev->dev, rtsu->start, + resource_size(rtsu), + dev_name(&pdev->dev))) { + dev_err(&pdev->dev, "can't request TSU resource.\n"); + ret = -EBUSY; + goto out_release; + } + mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start, + resource_size(rtsu)); + if (!mdp->tsu_addr) { + dev_err(&pdev->dev, "TSU region ioremap() failed.\n"); + ret = -ENOMEM; goto out_release; } mdp->port = devno % 2; Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.4/sh_eth-fix-sh7757-gether-initialization.patch queue-4.4/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix SH7757 GEther initialization" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix SH7757 GEther initialization to the 4.4-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: sh_eth-fix-sh7757-gether-initialization.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Thu, 4 Jan 2018 21:06:49 +0300 Subject: sh_eth: fix SH7757 GEther initialization From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ] Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the 'sh_eth' driver can only reset and initialize TSU of the first controller pair. Shimoda-san tried to solve that adding the 'needs_init' member to the 'struct sh_eth_plat_data', however the platform code still never sets this flag. I think that we can infer this information from the 'devno' variable (set to 'platform_device::id') and reset/init the Ether controller pair only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be removed... Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization") Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 4 ++-- include/linux/sh_eth.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3205,8 +3205,8 @@ static int sh_eth_drv_probe(struct platf ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER; } - /* initialize first or needed device */ - if (!devno || pd->needs_init) { + /* Need to init only the first port of the two sharing a TSU */ + if (devno % 2 == 0) { if (mdp->cd->chip_reset) mdp->cd->chip_reset(ndev); --- a/include/linux/sh_eth.h +++ b/include/linux/sh_eth.h @@ -16,7 +16,6 @@ struct sh_eth_plat_data { unsigned char mac_addr[ETH_ALEN]; unsigned no_ether_link:1; unsigned ether_link_active_low:1; - unsigned needs_init:1; }; #endif Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.4/sh_eth-fix-sh7757-gether-initialization.patch queue-4.4/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: null pointer dereference in rds_atomic_free_op" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: null pointer dereference in rds_atomic_free_op to the 4.4-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: rds-null-pointer-dereference-in-rds_atomic_free_op.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Wed, 3 Jan 2018 21:06:06 +0000 Subject: RDS: null pointer dereference in rds_atomic_free_op From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ] set rm->atomic.op_active to 0 when rds_pin_pages() fails or the user supplied address is invalid, this prevents a NULL pointer usage in rds_atomic_free_op() Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -869,6 +869,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, err: if (page) put_page(page); + rm->atomic.op_active = 0; kfree(rm->atomic.op_notifier); return ret; Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.4/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.4/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: Heap OOB write in rds_message_alloc_sgs()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: Heap OOB write in rds_message_alloc_sgs() to the 4.4-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: rds-heap-oob-write-in-rds_message_alloc_sgs.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Tue, 2 Jan 2018 19:44:34 +0000 Subject: RDS: Heap OOB write in rds_message_alloc_sgs() From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ] When args->nr_local is 0, nr_pages gets also 0 due some size calculation via rds_rm_size(), which is later used to allocate pages for DMA, this bug produces a heap Out-Of-Bound write access to a specific memory region. Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -517,6 +517,9 @@ int rds_rdma_extra_size(struct rds_rdma_ local_vec = (struct rds_iovec __user *)(unsigned long) args->local_vec_addr; + if (args->nr_local == 0) + return -EINVAL; + /* figure out the number of pages in the vector */ for (i = 0; i < args->nr_local; i++) { if (copy_from_user(&vec, &local_vec[i], Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.4/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.4/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: stmmac: enable EEE in MII, GMII or RGMII only" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: stmmac: enable EEE in MII, GMII or RGMII only to the 4.4-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: net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Wed, 3 Jan 2018 16:46:29 +0100 Subject: net: stmmac: enable EEE in MII, GMII or RGMII only From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 879626e3a52630316d817cbda7cec9a5446d1d82 ] Note in the databook - Section 4.4 - EEE : " The EEE feature is not supported when the MAC is configured to use the TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC supports multiple PHY interfaces, you should activate the EEE mode only when the MAC is operating with GMII, MII, or RGMII interface." Applying this restriction solves a stability issue observed on Amlogic gxl platforms operating with RMII interface and the internal PHY. Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Tested-by: Arnaud Patard <arnaud.patard(a)rtp-net.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++ include/linux/phy.h | 11 +++++++++++ 2 files changed, 17 insertions(+) --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -272,8 +272,14 @@ bool stmmac_eee_init(struct stmmac_priv { char *phy_bus_name = priv->plat->phy_bus_name; unsigned long flags; + int interface = priv->plat->interface; bool ret = false; + if ((interface != PHY_INTERFACE_MODE_MII) && + (interface != PHY_INTERFACE_MODE_GMII) && + !phy_interface_mode_is_rgmii(interface)) + goto out; + /* Using PCS we cannot dial with the phy registers at this stage * so we do not support extra feature like EEE. */ --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -683,6 +683,17 @@ static inline bool phy_is_internal(struc } /** + * phy_interface_mode_is_rgmii - Convenience function for testing if a + * PHY interface mode is RGMII (all variants) + * @mode: the phy_interface_t enum + */ +static inline bool phy_interface_mode_is_rgmii(phy_interface_t mode) +{ + return mode >= PHY_INTERFACE_MODE_RGMII && + mode <= PHY_INTERFACE_MODE_RGMII_TXID; +}; + +/** * phy_interface_is_rgmii - Convenience function for testing if a PHY interface * is RGMII (all variants) * @phydev: the phy_device struct Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.4/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: core: fix module type in sock_diag_bind" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: core: fix module type in sock_diag_bind to the 4.4-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: net-core-fix-module-type-in-sock_diag_bind.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Andrii Vladyka <tulup(a)mail.ru> Date: Thu, 4 Jan 2018 13:09:17 +0200 Subject: net: core: fix module type in sock_diag_bind From: Andrii Vladyka <tulup(a)mail.ru> [ Upstream commit b8fd0823e0770c2d5fdbd865bccf0d5e058e5287 ] Use AF_INET6 instead of AF_INET in IPv6-related code path Signed-off-by: Andrii Vladyka <tulup(a)mail.ru> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/sock_diag.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/core/sock_diag.c +++ b/net/core/sock_diag.c @@ -289,7 +289,7 @@ static int sock_diag_bind(struct net *ne case SKNLGRP_INET6_UDP_DESTROY: if (!sock_diag_handlers[AF_INET6]) request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK, - NETLINK_SOCK_DIAG, AF_INET); + NETLINK_SOCK_DIAG, AF_INET6); break; } return 0; Patches currently in stable-queue which might be from tulup(a)mail.ru are queue-4.4/net-core-fix-module-type-in-sock_diag_bind.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ipv6: fix possible mem leaks in ipv6_make_skb()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: fix possible mem leaks in ipv6_make_skb() to the 4.4-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: ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 10 Jan 2018 03:45:49 -0800 Subject: ipv6: fix possible mem leaks in ipv6_make_skb() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ] ip6_setup_cork() might return an error, while memory allocations have been done and must be rolled back. Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Vlad Yasevich <vyasevich(a)gmail.com> Reported-by: Mike Maloney <maloney(a)google.com> Acked-by: Mike Maloney <maloney(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_output.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1785,8 +1785,10 @@ struct sk_buff *ip6_make_skb(struct sock cork.base.opt = NULL; v6_cork.opt = NULL; err = ip6_setup_cork(sk, &cork, &v6_cork, hlimit, tclass, opt, rt, fl6); - if (err) + if (err) { + ip6_cork_release(&cork, &v6_cork); return ERR_PTR(err); + } if (dontfrag < 0) dontfrag = inet6_sk(sk)->dontfrag; Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ip6_tunnel: disable dst caching if tunnel is dual-stack" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_tunnel: disable dst caching if tunnel is dual-stack to the 4.4-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: ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Eli Cooper <elicooper(a)gmx.com> Date: Mon, 25 Dec 2017 10:43:49 +0800 Subject: ip6_tunnel: disable dst caching if tunnel is dual-stack From: Eli Cooper <elicooper(a)gmx.com> [ Upstream commit 23263ec86a5f44312d2899323872468752324107 ] When an ip6_tunnel is in mode 'any', where the transport layer protocol can be either 4 or 41, dst_cache must be disabled. This is because xfrm policies might apply to only one of the two protocols. Caching dst would cause xfrm policies for one protocol incorrectly used for the other. Signed-off-by: Eli Cooper <elicooper(a)gmx.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_tunnel.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1083,10 +1083,11 @@ static int ip6_tnl_xmit2(struct sk_buff memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr)); neigh_release(neigh); } - } else if (!(t->parms.flags & - (IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) { - /* enable the cache only only if the routing decision does - * not depend on the current inner header value + } else if (t->parms.proto != 0 && !(t->parms.flags & + (IP6_TNL_F_USE_ORIG_TCLASS | + IP6_TNL_F_USE_ORIG_FWMARK))) { + /* enable the cache only if neither the outer protocol nor the + * routing decision depends on the current inner header value */ use_cache = true; } Patches currently in stable-queue which might be from elicooper(a)gmx.com are queue-4.4/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "8021q: fix a memory leak for VLAN 0 device" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 8021q: fix a memory leak for VLAN 0 device to the 4.4-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: 8021q-fix-a-memory-leak-for-vlan-0-device.patch and it can be found in the queue-4.4 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 foo@baz Sat Jan 13 14:28:20 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Tue, 9 Jan 2018 13:40:41 -0800 Subject: 8021q: fix a memory leak for VLAN 0 device From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ] A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi vlan_gvrp_uninit_applicant(real_dev); } - /* Take it out of our own structures, but be sure to interlock with - * HW accelerating devices or SW vlan input packet processing if - * VLAN is not 0 (leave it there for 802.1p). - */ - if (vlan_id) - vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); + vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev); Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.4/8021q-fix-a-memory-leak-for-vlan-0-device.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "membarrier: Disable preemption when calling smp_call_function_many()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled membarrier: Disable preemption when calling smp_call_function_many() to the 4.14-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: membarrier-disable-preemption-when-calling-smp_call_function_many.patch and it can be found in the queue-4.14 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 541676078b52f365f53d46ee5517d305cd1b6350 Mon Sep 17 00:00:00 2001 From: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Date: Fri, 15 Dec 2017 14:23:10 -0500 Subject: membarrier: Disable preemption when calling smp_call_function_many() From: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> commit 541676078b52f365f53d46ee5517d305cd1b6350 upstream. smp_call_function_many() requires disabling preemption around the call. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Andrea Parri <parri.andrea(a)gmail.com> Cc: Andrew Hunter <ahh(a)google.com> Cc: Avi Kivity <avi(a)scylladb.com> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Boqun Feng <boqun.feng(a)gmail.com> Cc: Dave Watson <davejwatson(a)fb.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Maged Michael <maged.michael(a)gmail.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Paul E . McKenney <paulmck(a)linux.vnet.ibm.com> Cc: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Cc: Paul Mackerras <paulus(a)samba.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20171215192310.25293-1-mathieu.desnoyers@efficios.… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/membarrier.c | 2 ++ 1 file changed, 2 insertions(+) --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -89,7 +89,9 @@ static int membarrier_private_expedited( rcu_read_unlock(); } if (!fallback) { + preempt_disable(); smp_call_function_many(tmpmask, ipi_mb, NULL, 1); + preempt_enable(); free_cpumask_var(tmpmask); } cpus_read_unlock(); Patches currently in stable-queue which might be from mathieu.desnoyers(a)efficios.com are queue-4.14/membarrier-disable-preemption-when-calling-smp_call_function_many.patch queue-4.14/kvm-fix-stack-out-of-bounds-read-in-write_mmio.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/pti/efi: broken conversion from efi to kernel page table" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/pti/efi: broken conversion from efi to kernel page table to the 4.9-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: x86-pti-efi-broken-conversion-from-efi-to-kernel-page-table.patch and it can be found in the queue-4.9 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 pasha.tatashin(a)oracle.com Sat Jan 13 14:16:28 2018 From: Pavel Tatashin <pasha.tatashin(a)oracle.com> Date: Thu, 11 Jan 2018 16:58:20 -0500 Subject: x86/pti/efi: broken conversion from efi to kernel page table To: steven.sistare(a)oracle.com, linux-kernel(a)vger.kernel.org, tglx(a)linutronix.de, mingo(a)redhat.com, hpa(a)zytor.com, x86(a)kernel.org, gregkh(a)linuxfoundation.org, jkosina(a)suse.cz, hughd(a)google.com, dave.hansen(a)linux.intel.com, luto(a)kernel.org, torvalds(a)linux-foundation.org Message-ID: <20180111215820.29736-1-pasha.tatashin(a)oracle.com> From: Pavel Tatashin <pasha.tatashin(a)oracle.com> The page table order must be increased for EFI table in order to avoid a bug where NMI tries to change the page table to kernel page table, while efi page table is active. For more disccussion about this bug, see this thread: http://lkml.iu.edu/hypermail/linux/kernel/1801.1/00951.html Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Reviewed-by: Steven Sistare <steven.sistare(a)oracle.com> Acked-by: Jiri Kosina <jkosina(a)suse.cz> --- arch/x86/include/asm/pgalloc.h | 11 +++++++++++ arch/x86/platform/efi/efi_64.c | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/pgalloc.h +++ b/arch/x86/include/asm/pgalloc.h @@ -27,6 +27,17 @@ static inline void paravirt_release_pud( */ extern gfp_t __userpte_alloc_gfp; +#ifdef CONFIG_PAGE_TABLE_ISOLATION +/* + * Instead of one PGD, we acquire two PGDs. Being order-1, it is + * both 8k in size and 8k-aligned. That lets us just flip bit 12 + * in a pointer to swap between the two 4k halves. + */ +#define PGD_ALLOCATION_ORDER 1 +#else +#define PGD_ALLOCATION_ORDER 0 +#endif + /* * Allocate and free page tables. */ --- a/arch/x86/platform/efi/efi_64.c +++ b/arch/x86/platform/efi/efi_64.c @@ -142,7 +142,7 @@ int __init efi_alloc_page_tables(void) return 0; gfp_mask = GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO; - efi_pgd = (pgd_t *)__get_free_page(gfp_mask); + efi_pgd = (pgd_t *)__get_free_pages(gfp_mask, PGD_ALLOCATION_ORDER); if (!efi_pgd) return -ENOMEM; Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are queue-4.9/x86-pti-efi-broken-conversion-from-efi-to-kernel-page-table.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/pti/efi: broken conversion from efi to kernel page table" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/pti/efi: broken conversion from efi to kernel page table to the 4.4-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: x86-pti-efi-broken-conversion-from-efi-to-kernel-page-table.patch and it can be found in the queue-4.4 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 pasha.tatashin(a)oracle.com Sat Jan 13 14:14:57 2018 From: Pavel Tatashin <pasha.tatashin(a)oracle.com> Date: Thu, 11 Jan 2018 14:07:46 -0500 Subject: x86/pti/efi: broken conversion from efi to kernel page table To: steven.sistare(a)oracle.com, linux-kernel(a)vger.kernel.org, tglx(a)linutronix.de, mingo(a)redhat.com, hpa(a)zytor.com, x86(a)kernel.org, gregkh(a)linuxfoundation.org, jkosina(a)suse.cz, hughd(a)google.com, dave.hansen(a)linux.intel.com, luto(a)kernel.org, torvalds(a)linux-foundation.org Message-ID: <20180111190746.15426-2-pasha.tatashin(a)oracle.com> From: Pavel Tatashin <pasha.tatashin(a)oracle.com> In entry_64.S we have code like this: /* Unconditionally use kernel CR3 for do_nmi() */ /* %rax is saved above, so OK to clobber here */ ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER /* If PCID enabled, NOFLUSH now and NOFLUSH on return */ ALTERNATIVE "", "bts $63, %rax", X86_FEATURE_PCID pushq %rax /* mask off "user" bit of pgd address and 12 PCID bits: */ andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax movq %rax, %cr3 2: /* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */ call do_nmi With this instruction: andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax We unconditionally switch from whatever our CR3 was to kernel page table. But, in arch/x86/platform/efi/efi_64.c We temporarily set a different page table, that does not have the kernel page table with 0x1000 offset from it. Look in efi_thunk() and efi_thunk_set_virtual_address_map(). So, while CR3 points to the other page table, we get an NMI interrupt, and clear 0x1000 from CR3, resulting in a bogus CR3 if the 0x1000 bit was set. The efi page table comes from realmode/rm/trampoline_64.S: arch/x86/realmode/rm/trampoline_64.S 141 .bss 142 .balign PAGE_SIZE 143 GLOBAL(trampoline_pgd) .space PAGE_SIZE Notice: alignment is PAGE_SIZE, so after applying KAISER_SHADOW_PGD_OFFSET which equal to PAGE_SIZE, we can get a different page table. But, even if we fix alignment, here the trampoline binary is later copied into dynamically allocated memory in reserve_real_mode(), so we need to fix that place as well. Fixes: 8a43ddfb93a0 ("KAISER: Kernel Address Isolation") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Reviewed-by: Steven Sistare <steven.sistare(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/kaiser.h | 8 ++++++++ arch/x86/realmode/init.c | 4 +++- arch/x86/realmode/rm/trampoline_64.S | 3 ++- 3 files changed, 13 insertions(+), 2 deletions(-) --- a/arch/x86/include/asm/kaiser.h +++ b/arch/x86/include/asm/kaiser.h @@ -19,6 +19,12 @@ #define KAISER_SHADOW_PGD_OFFSET 0x1000 +/* + * A page table address must have this alignment to stay the same when + * KAISER_SHADOW_PGD_OFFSET mask is applied + */ +#define KAISER_KERNEL_PGD_ALIGNMENT (KAISER_SHADOW_PGD_OFFSET << 1) + #ifdef __ASSEMBLY__ #ifdef CONFIG_PAGE_TABLE_ISOLATION @@ -71,6 +77,8 @@ movq PER_CPU_VAR(unsafe_stack_register_b #else /* CONFIG_PAGE_TABLE_ISOLATION */ +#define KAISER_KERNEL_PGD_ALIGNMENT PAGE_SIZE + .macro SWITCH_KERNEL_CR3 .endm .macro SWITCH_USER_CR3 --- a/arch/x86/realmode/init.c +++ b/arch/x86/realmode/init.c @@ -1,5 +1,6 @@ #include <linux/io.h> #include <linux/memblock.h> +#include <linux/kaiser.h> #include <asm/cacheflush.h> #include <asm/pgtable.h> @@ -15,7 +16,8 @@ void __init reserve_real_mode(void) size_t size = PAGE_ALIGN(real_mode_blob_end - real_mode_blob); /* Has to be under 1M so we can execute real-mode AP code. */ - mem = memblock_find_in_range(0, 1<<20, size, PAGE_SIZE); + mem = memblock_find_in_range(0, 1 << 20, size, + KAISER_KERNEL_PGD_ALIGNMENT); if (!mem) panic("Cannot allocate trampoline\n"); --- a/arch/x86/realmode/rm/trampoline_64.S +++ b/arch/x86/realmode/rm/trampoline_64.S @@ -30,6 +30,7 @@ #include <asm/msr.h> #include <asm/segment.h> #include <asm/processor-flags.h> +#include <asm/kaiser.h> #include "realmode.h" .text @@ -139,7 +140,7 @@ tr_gdt: tr_gdt_end: .bss - .balign PAGE_SIZE + .balign KAISER_KERNEL_PGD_ALIGNMENT GLOBAL(trampoline_pgd) .space PAGE_SIZE .balign 8 Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are queue-4.4/x86-pti-efi-broken-conversion-from-efi-to-kernel-page-table.patch

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] Yet another KPTI regression with 4.14.x series in a VM

by Peter Zijlstra

On Sat, Jan 13, 2018 at 12:30:11PM +0000, David Woodhouse wrote: > On Sat, 2018-01-13 at 13:08 +0100, Peter Zijlstra wrote: > > > > ALTERNATIVE "orq $(PTI_SWITCH_PGTABLE_MASK), \scratch_reg", > > "orq $(PTI_SWITCH_MASK), \scratch_reg", X86_FEATURE_PCID > > > > Is not wanting to compile though; probably that whole alternative vs > > macro thing again :/ > > Welcome to my world. Try > > ALTERNATIVE __stringify(orq $(PTI_SWITCH_PGTABLE_MASK), \scratch_reg), \ > __stringify(orq $(PTI_SWITCH_MASK), \scratch_reg), \ > X86_FEATURE_PCID Doesn't seem to work, gets literal __stringy() crud in the .s file.

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "userfaultfd: selftest: vm: allow to build in vm/ directory"" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "userfaultfd: selftest: vm: allow to build in vm/ directory" to the 4.4-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: revert-userfaultfd-selftest-vm-allow-to-build-in-vm.patch and it can be found in the queue-4.4 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 b224975a2c971c773f1211483a1392262fe8fb15 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Sat, 13 Jan 2018 11:19:07 +0100 Subject: Revert "userfaultfd: selftest: vm: allow to build in vm/ directory" From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> This reverts commit b5213e1e9f25ccde958aa6364815ee87fef91100 which was commit 46aa6a302b53f543f8e8b8e1714dc5e449ad36a6 upstream. This is being reverted because the affected commit this was trying to fix, a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT"), was never backported to the 4.4-stable tree. Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: "Dr. David Alan Gilbert" <dgilbert(a)redhat.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Pavel Emelyanov <xemul(a)parallels.com> Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/Makefile | 4 ---- 1 file changed, 4 deletions(-) --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -1,9 +1,5 @@ # Makefile for vm selftests -ifndef OUTPUT - OUTPUT := $(shell pwd) -endif - CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS) BINARIES = compaction_test BINARIES += hugepage-mmap Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.4/kvm-vmx-scrub-hardware-gprs-at-vm-exit.patch queue-4.4/net-mac80211-debugfs.c-prevent-build-failure-with-config_ubsan-y.patch queue-4.4/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-4.4/hwrng-core-sleep-interruptible-in-read.patch queue-4.4/x86-mm-pat-dev-mem-remove-superfluous-error-message.patch queue-4.4/mm-zswap-use-workqueue-to-destroy-pool.patch queue-4.4/mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_page.patch queue-4.4/alsa-pcm-remove-incorrect-snd_bug_on-usages.patch queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch queue-4.4/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-4.4/ib-srpt-disable-rdma-access-by-the-initiator.patch queue-4.4/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-4.4/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-4.4/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-4.4/locking-mutex-allow-next-waiter-lockless-wakeup.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/r8152-fix-the-wake-event.patch queue-4.4/mm-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.patch queue-4.4/x86-vsdo-fix-build-on-paravirt_clock-y-kvm_guest-n.patch queue-4.4/dm-bufio-fix-shrinker-scans-when-nr_to_scan-retain_target.patch queue-4.4/can-gs_usb-fix-return-value-of-the-set_bittiming-callback.patch queue-4.4/x86-acpi-handle-sci-interrupts-above-legacy-space-gracefully.patch queue-4.4/zswap-don-t-param_set_charp-while-holding-spinlock.patch queue-4.4/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch queue-4.4/alsa-pcm-add-missing-error-checks-in-oss-emulation-plugin-builder.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/futex-replace-barrier-in-unqueue_me-with-read_once.patch queue-4.4/iommu-arm-smmu-v3-don-t-free-page-table-ops-twice.patch queue-4.4/r8152-adjust-aldps-function.patch queue-4.4/kvm-fix-stack-out-of-bounds-read-in-write_mmio.patch queue-4.4/revert-userfaultfd-selftest-vm-allow-to-build-in-vm.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/alsa-pcm-abort-properly-at-pending-signal-in-oss-read-write-loops.patch queue-4.4/usbvision-fix-overflow-of-interfaces-array.patch queue-4.4/mm-page-writeback-fix-dirty_ratelimit-calculation.patch queue-4.4/alsa-pcm-allow-aborting-mutex-lock-at-oss-read-write-loops.patch queue-4.4/r8152-use-test_and_clear_bit.patch queue-4.4/locks-don-t-check-for-race-with-close-when-setting-ofd-lock.patch queue-4.4/x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch queue-4.4/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch queue-4.4/alsa-aloop-fix-racy-hw-constraints-adjustment.patch queue-4.4/alsa-aloop-release-cable-upon-open-error-path.patch queue-4.4/sysrq-fix-warning-in-sysrq-generated-crash.patch queue-4.4/usb-musb-ux500-fix-null-pointer-dereference-at-system-pm.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] selftests/x86: Add test_vsyscall

by Andy Lutomirski

This tests that the vsyscall entries do what they're expected to do. It also confirms that attempts to read the vsyscall page behave as expected. If changes are made to the vsyscall code or its memory map handling, running this test in all three of vsyscall=none, vsyscall=emulate, and vsyscall=native are helpful. (Because it's easy, this also compares the vsyscall results to their vDSO equivalents.) Cc: stable(a)vger.kernel.org Signed-off-by: Andy Lutomirski <luto(a)kernel.org> --- Note to KAISER backporters: please test this under all three vsyscall modes. Also, in the emulate and native modes, make sure that test_vsyscall_64 agrees with the command line or config option as to which mode you're in. It's quite easy to mess up the kernel such that native mode accidentally emulates or vice versa. Greg, etc: please backport this to all your Meltdown-patched kernels. It'll help make sure the patches didn't regress vsyscalls. Changes from RFC version: - Doesn't warn on 32-bit - Detects native vs emulate tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/test_vsyscall.c | 500 ++++++++++++++++++++++++++++ 2 files changed, 501 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/x86/test_vsyscall.c diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 939a337128db..5d4f10ac2af2 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -7,7 +7,7 @@ include ../lib.mk TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt ptrace_syscall test_mremap_vdso \ check_initial_reg_state sigreturn ldt_gdt iopl mpx-mini-test ioperm \ - protection_keys test_vdso + protection_keys test_vdso test_vsyscall TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso unwind_vdso \ test_FCMOV test_FCOMI test_FISTTP \ vdso_restorer diff --git a/tools/testing/selftests/x86/test_vsyscall.c b/tools/testing/selftests/x86/test_vsyscall.c new file mode 100644 index 000000000000..7a744fa7b786 --- /dev/null +++ b/tools/testing/selftests/x86/test_vsyscall.c @@ -0,0 +1,500 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#define _GNU_SOURCE + +#include <stdio.h> +#include <sys/time.h> +#include <time.h> +#include <stdlib.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <dlfcn.h> +#include <string.h> +#include <inttypes.h> +#include <signal.h> +#include <sys/ucontext.h> +#include <errno.h> +#include <err.h> +#include <sched.h> +#include <stdbool.h> +#include <setjmp.h> + +#ifdef __x86_64__ +# define VSYS(x) (x) +#else +# define VSYS(x) 0 +#endif + +#ifndef SYS_getcpu +# ifdef __x86_64__ +# define SYS_getcpu 309 +# else +# define SYS_getcpu 318 +# endif +#endif + +static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *), + int flags) +{ + struct sigaction sa; + memset(&sa, 0, sizeof(sa)); + sa.sa_sigaction = handler; + sa.sa_flags = SA_SIGINFO | flags; + sigemptyset(&sa.sa_mask); + if (sigaction(sig, &sa, 0)) + err(1, "sigaction"); +} + +/* vsyscalls and vDSO */ +bool should_read_vsyscall = false; + +typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); +gtod_t vgtod = (gtod_t)VSYS(0xffffffffff600000); +gtod_t vdso_gtod; + +typedef int (*vgettime_t)(clockid_t, struct timespec *); +vgettime_t vdso_gettime; + +typedef long (*time_func_t)(time_t *t); +time_func_t vtime = (time_func_t)VSYS(0xffffffffff600400); +time_func_t vdso_time; + +typedef long (*getcpu_t)(unsigned *, unsigned *, void *); +getcpu_t vgetcpu = (getcpu_t)VSYS(0xffffffffff600800); +getcpu_t vdso_getcpu; + +static void init_vdso(void) +{ + void *vdso = dlopen("linux-vdso.so.1", RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD); + if (!vdso) + vdso = dlopen("linux-gate.so.1", RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD); + if (!vdso) { + printf("[WARN]\tfailed to find vDSO\n"); + return; + } + + vdso_gtod = (gtod_t)dlsym(vdso, "__vdso_gettimeofday"); + if (!vdso_gtod) + printf("[WARN]\tfailed to find gettimeofday in vDSO\n"); + + vdso_gettime = (vgettime_t)dlsym(vdso, "__vdso_clock_gettime"); + if (!vdso_gettime) + printf("[WARN]\tfailed to find clock_gettime in vDSO\n"); + + vdso_time = (time_func_t)dlsym(vdso, "__vdso_time"); + if (!vdso_time) + printf("[WARN]\tfailed to find time in vDSO\n"); + + vdso_getcpu = (getcpu_t)dlsym(vdso, "__vdso_getcpu"); + if (!vdso_getcpu) { + /* getcpu() was never wired up in the 32-bit vDSO. */ + printf("[%s]\tfailed to find getcpu in vDSO\n", + sizeof(long) == 8 ? "WARN" : "NOTE"); + } +} + +static int init_vsys(void) +{ +#ifdef __x86_64__ + int nerrs = 0; + FILE *maps; + char line[128]; + bool found = false; + + maps = fopen("/proc/self/maps", "r"); + if (!maps) { + printf("[WARN]\tCould not open /proc/self/maps -- assuming vsyscall is r-x\n"); + should_read_vsyscall = true; + return 0; + } + + while (fgets(line, sizeof(line), maps)) { + char r, x; + void *start, *end; + char name[128]; + if (sscanf(line, "%p-%p %c-%cp %*x %*x:%*x %*u %s", + &start, &end, &r, &x, name) != 5) + continue; + + if (strcmp(name, "[vsyscall]")) + continue; + + printf("\tvsyscall map: %s", line); + + if (start != (void *)0xffffffffff600000 || + end != (void *)0xffffffffff601000) { + printf("[FAIL]\taddress range is nonsense\n"); + nerrs++; + } + + printf("\tvsyscall permissions are %c-%c\n", r, x); + should_read_vsyscall = (r == 'r'); + if (x != 'x') { + vgtod = NULL; + vtime = NULL; + vgetcpu = NULL; + } + + found = true; + break; + } + + fclose(maps); + + if (!found) { + printf("\tno vsyscall map in /proc/self/maps\n"); + should_read_vsyscall = false; + vgtod = NULL; + vtime = NULL; + vgetcpu = NULL; + } + + return nerrs; +#else + return 0; +#endif +} + +/* syscalls */ +static inline long sys_gtod(struct timeval *tv, struct timezone *tz) +{ + return syscall(SYS_gettimeofday, tv, tz); +} + +static inline int sys_clock_gettime(clockid_t id, struct timespec *ts) +{ + return syscall(SYS_clock_gettime, id, ts); +} + +static inline long sys_time(time_t *t) +{ + return syscall(SYS_time, t); +} + +static inline long sys_getcpu(unsigned * cpu, unsigned * node, + void* cache) +{ + return syscall(SYS_getcpu, cpu, node, cache); +} + +static jmp_buf jmpbuf; + +static void sigsegv(int sig, siginfo_t *info, void *ctx_void) +{ + siglongjmp(jmpbuf, 1); +} + +static double tv_diff(const struct timeval *a, const struct timeval *b) +{ + return (double)(a->tv_sec - b->tv_sec) + + (double)((int)a->tv_usec - (int)b->tv_usec) * 1e-6; +} + +static int check_gtod(const struct timeval *tv_sys1, + const struct timeval *tv_sys2, + const struct timezone *tz_sys, + const char *which, + const struct timeval *tv_other, + const struct timezone *tz_other) +{ + int nerrs = 0; + double d1, d2; + + if (tz_other && (tz_sys->tz_minuteswest != tz_other->tz_minuteswest || tz_sys->tz_dsttime != tz_other->tz_dsttime)) { + printf("[FAIL] %s tz mismatch\n", which); + nerrs++; + } + + d1 = tv_diff(tv_other, tv_sys1); + d2 = tv_diff(tv_sys2, tv_other); + printf("\t%s time offsets: %lf %lf\n", which, d1, d2); + + if (d1 < 0 || d2 < 0) { + printf("[FAIL]\t%s time was inconsistent with the syscall\n", which); + nerrs++; + } else { + printf("[OK]\t%s gettimeofday()'s timeval was okay\n", which); + } + + return nerrs; +} + +static int test_gtod(void) +{ + struct timeval tv_sys1, tv_sys2, tv_vdso, tv_vsys; + struct timezone tz_sys, tz_vdso, tz_vsys; + long ret_vdso = -1; + long ret_vsys = -1; + int nerrs = 0; + + printf("[RUN]\ttest gettimeofday()\n"); + + if (sys_gtod(&tv_sys1, &tz_sys) != 0) + err(1, "syscall gettimeofday"); + if (vdso_gtod) + ret_vdso = vdso_gtod(&tv_vdso, &tz_vdso); + if (vgtod) + ret_vsys = vgtod(&tv_vsys, &tz_vsys); + if (sys_gtod(&tv_sys2, &tz_sys) != 0) + err(1, "syscall gettimeofday"); + + if (vdso_gtod) { + if (ret_vdso == 0) { + nerrs += check_gtod(&tv_sys1, &tv_sys2, &tz_sys, "vDSO", &tv_vdso, &tz_vdso); + } else { + printf("[FAIL]\tvDSO gettimeofday() failed: %ld\n", ret_vdso); + nerrs++; + } + } + + if (vgtod) { + if (ret_vsys == 0) { + nerrs += check_gtod(&tv_sys1, &tv_sys2, &tz_sys, "vsyscall", &tv_vsys, &tz_vsys); + } else { + printf("[FAIL]\tvsys gettimeofday() failed: %ld\n", ret_vsys); + nerrs++; + } + } + + return nerrs; +} + +static int test_time(void) { + int nerrs = 0; + + printf("[RUN]\ttest time()\n"); + long t_sys1, t_sys2, t_vdso = 0, t_vsys = 0; + long t2_sys1 = -1, t2_sys2 = -1, t2_vdso = -1, t2_vsys = -1; + t_sys1 = sys_time(&t2_sys1); + if (vdso_time) + t_vdso = vdso_time(&t2_vdso); + if (vtime) + t_vsys = vtime(&t2_vsys); + t_sys2 = sys_time(&t2_sys2); + if (t_sys1 < 0 || t_sys1 != t2_sys1 || t_sys2 < 0 || t_sys2 != t2_sys2) { + printf("[FAIL]\tsyscall failed (ret1:%ld output1:%ld ret2:%ld output2:%ld)\n", t_sys1, t2_sys1, t_sys2, t2_sys2); + nerrs++; + return nerrs; + } + + if (vdso_time) { + if (t_vdso < 0 || t_vdso != t2_vdso) { + printf("[FAIL]\tvDSO failed (ret:%ld output:%ld)\n", t_vdso, t2_vdso); + nerrs++; + } else if (t_vdso < t_sys1 || t_vdso > t_sys2) { + printf("[FAIL]\tvDSO returned the wrong time (%ld %ld %ld)\n", t_sys1, t_vdso, t_sys2); + nerrs++; + } else { + printf("[OK]\tvDSO time() is okay\n"); + } + } + + if (vtime) { + if (t_vsys < 0 || t_vsys != t2_vsys) { + printf("[FAIL]\tvsyscall failed (ret:%ld output:%ld)\n", t_vsys, t2_vsys); + nerrs++; + } else if (t_vsys < t_sys1 || t_vsys > t_sys2) { + printf("[FAIL]\tvsyscall returned the wrong time (%ld %ld %ld)\n", t_sys1, t_vsys, t_sys2); + nerrs++; + } else { + printf("[OK]\tvsyscall time() is okay\n"); + } + } + + return nerrs; +} + +static int test_getcpu(int cpu) +{ + int nerrs = 0; + long ret_sys, ret_vdso = -1, ret_vsys = -1; + + printf("[RUN]\tgetcpu() on CPU %d\n", cpu); + + cpu_set_t cpuset; + CPU_ZERO(&cpuset); + CPU_SET(cpu, &cpuset); + if (sched_setaffinity(0, sizeof(cpuset), &cpuset) != 0) { + printf("[SKIP]\tfailed to force CPU %d\n", cpu); + return nerrs; + } + + unsigned cpu_sys, cpu_vdso, cpu_vsys, node_sys, node_vdso, node_vsys; + unsigned node = 0; + bool have_node = false; + ret_sys = sys_getcpu(&cpu_sys, &node_sys, 0); + if (vdso_getcpu) + ret_vdso = vdso_getcpu(&cpu_vdso, &node_vdso, 0); + if (vgetcpu) + ret_vsys = vgetcpu(&cpu_vsys, &node_vsys, 0); + + if (ret_sys == 0) { + if (cpu_sys != cpu) { + printf("[FAIL]\tsyscall reported CPU %hu but should be %d\n", cpu_sys, cpu); + nerrs++; + } + + have_node = true; + node = node_sys; + } + + if (vdso_getcpu) { + if (ret_vdso) { + printf("[FAIL]\tvDSO getcpu() failed\n"); + nerrs++; + } else { + if (!have_node) { + have_node = true; + node = node_vdso; + } + + if (cpu_vdso != cpu) { + printf("[FAIL]\tvDSO reported CPU %hu but should be %d\n", cpu_vdso, cpu); + nerrs++; + } else { + printf("[OK]\tvDSO reported correct CPU\n"); + } + + if (node_vdso != node) { + printf("[FAIL]\tvDSO reported node %hu but should be %hu\n", node_vdso, node); + nerrs++; + } else { + printf("[OK]\tvDSO reported correct node\n"); + } + } + } + + if (vgetcpu) { + if (ret_vsys) { + printf("[FAIL]\tvsyscall getcpu() failed\n"); + nerrs++; + } else { + if (!have_node) { + have_node = true; + node = node_vsys; + } + + if (cpu_vsys != cpu) { + printf("[FAIL]\tvsyscall reported CPU %hu but should be %d\n", cpu_vsys, cpu); + nerrs++; + } else { + printf("[OK]\tvsyscall reported correct CPU\n"); + } + + if (node_vsys != node) { + printf("[FAIL]\tvsyscall reported node %hu but should be %hu\n", node_vsys, node); + nerrs++; + } else { + printf("[OK]\tvsyscall reported correct node\n"); + } + } + } + + return nerrs; +} + +static int test_vsys_r(void) +{ +#ifdef __x86_64__ + printf("[RUN]\tChecking read access to the vsyscall page\n"); + bool can_read; + if (sigsetjmp(jmpbuf, 1) == 0) { + *(volatile int *)0xffffffffff600000; + can_read = true; + } else { + can_read = false; + } + + if (can_read && !should_read_vsyscall) { + printf("[FAIL]\tWe have read access, but we shouldn't\n"); + return 1; + } else if (!can_read && should_read_vsyscall) { + printf("[FAIL]\tWe don't have read access, but we should\n"); + return 1; + } else { + printf("[OK]\tgot expected result\n"); + } +#endif + + return 0; +} + + +#ifdef __x86_64__ +#define X86_EFLAGS_TF (1UL << 8) +static volatile sig_atomic_t num_vsyscall_traps; + +static unsigned long get_eflags(void) +{ + unsigned long eflags; + asm volatile ("pushfq\n\tpopq %0" : "=rm" (eflags)); + return eflags; +} + +static void set_eflags(unsigned long eflags) +{ + asm volatile ("pushq %0\n\tpopfq" : : "rm" (eflags) : "flags"); +} + +static void sigtrap(int sig, siginfo_t *info, void *ctx_void) +{ + ucontext_t *ctx = (ucontext_t *)ctx_void; + unsigned long ip = ctx->uc_mcontext.gregs[REG_RIP]; + + if (((ip ^ 0xffffffffff600000UL) & ~0xfffUL) == 0) + num_vsyscall_traps++; +} + +static int test_native_vsyscall(void) +{ + time_t tmp; + bool is_native; + + if (!vtime) + return 0; + + printf("[RUN]\tchecking for native vsyscall\n"); + sethandler(SIGTRAP, sigtrap, 0); + set_eflags(get_eflags() | X86_EFLAGS_TF); + vtime(&tmp); + set_eflags(get_eflags() & ~X86_EFLAGS_TF); + + /* + * If vsyscalls are emulated, we expect a single trap in the + * vsyscall page -- the call instruction will trap with RIP + * pointing to the entry point before emulation takes over. + * In native mode, we expect two traps, since whatever code + * the vsyscall page contains will be more than just a ret + * instruction. + */ + is_native = (num_vsyscall_traps > 1); + + printf("\tvsyscalls are %s (%d instructions in vsyscall page)\n", + (is_native ? "native" : "emulated"), + (int)num_vsyscall_traps); + + return 0; +} +#endif + +int main(int argc, char **argv) +{ + int nerrs = 0; + + init_vdso(); + nerrs += init_vsys(); + + nerrs += test_gtod(); + nerrs += test_time(); + nerrs += test_getcpu(0); + nerrs += test_getcpu(1); + + sethandler(SIGSEGV, sigsegv, 0); + nerrs += test_vsys_r(); + +#ifdef __x86_64__ + nerrs += test_native_vsyscall(); +#endif + + return nerrs ? 1 : 0; +} -- 2.13.6

7 years, 5 months

4
7
0 0

[Linux-stable-mirror] Build error in v3.18.y-queue

by Guenter Roeck

Build reference: v3.18.91-23-g72813f7 gcc version: arm-poky-linux-gnueabi-gcc (GCC) 4.9.1 Building arm:allmodconfig ... failed -------------- Error log: /opt/buildbot/slave/stable-queue-3.18/build/drivers/mtd/nand/pxa3xx_nand.c: In function 'prepare_start_command': /opt/buildbot/slave/stable-queue-3.18/build/drivers/mtd/nand/pxa3xx_nand.c:749:2: error: duplicate case value case NAND_CMD_READOOB: ^ /opt/buildbot/slave/stable-queue-3.18/build/drivers/mtd/nand/pxa3xx_nand.c:746:2: error: previously used here case NAND_CMD_READOOB: ^ make[4]: *** [drivers/mtd/nand/pxa3xx_nand.o] Error 1 Guenter

7 years, 5 months

2
1
0 0

Re: [Linux-stable-mirror] stable-rc build: 0 warnings 5 failures (stable-rc/v3.18.91-23-g72813f7)

by Arnd Bergmann

On Fri, Jan 12, 2018 at 11:49 AM, Olof's autobuilder <build(a)lixom.net> wrote: > Here are the build results from automated periodic testing. > > The tree being built was stable-rc, found at: > > URL: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Errors: > > arm.allmodconfig: > /work/build/batch/drivers/mtd/nand/pxa3xx_nand.c:749:2: error: duplicate case value > > arm.cm_x300_defconfig: > /work/build/batch/drivers/mtd/nand/pxa3xx_nand.c:749:2: error: duplicate case value > > arm.mvebu_v7_defconfig: > /work/build/batch/drivers/mtd/nand/pxa3xx_nand.c:749:2: error: duplicate case value > > arm.pxa3xx_defconfig: > /work/build/batch/drivers/mtd/nand/pxa3xx_nand.c:749:2: error: duplicate case value > > arm.raumfeld_defconfig: > /work/build/batch/drivers/mtd/nand/pxa3xx_nand.c:749:2: error: duplicate case value Same problem as with 4.4.y before: fee4380f368e ("mtd: nand: pxa3xx: Fix READOOB implementation") was backported as commit fea22562533e but needs to be done differently here. Arnd

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] [PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for v4.9 and v4.14 -stable, respecetively. Thank you!

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] Patch "sh_eth: fix TSU resource handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix TSU resource handling to the 4.9-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: sh_eth-fix-tsu-resource-handling.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Wed, 3 Jan 2018 20:09:49 +0300 Subject: sh_eth: fix TSU resource handling From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ] When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3087,10 +3087,29 @@ static int sh_eth_drv_probe(struct platf /* ioremap the TSU registers */ if (mdp->cd->tsu) { struct resource *rtsu; + rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1); - mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu); - if (IS_ERR(mdp->tsu_addr)) { - ret = PTR_ERR(mdp->tsu_addr); + if (!rtsu) { + dev_err(&pdev->dev, "no TSU resource\n"); + ret = -ENODEV; + goto out_release; + } + /* We can only request the TSU region for the first port + * of the two sharing this TSU for the probe to succeed... + */ + if (devno % 2 == 0 && + !devm_request_mem_region(&pdev->dev, rtsu->start, + resource_size(rtsu), + dev_name(&pdev->dev))) { + dev_err(&pdev->dev, "can't request TSU resource.\n"); + ret = -EBUSY; + goto out_release; + } + mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start, + resource_size(rtsu)); + if (!mdp->tsu_addr) { + dev_err(&pdev->dev, "TSU region ioremap() failed.\n"); + ret = -ENOMEM; goto out_release; } mdp->port = devno % 2; Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.9/sh_eth-fix-sh7757-gether-initialization.patch queue-4.9/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: null pointer dereference in rds_atomic_free_op" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: null pointer dereference in rds_atomic_free_op to the 4.9-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: rds-null-pointer-dereference-in-rds_atomic_free_op.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Wed, 3 Jan 2018 21:06:06 +0000 Subject: RDS: null pointer dereference in rds_atomic_free_op From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ] set rm->atomic.op_active to 0 when rds_pin_pages() fails or the user supplied address is invalid, this prevents a NULL pointer usage in rds_atomic_free_op() Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -876,6 +876,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, err: if (page) put_page(page); + rm->atomic.op_active = 0; kfree(rm->atomic.op_notifier); return ret; Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.9/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.9/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix SH7757 GEther initialization" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix SH7757 GEther initialization to the 4.9-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: sh_eth-fix-sh7757-gether-initialization.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Thu, 4 Jan 2018 21:06:49 +0300 Subject: sh_eth: fix SH7757 GEther initialization From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ] Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the 'sh_eth' driver can only reset and initialize TSU of the first controller pair. Shimoda-san tried to solve that adding the 'needs_init' member to the 'struct sh_eth_plat_data', however the platform code still never sets this flag. I think that we can infer this information from the 'devno' variable (set to 'platform_device::id') and reset/init the Ether controller pair only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be removed... Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization") Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 4 ++-- include/linux/sh_eth.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3116,8 +3116,8 @@ static int sh_eth_drv_probe(struct platf ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER; } - /* initialize first or needed device */ - if (!devno || pd->needs_init) { + /* Need to init only the first port of the two sharing a TSU */ + if (devno % 2 == 0) { if (mdp->cd->chip_reset) mdp->cd->chip_reset(ndev); --- a/include/linux/sh_eth.h +++ b/include/linux/sh_eth.h @@ -16,7 +16,6 @@ struct sh_eth_plat_data { unsigned char mac_addr[ETH_ALEN]; unsigned no_ether_link:1; unsigned ether_link_active_low:1; - unsigned needs_init:1; }; #endif Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.9/sh_eth-fix-sh7757-gether-initialization.patch queue-4.9/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: stmmac: enable EEE in MII, GMII or RGMII only" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: stmmac: enable EEE in MII, GMII or RGMII only to the 4.9-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: net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Wed, 3 Jan 2018 16:46:29 +0100 Subject: net: stmmac: enable EEE in MII, GMII or RGMII only From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 879626e3a52630316d817cbda7cec9a5446d1d82 ] Note in the databook - Section 4.4 - EEE : " The EEE feature is not supported when the MAC is configured to use the TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC supports multiple PHY interfaces, you should activate the EEE mode only when the MAC is operating with GMII, MII, or RGMII interface." Applying this restriction solves a stability issue observed on Amlogic gxl platforms operating with RMII interface and the internal PHY. Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Tested-by: Arnaud Patard <arnaud.patard(a)rtp-net.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++ include/linux/phy.h | 11 +++++++++++ 2 files changed, 17 insertions(+) --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -280,8 +280,14 @@ static void stmmac_eee_ctrl_timer(unsign bool stmmac_eee_init(struct stmmac_priv *priv) { unsigned long flags; + int interface = priv->plat->interface; bool ret = false; + if ((interface != PHY_INTERFACE_MODE_MII) && + (interface != PHY_INTERFACE_MODE_GMII) && + !phy_interface_mode_is_rgmii(interface)) + goto out; + /* Using PCS we cannot dial with the phy registers at this stage * so we do not support extra feature like EEE. */ --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -684,6 +684,17 @@ static inline bool phy_is_internal(struc } /** + * phy_interface_mode_is_rgmii - Convenience function for testing if a + * PHY interface mode is RGMII (all variants) + * @mode: the phy_interface_t enum + */ +static inline bool phy_interface_mode_is_rgmii(phy_interface_t mode) +{ + return mode >= PHY_INTERFACE_MODE_RGMII && + mode <= PHY_INTERFACE_MODE_RGMII_TXID; +}; + +/** * phy_interface_is_rgmii - Convenience function for testing if a PHY interface * is RGMII (all variants) * @phydev: the phy_device struct Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.9/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: Heap OOB write in rds_message_alloc_sgs()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: Heap OOB write in rds_message_alloc_sgs() to the 4.9-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: rds-heap-oob-write-in-rds_message_alloc_sgs.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Tue, 2 Jan 2018 19:44:34 +0000 Subject: RDS: Heap OOB write in rds_message_alloc_sgs() From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ] When args->nr_local is 0, nr_pages gets also 0 due some size calculation via rds_rm_size(), which is later used to allocate pages for DMA, this bug produces a heap Out-Of-Bound write access to a specific memory region. Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -524,6 +524,9 @@ int rds_rdma_extra_size(struct rds_rdma_ local_vec = (struct rds_iovec __user *)(unsigned long) args->local_vec_addr; + if (args->nr_local == 0) + return -EINVAL; + /* figure out the number of pages in the vector */ for (i = 0; i < args->nr_local; i++) { if (copy_from_user(&vec, &local_vec[i], Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.9/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.9/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net/sched: Fix update of lastuse in act modules implementing stats_update" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/sched: Fix update of lastuse in act modules implementing stats_update to the 4.9-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: net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Roi Dayan <roid(a)mellanox.com> Date: Tue, 26 Dec 2017 07:48:51 +0200 Subject: net/sched: Fix update of lastuse in act modules implementing stats_update From: Roi Dayan <roid(a)mellanox.com> [ Upstream commit 3bb23421a504f01551b7cb9dff0e41dbf16656b0 ] We need to update lastuse to to the most updated value between what is already set and the new value. If HW matching fails, i.e. because of an issue, the stats are not updated but it could be that software did match and updated lastuse. Fixes: 5712bf9c5c30 ("net/sched: act_mirred: Use passed lastuse argument") Fixes: 9fea47d93bcc ("net/sched: act_gact: Update statistics when offloaded to hardware") Signed-off-by: Roi Dayan <roid(a)mellanox.com> Reviewed-by: Paul Blakey <paulb(a)mellanox.com> Acked-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sched/act_gact.c | 2 +- net/sched/act_mirred.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/sched/act_gact.c +++ b/net/sched/act_gact.c @@ -161,7 +161,7 @@ static void tcf_gact_stats_update(struct if (action == TC_ACT_SHOT) this_cpu_ptr(gact->common.cpu_qstats)->drops += packets; - tm->lastuse = lastuse; + tm->lastuse = max_t(u64, tm->lastuse, lastuse); } static int tcf_gact_dump(struct sk_buff *skb, struct tc_action *a, --- a/net/sched/act_mirred.c +++ b/net/sched/act_mirred.c @@ -211,7 +211,7 @@ static void tcf_stats_update(struct tc_a struct tcf_t *tm = &m->tcf_tm; _bstats_cpu_update(this_cpu_ptr(a->cpu_bstats), bytes, packets); - tm->lastuse = lastuse; + tm->lastuse = max_t(u64, tm->lastuse, lastuse); } static int tcf_mirred_dump(struct sk_buff *skb, struct tc_action *a, int bind, Patches currently in stable-queue which might be from roid(a)mellanox.com are queue-4.9/net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: core: fix module type in sock_diag_bind" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: core: fix module type in sock_diag_bind to the 4.9-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: net-core-fix-module-type-in-sock_diag_bind.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Andrii Vladyka <tulup(a)mail.ru> Date: Thu, 4 Jan 2018 13:09:17 +0200 Subject: net: core: fix module type in sock_diag_bind From: Andrii Vladyka <tulup(a)mail.ru> [ Upstream commit b8fd0823e0770c2d5fdbd865bccf0d5e058e5287 ] Use AF_INET6 instead of AF_INET in IPv6-related code path Signed-off-by: Andrii Vladyka <tulup(a)mail.ru> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/sock_diag.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/core/sock_diag.c +++ b/net/core/sock_diag.c @@ -295,7 +295,7 @@ static int sock_diag_bind(struct net *ne case SKNLGRP_INET6_UDP_DESTROY: if (!sock_diag_handlers[AF_INET6]) request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK, - NETLINK_SOCK_DIAG, AF_INET); + NETLINK_SOCK_DIAG, AF_INET6); break; } return 0; Patches currently in stable-queue which might be from tulup(a)mail.ru are queue-4.9/net-core-fix-module-type-in-sock_diag_bind.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mlxsw: spectrum_router: Fix NULL pointer deref" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlxsw: spectrum_router: Fix NULL pointer deref to the 4.9-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: mlxsw-spectrum_router-fix-null-pointer-deref.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Ido Schimmel <idosch(a)mellanox.com> Date: Mon, 25 Dec 2017 08:57:35 +0100 Subject: mlxsw: spectrum_router: Fix NULL pointer deref From: Ido Schimmel <idosch(a)mellanox.com> [ Upstream commit 8764a8267b128405cf383157d5e9a4a3735d2409 ] When we remove the neighbour associated with a nexthop we should always refuse to write the nexthop to the adjacency table. Regardless if it is already present in the table or not. Otherwise, we risk dereferencing the NULL pointer that was set instead of the neighbour. Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing") Signed-off-by: Ido Schimmel <idosch(a)mellanox.com> Reported-by: Alexander Petrovskiy <alexpe(a)mellanox.com> Signed-off-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c @@ -1328,9 +1328,9 @@ set_trap: static void __mlxsw_sp_nexthop_neigh_update(struct mlxsw_sp_nexthop *nh, bool removing) { - if (!removing && !nh->should_offload) + if (!removing) nh->should_offload = 1; - else if (removing && nh->offloaded) + else nh->should_offload = 0; nh->update = 1; } Patches currently in stable-queue which might be from idosch(a)mellanox.com are queue-4.9/mlxsw-spectrum_router-fix-null-pointer-deref.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ipv6: fix possible mem leaks in ipv6_make_skb()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: fix possible mem leaks in ipv6_make_skb() to the 4.9-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: ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 10 Jan 2018 03:45:49 -0800 Subject: ipv6: fix possible mem leaks in ipv6_make_skb() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ] ip6_setup_cork() might return an error, while memory allocations have been done and must be rolled back. Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Vlad Yasevich <vyasevich(a)gmail.com> Reported-by: Mike Maloney <maloney(a)google.com> Acked-by: Mike Maloney <maloney(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_output.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1800,9 +1800,10 @@ struct sk_buff *ip6_make_skb(struct sock cork.base.opt = NULL; v6_cork.opt = NULL; err = ip6_setup_cork(sk, &cork, &v6_cork, ipc6, rt, fl6); - if (err) + if (err) { + ip6_cork_release(&cork, &v6_cork); return ERR_PTR(err); - + } if (ipc6->dontfrag < 0) ipc6->dontfrag = inet6_sk(sk)->dontfrag; Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ip6_tunnel: disable dst caching if tunnel is dual-stack" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_tunnel: disable dst caching if tunnel is dual-stack to the 4.9-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: ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Eli Cooper <elicooper(a)gmx.com> Date: Mon, 25 Dec 2017 10:43:49 +0800 Subject: ip6_tunnel: disable dst caching if tunnel is dual-stack From: Eli Cooper <elicooper(a)gmx.com> [ Upstream commit 23263ec86a5f44312d2899323872468752324107 ] When an ip6_tunnel is in mode 'any', where the transport layer protocol can be either 4 or 41, dst_cache must be disabled. This is because xfrm policies might apply to only one of the two protocols. Caching dst would cause xfrm policies for one protocol incorrectly used for the other. Signed-off-by: Eli Cooper <elicooper(a)gmx.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_tunnel.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1080,10 +1080,11 @@ int ip6_tnl_xmit(struct sk_buff *skb, st memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr)); neigh_release(neigh); } - } else if (!(t->parms.flags & - (IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) { - /* enable the cache only only if the routing decision does - * not depend on the current inner header value + } else if (t->parms.proto != 0 && !(t->parms.flags & + (IP6_TNL_F_USE_ORIG_TCLASS | + IP6_TNL_F_USE_ORIG_FWMARK))) { + /* enable the cache only if neither the outer protocol nor the + * routing decision depends on the current inner header value */ use_cache = true; } Patches currently in stable-queue which might be from elicooper(a)gmx.com are queue-4.9/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ethtool: do not print warning for applications using legacy API" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ethtool: do not print warning for applications using legacy API to the 4.9-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: ethtool-do-not-print-warning-for-applications-using-legacy-api.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Fri, 29 Dec 2017 10:02:52 -0800 Subject: ethtool: do not print warning for applications using legacy API From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 71891e2dab6b55a870f8f7735e44a2963860b5c6 ] In kernel log ths message appears on every boot: "warning: `NetworkChangeNo' uses legacy ethtool link settings API, link modes are only partially reported" When ethtool link settings API changed, it started complaining about usages of old API. Ironically, the original patch was from google but the application using the legacy API is chrome. Linux ABI is fixed as much as possible. The kernel must not break it and should not complain about applications using legacy API's. This patch just removes the warning since using legacy API's in Linux is perfectly acceptable. Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API") Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.org> Signed-off-by: David Decotigny <decot(a)googlers.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/ethtool.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) --- a/net/core/ethtool.c +++ b/net/core/ethtool.c @@ -742,15 +742,6 @@ static int ethtool_set_link_ksettings(st return dev->ethtool_ops->set_link_ksettings(dev, &link_ksettings); } -static void -warn_incomplete_ethtool_legacy_settings_conversion(const char *details) -{ - char name[sizeof(current->comm)]; - - pr_info_once("warning: `%s' uses legacy ethtool link settings API, %s\n", - get_task_comm(name, current), details); -} - /* Query device for its ethtool_cmd settings. * * Backward compatibility note: for compatibility with legacy ethtool, @@ -777,10 +768,8 @@ static int ethtool_get_settings(struct n &link_ksettings); if (err < 0) return err; - if (!convert_link_ksettings_to_legacy_settings(&cmd, - &link_ksettings)) - warn_incomplete_ethtool_legacy_settings_conversion( - "link modes are only partially reported"); + convert_link_ksettings_to_legacy_settings(&cmd, + &link_ksettings); /* send a sensible cmd tag back to user */ cmd.cmd = ETHTOOL_GSET; Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.9/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "8021q: fix a memory leak for VLAN 0 device" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 8021q: fix a memory leak for VLAN 0 device to the 4.9-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: 8021q-fix-a-memory-leak-for-vlan-0-device.patch and it can be found in the queue-4.9 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 foo@baz Sat Jan 13 10:51:19 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Tue, 9 Jan 2018 13:40:41 -0800 Subject: 8021q: fix a memory leak for VLAN 0 device From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ] A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi vlan_gvrp_uninit_applicant(real_dev); } - /* Take it out of our own structures, but be sure to interlock with - * HW accelerating devices or SW vlan input packet processing if - * VLAN is not 0 (leave it there for 802.1p). - */ - if (vlan_id) - vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); + vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev); Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.9/8021q-fix-a-memory-leak-for-vlan-0-device.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix TSU resource handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix TSU resource handling to the 4.14-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: sh_eth-fix-tsu-resource-handling.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Wed, 3 Jan 2018 20:09:49 +0300 Subject: sh_eth: fix TSU resource handling From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ] When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3212,10 +3212,29 @@ static int sh_eth_drv_probe(struct platf /* ioremap the TSU registers */ if (mdp->cd->tsu) { struct resource *rtsu; + rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1); - mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu); - if (IS_ERR(mdp->tsu_addr)) { - ret = PTR_ERR(mdp->tsu_addr); + if (!rtsu) { + dev_err(&pdev->dev, "no TSU resource\n"); + ret = -ENODEV; + goto out_release; + } + /* We can only request the TSU region for the first port + * of the two sharing this TSU for the probe to succeed... + */ + if (devno % 2 == 0 && + !devm_request_mem_region(&pdev->dev, rtsu->start, + resource_size(rtsu), + dev_name(&pdev->dev))) { + dev_err(&pdev->dev, "can't request TSU resource.\n"); + ret = -EBUSY; + goto out_release; + } + mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start, + resource_size(rtsu)); + if (!mdp->tsu_addr) { + dev_err(&pdev->dev, "TSU region ioremap() failed.\n"); + ret = -ENOMEM; goto out_release; } mdp->port = devno % 2; Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch queue-4.14/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix SH7757 GEther initialization" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix SH7757 GEther initialization to the 4.14-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: sh_eth-fix-sh7757-gether-initialization.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Thu, 4 Jan 2018 21:06:49 +0300 Subject: sh_eth: fix SH7757 GEther initialization From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ] Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the 'sh_eth' driver can only reset and initialize TSU of the first controller pair. Shimoda-san tried to solve that adding the 'needs_init' member to the 'struct sh_eth_plat_data', however the platform code still never sets this flag. I think that we can infer this information from the 'devno' variable (set to 'platform_device::id') and reset/init the Ether controller pair only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be removed... Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization") Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 4 ++-- include/linux/sh_eth.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3241,8 +3241,8 @@ static int sh_eth_drv_probe(struct platf ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER; } - /* initialize first or needed device */ - if (!devno || pd->needs_init) { + /* Need to init only the first port of the two sharing a TSU */ + if (devno % 2 == 0) { if (mdp->cd->chip_reset) mdp->cd->chip_reset(ndev); --- a/include/linux/sh_eth.h +++ b/include/linux/sh_eth.h @@ -17,7 +17,6 @@ struct sh_eth_plat_data { unsigned char mac_addr[ETH_ALEN]; unsigned no_ether_link:1; unsigned ether_link_active_low:1; - unsigned needs_init:1; }; #endif Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch queue-4.14/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sfp: fix sfp-bus oops when removing socket/upstream" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfp: fix sfp-bus oops when removing socket/upstream to the 4.14-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: sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Tue, 26 Dec 2017 23:15:17 +0000 Subject: sfp: fix sfp-bus oops when removing socket/upstream From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit 0b2122e4934c7783d336397864e34ee53aad0965 ] When we remove a socket or upstream, and the other side isn't registered, we dereference a NULL pointer, causing a kernel oops. Fix this. Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/sfp-bus.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/phy/sfp-bus.c +++ b/drivers/net/phy/sfp-bus.c @@ -359,7 +359,8 @@ EXPORT_SYMBOL_GPL(sfp_register_upstream) void sfp_unregister_upstream(struct sfp_bus *bus) { rtnl_lock(); - sfp_unregister_bus(bus); + if (bus->sfp) + sfp_unregister_bus(bus); bus->upstream = NULL; bus->netdev = NULL; rtnl_unlock(); @@ -464,7 +465,8 @@ EXPORT_SYMBOL_GPL(sfp_register_socket); void sfp_unregister_socket(struct sfp_bus *bus) { rtnl_lock(); - sfp_unregister_bus(bus); + if (bus->netdev) + sfp_unregister_bus(bus); bus->sfp_dev = NULL; bus->sfp = NULL; bus->socket_ops = NULL; Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch queue-4.14/phylink-ensure-we-report-link-down-when-los-asserted.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: fix the handling of ICMP Frag Needed for too small MTUs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: fix the handling of ICMP Frag Needed for too small MTUs to the 4.14-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: sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Date: Fri, 5 Jan 2018 11:17:18 -0200 Subject: sctp: fix the handling of ICMP Frag Needed for too small MTUs From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> [ Upstream commit b6c5734db07079c9410147b32407f2366d584e6c ] syzbot reported a hang involving SCTP, on which it kept flooding dmesg with the message: [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default minimum of 512 That happened because whenever SCTP hits an ICMP Frag Needed, it tries to adjust to the new MTU and triggers an immediate retransmission. But it didn't consider the fact that MTUs smaller than the SCTP minimum MTU allowed (512) would not cause the PMTU to change, and issued the retransmission anyway (thus leading to another ICMP Frag Needed, and so on). As IPv4 (ip_rt_min_pmtu=556) and IPv6 (IPV6_MIN_MTU=1280) minimum MTU are higher than that, sctp_transport_update_pmtu() is changed to re-fetch the PMTU that got set after our request, and with that, detect if there was an actual change or not. The fix, thus, skips the immediate retransmission if the received ICMP resulted in no change, in the hope that SCTP will select another path. Note: The value being used for the minimum MTU (512, SCTP_DEFAULT_MINSEGMENT) is not right and instead it should be (576, SCTP_MIN_PMTU), but such change belongs to another patch. Changes from v1: - do not disable PMTU discovery, in the light of commit 06ad391919b2 ("[SCTP] Don't disable PMTU discovery when mtu is small") and as suggested by Xin Long. - changed the way to break the rtx loop by detecting if the icmp resulted in a change or not Changes from v2: none See-also: https://lkml.org/lkml/2017/12/22/811 Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/net/sctp/structs.h | 2 +- net/sctp/input.c | 8 ++++++-- net/sctp/transport.c | 29 +++++++++++++++++++---------- 3 files changed, 26 insertions(+), 13 deletions(-) --- a/include/net/sctp/structs.h +++ b/include/net/sctp/structs.h @@ -955,7 +955,7 @@ void sctp_transport_burst_limited(struct void sctp_transport_burst_reset(struct sctp_transport *); unsigned long sctp_transport_timeout(struct sctp_transport *); void sctp_transport_reset(struct sctp_transport *t); -void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu); +bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu); void sctp_transport_immediate_rtx(struct sctp_transport *); void sctp_transport_dst_release(struct sctp_transport *t); void sctp_transport_dst_confirm(struct sctp_transport *t); --- a/net/sctp/input.c +++ b/net/sctp/input.c @@ -406,8 +406,12 @@ void sctp_icmp_frag_needed(struct sock * */ return; - /* Update transports view of the MTU */ - sctp_transport_update_pmtu(t, pmtu); + /* Update transports view of the MTU. Return if no update was needed. + * If an update wasn't needed/possible, it also doesn't make sense to + * try to retransmit now. + */ + if (!sctp_transport_update_pmtu(t, pmtu)) + return; /* Update association pmtu. */ sctp_assoc_sync_pmtu(asoc); --- a/net/sctp/transport.c +++ b/net/sctp/transport.c @@ -251,28 +251,37 @@ void sctp_transport_pmtu(struct sctp_tra transport->pathmtu = SCTP_DEFAULT_MAXSEGMENT; } -void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu) +bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu) { struct dst_entry *dst = sctp_transport_dst_check(t); + bool change = true; if (unlikely(pmtu < SCTP_DEFAULT_MINSEGMENT)) { - pr_warn("%s: Reported pmtu %d too low, using default minimum of %d\n", - __func__, pmtu, SCTP_DEFAULT_MINSEGMENT); - /* Use default minimum segment size and disable - * pmtu discovery on this transport. - */ - t->pathmtu = SCTP_DEFAULT_MINSEGMENT; - } else { - t->pathmtu = pmtu; + pr_warn_ratelimited("%s: Reported pmtu %d too low, using default minimum of %d\n", + __func__, pmtu, SCTP_DEFAULT_MINSEGMENT); + /* Use default minimum segment instead */ + pmtu = SCTP_DEFAULT_MINSEGMENT; } + pmtu = SCTP_TRUNC4(pmtu); if (dst) { dst->ops->update_pmtu(dst, t->asoc->base.sk, NULL, pmtu); dst = sctp_transport_dst_check(t); } - if (!dst) + if (!dst) { t->af_specific->get_dst(t, &t->saddr, &t->fl, t->asoc->base.sk); + dst = t->dst; + } + + if (dst) { + /* Re-fetch, as under layers may have a higher minimum size */ + pmtu = SCTP_TRUNC4(dst_mtu(dst)); + change = t->pathmtu != pmtu; + } + t->pathmtu = pmtu; + + return change; } /* Caches the dst entry and source address for a transport's destination Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled to the 4.14-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: sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Date: Fri, 5 Jan 2018 11:17:17 -0200 Subject: sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> [ Upstream commit cc35c3d1edf7a8373a1a5daa80a912dec96a9cd5 ] Currently, if PMTU discovery is disabled on a given transport, but the configured value is higher than the actual PMTU, it is likely that we will get some icmp Frag Needed. The issue is, if PMTU discovery is disabled, we won't update the information and will issue a retransmission immediately, which may very well trigger another ICMP, and another retransmission, leading to a loop. The fix is to simply not trigger immediate retransmissions if PMTU discovery is disabled on the given transport. Changes from v2: - updated stale comment, noticed by Xin Long Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/input.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) --- a/net/sctp/input.c +++ b/net/sctp/input.c @@ -399,20 +399,20 @@ void sctp_icmp_frag_needed(struct sock * return; } - if (t->param_flags & SPP_PMTUD_ENABLE) { - /* Update transports view of the MTU */ - sctp_transport_update_pmtu(t, pmtu); + if (!(t->param_flags & SPP_PMTUD_ENABLE)) + /* We can't allow retransmitting in such case, as the + * retransmission would be sized just as before, and thus we + * would get another icmp, and retransmit again. + */ + return; - /* Update association pmtu. */ - sctp_assoc_sync_pmtu(asoc); - } + /* Update transports view of the MTU */ + sctp_transport_update_pmtu(t, pmtu); + + /* Update association pmtu. */ + sctp_assoc_sync_pmtu(asoc); - /* Retransmit with the new pmtu setting. - * Normally, if PMTU discovery is disabled, an ICMP Fragmentation - * Needed will never be sent, but if a message was sent before - * PMTU discovery was disabled that was larger than the PMTU, it - * would not be fragmented, so it must be re-transmitted fragmented. - */ + /* Retransmit with the new pmtu setting. */ sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD); } Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."" to the 4.14-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: revert-revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: "David S. Miller" <davem(a)davemloft.net> Date: Fri, 12 Jan 2018 16:09:58 -0500 Subject: Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."" From: "David S. Miller" <davem(a)davemloft.net> This reverts commit 94802151894d482e82c324edf2c658f8e6b96508. It breaks transport mode when the policy template has wildcard addresses configured. Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_policy.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -1362,36 +1362,29 @@ xfrm_tmpl_resolve_one(struct xfrm_policy struct net *net = xp_net(policy); int nx; int i, error; - xfrm_address_t *daddr = xfrm_flowi_daddr(fl, family); - xfrm_address_t *saddr = xfrm_flowi_saddr(fl, family); xfrm_address_t tmp; for (nx = 0, i = 0; i < policy->xfrm_nr; i++) { struct xfrm_state *x; - xfrm_address_t *remote = daddr; - xfrm_address_t *local = saddr; + xfrm_address_t *local; + xfrm_address_t *remote; struct xfrm_tmpl *tmpl = &policy->xfrm_vec[i]; - if (tmpl->mode == XFRM_MODE_TUNNEL || - tmpl->mode == XFRM_MODE_BEET) { - remote = &tmpl->id.daddr; - local = &tmpl->saddr; - if (xfrm_addr_any(local, tmpl->encap_family)) { - error = xfrm_get_saddr(net, fl->flowi_oif, - &tmp, remote, - tmpl->encap_family, 0); - if (error) - goto fail; - local = &tmp; - } + remote = &tmpl->id.daddr; + local = &tmpl->saddr; + if (xfrm_addr_any(local, tmpl->encap_family)) { + error = xfrm_get_saddr(net, fl->flowi_oif, + &tmp, remote, + tmpl->encap_family, 0); + if (error) + goto fail; + local = &tmp; } x = xfrm_state_find(remote, local, fl, tmpl, policy, &error, family); if (x && x->km.state == XFRM_STATE_VALID) { xfrm[nx++] = x; - daddr = remote; - saddr = local; continue; } if (x) { Patches currently in stable-queue which might be from davem(a)davemloft.net are queue-4.14/net-fec-defer-probe-if-regulator-is-not-ready.patch queue-4.14/sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch queue-4.14/8021q-fix-a-memory-leak-for-vlan-0-device.patch queue-4.14/net-fec-free-restore-resource-in-related-probe-error-pathes.patch queue-4.14/revert-revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch queue-4.14/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch queue-4.14/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.14/phylink-ensure-we-report-link-down-when-los-asserted.patch queue-4.14/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch queue-4.14/rds-heap-oob-write-in-rds_message_alloc_sgs.patch queue-4.14/mlxsw-spectrum_router-fix-null-pointer-deref.patch queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch queue-4.14/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch queue-4.14/net-core-fix-module-type-in-sock_diag_bind.patch queue-4.14/mlxsw-spectrum-relax-sanity-checks-during-enslavement.patch queue-4.14/net-fec-restore-dev_id-in-the-cases-of-probe-error.patch queue-4.14/sh_eth-fix-tsu-resource-handling.patch queue-4.14/ipv6-sr-fix-tlvs-not-being-copied-using-setsockopt.patch queue-4.14/net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch queue-4.14/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: null pointer dereference in rds_atomic_free_op" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: null pointer dereference in rds_atomic_free_op to the 4.14-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: rds-null-pointer-dereference-in-rds_atomic_free_op.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Wed, 3 Jan 2018 21:06:06 +0000 Subject: RDS: null pointer dereference in rds_atomic_free_op From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ] set rm->atomic.op_active to 0 when rds_pin_pages() fails or the user supplied address is invalid, this prevents a NULL pointer usage in rds_atomic_free_op() Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -877,6 +877,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, err: if (page) put_page(page); + rm->atomic.op_active = 0; kfree(rm->atomic.op_notifier); return ret; Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.14/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.14/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: Heap OOB write in rds_message_alloc_sgs()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: Heap OOB write in rds_message_alloc_sgs() to the 4.14-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: rds-heap-oob-write-in-rds_message_alloc_sgs.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Tue, 2 Jan 2018 19:44:34 +0000 Subject: RDS: Heap OOB write in rds_message_alloc_sgs() From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ] When args->nr_local is 0, nr_pages gets also 0 due some size calculation via rds_rm_size(), which is later used to allocate pages for DMA, this bug produces a heap Out-Of-Bound write access to a specific memory region. Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -525,6 +525,9 @@ int rds_rdma_extra_size(struct rds_rdma_ local_vec = (struct rds_iovec __user *)(unsigned long) args->local_vec_addr; + if (args->nr_local == 0) + return -EINVAL; + /* figure out the number of pages in the vector */ for (i = 0; i < args->nr_local; i++) { if (copy_from_user(&vec, &local_vec[i], Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.14/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.14/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "phylink: ensure we report link down when LOS asserted" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phylink: ensure we report link down when LOS asserted to the 4.14-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: phylink-ensure-we-report-link-down-when-los-asserted.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Tue, 26 Dec 2017 23:15:12 +0000 Subject: phylink: ensure we report link down when LOS asserted From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit ac817f5ad066697e4d4d35ec68c974eba2c5f17a ] Although we disable the netdev carrier, we fail to report in the kernel log that the link went down. Fix this. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/phylink.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -1428,9 +1428,8 @@ static void phylink_sfp_link_down(void * WARN_ON(!lockdep_rtnl_is_held()); set_bit(PHYLINK_DISABLE_LINK, &pl->phylink_disable_state); + queue_work(system_power_efficient_wq, &pl->resolve); flush_work(&pl->resolve); - - netif_carrier_off(pl->netdev); } static void phylink_sfp_link_up(void *upstream) Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch queue-4.14/phylink-ensure-we-report-link-down-when-los-asserted.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: stmmac: enable EEE in MII, GMII or RGMII only" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: stmmac: enable EEE in MII, GMII or RGMII only to the 4.14-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: net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Wed, 3 Jan 2018 16:46:29 +0100 Subject: net: stmmac: enable EEE in MII, GMII or RGMII only From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 879626e3a52630316d817cbda7cec9a5446d1d82 ] Note in the databook - Section 4.4 - EEE : " The EEE feature is not supported when the MAC is configured to use the TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC supports multiple PHY interfaces, you should activate the EEE mode only when the MAC is operating with GMII, MII, or RGMII interface." Applying this restriction solves a stability issue observed on Amlogic gxl platforms operating with RMII interface and the internal PHY. Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Tested-by: Arnaud Patard <arnaud.patard(a)rtp-net.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -364,9 +364,15 @@ static void stmmac_eee_ctrl_timer(unsign bool stmmac_eee_init(struct stmmac_priv *priv) { struct net_device *ndev = priv->dev; + int interface = priv->plat->interface; unsigned long flags; bool ret = false; + if ((interface != PHY_INTERFACE_MODE_MII) && + (interface != PHY_INTERFACE_MODE_GMII) && + !phy_interface_mode_is_rgmii(interface)) + goto out; + /* Using PCS we cannot dial with the phy registers at this stage * so we do not support extra feature like EEE. */ Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.14/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net/sched: Fix update of lastuse in act modules implementing stats_update" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/sched: Fix update of lastuse in act modules implementing stats_update to the 4.14-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: net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Roi Dayan <roid(a)mellanox.com> Date: Tue, 26 Dec 2017 07:48:51 +0200 Subject: net/sched: Fix update of lastuse in act modules implementing stats_update From: Roi Dayan <roid(a)mellanox.com> [ Upstream commit 3bb23421a504f01551b7cb9dff0e41dbf16656b0 ] We need to update lastuse to to the most updated value between what is already set and the new value. If HW matching fails, i.e. because of an issue, the stats are not updated but it could be that software did match and updated lastuse. Fixes: 5712bf9c5c30 ("net/sched: act_mirred: Use passed lastuse argument") Fixes: 9fea47d93bcc ("net/sched: act_gact: Update statistics when offloaded to hardware") Signed-off-by: Roi Dayan <roid(a)mellanox.com> Reviewed-by: Paul Blakey <paulb(a)mellanox.com> Acked-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sched/act_gact.c | 2 +- net/sched/act_mirred.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/sched/act_gact.c +++ b/net/sched/act_gact.c @@ -159,7 +159,7 @@ static void tcf_gact_stats_update(struct if (action == TC_ACT_SHOT) this_cpu_ptr(gact->common.cpu_qstats)->drops += packets; - tm->lastuse = lastuse; + tm->lastuse = max_t(u64, tm->lastuse, lastuse); } static int tcf_gact_dump(struct sk_buff *skb, struct tc_action *a, --- a/net/sched/act_mirred.c +++ b/net/sched/act_mirred.c @@ -238,7 +238,7 @@ static void tcf_stats_update(struct tc_a struct tcf_t *tm = &m->tcf_tm; _bstats_cpu_update(this_cpu_ptr(a->cpu_bstats), bytes, packets); - tm->lastuse = lastuse; + tm->lastuse = max_t(u64, tm->lastuse, lastuse); } static int tcf_mirred_dump(struct sk_buff *skb, struct tc_action *a, int bind, Patches currently in stable-queue which might be from roid(a)mellanox.com are queue-4.14/net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: fec: restore dev_id in the cases of probe error" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: fec: restore dev_id in the cases of probe error to the 4.14-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: net-fec-restore-dev_id-in-the-cases-of-probe-error.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Fugang Duan <fugang.duan(a)nxp.com> Date: Wed, 3 Jan 2018 10:39:29 +0800 Subject: net: fec: restore dev_id in the cases of probe error From: Fugang Duan <fugang.duan(a)nxp.com> [ Upstream commit e90f686b4358d7d7e5dbaa48b8e78c9a4e41826e ] The static variable dev_id always plus one before netdev registerred. It should restore the dev_id value in the cases of probe error. Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/fec_main.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3543,6 +3543,7 @@ failed_phy: of_node_put(phy_node); failed_ioremap: free_netdev(ndev); + dev_id--; return ret; } Patches currently in stable-queue which might be from fugang.duan(a)nxp.com are queue-4.14/net-fec-defer-probe-if-regulator-is-not-ready.patch queue-4.14/net-fec-free-restore-resource-in-related-probe-error-pathes.patch queue-4.14/net-fec-restore-dev_id-in-the-cases-of-probe-error.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: fec: free/restore resource in related probe error pathes" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: fec: free/restore resource in related probe error pathes to the 4.14-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: net-fec-free-restore-resource-in-related-probe-error-pathes.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Fugang Duan <fugang.duan(a)nxp.com> Date: Thu, 4 Jan 2018 10:47:20 +0800 Subject: net: fec: free/restore resource in related probe error pathes From: Fugang Duan <fugang.duan(a)nxp.com> [ Upstream commit d1616f07e8f1a4a490d1791316d4a68906b284aa ] Fixes in probe error path: - Restore dev_id before failed_ioremap path. Fixes: ("net: fec: restore dev_id in the cases of probe error") - Call of_node_put(phy_node) before failed_phy path. Fixes: ("net: fec: Support phys probed from devicetree and fixed-link") Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/fec_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3543,11 +3543,11 @@ failed_clk_ipg: failed_clk: if (of_phy_is_fixed_link(np)) of_phy_deregister_fixed_link(np); -failed_phy: of_node_put(phy_node); +failed_phy: + dev_id--; failed_ioremap: free_netdev(ndev); - dev_id--; return ret; } Patches currently in stable-queue which might be from fugang.duan(a)nxp.com are queue-4.14/net-fec-defer-probe-if-regulator-is-not-ready.patch queue-4.14/net-fec-free-restore-resource-in-related-probe-error-pathes.patch queue-4.14/net-fec-restore-dev_id-in-the-cases-of-probe-error.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: fec: defer probe if regulator is not ready" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: fec: defer probe if regulator is not ready to the 4.14-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: net-fec-defer-probe-if-regulator-is-not-ready.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Fugang Duan <fugang.duan(a)nxp.com> Date: Wed, 3 Jan 2018 10:39:30 +0800 Subject: net: fec: defer probe if regulator is not ready From: Fugang Duan <fugang.duan(a)nxp.com> [ Upstream commit 3f38c683033a9a0a2738e7067f449deefabfa3ef ] Defer probe if regulator is not ready. E.g. some regulator is fixed regulator controlled by i2c expander gpio, the i2c device may be probed after the driver, then it should handle the case of defer probe error. Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/fec_main.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3458,6 +3458,10 @@ fec_probe(struct platform_device *pdev) goto failed_regulator; } } else { + if (PTR_ERR(fep->reg_phy) == -EPROBE_DEFER) { + ret = -EPROBE_DEFER; + goto failed_regulator; + } fep->reg_phy = NULL; } Patches currently in stable-queue which might be from fugang.duan(a)nxp.com are queue-4.14/net-fec-defer-probe-if-regulator-is-not-ready.patch queue-4.14/net-fec-free-restore-resource-in-related-probe-error-pathes.patch queue-4.14/net-fec-restore-dev_id-in-the-cases-of-probe-error.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: core: fix module type in sock_diag_bind" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: core: fix module type in sock_diag_bind to the 4.14-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: net-core-fix-module-type-in-sock_diag_bind.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Andrii Vladyka <tulup(a)mail.ru> Date: Thu, 4 Jan 2018 13:09:17 +0200 Subject: net: core: fix module type in sock_diag_bind From: Andrii Vladyka <tulup(a)mail.ru> [ Upstream commit b8fd0823e0770c2d5fdbd865bccf0d5e058e5287 ] Use AF_INET6 instead of AF_INET in IPv6-related code path Signed-off-by: Andrii Vladyka <tulup(a)mail.ru> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/sock_diag.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/core/sock_diag.c +++ b/net/core/sock_diag.c @@ -288,7 +288,7 @@ static int sock_diag_bind(struct net *ne case SKNLGRP_INET6_UDP_DESTROY: if (!sock_diag_handlers[AF_INET6]) request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK, - NETLINK_SOCK_DIAG, AF_INET); + NETLINK_SOCK_DIAG, AF_INET6); break; } return 0; Patches currently in stable-queue which might be from tulup(a)mail.ru are queue-4.14/net-core-fix-module-type-in-sock_diag_bind.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mlxsw: spectrum_router: Fix NULL pointer deref" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlxsw: spectrum_router: Fix NULL pointer deref to the 4.14-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: mlxsw-spectrum_router-fix-null-pointer-deref.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Ido Schimmel <idosch(a)mellanox.com> Date: Mon, 25 Dec 2017 08:57:35 +0100 Subject: mlxsw: spectrum_router: Fix NULL pointer deref From: Ido Schimmel <idosch(a)mellanox.com> [ Upstream commit 8764a8267b128405cf383157d5e9a4a3735d2409 ] When we remove the neighbour associated with a nexthop we should always refuse to write the nexthop to the adjacency table. Regardless if it is already present in the table or not. Otherwise, we risk dereferencing the NULL pointer that was set instead of the neighbour. Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing") Signed-off-by: Ido Schimmel <idosch(a)mellanox.com> Reported-by: Alexander Petrovskiy <alexpe(a)mellanox.com> Signed-off-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c @@ -2536,7 +2536,7 @@ static void __mlxsw_sp_nexthop_neigh_upd { if (!removing) nh->should_offload = 1; - else if (nh->offloaded) + else nh->should_offload = 0; nh->update = 1; } Patches currently in stable-queue which might be from idosch(a)mellanox.com are queue-4.14/mlxsw-spectrum_router-fix-null-pointer-deref.patch queue-4.14/mlxsw-spectrum-relax-sanity-checks-during-enslavement.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mlxsw: spectrum: Relax sanity checks during enslavement" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlxsw: spectrum: Relax sanity checks during enslavement to the 4.14-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: mlxsw-spectrum-relax-sanity-checks-during-enslavement.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Ido Schimmel <idosch(a)mellanox.com> Date: Mon, 25 Dec 2017 09:05:33 +0100 Subject: mlxsw: spectrum: Relax sanity checks during enslavement From: Ido Schimmel <idosch(a)mellanox.com> [ Upstream commit 90045fc9c78855bdc625a0ab185d97b72a937613 ] Since commit 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that have uppers") the driver forbids enslavement to netdevs that already have uppers of their own, as this can result in various ordering problems. This requirement proved to be too strict for some users who need to be able to enslave ports to a bridge that already has uppers. In this case, we can allow the enslavement if the bridge is already known to us, as any configuration performed on top of the bridge was already reflected to the device. Fixes: 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that have uppers") Signed-off-by: Ido Schimmel <idosch(a)mellanox.com> Reported-by: Alexander Petrovskiy <alexpe(a)mellanox.com> Tested-by: Alexander Petrovskiy <alexpe(a)mellanox.com> Signed-off-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 11 +++++++++-- drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 ++ drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 ++++++ 3 files changed, 17 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c @@ -4235,7 +4235,10 @@ static int mlxsw_sp_netdevice_port_upper return -EINVAL; if (!info->linking) break; - if (netdev_has_any_upper_dev(upper_dev)) + if (netdev_has_any_upper_dev(upper_dev) && + (!netif_is_bridge_master(upper_dev) || + !mlxsw_sp_bridge_device_is_offloaded(mlxsw_sp, + upper_dev))) return -EINVAL; if (netif_is_lag_master(upper_dev) && !mlxsw_sp_master_lag_check(mlxsw_sp, upper_dev, @@ -4347,6 +4350,7 @@ static int mlxsw_sp_netdevice_port_vlan_ u16 vid) { struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev); + struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp; struct netdev_notifier_changeupper_info *info = ptr; struct net_device *upper_dev; int err = 0; @@ -4358,7 +4362,10 @@ static int mlxsw_sp_netdevice_port_vlan_ return -EINVAL; if (!info->linking) break; - if (netdev_has_any_upper_dev(upper_dev)) + if (netdev_has_any_upper_dev(upper_dev) && + (!netif_is_bridge_master(upper_dev) || + !mlxsw_sp_bridge_device_is_offloaded(mlxsw_sp, + upper_dev))) return -EINVAL; break; case NETDEV_CHANGEUPPER: --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h @@ -326,6 +326,8 @@ int mlxsw_sp_port_bridge_join(struct mlx void mlxsw_sp_port_bridge_leave(struct mlxsw_sp_port *mlxsw_sp_port, struct net_device *brport_dev, struct net_device *br_dev); +bool mlxsw_sp_bridge_device_is_offloaded(const struct mlxsw_sp *mlxsw_sp, + const struct net_device *br_dev); /* spectrum.c */ int mlxsw_sp_port_ets_set(struct mlxsw_sp_port *mlxsw_sp_port, --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c @@ -134,6 +134,12 @@ mlxsw_sp_bridge_device_find(const struct return NULL; } +bool mlxsw_sp_bridge_device_is_offloaded(const struct mlxsw_sp *mlxsw_sp, + const struct net_device *br_dev) +{ + return !!mlxsw_sp_bridge_device_find(mlxsw_sp->bridge, br_dev); +} + static struct mlxsw_sp_bridge_device * mlxsw_sp_bridge_device_create(struct mlxsw_sp_bridge *bridge, struct net_device *br_dev) Patches currently in stable-queue which might be from idosch(a)mellanox.com are queue-4.14/mlxsw-spectrum_router-fix-null-pointer-deref.patch queue-4.14/mlxsw-spectrum-relax-sanity-checks-during-enslavement.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ipv6: sr: fix TLVs not being copied using setsockopt" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: sr: fix TLVs not being copied using setsockopt to the 4.14-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: ipv6-sr-fix-tlvs-not-being-copied-using-setsockopt.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Mathieu Xhonneux <m.xhonneux(a)gmail.com> Date: Wed, 10 Jan 2018 13:35:49 +0000 Subject: ipv6: sr: fix TLVs not being copied using setsockopt From: Mathieu Xhonneux <m.xhonneux(a)gmail.com> [ Upstream commit ccc12b11c5332c84442ef120dcd631523be75089 ] Function ipv6_push_rthdr4 allows to add an IPv6 Segment Routing Header to a socket through setsockopt, but the current implementation doesn't copy possible TLVs at the end of the SRH received from userspace. Therefore, the execution of the following branch if (sr_has_hmac(sr_phdr)) { ... } will never complete since the len and type fields of a possible HMAC TLV are not copied, hence seg6_get_tlv_hmac will return an error, and the HMAC will not be computed. This commit adds a memcpy in case TLVs have been appended to the SRH. Fixes: a149e7c7ce81 ("ipv6: sr: add support for SRH injection through setsockopt") Acked-by: David Lebrun <dlebrun(a)google.com> Signed-off-by: Mathieu Xhonneux <m.xhonneux(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/exthdrs.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/net/ipv6/exthdrs.c +++ b/net/ipv6/exthdrs.c @@ -884,6 +884,15 @@ static void ipv6_push_rthdr4(struct sk_b sr_phdr->segments[0] = **addr_p; *addr_p = &sr_ihdr->segments[sr_ihdr->segments_left]; + if (sr_ihdr->hdrlen > hops * 2) { + int tlvs_offset, tlvs_length; + + tlvs_offset = (1 + hops * 2) << 3; + tlvs_length = (sr_ihdr->hdrlen - hops * 2) << 3; + memcpy((char *)sr_phdr + tlvs_offset, + (char *)sr_ihdr + tlvs_offset, tlvs_length); + } + #ifdef CONFIG_IPV6_SEG6_HMAC if (sr_has_hmac(sr_phdr)) { struct net *net = NULL; Patches currently in stable-queue which might be from m.xhonneux(a)gmail.com are queue-4.14/ipv6-sr-fix-tlvs-not-being-copied-using-setsockopt.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ipv6: fix possible mem leaks in ipv6_make_skb()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: fix possible mem leaks in ipv6_make_skb() to the 4.14-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: ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 10 Jan 2018 03:45:49 -0800 Subject: ipv6: fix possible mem leaks in ipv6_make_skb() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ] ip6_setup_cork() might return an error, while memory allocations have been done and must be rolled back. Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Vlad Yasevich <vyasevich(a)gmail.com> Reported-by: Mike Maloney <maloney(a)google.com> Acked-by: Mike Maloney <maloney(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_output.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1735,9 +1735,10 @@ struct sk_buff *ip6_make_skb(struct sock cork.base.opt = NULL; v6_cork.opt = NULL; err = ip6_setup_cork(sk, &cork, &v6_cork, ipc6, rt, fl6); - if (err) + if (err) { + ip6_cork_release(&cork, &v6_cork); return ERR_PTR(err); - + } if (ipc6->dontfrag < 0) ipc6->dontfrag = inet6_sk(sk)->dontfrag; Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.14/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ip6_tunnel: disable dst caching if tunnel is dual-stack" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_tunnel: disable dst caching if tunnel is dual-stack to the 4.14-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: ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Eli Cooper <elicooper(a)gmx.com> Date: Mon, 25 Dec 2017 10:43:49 +0800 Subject: ip6_tunnel: disable dst caching if tunnel is dual-stack From: Eli Cooper <elicooper(a)gmx.com> [ Upstream commit 23263ec86a5f44312d2899323872468752324107 ] When an ip6_tunnel is in mode 'any', where the transport layer protocol can be either 4 or 41, dst_cache must be disabled. This is because xfrm policies might apply to only one of the two protocols. Caching dst would cause xfrm policies for one protocol incorrectly used for the other. Signed-off-by: Eli Cooper <elicooper(a)gmx.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_tunnel.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1081,10 +1081,11 @@ int ip6_tnl_xmit(struct sk_buff *skb, st memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr)); neigh_release(neigh); } - } else if (!(t->parms.flags & - (IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) { - /* enable the cache only only if the routing decision does - * not depend on the current inner header value + } else if (t->parms.proto != 0 && !(t->parms.flags & + (IP6_TNL_F_USE_ORIG_TCLASS | + IP6_TNL_F_USE_ORIG_FWMARK))) { + /* enable the cache only if neither the outer protocol nor the + * routing decision depends on the current inner header value */ use_cache = true; } Patches currently in stable-queue which might be from elicooper(a)gmx.com are queue-4.14/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ethtool: do not print warning for applications using legacy API" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ethtool: do not print warning for applications using legacy API to the 4.14-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: ethtool-do-not-print-warning-for-applications-using-legacy-api.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Fri, 29 Dec 2017 10:02:52 -0800 Subject: ethtool: do not print warning for applications using legacy API From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 71891e2dab6b55a870f8f7735e44a2963860b5c6 ] In kernel log ths message appears on every boot: "warning: `NetworkChangeNo' uses legacy ethtool link settings API, link modes are only partially reported" When ethtool link settings API changed, it started complaining about usages of old API. Ironically, the original patch was from google but the application using the legacy API is chrome. Linux ABI is fixed as much as possible. The kernel must not break it and should not complain about applications using legacy API's. This patch just removes the warning since using legacy API's in Linux is perfectly acceptable. Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API") Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.org> Signed-off-by: David Decotigny <decot(a)googlers.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/ethtool.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) --- a/net/core/ethtool.c +++ b/net/core/ethtool.c @@ -754,15 +754,6 @@ static int ethtool_set_link_ksettings(st return dev->ethtool_ops->set_link_ksettings(dev, &link_ksettings); } -static void -warn_incomplete_ethtool_legacy_settings_conversion(const char *details) -{ - char name[sizeof(current->comm)]; - - pr_info_once("warning: `%s' uses legacy ethtool link settings API, %s\n", - get_task_comm(name, current), details); -} - /* Query device for its ethtool_cmd settings. * * Backward compatibility note: for compatibility with legacy ethtool, @@ -789,10 +780,8 @@ static int ethtool_get_settings(struct n &link_ksettings); if (err < 0) return err; - if (!convert_link_ksettings_to_legacy_settings(&cmd, - &link_ksettings)) - warn_incomplete_ethtool_legacy_settings_conversion( - "link modes are only partially reported"); + convert_link_ksettings_to_legacy_settings(&cmd, + &link_ksettings); /* send a sensible cmd tag back to user */ cmd.cmd = ETHTOOL_GSET; Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.14/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "8021q: fix a memory leak for VLAN 0 device" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 8021q: fix a memory leak for VLAN 0 device to the 4.14-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: 8021q-fix-a-memory-leak-for-vlan-0-device.patch and it can be found in the queue-4.14 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 foo@baz Sat Jan 13 10:51:05 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Tue, 9 Jan 2018 13:40:41 -0800 Subject: 8021q: fix a memory leak for VLAN 0 device From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ] A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi vlan_gvrp_uninit_applicant(real_dev); } - /* Take it out of our own structures, but be sure to interlock with - * HW accelerating devices or SW vlan input packet processing if - * VLAN is not 0 (leave it there for 802.1p). - */ - if (vlan_id) - vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); + vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev); Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.14/8021q-fix-a-memory-leak-for-vlan-0-device.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Please pick 0cb5b30: kvm: vmx: Scrub hardware GPRs at VM-exit

by Eric Wheeler

Hello stable list: This was just posted to 4.15-rc7 since it "defeats the Project Zero PoC for CVE 2017-5715." Should it be marked stable? It cherry-picks cleanly into 4.14.12, not sure about other branches. Full text below. -- Eric Wheeler kvm: vmx: Scrub hardware GPRs at VM-exit Guest GPR values are live in the hardware GPRs at VM-exit. Do not leave any guest values in hardware GPRs after the guest GPR values are saved to the vcpu_vmx structure. This is a partial mitigation for CVE 2017-5715 and CVE 2017-5753. Specifically, it defeats the Project Zero PoC for CVE 2017-5715. Suggested-by: Eric Northup <digitaleric(a)google.com> Signed-off-by: Jim Mattson <jmattson(a)google.com> Reviewed-by: Eric Northup <digitaleric(a)google.com> Reviewed-by: Benjamin Serebrin <serebrin(a)google.com> Reviewed-by: Andrew Honig <ahonig(a)google.com> [Paolo: Add AMD bits, Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com>] Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH v3 0/2] usb: dwc3: Properly update ep0 for IN direction

by Thinh Nguyen

This patch series fixes an issue with HS/FS 3-stage control read transfer where DWC3 incorrectly check when to send ZLP. Changes in v3: - Add 'Fixes:' tags - Minor update to commit message for clarity Changes in v2: - Separate from "usb: dwc3: Add new updates for DWC_usb31" patch series - Add 'Cc' to stable mailing list Thinh Nguyen (2): usb: dwc3: gadget: Set maxpacket size for ep0 IN usb: dwc3: ep0: Reset TRB counter for ep0 IN drivers/usb/dwc3/ep0.c | 7 ++++++- drivers/usb/dwc3/gadget.c | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-) -- 2.11.0

7 years, 5 months

1
2
0 0

[Linux-stable-mirror] [patch 3/4] kdump: write correct address of mem_section into vmcoreinfo

by akpm＠linux-foundation.org

From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Subject: kdump: write correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '&mem_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation correctly for both cases. Link: http://lkml.kernel.org/r/20180112162532.35896-1-kirill.shutemov@linux.intel… Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") Acked-by: Baoquan He <bhe(a)redhat.com> Acked-by: Dave Young <dyoung(a)redhat.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Dave Young <dyoung(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Vivek Goyal <vgoyal(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff -puN include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo include/linux/crash_core.h --- a/include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo +++ a/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name) +#define VMCOREINFO_SYMBOL_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff -puN kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo kernel/crash_core.c --- a/kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo +++ a/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_ VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_SYMBOL_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); _

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] PCI: Fix MSI disabled for HiSilicon Hip06/Hip07 EP mode

by Dongdong Liu

HiSilicon Hip06/Hip07 can work as RC mode and EP mode. The PCIe Root Port in Hip06/Hip07 SoCs advertises an MSI capability, but it can not generate MSIs. It can generate MSIs When it works as EP mode, but the vendor id and device id of RP and EP are the same. Current code also disable MSI for EP mode, we only need to disable MSI for Root Port. Cc: <stable(a)vger.kernel.org> Fixes: 72f2ff0deb87 ("PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports") Signed-off-by: Dongdong Liu <liudongdong3(a)huawei.com> --- drivers/pci/quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 10684b1..d22750e 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1636,8 +1636,8 @@ static void quirk_pcie_mch(struct pci_dev *pdev) DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7520_MCH, quirk_pcie_mch); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH, quirk_pcie_mch); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH, quirk_pcie_mch); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, quirk_pcie_mch); +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, PCI_CLASS_BRIDGE_PCI, 8, quirk_pcie_mch); /* * It's possible for the MSI to get corrupted if shpc and acpi -- 1.9.1

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] [PATCH-4.1.y 0/2] target: stable backports

by Nicholas A. Bellinger

From: Nicholas Bellinger <nab(a)linux-iscsi.org> Hi Sasha, Here are two target patches for v4.1.y stable, which did not apply due to minor context changes. The series has been cut against v4.1.48. Please apply at your earliest convenience. Thank you, --nab Nicholas Bellinger (2): iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK drivers/target/iscsi/iscsi_target.c | 20 +++++++------------- drivers/target/target_core_tmr.c | 9 +++++++++ drivers/target/target_core_transport.c | 2 ++ include/target/target_core_base.h | 1 + 4 files changed, 19 insertions(+), 13 deletions(-) -- 1.8.5.3

7 years, 5 months

1
2
0 0

[Linux-stable-mirror] + kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: kdump: write correct address of mem_section into vmcoreinfo has been added to the -mm tree. Its filename is kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/kdump-write-a-correct-address-of-m… and later at http://ozlabs.org/~akpm/mmotm/broken-out/kdump-write-a-correct-address-of-m… 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/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Subject: kdump: write correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '&mem_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation correctly for both cases. Link: http://lkml.kernel.org/r/20180112162532.35896-1-kirill.shutemov@linux.intel… Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") Acked-by: Baoquan He <bhe(a)redhat.com> Acked-by: Dave Young <dyoung(a)redhat.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Dave Young <dyoung(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Vivek Goyal <vgoyal(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff -puN include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo include/linux/crash_core.h --- a/include/linux/crash_core.h~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo +++ a/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name) +#define VMCOREINFO_SYMBOL_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff -puN kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo kernel/crash_core.c --- a/kernel/crash_core.c~kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo +++ a/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_ VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_SYMBOL_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); _ Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are kdump-write-a-correct-address-of-mem_section-into-vmcoreinfo.patch asm-generic-provide-generic_pmdp_establish.patch arc-use-generic_pmdp_establish-as-pmdp_establish.patch arm-mm-provide-pmdp_establish-helper.patch mips-use-generic_pmdp_establish-as-pmdp_establish.patch x86-mm-provide-pmdp_establish-helper.patch mm-do-not-lose-dirty-and-access-bits-in-pmdp_invalidate.patch mm-use-updated-pmdp_invalidate-interface-to-track-dirty-accessed-bits.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 2/2] RDMA/rxe: Fix rxe_qp_cleanup()

by Bart Van Assche

rxe_qp_cleanup() can sleep so it must be run in thread context and not in atomic context. This patch avoids that the following bug is triggered: Kernel BUG at 00000000560033f3 [verbose debug info unavailable] BUG: sleeping function called from invalid context at net/core/sock.c:2761 in_atomic(): 1, irqs_disabled(): 0, pid: 7, name: ksoftirqd/0 INFO: lockdep is turned off. Preemption disabled at: [<00000000b6e69628>] __do_softirq+0x4e/0x540 CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.15.0-rc7-dbg+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x85/0xbf ___might_sleep+0x177/0x260 lock_sock_nested+0x1d/0x90 inet_shutdown+0x2e/0xd0 rxe_qp_cleanup+0x107/0x140 [rdma_rxe] rxe_elem_release+0x18/0x80 [rdma_rxe] rxe_requester+0x1cf/0x11b0 [rdma_rxe] rxe_do_task+0x78/0xf0 [rdma_rxe] tasklet_action+0x99/0x270 __do_softirq+0xc0/0x540 run_ksoftirqd+0x1c/0x70 smpboot_thread_fn+0x1be/0x270 kthread+0x117/0x130 ret_from_fork+0x24/0x30 Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Cc: stable(a)vger.kernel.org --- drivers/infiniband/sw/rxe/rxe_qp.c | 12 ++++++++++-- drivers/infiniband/sw/rxe/rxe_verbs.h | 3 +++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_qp.c b/drivers/infiniband/sw/rxe/rxe_qp.c index 4469592b839d..137d6c0c49d4 100644 --- a/drivers/infiniband/sw/rxe/rxe_qp.c +++ b/drivers/infiniband/sw/rxe/rxe_qp.c @@ -824,9 +824,9 @@ void rxe_qp_destroy(struct rxe_qp *qp) } /* called when the last reference to the qp is dropped */ -void rxe_qp_cleanup(struct rxe_pool_entry *arg) +static void rxe_qp_do_cleanup(struct work_struct *work) { - struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + struct rxe_qp *qp = container_of(work, typeof(*qp), cleanup_work.work); rxe_drop_all_mcast_groups(qp); @@ -859,3 +859,11 @@ void rxe_qp_cleanup(struct rxe_pool_entry *arg) kernel_sock_shutdown(qp->sk, SHUT_RDWR); sock_release(qp->sk); } + +/* called when the last reference to the qp is dropped */ +void rxe_qp_cleanup(struct rxe_pool_entry *arg) +{ + struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + + execute_in_process_context(rxe_qp_do_cleanup, &qp->cleanup_work); +} diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h b/drivers/infiniband/sw/rxe/rxe_verbs.h index 0c2dbe45c729..1019f5e7dbdd 100644 --- a/drivers/infiniband/sw/rxe/rxe_verbs.h +++ b/drivers/infiniband/sw/rxe/rxe_verbs.h @@ -35,6 +35,7 @@ #define RXE_VERBS_H #include <linux/interrupt.h> +#include <linux/workqueue.h> #include <rdma/rdma_user_rxe.h> #include "rxe_pool.h" #include "rxe_task.h" @@ -281,6 +282,8 @@ struct rxe_qp { struct timer_list rnr_nak_timer; spinlock_t state_lock; /* guard requester and completer */ + + struct execute_work cleanup_work; }; enum rxe_mem_state { -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] RDMA/rxe: Fix a race condition in rxe_requester()

by Bart Van Assche

The rxe driver works as follows: * The send queue, receive queue and completion queues are implemented as circular buffers. * ib_post_send() and ib_post_recv() calls are serialized through a spinlock. * Removing elements from various queues happens from tasklet context. Tasklets are guaranteed to run on at most one CPU. This serializes access to these queues. See also rxe_completer(), rxe_requester() and rxe_responder(). * rxe_completer() processes the skbs queued onto qp->resp_pkts. * rxe_requester() handles the send queue (qp->sq.queue). * rxe_responder() processes the skbs queued onto qp->req_pkts. Since rxe_drain_req_pkts() processes qp->req_pkts, calling rxe_drain_req_pkts() from rxe_requester() is racy. Hence this patch. Reported-by: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: stable(a)vger.kernel.org --- drivers/infiniband/sw/rxe/rxe_loc.h | 1 - drivers/infiniband/sw/rxe/rxe_req.c | 9 +-------- drivers/infiniband/sw/rxe/rxe_resp.c | 2 +- 3 files changed, 2 insertions(+), 10 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h b/drivers/infiniband/sw/rxe/rxe_loc.h index d7472a442a2c..96c3a6c5c4b5 100644 --- a/drivers/infiniband/sw/rxe/rxe_loc.h +++ b/drivers/infiniband/sw/rxe/rxe_loc.h @@ -237,7 +237,6 @@ int rxe_srq_from_attr(struct rxe_dev *rxe, struct rxe_srq *srq, void rxe_release(struct kref *kref); -void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify); int rxe_completer(void *arg); int rxe_requester(void *arg); int rxe_responder(void *arg); diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c index 26a7f923045b..7bdaf71b8221 100644 --- a/drivers/infiniband/sw/rxe/rxe_req.c +++ b/drivers/infiniband/sw/rxe/rxe_req.c @@ -594,15 +594,8 @@ int rxe_requester(void *arg) rxe_add_ref(qp); next_wqe: - if (unlikely(!qp->valid)) { - rxe_drain_req_pkts(qp, true); + if (unlikely(!qp->valid || qp->req.state == QP_STATE_ERROR)) goto exit; - } - - if (unlikely(qp->req.state == QP_STATE_ERROR)) { - rxe_drain_req_pkts(qp, true); - goto exit; - } if (unlikely(qp->req.state == QP_STATE_RESET)) { qp->req.wqe_index = consumer_index(qp->sq.queue); diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c index 4240866a5331..01f926fd9029 100644 --- a/drivers/infiniband/sw/rxe/rxe_resp.c +++ b/drivers/infiniband/sw/rxe/rxe_resp.c @@ -1210,7 +1210,7 @@ static enum resp_states do_class_d1e_error(struct rxe_qp *qp) } } -void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify) +static void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify) { struct sk_buff *skb; -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [merged] userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails has been removed from the -mm tree. Its filename was userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Andrea Arcangeli <aarcange(a)redhat.com> Subject: userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails The previous fix 384632e67e0829 ("userfaultfd: non-cooperative: fix fork use after free") corrected the refcounting in case of UFFD_EVENT_FORK failure for the fork userfault paths. That still didn't clear the vma->vm_userfaultfd_ctx of the vmas that were set to point to the aborted new uffd ctx earlier in dup_userfaultfd. Link: http://lkml.kernel.org/r/20171223002505.593-2-aarcange@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Reviewed-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: Eric Biggers <ebiggers3(a)gmail.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff -puN fs/userfaultfd.c~userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails fs/userfaultfd.c --- a/fs/userfaultfd.c~userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails +++ a/fs/userfaultfd.c @@ -570,11 +570,14 @@ out: static void userfaultfd_event_wait_completion(struct userfaultfd_ctx *ctx, struct userfaultfd_wait_queue *ewq) { + struct userfaultfd_ctx *release_new_ctx; + if (WARN_ON_ONCE(current->flags & PF_EXITING)) goto out; ewq->ctx = ctx; init_waitqueue_entry(&ewq->wq, current); + release_new_ctx = NULL; spin_lock(&ctx->event_wqh.lock); /* @@ -601,8 +604,7 @@ static void userfaultfd_event_wait_compl new = (struct userfaultfd_ctx *) (unsigned long) ewq->msg.arg.reserved.reserved1; - - userfaultfd_ctx_put(new); + release_new_ctx = new; } break; } @@ -617,6 +619,20 @@ static void userfaultfd_event_wait_compl __set_current_state(TASK_RUNNING); spin_unlock(&ctx->event_wqh.lock); + if (release_new_ctx) { + struct vm_area_struct *vma; + struct mm_struct *mm = release_new_ctx->mm; + + /* the various vma->vm_userfaultfd_ctx still points to it */ + down_write(&mm->mmap_sem); + for (vma = mm->mmap; vma; vma = vma->vm_next) + if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx) + vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX; + up_write(&mm->mmap_sem); + + userfaultfd_ctx_put(release_new_ctx); + } + /* * ctx may go away after this if the userfault pseudo fd is * already released. _ Patches currently in -mm which might be from aarcange(a)redhat.com are

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [merged] mm-sparsec-wrong-allocation-for-mem_section.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/sparse.c: wrong allocation for mem_section has been removed from the -mm tree. Its filename was mm-sparsec-wrong-allocation-for-mem_section.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Baoquan He <bhe(a)redhat.com> Subject: mm/sparse.c: wrong allocation for mem_section In 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") mem_section is allocated at runtime to save memory. While it allocates the first dimension of array with sizeof(struct mem_section). It costs extra memory, should be sizeof(struct mem_section*). Fix it. Link: http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-bhe@redhat.com Fixes: 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") Signed-off-by: Baoquan He <bhe(a)redhat.com> Tested-by: Dave Young <dyoung(a)redhat.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Atsushi Kumagai <ats-kumagai(a)wm.jp.nec.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section mm/sparse.c --- a/mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section +++ a/mm/sparse.c @@ -211,7 +211,7 @@ void __init memory_present(int nid, unsi if (unlikely(!mem_section)) { unsigned long size, align; - size = sizeof(struct mem_section) * NR_SECTION_ROOTS; + size = sizeof(struct mem_section*) * NR_SECTION_ROOTS; align = 1 << (INTERNODE_CACHE_SHIFT); mem_section = memblock_virt_alloc(size, align); } _ Patches currently in -mm which might be from bhe(a)redhat.com are

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [merged] mm-mprotect-add-a-cond_resched-inside-change_pmd_range.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/mprotect: add a cond_resched() inside change_pmd_range() has been removed from the -mm tree. Its filename was mm-mprotect-add-a-cond_resched-inside-change_pmd_range.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Subject: mm/mprotect: add a cond_resched() inside change_pmd_range() While testing on a large CPU system, detected the following RCU stall many times over the span of the workload. This problem is solved by adding a cond_resched() in the change_pmd_range() function. [ 850.962530] INFO: rcu_sched detected stalls on CPUs/tasks: [ 850.962584] 154-....: (670 ticks this GP) idle=022/140000000000000/0 softirq=2825/2825 fqs=612 [ 850.962605] (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864) [ 850.962895] Sending NMI from CPU 955 to CPUs 154: [ 850.992667] NMI backtrace for cpu 154 [ 850.993069] CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3 [ 850.993258] NIP: c0000000000b3f64 LR: c0000000000b33d4 CTR: 000000000000aa18 [ 850.993503] REGS: 00000000a4b0fb44 TRAP: 0501 Not tainted (4.15.0-rc3+) [ 850.993707] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22422082 XER: 00000000 [ 850.994386] CFAR: 00000000006cf8f0 SOFTE: 1 GPR00: 0010000000000000 c00003ef9b1cb8c0 c0000000010cc600 0000000000000000 GPR04: 8e0000018c32b200 40017b3858fd6e00 8e0000018c32b208 40017b3858fd6e00 GPR08: 8e0000018c32b210 40017b3858fd6e00 8e0000018c32b218 40017b3858fd6e00 GPR12: ffffffffffffffff c00000000fb25100 [ 850.995976] NIP [c0000000000b3f64] plpar_hcall9+0x44/0x7c [ 850.996174] LR [c0000000000b33d4] pSeries_lpar_flush_hash_range+0x384/0x420 [ 850.996401] Call Trace: [ 850.996600] [c00003ef9b1cb8c0] [c00003fa8fff7d40] 0xc00003fa8fff7d40 (unreliable) [ 850.996959] [c00003ef9b1cba40] [c0000000000688a8] flush_hash_range+0x48/0x100 [ 850.997261] [c00003ef9b1cba90] [c000000000071b14] __flush_tlb_pending+0x44/0xd0 [ 850.997600] [c00003ef9b1cbac0] [c000000000071fa8] hpte_need_flush+0x408/0x470 [ 850.997958] [c00003ef9b1cbb30] [c0000000002c646c] change_protection_range+0xaac/0xf10 [ 850.998180] [c00003ef9b1cbcb0] [c0000000002f2510] change_prot_numa+0x30/0xb0 [ 850.998502] [c00003ef9b1cbce0] [c00000000013a950] task_numa_work+0x2d0/0x3e0 [ 850.998816] [c00003ef9b1cbda0] [c00000000011ea30] task_work_run+0x130/0x190 [ 850.999121] [c00003ef9b1cbe00] [c00000000001bcd8] do_notify_resume+0x118/0x120 [ 850.999421] [c00003ef9b1cbe30] [c00000000000b744] ret_from_except_lite+0x70/0x74 [ 850.999716] Instruction dump: [ 850.999959] 60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378 [ 851.000575] e9410060 e9610068 e9810070 44000022 <7d806378> e9810028 f88c0000 f8ac0008 Link: http://lkml.kernel.org/r/20171214140551.5794-1-khandual@linux.vnet.ibm.com Signed-off-by: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Suggested-by: Nicholas Piggin <npiggin(a)gmail.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mprotect.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff -puN mm/mprotect.c~mm-mprotect-add-a-cond_resched-inside-change_pmd_range mm/mprotect.c --- a/mm/mprotect.c~mm-mprotect-add-a-cond_resched-inside-change_pmd_range +++ a/mm/mprotect.c @@ -166,7 +166,7 @@ static inline unsigned long change_pmd_r next = pmd_addr_end(addr, end); if (!is_swap_pmd(*pmd) && !pmd_trans_huge(*pmd) && !pmd_devmap(*pmd) && pmd_none_or_clear_bad(pmd)) - continue; + goto next; /* invoke the mmu notifier if the pmd is populated */ if (!mni_start) { @@ -188,7 +188,7 @@ static inline unsigned long change_pmd_r } /* huge pmd was handled */ - continue; + goto next; } } /* fall through, the trans huge pmd just split */ @@ -196,6 +196,8 @@ static inline unsigned long change_pmd_r this_pages = change_pte_range(vma, pmd, addr, next, newprot, dirty_accountable, prot_numa); pages += this_pages; +next: + cond_resched(); } while (pmd++, addr = next, addr != end); if (mni_start) _ Patches currently in -mm which might be from khandual(a)linux.vnet.ibm.com are

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [merged] acct-fix-the-acct-needcheck-check-in-check_free_space.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: kernel/acct.c: fix the acct->needcheck check in check_free_space() has been removed from the -mm tree. Its filename was acct-fix-the-acct-needcheck-check-in-check_free_space.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Oleg Nesterov <oleg(a)redhat.com> Subject: kernel/acct.c: fix the acct->needcheck check in check_free_space() As Tsukada explains, the time_is_before_jiffies(acct->needcheck) check is very wrong, we need time_is_after_jiffies() to make sys_acct() work. Ignoring the overflows, the code should "goto out" if needcheck > jiffies, while currently it checks "needcheck < jiffies" and thus in the likely case check_free_space() does nothing until jiffies overflow. In particular this means that sys_acct() is simply broken, acct_on() sets acct->needcheck = jiffies and expects that check_free_space() should set acct->active = 1 after the free-space check, but this won't happen if jiffies increments in between. This was broken by commit 32dc73086015 ("get rid of timer in kern/acct.c") in 2011, then another (correct) commit 795a2f22a8ea ("acct() should honour the limits from the very beginning") made the problem more visible. Link: http://lkml.kernel.org/r/20171213133940.GA6554@redhat.com Fixes: 32dc73086015 ("get rid of timer in kern/acct.c") Reported-by: TSUKADA Koutaro <tsukada(a)ascade.co.jp> Suggested-by: TSUKADA Koutaro <tsukada(a)ascade.co.jp> Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/acct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN kernel/acct.c~acct-fix-the-acct-needcheck-check-in-check_free_space kernel/acct.c --- a/kernel/acct.c~acct-fix-the-acct-needcheck-check-in-check_free_space +++ a/kernel/acct.c @@ -102,7 +102,7 @@ static int check_free_space(struct bsd_a { struct kstatfs sbuf; - if (time_is_before_jiffies(acct->needcheck)) + if (time_is_after_jiffies(acct->needcheck)) goto out; /* May block */ _ Patches currently in -mm which might be from oleg(a)redhat.com are

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 2/2] mwifiex: resolve reset vs. remove()/shutdown() deadlocks

by Brian Norris

Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") resolves races between driver reset and removal, but it introduces some new deadlock problems. If we see a timeout while we've already started suspending, removing, or shutting down the driver, we might see: (a) a worker thread, running mwifiex_pcie_work() -> mwifiex_pcie_card_reset_work() -> pci_reset_function() (b) a removal thread, running mwifiex_pcie_remove() -> mwifiex_free_adapter() -> mwifiex_unregister() -> mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work) Unfortunately, mwifiex_pcie_remove() already holds the device lock that pci_reset_function() is now requesting, and so we see a deadlock. It's necessary to cancel and synchronize our outstanding work before tearing down the driver, so we can't have this work wait indefinitely for the lock. It's reasonable to only "try" to reset here, since this will mostly happen for cases where it's already difficult to reset the firmware anyway (e.g., while we're suspending or powering off the system). And if reset *really* needs to happen, we can always try again later. Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: <stable(a)vger.kernel.org> Cc: Xinming Hu <huxm(a)marvell.com> Signed-off-by: Brian Norris <briannorris(a)chromium.org> --- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index f666cb2ea7e0..97a6199692ab 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -2786,7 +2786,10 @@ static void mwifiex_pcie_card_reset_work(struct mwifiex_adapter *adapter) { struct pcie_service_card *card = adapter->card; - pci_reset_function(card->dev); + /* We can't afford to wait here; remove() might be waiting on us. If we + * can't grab the device lock, maybe we'll get another chance later. + */ + pci_try_reset_function(card->dev); } static void mwifiex_pcie_work(struct work_struct *work) -- 2.16.0.rc1.238.g530d649a79-goog

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy

by Eric W. Biederman

Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely not correct. With si_code set to SI_USER si_pid and si_uid will be copied to userspace instead of si_addr. Which is very wrong. So fix this by using a sensible si_code (SEGV_MAPERR) for this failure. Cc: stable(a)vger.kernel.org Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel") Cc: David Howells <dhowells(a)redhat.com> Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com> Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com> Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> --- arch/mn10300/mm/misalignment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mn10300/mm/misalignment.c b/arch/mn10300/mm/misalignment.c index b39a388825ae..8ace89617c1c 100644 --- a/arch/mn10300/mm/misalignment.c +++ b/arch/mn10300/mm/misalignment.c @@ -437,7 +437,7 @@ asmlinkage void misalignment(struct pt_regs *regs, enum exception_code code) info.si_signo = SIGSEGV; info.si_errno = 0; - info.si_code = 0; + info.si_code = SEGV_MAPERR; info.si_addr = (void *) regs->pc; force_sig_info(SIGSEGV, &info, current); return; -- 2.14.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2] PCI: iproc: Fix NULL pointer dereference for BCMA

by Ray Jui

With the inbound DMA mapping supported added, the iProc PCIe driver parses DT property "dma-ranges" through call to "of_pci_dma_range_parser_init". In the case of BCMA, this results in a NULL pointer deference due to a missing of_node. Fix this by adding a guard in pcie-iproc-platform.c to only enable the inbound DMA mapping logic when DT property "dma-ranges" is present Fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support") Reported-by: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Ray Jui <ray.jui(a)broadcom.com> Tested-by: Rafał Miłecki <rafal(a)milecki.pl> cc: <stable(a)vger.kernel.org> # 4.10+ --- drivers/pci/host/pcie-iproc-platform.c | 7 +++++++ drivers/pci/host/pcie-iproc.c | 8 +++++--- drivers/pci/host/pcie-iproc.h | 2 ++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c index a5073a9..32228d4 100644 --- a/drivers/pci/host/pcie-iproc-platform.c +++ b/drivers/pci/host/pcie-iproc-platform.c @@ -92,6 +92,13 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev) pcie->need_ob_cfg = true; } + /* + * DT nodes are not used by all platforms that use the iProc PCIe + * core driver. For platforms that require explict inbound mapping + * configuration, "dma-ranges" would have been present in DT + */ + pcie->need_ib_cfg = of_property_read_bool(np, "dma-ranges"); + /* PHY use is optional */ pcie->phy = devm_phy_get(dev, "pcie-phy"); if (IS_ERR(pcie->phy)) { diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index 935909b..7583606 100644 --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -1378,9 +1378,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res) } } - ret = iproc_pcie_map_dma_ranges(pcie); - if (ret && ret != -ENOENT) - goto err_power_off_phy; + if (pcie->need_ib_cfg) { + ret = iproc_pcie_map_dma_ranges(pcie); + if (ret && ret != -ENOENT) + goto err_power_off_phy; + } #ifdef CONFIG_ARM pcie->sysdata.private_data = pcie; diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h index a6b55ce..4ac6282 100644 --- a/drivers/pci/host/pcie-iproc.h +++ b/drivers/pci/host/pcie-iproc.h @@ -74,6 +74,7 @@ struct iproc_msi; * @ob: outbound mapping related parameters * @ob_map: outbound mapping related parameters specific to the controller * + * @need_ib_cfg: indicates SW needs to configure the inbound mapping window * @ib: inbound mapping related parameters * @ib_map: outbound mapping region related parameters * @@ -101,6 +102,7 @@ struct iproc_pcie { struct iproc_pcie_ob ob; const struct iproc_pcie_ob_map *ob_map; + bool need_ib_cfg; struct iproc_pcie_ib ib; const struct iproc_pcie_ib_map *ib_map; -- 2.1.4

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH 03/11] signal/openrisc: Fix do_unaligned_access to send the proper signal

by Eric W. Biederman

While reviewing the signal sending on openrisc the do_unaligned_access function stood out because it is obviously wrong. A comment about an si_code set above when actually si_code is never set. Leading to a random si_code being sent to userspace in the event of an unaligned access. Looking further SIGBUS BUS_ADRALN is the proper pair of signal and si_code to send for an unaligned access. That is what other architectures do and what is required by posix. Given that do_unaligned_access is broken in a way that no one can be relying on it on openrisc fix the code to just do the right thing. Cc: stable(a)vger.kernel.org Fixes: 769a8a96229e ("OpenRISC: Traps") Cc: Jonas Bonn <jonas(a)southpole.se> Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi> Cc: Stafford Horne <shorne(a)gmail.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: openrisc(a)lists.librecores.org Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> --- arch/openrisc/kernel/traps.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c index 4085d72fa5ae..9e38dc66c9e4 100644 --- a/arch/openrisc/kernel/traps.c +++ b/arch/openrisc/kernel/traps.c @@ -266,12 +266,12 @@ asmlinkage void do_unaligned_access(struct pt_regs *regs, unsigned long address) siginfo_t info; if (user_mode(regs)) { - /* Send a SIGSEGV */ - info.si_signo = SIGSEGV; + /* Send a SIGBUS */ + info.si_signo = SIGBUS; info.si_errno = 0; - /* info.si_code has been set above */ - info.si_addr = (void *)address; - force_sig_info(SIGSEGV, &info, current); + info.si_code = BUS_ADRALN; + info.si_addr = (void __user *)address; + force_sig_info(SIGBUS, &info, current); } else { printk("KERNEL: Unaligned Access 0x%.8lx\n", address); show_registers(regs); -- 2.14.1

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] [PATCH v3] mtd: nand: Fix nand_do_read_oob() return value

by Miquel Raynal

Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a negative error, and the MTD layer expected it. However, the trend for the NAND layer is now to return an error or a positive number of bitflips. Deciding which status to return to the user belongs to the MTD layer. Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") brought this logic to the mtd_read_oob() function while the return value coming from nand_do_read_oob() (called by the ->_read_oob() hook) was left unchanged. Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> --- Changes since v2: - Correctly return the maximum number of bitflips, not the number of bitflips of the last chunk only. Changes since v1: - s/->ecc.read_oob() hook/->_read_oob() hook/ in the commit message - Fixed the compilation issue drivers/mtd/nand/nand_base.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 469220065b8b..e4e39890a975 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3794,6 +3794,7 @@ EXPORT_SYMBOL(nand_write_oob_syndrome); static int nand_do_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops) { + unsigned int max_bitflips = 0; int page, realpage, chipnr; struct nand_chip *chip = mtd_to_nand(mtd); struct mtd_ecc_stats stats; @@ -3855,6 +3856,8 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from, if (!readlen) break; + max_bitflips = max_t(unsigned int, max_bitflips, ret); + /* Increment page address */ realpage++; @@ -3876,7 +3879,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from, if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG; - return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; + return max_bitflips; } /** -- 2.11.0

7 years, 5 months

2
2
0 0

[Linux-stable-mirror] [PATCH v4] RFT: mmc: sdhci: Implement an SDHCI-specific bounce buffer

by Linus Walleij

The bounce buffer is gone from the MMC core, and now we found out that there are some (crippled) i.MX boards out there that have broken ADMA (cannot do scatter-gather), and broken PIO so they must use SDMA. Closer examination shows a less significant slowdown also on SDMA-only capable Laptop hosts. SDMA sets down the number of segments to one, so that each segment gets turned into a singular request that ping-pongs to the block layer before the next request/segment is issued. Apparently it happens a lot that the block layer send requests that include a lot of physically discontigous segments. My guess is that this phenomenon is coming from the file system. These devices that cannot handle scatterlists in hardware can see major benefits from a DMA-contigous bounce buffer. This patch accumulates those fragmented scatterlists in a physically contigous bounce buffer so that we can issue bigger DMA data chunks to/from the card. When tested with thise PCI-integrated host (1217:8221) that only supports SDMA: 0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS SD/MMC Card Reader Controller (rev 05) This patch gave ~1Mbyte/s improved throughput on large reads and writes when testing using iozone than without the patch. On the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35 the patch restores the performance to what it was before we removed the bounce buffers, and then some: performance is better than ever because we now allocate a bounce buffer the size of the maximum single request the SDMA engine can handle. On the PCI laptop this is 256K, whereas with the old bounce buffer code it was 64K max. Cc: Benjamin Beckmeyer <beckmeyer.b(a)rittal.de> Cc: Pierre Ossman <pierre(a)ossman.eu> Cc: Benoît Thébaudeau <benoit(a)wsystem.com> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: stable(a)vger.kernel.org Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling") Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- --- ChangeLog v3->v4: - Cap the bounce buffer to 64KB instead of the biggest segment as we experience diminishing returns with buffers > 64KB. - Instead of using dma_alloc_coherent(), use good old devm_kmalloc() and issue dma_sync_single_for*() to explicitly switch ownership between CPU and the device. This way we exercise the cache better and may consume less CPU. - Bail out with single segments if we cannot allocate a bounce buffer. - Tested on the PCI SDHCI on my laptop: requesting a new test on i.MX from Benjamin. (Please!) ChangeLog v2->v3: - Rewrite the commit message a bit - Add Benjamin's Tested-by - Add Fixes and stable tags ChangeLog v1->v2: - Skip the remapping and fiddling with the buffer, instead use dma_alloc_coherent() and use a simple, coherent bounce buffer. - Couple kernel messages to ->parent of the mmc_host as it relates to the hardware characteristics. --- drivers/mmc/host/sdhci.c | 125 ++++++++++++++++++++++++++++++++++++++++++++--- drivers/mmc/host/sdhci.h | 3 ++ 2 files changed, 120 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index e9290a3439d5..694a320d9444 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -21,6 +21,7 @@ #include <linux/dma-mapping.h> #include <linux/slab.h> #include <linux/scatterlist.h> +#include <linux/sizes.h> #include <linux/swiotlb.h> #include <linux/regulator/consumer.h> #include <linux/pm_runtime.h> @@ -502,8 +503,27 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host, if (data->host_cookie == COOKIE_PRE_MAPPED) return data->sg_count; - sg_count = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len, - mmc_get_dma_dir(data)); + /* Bounce write requests to the bounce buffer */ + if (host->bounce_buffer) { + if (mmc_get_dma_dir(data) == DMA_TO_DEVICE) { + /* Copy the data to the bounce buffer */ + sg_copy_to_buffer(data->sg, data->sg_len, + host->bounce_buffer, + host->bounce_buffer_size); + } + /* Switch ownership to the DMA */ + dma_sync_single_for_device(host->mmc->parent, + host->bounce_addr, + host->bounce_buffer_size, + DMA_TO_DEVICE); + /* Just a dummy value */ + sg_count = 1; + } else { + /* Just access the data directly from memory */ + sg_count = dma_map_sg(mmc_dev(host->mmc), + data->sg, data->sg_len, + mmc_get_dma_dir(data)); + } if (sg_count == 0) return -ENOSPC; @@ -858,8 +878,13 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd) SDHCI_ADMA_ADDRESS_HI); } else { WARN_ON(sg_cnt != 1); - sdhci_writel(host, sg_dma_address(data->sg), - SDHCI_DMA_ADDRESS); + /* Bounce buffer goes to work */ + if (host->bounce_buffer) + sdhci_writel(host, host->bounce_addr, + SDHCI_DMA_ADDRESS); + else + sdhci_writel(host, sg_dma_address(data->sg), + SDHCI_DMA_ADDRESS); } } @@ -2248,7 +2273,12 @@ static void sdhci_pre_req(struct mmc_host *mmc, struct mmc_request *mrq) mrq->data->host_cookie = COOKIE_UNMAPPED; - if (host->flags & SDHCI_REQ_USE_DMA) + /* + * No pre-mapping in the pre hook if we're using the bounce buffer, + * for that we would need two bounce buffers since one buffer is + * in flight when this is getting called. + */ + if (host->flags & SDHCI_REQ_USE_DMA && !host->bounce_buffer) sdhci_pre_dma_transfer(host, mrq->data, COOKIE_PRE_MAPPED); } @@ -2352,8 +2382,28 @@ static bool sdhci_request_done(struct sdhci_host *host) struct mmc_data *data = mrq->data; if (data && data->host_cookie == COOKIE_MAPPED) { - dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, - mmc_get_dma_dir(data)); + if (host->bounce_buffer) { + /* + * On reads, copy the bounced data into the + * sglist + */ + if (mmc_get_dma_dir(data) == DMA_FROM_DEVICE) { + dma_sync_single_for_cpu( + host->mmc->parent, + host->bounce_addr, + host->bounce_buffer_size, + DMA_FROM_DEVICE); + sg_copy_from_buffer(data->sg, + data->sg_len, + host->bounce_buffer, + host->bounce_buffer_size); + } + } else { + /* Unmap the raw data */ + dma_unmap_sg(mmc_dev(host->mmc), data->sg, + data->sg_len, + mmc_get_dma_dir(data)); + } data->host_cookie = COOKIE_UNMAPPED; } } @@ -2636,7 +2686,12 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask) */ if (intmask & SDHCI_INT_DMA_END) { u32 dmastart, dmanow; - dmastart = sg_dma_address(host->data->sg); + + if (host->bounce_buffer) + dmastart = host->bounce_addr; + else + dmastart = sg_dma_address(host->data->sg); + dmanow = dmastart + host->data->bytes_xfered; /* * Force update to the next DMA block boundary. @@ -3713,6 +3768,60 @@ int sdhci_setup_host(struct sdhci_host *host) */ mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535; + if (mmc->max_segs == 1) { + unsigned int max_blocks; + unsigned int max_seg_size; + + /* + * Cap the bounce buffer at 64KB. Using a bigger bounce buffer + * has diminishing returns, this is probably because SD/MMC + * cards are usually optimized to handle this size of requests. + */ + max_seg_size = SZ_64K; + if (mmc->max_req_size < max_seg_size) + max_seg_size = mmc->max_req_size; + max_blocks = max_seg_size / 512; + dev_info(mmc->parent, + "host only supports SDMA, activate bounce buffer\n"); + + /* + * When we just support one segment, we can get significant + * speedups by the help of a bounce buffer to group scattered + * reads/writes together. + */ + host->bounce_buffer = devm_kmalloc(mmc->parent, + max_seg_size, + GFP_KERNEL); + if (!host->bounce_buffer) { + dev_err(mmc->parent, + "failed to allocate %u bytes for bounce buffer, falling back to single segments\n", + max_seg_size); + /* + * Exiting with zero here makes sure we proceed with + * mmc->max_segs == 1. + */ + return 0; + } + + host->bounce_buffer_size = max_seg_size; + host->bounce_addr = dma_map_single(mmc->parent, + host->bounce_buffer, + host->bounce_buffer_size, + DMA_BIDIRECTIONAL); + ret = dma_mapping_error(mmc->parent, host->bounce_addr); + if (ret) + /* Again fall back to max_segs == 1 */ + return 0; + + /* Lie about this since we're bouncing */ + mmc->max_segs = max_blocks; + mmc->max_seg_size = max_seg_size; + + dev_info(mmc->parent, + "bounce buffer: bounce up to %u segments into one, max segment size %u bytes\n", + max_blocks, max_seg_size); + } + return 0; unreg: diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index 54bc444c317f..865e09618d22 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -440,6 +440,9 @@ struct sdhci_host { int irq; /* Device IRQ */ void __iomem *ioaddr; /* Mapped address */ + char *bounce_buffer; /* For packing SDMA reads/writes */ + dma_addr_t bounce_addr; + size_t bounce_buffer_size; const struct sdhci_ops *ops; /* Low level hw interface */ -- 2.14.3

7 years, 5 months

2
2
0 0

[Linux-stable-mirror] [PULL 1/2] KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2

by Christoffer Dall

From: Punit Agrawal <punit.agrawal(a)arm.com> KVM only supports PMD hugepages at stage 2 but doesn't actually check that the provided hugepage memory pagesize is PMD_SIZE before populating stage 2 entries. In cases where the backing hugepage size is smaller than PMD_SIZE (such as when using contiguous hugepages), KVM can end up creating stage 2 mappings that extend beyond the supplied memory. Fix this by checking for the pagesize of userspace vma before creating PMD hugepage at stage 2. Fixes: 66b3923a1a0f77a ("arm64: hugetlb: add support for PTE contiguous bit") Signed-off-by: Punit Agrawal <punit.agrawal(a)arm.com> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: <stable(a)vger.kernel.org> # v4.5+ Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- virt/kvm/arm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c index b4b69c2d1012..9dea96380339 100644 --- a/virt/kvm/arm/mmu.c +++ b/virt/kvm/arm/mmu.c @@ -1310,7 +1310,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, return -EFAULT; } - if (is_vm_hugetlb_page(vma) && !logging_active) { + if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) { hugetlb = true; gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT; } else { -- 2.14.2

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4.4 00/37] 4.4.110-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.4.110-rc1 Kees Cook <keescook(a)chromium.org> KPTI: Report when enabled Kees Cook <keescook(a)chromium.org> KPTI: Rename to PAGE_TABLE_ISOLATION Borislav Petkov <bp(a)suse.de> x86/kaiser: Move feature detection up Jiri Kosina <jkosina(a)suse.cz> kaiser: disabled on Xen PV Borislav Petkov <bp(a)suse.de> x86/kaiser: Reenable PARAVIRT Thomas Gleixner <tglx(a)linutronix.de> x86/paravirt: Dont patch flush_tlb_single Hugh Dickins <hughd(a)google.com> kaiser: kaiser_flush_tlb_on_return_to_user() check PCID Hugh Dickins <hughd(a)google.com> kaiser: asm/tlbflush.h handle noPGE at lower level Hugh Dickins <hughd(a)google.com> kaiser: drop is_atomic arg to kaiser_pagetable_walk() Hugh Dickins <hughd(a)google.com> kaiser: use ALTERNATIVE instead of x86_cr3_pcid_noflush Borislav Petkov <bp(a)suse.de> x86/kaiser: Check boottime cmdline params Borislav Petkov <bp(a)suse.de> x86/kaiser: Rename and simplify X86_FEATURE_KAISER handling Hugh Dickins <hughd(a)google.com> kaiser: add "nokaiser" boot option, using ALTERNATIVE Hugh Dickins <hughd(a)google.com> kaiser: fix unlikely error in alloc_ldt_struct() Hugh Dickins <hughd(a)google.com> kaiser: _pgd_alloc() without __GFP_REPEAT to avoid stalls Hugh Dickins <hughd(a)google.com> kaiser: paranoid_entry pass cr3 need to paranoid_exit Hugh Dickins <hughd(a)google.com> kaiser: x86_cr3_pcid_noflush and x86_cr3_pcid_user Hugh Dickins <hughd(a)google.com> kaiser: PCID 0 for kernel and 128 for user Hugh Dickins <hughd(a)google.com> kaiser: load_new_mm_cr3() let SWITCH_USER_CR3 flush user Dave Hansen <dave.hansen(a)linux.intel.com> kaiser: enhanced by kernel and user PCIDs Hugh Dickins <hughd(a)google.com> kaiser: vmstat show NR_KAISERTABLE as nr_overhead Hugh Dickins <hughd(a)google.com> kaiser: delete KAISER_REAL_SWITCH option Hugh Dickins <hughd(a)google.com> kaiser: name that 0x1000 KAISER_SHADOW_PGD_OFFSET Hugh Dickins <hughd(a)google.com> kaiser: cleanups while trying for gold link Hugh Dickins <hughd(a)google.com> kaiser: kaiser_remove_mapping() move along the pgd Hugh Dickins <hughd(a)google.com> kaiser: tidied up kaiser_add/remove_mapping slightly Hugh Dickins <hughd(a)google.com> kaiser: tidied up asm/kaiser.h somewhat Hugh Dickins <hughd(a)google.com> kaiser: ENOMEM if kaiser_pagetable_walk() NULL Hugh Dickins <hughd(a)google.com> kaiser: fix perf crashes Hugh Dickins <hughd(a)google.com> kaiser: fix regs to do_nmi() ifndef CONFIG_KAISER Hugh Dickins <hughd(a)google.com> kaiser: KAISER depends on SMP Hugh Dickins <hughd(a)google.com> kaiser: fix build and FIXME in alloc_ldt_struct() Hugh Dickins <hughd(a)google.com> kaiser: stack map PAGE_SIZE at THREAD_SIZE-PAGE_SIZE Hugh Dickins <hughd(a)google.com> kaiser: do not set _PAGE_NX on pgd_none Dave Hansen <dave.hansen(a)linux.intel.com> kaiser: merged update Richard Fellner <richard.fellner(a)student.tugraz.at> KAISER: Kernel Address Isolation Tom Lendacky <thomas.lendacky(a)amd.com> x86/boot: Add early cmdline parsing for options with arguments ------------- Diffstat: Documentation/kernel-parameters.txt | 8 + Makefile | 4 +- arch/x86/boot/compressed/misc.h | 1 + arch/x86/entry/entry_64.S | 164 ++++++++-- arch/x86/entry/entry_64_compat.S | 7 + arch/x86/include/asm/cmdline.h | 2 + arch/x86/include/asm/cpufeature.h | 4 + arch/x86/include/asm/desc.h | 2 +- arch/x86/include/asm/hw_irq.h | 2 +- arch/x86/include/asm/kaiser.h | 141 +++++++++ arch/x86/include/asm/pgtable.h | 28 +- arch/x86/include/asm/pgtable_64.h | 25 +- arch/x86/include/asm/pgtable_types.h | 29 +- arch/x86/include/asm/processor.h | 2 +- arch/x86/include/asm/tlbflush.h | 74 ++++- arch/x86/include/uapi/asm/processor-flags.h | 3 +- arch/x86/kernel/cpu/common.c | 28 +- arch/x86/kernel/cpu/perf_event_intel_ds.c | 57 +++- arch/x86/kernel/espfix_64.c | 10 + arch/x86/kernel/head_64.S | 35 ++- arch/x86/kernel/irqinit.c | 2 +- arch/x86/kernel/ldt.c | 25 +- arch/x86/kernel/paravirt_patch_64.c | 2 - arch/x86/kernel/process.c | 2 +- arch/x86/kernel/setup.c | 7 + arch/x86/kernel/tracepoint.c | 2 + arch/x86/kvm/x86.c | 3 +- arch/x86/lib/cmdline.c | 105 +++++++ arch/x86/mm/Makefile | 1 + arch/x86/mm/init.c | 2 +- arch/x86/mm/init_64.c | 10 + arch/x86/mm/kaiser.c | 455 ++++++++++++++++++++++++++++ arch/x86/mm/pageattr.c | 63 +++- arch/x86/mm/pgtable.c | 16 +- arch/x86/mm/tlb.c | 39 ++- include/asm-generic/vmlinux.lds.h | 7 + include/linux/kaiser.h | 52 ++++ include/linux/mmzone.h | 3 +- include/linux/percpu-defs.h | 32 +- init/main.c | 2 + kernel/fork.c | 6 + mm/vmstat.c | 1 + security/Kconfig | 10 + 43 files changed, 1375 insertions(+), 98 deletions(-)

7 years, 5 months

19
141
0 0

[Linux-stable-mirror] [PATCH v2] mtd: nand: Fix nand_do_read_oob() return value

by Miquel Raynal

Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a negative error, and the MTD layer expected it. However, the trend for the NAND layer is now to return an error or a positive number of bitflips. Deciding which status to return to the user belongs to the MTD layer. Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") brought this logic to the mtd_read_oob() function while the return value coming from nand_do_read_oob() (called by the ->_read_oob() hook) was left unchanged. Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> --- Changes since v1: - s/->ecc.read_oob() hook/->_read_oob() hook/ in the commit message - Fixed the compilation issue drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 469220065b8b..440d9f5d5b17 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3876,7 +3876,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from, if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG; - return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; + return ret; } /** -- 2.11.0

7 years, 5 months

2
2
0 0

Re: [Linux-stable-mirror] [PATCH] RDMA/rxe: Fix a race condition related to the QP error state

by Bart Van Assche

On Fri, 2018-01-12 at 08:23 +0200, Leon Romanovsky wrote: > On Thu, Jan 11, 2018 at 07:07:06PM +0000, Bart Van Assche wrote: > > On Thu, 2018-01-11 at 21:00 +0200, Leon Romanovsky wrote: > > > On Thu, Jan 11, 2018 at 04:02:33PM +0000, Bart Van Assche wrote: > > > > On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote: > > > > > The proposed patch definitely decreases the chance of races, but it is not fixing them. > > > > > There is a chance to have change in qp state immediately after your "if ..." check. > > > > > > > > Hello Leon, > > > > > > > > Please have a look at rxe_qp_error() and you will see that the patch I posted > > > > is a proper fix. In the scenario you described rxe_qp_error() will trigger a > > > > run of rxe_completer(). > > > > > > Bart, > > > > > > What am I missing? > > > > > > CPU1 CPU2 > > > if (unlikely.... > > > <--- > > > /* move the qp to the error state */ > > > void rxe_qp_error(struct rxe_qp *qp) > > > { > > > qp->req.state = QP_STATE_ERROR; > > > qp->resp.state = QP_STATE_ERROR; > > > qp->attr.qp_state = IB_QPS_ERR; > > > ---> > > > rxe_run_task(&qp->req.task, must_sched); > > > > > > > > > > > > It is more or less the same as without "if (unlikely..." > > > > Hello Leon, > > > > In the above the part of rxe_qp_error() that I was referring to in my e-mail > > is missing: > > > > if (qp_type(qp) == IB_QPT_RC) > > rxe_run_task(&qp->comp.task, 1); > > > But it is exactly where race exists, as long QP isn't protected, it can > switch CPUs and create race. Hello Leon, Can you clarify which race you are referring to? rxe_run_task() uses the tasklet mechanism and tasklets are guaranteed to run on at most one CPU at a time. See also the "Top and Bottom Halves" chapter in Linux Device Drivers, 3rd edition. See also the tasklet_schedule() implementation in <linux/interrupt.h> and in kernel/softirq.c. Thanks, Bart.

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] phy: work around 'phys' references to usb-phy devices

by Kishon Vijay Abraham I

Hi Arnd, On Thursday 11 January 2018 11:46 PM, Eric Anholt wrote: > Arnd Bergmann <arnd(a)arndb.de> writes: > >> On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I <kishon(a)ti.com> wrote: >>> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote: >>>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kishon(a)ti.com> wrote: >>>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote: >>>>>> Stefan Wahren reports a problem with a warning fix that was merged >>>>>> --- >>>>>> This obviously needs to be tested, I wrote this up as a reply to >>>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy >>>>>> driver strings here. My goal is to have a fix merged into 4.15 >>>>>> rather than reverting all the DT fixes. >>>>> >>>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able >>>>> to find the phy either using usb-phy or generic phy? >>>> >>>> Stefan has posted a patch to that effect now, but I fear that might be >>>> a little fragile, in particular this short before the release with the >>>> regression >>>> in place. >>>> >>>> The main problem is that we'd have to change the generic >>>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore >>>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev() >>>> has already succeeded. >>>> >>>> If there is any HCD that relies on usb_add_hcd() to get both the >>>> usb_phy and the phy structures, and it may need to defer probing >>>> when the latter one isn't ready yet, that fix would break another >>>> driver. >>> >>> hmm.. IMO the better thing right now would be to revert the dt patch which adds >>> #phy-cells. >>> We have to see if there are better fixes in order to add #phy-cells warning fix >>> in stable tree. >> >> Let's see which patches that would be, I think this is the full list of >> nodes that got an extra #phy-cells: >> >> c22fe696157d ARM: dts: Fix dm814x missing phy-cells property >> f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy >> c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv >> 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv >> 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells >> f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv >> >> plus a couple in linux-next: >> >> d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv >> 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv >> >> It's a lot of patches to revert, and I guess it would get us back to hundreds >> of warnings in an allmodconfig build, so I'd first try to come up with >> ways to prove that at least some of them can stay. >> >> Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions >> I could find are the OMAP ones (the first two patches), which use >> "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That >> particular driver is not affected by the bug, so we can leave that in. >> >> To deal with all the "usb-nop-xceiv" references including the one that >> Stefan reported, we could use a much simpler version of my earlier >> patch, do you think this is any better? yeah, this looks simpler. >> >> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> In case you want to take this patch yourself Acked-by: Kishon Vijay Abraham I <kishon(a)ti.com> (or let me know if I have to create a separate pull request for Greg) Thanks Kishon >> >> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c >> index b4964b067aec..f056d8fb3921 100644 >> --- a/drivers/phy/phy-core.c >> +++ b/drivers/phy/phy-core.c >> @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node >> *np, int index) >> if (ret) >> return ERR_PTR(-ENODEV); >> >> + /* This phy type handled by the usb-phy subsystem for now */ >> + if (of_device_is_compatible("usb-nop-xceiv")) >> + return ERR_PTR(-ENODEV); >> + >> mutex_lock(&phy_provider_mutex); >> phy_provider = of_phy_provider_lookup(args.np); >> if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) { > > This seems like a nice workaround! >

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 02/11] signal/sh: Ensure si_signo is initialized in do_divide_error

by Eric W. Biederman

Set si_signo. Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp> Cc: Rich Felker <dalias(a)libc.org> Cc: Paul Mundt <lethal(a)linux-sh.org> Cc: linux-sh(a)vger.kernel.org Cc: stable(a)vger.kernel.org Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> --- arch/sh/kernel/traps_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/sh/kernel/traps_32.c b/arch/sh/kernel/traps_32.c index 57cff00cad17..b3770bb26211 100644 --- a/arch/sh/kernel/traps_32.c +++ b/arch/sh/kernel/traps_32.c @@ -609,7 +609,8 @@ asmlinkage void do_divide_error(unsigned long r4) break; } - force_sig_info(SIGFPE, &info, current); + info.si_signo = SIGFPE; + force_sig_info(info.si_signo, &info, current); } #endif -- 2.14.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] + pipe-fix-off-by-one-error-when-checking-buffer-limits.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: pipe: fix off-by-one error when checking buffer limits has been added to the -mm tree. Its filename is pipe-fix-off-by-one-error-when-checking-buffer-limits.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/pipe-fix-off-by-one-error-when-che… and later at http://ozlabs.org/~akpm/mmotm/broken-out/pipe-fix-off-by-one-error-when-che… 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/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Eric Biggers <ebiggers(a)google.com> Subject: pipe: fix off-by-one error when checking buffer limits With pipe-user-pages-hard set to 'N', users were actually only allowed up to 'N - 1' buffers; and likewise for pipe-user-pages-soft. Fix this to allow up to 'N' buffers, as would be expected. Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Acked-by: Willy Tarreau <w(a)1wt.eu> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org> Cc: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Mikulas Patocka <mpatocka(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/pipe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN fs/pipe.c~pipe-fix-off-by-one-error-when-checking-buffer-limits fs/pipe.c --- a/fs/pipe.c~pipe-fix-off-by-one-error-when-checking-buffer-limits +++ a/fs/pipe.c @@ -605,12 +605,12 @@ static unsigned long account_pipe_buffer static bool too_many_pipe_buffers_soft(unsigned long user_bufs) { - return pipe_user_pages_soft && user_bufs >= pipe_user_pages_soft; + return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft; } static bool too_many_pipe_buffers_hard(unsigned long user_bufs) { - return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard; + return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard; } static bool is_unprivileged_user(void) _ Patches currently in -mm which might be from ebiggers(a)google.com are userfaultfd-convert-to-use-anon_inode_getfd.patch pipe-sysctl-drop-min-parameter-from-pipe-max-size-converter.patch pipe-sysctl-remove-pipe_proc_fn.patch pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch pipe-fix-off-by-one-error-when-checking-buffer-limits.patch pipe-reject-f_setpipe_sz-with-size-over-uint_max.patch pipe-simplify-round_pipe_size.patch pipe-read-buffer-limits-atomically.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] + pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: pipe: actually allow root to exceed the pipe buffer limits has been added to the -mm tree. Its filename is pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/pipe-actually-allow-root-to-exceed… and later at http://ozlabs.org/~akpm/mmotm/broken-out/pipe-actually-allow-root-to-exceed… 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/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Eric Biggers <ebiggers(a)google.com> Subject: pipe: actually allow root to exceed the pipe buffer limits pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply to unprivileged users, as documented in both Documentation/sysctl/fs.txt and the pipe(7) man page. However, the capabilities are actually only checked when increasing a pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore, if pipe-user-pages-hard has been set, the root user can run into it and be unable to create pipes. Similarly, if pipe-user-pages-soft has been set, the root user can run into it and have their pipes limited to 1 page each. Fix this by allowing the privileged override in both cases. Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org> Cc: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Mikulas Patocka <mpatocka(a)redhat.com> Cc: Willy Tarreau <w(a)1wt.eu> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/pipe.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff -puN fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits fs/pipe.c --- a/fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits +++ a/fs/pipe.c @@ -613,6 +613,11 @@ static bool too_many_pipe_buffers_hard(u return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard; } +static bool is_unprivileged_user(void) +{ + return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN); +} + struct pipe_inode_info *alloc_pipe_info(void) { struct pipe_inode_info *pipe; @@ -629,12 +634,12 @@ struct pipe_inode_info *alloc_pipe_info( user_bufs = account_pipe_buffers(user, 0, pipe_bufs); - if (too_many_pipe_buffers_soft(user_bufs)) { + if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) { user_bufs = account_pipe_buffers(user, pipe_bufs, 1); pipe_bufs = 1; } - if (too_many_pipe_buffers_hard(user_bufs)) + if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user()) goto out_revert_acct; pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer), @@ -1065,7 +1070,7 @@ static long pipe_set_size(struct pipe_in if (nr_pages > pipe->buffers && (too_many_pipe_buffers_hard(user_bufs) || too_many_pipe_buffers_soft(user_bufs)) && - !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) { + is_unprivileged_user()) { ret = -EPERM; goto out_revert_acct; } _ Patches currently in -mm which might be from ebiggers(a)google.com are userfaultfd-convert-to-use-anon_inode_getfd.patch pipe-sysctl-drop-min-parameter-from-pipe-max-size-converter.patch pipe-sysctl-remove-pipe_proc_fn.patch pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch pipe-fix-off-by-one-error-when-checking-buffer-limits.patch pipe-reject-f_setpipe_sz-with-size-over-uint_max.patch pipe-simplify-round_pipe_size.patch pipe-read-buffer-limits-atomically.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] mtd: nand: Fix nand_do_read_oob() return value

by Miquel Raynal

Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a negative error, and the MTD layer expected it. However, the trend for the NAND layer is now to return an error or a positive number of bitflips. Deciding which status to return to the user belongs to the MTD layer. Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") brought this logic to the mtd_read_oob() function while the status coming from nand_do_read_oob() (called by the ->ecc.read_oob() hook) was left unchanged. Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> --- drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 469220065b8b..88256b656072 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3876,7 +3876,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from, if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG; - return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; + return max_bitflips; } /** -- 2.11.0

7 years, 5 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH v2 2/2] usb: dwc3: ep0: Reset TRB counter for ep0 IN

by Thinh Nguyen

Hi, On 1/11/2018 12:16 AM, Felipe Balbi wrote: > > Hi, > > Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> writes: >> In control read transfer completion handler, the driver needs to reset >> the TRB enqueue counter. Since there is one control endpoint structure >> for each direction, we must also track the TRB enqueue counter for each >> direction. Currently the driver only resets the TRB counter for control >> OUT endpoint only. Check for the data direction and properly reset the >> TRB counter from correct control endpoint. >> >> Cc: stable(a)vger.kernel.org >> Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> > > missing Fixes tag Same with this patch. There's no particular commit that it fixes. BR, Thinh

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] PCI: iproc: Fix NULL pointer dereference for BCMA

by Ray Jui

With the inbound DMA mapping supported added, the iProc PCIe driver parses DT property "dma-ranges" through call to "of_pci_dma_range_parser_init". In the case of BCMA, this results in a NULL pointer deference due to a missing of_node. Fix this by adding a guard in pcie-iproc-platform.c to only enable the inbound DMA mapping logic when DT property "dma-ranges" is present fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support") Reported-by: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Ray Jui <ray.jui(a)broadcom.com> Tested-by: Rafał Miłecki <rafal(a)milecki.pl> Cc: <stable(a)vger.kernel.org> # 4.10+ --- drivers/pci/host/pcie-iproc-platform.c | 3 +++ drivers/pci/host/pcie-iproc.c | 8 +++++--- drivers/pci/host/pcie-iproc.h | 2 ++ 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c index a5073a9..235c545 100644 --- a/drivers/pci/host/pcie-iproc-platform.c +++ b/drivers/pci/host/pcie-iproc-platform.c @@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev) pcie->need_ob_cfg = true; } + if (of_property_read_bool(np, "dma-ranges")) + pcie->need_ib_cfg = true; + /* PHY use is optional */ pcie->phy = devm_phy_get(dev, "pcie-phy"); if (IS_ERR(pcie->phy)) { diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index 935909b..7583606 100644 --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -1378,9 +1378,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res) } } - ret = iproc_pcie_map_dma_ranges(pcie); - if (ret && ret != -ENOENT) - goto err_power_off_phy; + if (pcie->need_ib_cfg) { + ret = iproc_pcie_map_dma_ranges(pcie); + if (ret && ret != -ENOENT) + goto err_power_off_phy; + } #ifdef CONFIG_ARM pcie->sysdata.private_data = pcie; diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h index a6b55ce..4ac6282 100644 --- a/drivers/pci/host/pcie-iproc.h +++ b/drivers/pci/host/pcie-iproc.h @@ -74,6 +74,7 @@ struct iproc_msi; * @ob: outbound mapping related parameters * @ob_map: outbound mapping related parameters specific to the controller * + * @need_ib_cfg: indicates SW needs to configure the inbound mapping window * @ib: inbound mapping related parameters * @ib_map: outbound mapping region related parameters * @@ -101,6 +102,7 @@ struct iproc_pcie { struct iproc_pcie_ob ob; const struct iproc_pcie_ob_map *ob_map; + bool need_ib_cfg; struct iproc_pcie_ib ib; const struct iproc_pcie_ib_map *ib_map; -- 2.1.4

7 years, 5 months

2
2
0 0

Re: [Linux-stable-mirror] [PATCH v2 1/2] usb: dwc3: gadget: Set maxpacket size for ep0 IN

by Thinh Nguyen

Hi, On 1/11/2018 12:16 AM, Felipe Balbi wrote: > > Hi, > > Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> writes: >> There are 2 control endpoint structures for DWC3. However, the driver >> only updates the OUT direction control endpoint structure during >> ConnectDone event. DWC3 driver needs to update the endpoint max packet >> size for control IN endpoint as well. If the max packet size is not >> properly set, then the driver will incorrectly calculate the data >> transfer size and fail to send ZLP for HS/FS 3-stage control read >> transfer. >> >> The fix is simply to update the max packet size for the ep0 IN direction >> during ConnectDone event. >> >> Cc: stable(a)vger.kernel.org >> Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> > > missing Fixes tag This bug has been there since the beginning. There's no particular commit that it fixes. BR, Thinh

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] WTF: patch "[PATCH] drm/i915: Fix init_clock_gating for resume" was seriously submitted to be applied to the 4.14-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 4.14-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 16 Nov 2017 18:02:15 +0200 Subject: [PATCH] drm/i915: Fix init_clock_gating for resume MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moving the init_clock_gating() call from intel_modeset_init_hw() to intel_modeset_gem_init() had an unintended effect of not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS screen after hibernation. Fix the problem by explicitly calling init_clock_gating() from the resume path. I really hope this doesn't break something else again. At least the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549 didn't make a comeback, even after a hibernate cycle. v2: Reorder the init_clock_gating vs. modeset_init_hw to match the display reset path (Rodrigo) Cc: stable(a)vger.kernel.org Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was") Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171116160215.25715-1-ville.… Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> (cherry picked from commit 675f7ff35bd256e65d3d0f52718d8babf5d1002a) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 34191028bbad..7d9b07df32fa 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1714,6 +1714,7 @@ static int i915_drm_resume(struct drm_device *dev) intel_guc_resume(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup)

7 years, 5 months

6
11
0 0

Re: [Linux-stable-mirror] [PATCH] RDMA/rxe: Fix a race condition related to the QP error state

by Bart Van Assche

On Thu, 2018-01-11 at 21:00 +0200, Leon Romanovsky wrote: > On Thu, Jan 11, 2018 at 04:02:33PM +0000, Bart Van Assche wrote: > > On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote: > > > The proposed patch definitely decreases the chance of races, but it is not fixing them. > > > There is a chance to have change in qp state immediately after your "if ..." check. > > > > Hello Leon, > > > > Please have a look at rxe_qp_error() and you will see that the patch I posted > > is a proper fix. In the scenario you described rxe_qp_error() will trigger a > > run of rxe_completer(). > > Bart, > > What am I missing? > > CPU1 CPU2 > if (unlikely.... > <--- > /* move the qp to the error state */ > void rxe_qp_error(struct rxe_qp *qp) > { > qp->req.state = QP_STATE_ERROR; > qp->resp.state = QP_STATE_ERROR; > qp->attr.qp_state = IB_QPS_ERR; > ---> > rxe_run_task(&qp->req.task, must_sched); > > > > It is more or less the same as without "if (unlikely..." Hello Leon, In the above the part of rxe_qp_error() that I was referring to in my e-mail is missing: if (qp_type(qp) == IB_QPT_RC) rxe_run_task(&qp->comp.task, 1); Bart.

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] patch "usb: misc: usb3503: make sure reset is low for at least 100us" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: misc: usb3503: make sure reset is low for at least 100us to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-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 b8626f1dc29d3eee444bfaa92146ec7b291ef41c Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Thu, 11 Jan 2018 14:47:40 +0100 Subject: usb: misc: usb3503: make sure reset is low for at least 100us When using a GPIO which is high by default, and initialize the driver in USB Hub mode, initialization fails with: [ 111.757794] usb3503 0-0008: SP_ILOCK failed (-5) The reason seems to be that the chip is not properly reset. Probe does initialize reset low, however some lines later the code already set it back high, which is not long enouth. Make sure reset is asserted for at least 100us by inserting a delay after initializing the reset pin during probe. Signed-off-by: Stefan Agner <stefan(a)agner.ch> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/usb3503.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c index 465dbf68b463..f723f7b8c9ac 100644 --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -279,6 +279,8 @@ static int usb3503_probe(struct usb3503 *hub) if (gpio_is_valid(hub->gpio_reset)) { err = devm_gpio_request_one(dev, hub->gpio_reset, GPIOF_OUT_INIT_LOW, "usb3503 reset"); + /* Datasheet defines a hardware reset to be at least 100us */ + usleep_range(100, 10000); if (err) { dev_err(dev, "unable to request GPIO %d as reset pin (%d)\n", -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH stable 3.18-4.9] xhci: Fix ring leak in failure path of xhci_alloc_virt_device()

by Ben Hutchings

This is a stable-only fix for the backport of commit 5d9b70f7d52e ("xhci: Don't add a virt_dev to the devs array before it's fully allocated"). In branches that predate commit c5628a2af83a ("xhci: remove endpoint ring cache") there is an additional failure path in xhci_alloc_virt_device() where ring cache allocation fails, in which case we need to free the ring allocated for endpoint 0. Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- This is build-tested only. Ben. drivers/usb/host/xhci-mem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index f7481c4e2bc9..d9363713b7f1 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1071,7 +1071,8 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id, return 1; fail: - + if (dev->eps[0].ring) + xhci_ring_free(xhci, dev->eps[0].ring); if (dev->in_ctx) xhci_free_container_ctx(xhci, dev->in_ctx); if (dev->out_ctx) -- 2.15.0.rc0

7 years, 5 months

3
3
0 0

[Linux-stable-mirror] patch "USB: serial: cp210x: add new device ID ELV ALC 8xxx" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: cp210x: add new device ID ELV ALC 8xxx to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-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 d14ac576d10f865970bb1324d337e5e24d79aaf4 Mon Sep 17 00:00:00 2001 From: Christian Holl <cyborgx1(a)gmail.com> Date: Wed, 3 Jan 2018 19:53:02 +0100 Subject: USB: serial: cp210x: add new device ID ELV ALC 8xxx This adds the ELV ALC 8xxx Battery Charging device to the list of USB IDs of drivers/usb/serial/cp210x.c Signed-off-by: Christian Holl <cyborgx1(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index 38814225a816..06d502b3e913 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -175,6 +175,7 @@ static const struct usb_device_id id_table[] = { { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */ { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */ { USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */ + { USB_DEVICE(0x18EF, 0xE030) }, /* ELV ALC 8xxx Battery Charger */ { USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */ { USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */ { USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */ -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] patch "USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-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 4307413256ac1e09b8f53e8715af3df9e49beec3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Diego=20Elio=20Petten=C3=B2?= <flameeyes(a)flameeyes.eu> Date: Fri, 29 Dec 2017 09:54:25 +0000 Subject: USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add IDs for the OneTouch Verio IQ that comes with an embedded USB-to-serial converter. Signed-off-by: Diego Elio Pettenò <flameeyes(a)flameeyes.eu> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index 7c6273bf5beb..38814225a816 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -124,6 +124,7 @@ static const struct usb_device_id id_table[] = { { USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System Console */ { USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */ { USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */ + { USB_DEVICE(0x10C4, 0x85A7) }, /* LifeScan OneTouch Verio IQ */ { USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */ { USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */ { USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */ -- 2.15.1

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] RDMA/rxe: Fix a race condition related to the QP error state

by Bart Van Assche

The following sequence: * Change queue pair state into IB_QPS_ERR. * Post a work request on the queue pair. Triggers the following race condition in the rdma_rxe driver: * rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function that examines the QP send queue. * rxe_post_send() posts a work request on the QP send queue. Avoid that this race causes a work request to be ignored by scheduling an rxe_completer() call from rxe_post_send() for queues that are in the error state. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Cc: <stable(a)vger.kernel.org> # v4.8 --- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c b/drivers/infiniband/sw/rxe/rxe_verbs.c index a6fbed48db8a..8f631d64c192 100644 --- a/drivers/infiniband/sw/rxe/rxe_verbs.c +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c @@ -814,6 +814,8 @@ static int rxe_post_send_kernel(struct rxe_qp *qp, struct ib_send_wr *wr, (queue_count(qp->sq.queue) > 1); rxe_run_task(&qp->req.task, must_sched); + if (unlikely(qp->req.state == QP_STATE_ERROR)) + rxe_run_task(&qp->comp.task, 1); return err; } -- 2.15.1

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] [PATCH v2] USB: core: Fix misuse of USB_DT_USB_SSP_CAP_SIZE()

by Masakazu Mokuno

As USB_DT_USB_SSP_CAP_SIZE() takes SSAC value as an argument, the low bound of the size for struct usb_ssp_cap_descriptor should be described by USB_DT_USB_SSP_CAP_SIZE(0), not by USB_DT_USB_SSP_CAP_SIZE(1) The type-specific length check patch was added to stable and needs to be fixed as well. Fixes: 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors") Cc: linux-stable <stable(a)vger.kernel.org> Cc: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Masakazu Mokuno <masakazu.mokuno(a)gmail.com> --- changes from v1: * Fixed untabified tabs in the patch drivers/usb/core/config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 78e92d2..33a3ab7 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -911,7 +911,7 @@ void usb_release_bos_descriptor(struct usb_device *dev) [USB_CAP_TYPE_WIRELESS_USB] = USB_DT_USB_WIRELESS_CAP_SIZE, [USB_CAP_TYPE_EXT] = USB_DT_USB_EXT_CAP_SIZE, [USB_SS_CAP_TYPE] = USB_DT_USB_SS_CAP_SIZE, - [USB_SSP_CAP_TYPE] = USB_DT_USB_SSP_CAP_SIZE(1), + [USB_SSP_CAP_TYPE] = USB_DT_USB_SSP_CAP_SIZE(0), [CONTAINER_ID_TYPE] = USB_DT_USB_SS_CONTN_ID_SIZE, [USB_PTM_CAP_TYPE] = USB_DT_USB_PTM_ID_SIZE, }; -- Masakazu Mokuno

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] RDMA/rxe: Fix a race condition related to the QP error state

by Bart Van Assche

On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote: > The proposed patch definitely decreases the chance of races, but it is not fixing them. > There is a chance to have change in qp state immediately after your "if ..." check. Hello Leon, Please have a look at rxe_qp_error() and you will see that the patch I posted is a proper fix. In the scenario you described rxe_qp_error() will trigger a run of rxe_completer(). Bart.

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] USB: core: Fix misuse of USB_DT_USB_SSP_CAP_SIZE()

by Masakazu Mokuno

As USB_DT_USB_SSP_CAP_SIZE() takes SSAC value as an argument, the low bound of the size for struct usb_ssp_cap_descriptor should be described by USB_DT_USB_SSP_CAP_SIZE(0), not by USB_DT_USB_SSP_CAP_SIZE(1) The type-specific length check patch was added to stable and needs to be fixed as well. Fixes: 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors") Cc: linux-stable <stable(a)vger.kernel.org> Cc: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Masakazu Mokuno <masakazu.mokuno(a)gmail.com> -- drivers/usb/core/config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 78e92d2..33a3ab7 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -911,7 +911,7 @@ void usb_release_bos_descriptor(struct usb_device *dev) [USB_CAP_TYPE_WIRELESS_USB] = USB_DT_USB_WIRELESS_CAP_SIZE, [USB_CAP_TYPE_EXT] = USB_DT_USB_EXT_CAP_SIZE, [USB_SS_CAP_TYPE] = USB_DT_USB_SS_CAP_SIZE, - [USB_SSP_CAP_TYPE] = USB_DT_USB_SSP_CAP_SIZE(1), + [USB_SSP_CAP_TYPE] = USB_DT_USB_SSP_CAP_SIZE(0), [CONTAINER_ID_TYPE] = USB_DT_USB_SS_CONTN_ID_SIZE, [USB_PTM_CAP_TYPE] = USB_DT_USB_PTM_ID_SIZE, }; -- Masakazu Mokuno

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] [PATCH] phy: work around 'phys' references to usb-phy devices

by Arnd Bergmann

Stefan Wahren reports a problem with a warning fix that was merged for v4.15: we had lots of device nodes with a 'phys' property pointing to a device node that is not compliant with the binding documented in Documentation/devicetree/bindings/phy/phy-bindings.txt This generally works because USB HCD drivers that support both the generic phy subsystem and the older usb-phy subsystem ignore most errors from phy_get() and related calls and then use the usb-phy driver instead. However, usb_add_hcd() (along with the respective functions in dwc2 and dwc3) propagate the EPROBE_DEFER return code so we can try again whenever the driver gets loaded. In case the driver is written for the usb-phy subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load a generic-phy driver for it, and keep failing here. There is only a small number of remaining usb-phy drivers that support device tree, so this adds a workaround by providing a full list of the potentially affected drivers, and always failing the probe with -ENODEV here, which is the same behavior that we used to get with incorrect device tree files. Since we generally want older kernels to also want to work with the fixed devicetree files, it would be good to backport the patch into stable kernels as well (3.13+ are possibly affected). Reverting back to the DTS sources that work would in theory fix USB support for now, but in the long run we'd run into the same problem again when the drivers get ported from usb-phy to generic-phy. Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells") Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2 Cc: stable(a)vger.kernel.org Cc: Stefan Wahren <stefan.wahren(a)i2se.com> Cc: Felipe Balbi <balbi(a)kernel.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- This obviously needs to be tested, I wrote this up as a reply to Stefan's bug report. I'm fairly sure that I covered all usb-phy driver strings here. My goal is to have a fix merged into 4.15 rather than reverting all the DT fixes. --- drivers/phy/phy-core.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c index b4964b067aec..bb4dd2a2de2d 100644 --- a/drivers/phy/phy-core.c +++ b/drivers/phy/phy-core.c @@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy) } EXPORT_SYMBOL_GPL(phy_calibrate); +static struct of_device_id __maybe_unused legacy_usbphy[] = { + { .compatible = "fsl,imx23-usbphy" }, + { .compatible = "fsl,imx6q-usbphy" }, + { .compatible = "fsl,imx6sl-usbphy" }, + { .compatible = "fsl,imx6sx-usbphy" }, + { .compatible = "fsl,imx6ul-usbphy" }, + { .compatible = "fsl,vf610-usbphy" }, + { .compatible = "nvidia,tegra20-usb-phy" }, + { .compatible = "nvidia,tegra30-usb-phy" }, + { .compatible = "nxp,isp1301" }, + { .compatible = "ti,am335x-usb-ctrl-module" }, + { .compatible = "ti,am335x-usb-phy" }, + { .compatible = "ti,keystone-usbphy" }, + { .compatible = "ti,twl6030-usb" }, + { .compatible = "usb-nop-xceiv" }, + {}, +}; + /** * _of_phy_get() - lookup and obtain a reference to a phy by phandle * @np: device_node for which to get the phy @@ -410,6 +428,15 @@ static struct phy *_of_phy_get(struct device_node *np, int index) if (ret) return ERR_PTR(-ENODEV); + /* + * Some USB host controllers use a "phys" property to refer to + * a device that does not have a generic phy driver but that + * has a driver for the older usb-phy framework. + * We must not return -EPROBE_DEFER for those, so bail out early. + */ + if (of_match_node(legacy_usbphy, args.np)) + return ERR_PTR(-ENODEV); + mutex_lock(&phy_provider_mutex); phy_provider = of_phy_provider_lookup(args.np); if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) { -- 2.9.0

7 years, 5 months

2
4
0 0

[Linux-stable-mirror] [PATCH 3.18] MIPS: Factor out NT_PRFPREG regset access helpers

by Maciej W. Rozycki

In preparation to fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") FCSR access regression factor out NT_PRFPREG regset access helpers for the non-MSA and the MSA variants respectively, to avoid having to deal with excessive indentation in the actual fix. No functional change, however use `target->thread.fpu.fpr[0]' rather than `target->thread.fpu.fpr[i]' for FGR holding type size determination as there's no `i' variable to refer to anymore, and for the factored out `i' variable declaration use `unsigned int' rather than `unsigned' as its type, following the common style. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: James Hogan <james.hogan(a)mips.com> Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Alex Smith <alex(a)alex-smith.me.uk> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17925/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> --- Hi, This is a (mechanically regenerated) version of commit a03fe72572c1 for 3.18-stable and before. No functional changes. Please apply. Maciej --- arch/mips/kernel/ptrace.c | 106 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 82 insertions(+), 24 deletions(-) linux-mips-nt-prfpreg-factor-out.diff Index: linux-stable-el/arch/mips/kernel/ptrace.c =================================================================== --- linux-stable-el.orig/arch/mips/kernel/ptrace.c 2018-01-10 18:16:16.000000000 +0000 +++ linux-stable-el/arch/mips/kernel/ptrace.c 2018-01-10 20:00:49.092601000 +0000 @@ -400,25 +400,36 @@ static int gpr64_set(struct task_struct #endif /* CONFIG_64BIT */ -static int fpr_get(struct task_struct *target, - const struct user_regset *regset, - unsigned int pos, unsigned int count, - void *kbuf, void __user *ubuf) +/* + * Copy the floating-point context to the supplied NT_PRFPREG buffer, + * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots + * correspond 1:1 to buffer slots. + */ +static int fpr_get_fpa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + void **kbuf, void __user **ubuf) { - unsigned i; - int err; - u64 fpr_val; - - /* XXX fcr31 */ + return user_regset_copyout(pos, count, kbuf, ubuf, + &target->thread.fpu, + 0, sizeof(elf_fpregset_t)); +} - if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t)) - return user_regset_copyout(&pos, &count, &kbuf, &ubuf, - &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); +/* + * Copy the floating-point context to the supplied NT_PRFPREG buffer, + * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's + * general register slots are copied to buffer slots. + */ +static int fpr_get_msa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + void **kbuf, void __user **ubuf) +{ + unsigned int i; + u64 fpr_val; + int err; for (i = 0; i < NUM_FPU_REGS; i++) { fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0); - err = user_regset_copyout(&pos, &count, &kbuf, &ubuf, + err = user_regset_copyout(pos, count, kbuf, ubuf, &fpr_val, i * sizeof(elf_fpreg_t), (i + 1) * sizeof(elf_fpreg_t)); if (err) @@ -428,25 +439,54 @@ static int fpr_get(struct task_struct *t return 0; } -static int fpr_set(struct task_struct *target, +/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */ +static int fpr_get(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, - const void *kbuf, const void __user *ubuf) + void *kbuf, void __user *ubuf) { - unsigned i; int err; - u64 fpr_val; /* XXX fcr31 */ - if (sizeof(target->thread.fpu.fpr[i]) == sizeof(elf_fpreg_t)) - return user_regset_copyin(&pos, &count, &kbuf, &ubuf, - &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); + if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) + err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf); + else + err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf); + + return err; +} + +/* + * Copy the supplied NT_PRFPREG buffer to the floating-point context, + * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP + * context's general register slots. + */ +static int fpr_set_fpa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + const void **kbuf, const void __user **ubuf) +{ + return user_regset_copyin(pos, count, kbuf, ubuf, + &target->thread.fpu, + 0, sizeof(elf_fpregset_t)); +} + +/* + * Copy the supplied NT_PRFPREG buffer to the floating-point context, + * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64 + * bits only of FP context's general register slots. + */ +static int fpr_set_msa(struct task_struct *target, + unsigned int *pos, unsigned int *count, + const void **kbuf, const void __user **ubuf) +{ + unsigned int i; + u64 fpr_val; + int err; BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t)); - for (i = 0; i < NUM_FPU_REGS && count >= sizeof(elf_fpreg_t); i++) { - err = user_regset_copyin(&pos, &count, &kbuf, &ubuf, + for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) { + err = user_regset_copyin(pos, count, kbuf, ubuf, &fpr_val, i * sizeof(elf_fpreg_t), (i + 1) * sizeof(elf_fpreg_t)); if (err) @@ -457,6 +497,24 @@ static int fpr_set(struct task_struct *t return 0; } +/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */ +static int fpr_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int err; + + /* XXX fcr31 */ + + if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) + err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf); + else + err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf); + + return err; +} + enum mips_regset { REGSET_GPR, REGSET_FPR,

7 years, 5 months

2
2
0 0

[Linux-stable-mirror] Patch "lan78xx: use skb_cow_head() to deal with cloned skbs" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lan78xx: use skb_cow_head() to deal with cloned skbs to the 4.9-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: lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.9 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 d4ca73591916b760478d2b04334d5dcadc028e9c Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:24 -0700 Subject: lan78xx: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit d4ca73591916b760478d2b04334d5dcadc028e9c upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Cc: Woojung Huh <woojung.huh(a)microchip.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/lan78xx.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -2419,14 +2419,9 @@ static struct sk_buff *lan78xx_tx_prep(s { u32 tx_cmd_a, tx_cmd_b; - if (skb_headroom(skb) < TX_OVERHEAD) { - struct sk_buff *skb2; - - skb2 = skb_copy_expand(skb, TX_OVERHEAD, 0, flags); + if (skb_cow_head(skb, TX_OVERHEAD)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } if (lan78xx_linearize(skb) < 0) Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "smsc75xx: use skb_cow_head() to deal with cloned skbs" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled smsc75xx: use skb_cow_head() to deal with cloned skbs to the 4.9-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: smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.9 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 b7c6d2675899cfff0180412c63fc9cbd5bacdb4d Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:21 -0700 Subject: smsc75xx: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit b7c6d2675899cfff0180412c63fc9cbd5bacdb4d upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/smsc75xx.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) --- a/drivers/net/usb/smsc75xx.c +++ b/drivers/net/usb/smsc75xx.c @@ -2205,13 +2205,9 @@ static struct sk_buff *smsc75xx_tx_fixup { u32 tx_cmd_a, tx_cmd_b; - if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) { - struct sk_buff *skb2 = - skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags); + if (skb_cow_head(skb, SMSC75XX_TX_OVERHEAD)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } tx_cmd_a = (u32)(skb->len & TX_CMD_A_LEN) | TX_CMD_A_FCS; Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sr9700: use skb_cow_head() to deal with cloned skbs" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sr9700: use skb_cow_head() to deal with cloned skbs to the 4.9-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: sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.9 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 d532c1082f68176363ed766d09bf187616e282fe Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:23 -0700 Subject: sr9700: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit d532c1082f68176363ed766d09bf187616e282fe upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/sr9700.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/drivers/net/usb/sr9700.c +++ b/drivers/net/usb/sr9700.c @@ -456,14 +456,9 @@ static struct sk_buff *sr9700_tx_fixup(s len = skb->len; - if (skb_headroom(skb) < SR_TX_OVERHEAD) { - struct sk_buff *skb2; - - skb2 = skb_copy_expand(skb, SR_TX_OVERHEAD, 0, flags); + if (skb_cow_head(skb, SR_TX_OVERHEAD)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } __skb_push(skb, SR_TX_OVERHEAD); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "cx82310_eth: use skb_cow_head() to deal with cloned skbs" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cx82310_eth: use skb_cow_head() to deal with cloned skbs to the 4.9-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: cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.9 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 a9e840a2081ed28c2b7caa6a9a0041c950b3c37d Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:22 -0700 Subject: cx82310_eth: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit a9e840a2081ed28c2b7caa6a9a0041c950b3c37d upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cx82310_eth.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/drivers/net/usb/cx82310_eth.c +++ b/drivers/net/usb/cx82310_eth.c @@ -293,12 +293,9 @@ static struct sk_buff *cx82310_tx_fixup( { int len = skb->len; - if (skb_headroom(skb) < 2) { - struct sk_buff *skb2 = skb_copy_expand(skb, 2, 0, flags); + if (skb_cow_head(skb, 2)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } skb_push(skb, 2); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/mm/pat, /dev/mem: Remove superfluous error message" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm/pat, /dev/mem: Remove superfluous error message to the 4.4-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: x86-mm-pat-dev-mem-remove-superfluous-error-message.patch and it can be found in the queue-4.4 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 39380b80d72723282f0ea1d1bbf2294eae45013e Mon Sep 17 00:00:00 2001 From: Jiri Kosina <jkosina(a)suse.cz> Date: Fri, 8 Jul 2016 11:38:28 +0200 Subject: x86/mm/pat, /dev/mem: Remove superfluous error message From: Jiri Kosina <jkosina(a)suse.cz> commit 39380b80d72723282f0ea1d1bbf2294eae45013e upstream. Currently it's possible for broken (or malicious) userspace to flood a kernel log indefinitely with messages a-la Program dmidecode tried to access /dev/mem between f0000->100000 because range_is_allowed() is case of CONFIG_STRICT_DEVMEM being turned on dumps this information each and every time devmem_is_allowed() fails. Reportedly userspace that is able to trigger contignuous flow of these messages exists. It would be possible to rate limit this message, but that'd have a questionable value; the administrator wouldn't get information about all the failing accessess, so then the information would be both superfluous and incomplete at the same time :) Returning EPERM (which is what is actually happening) is enough indication for userspace what has happened; no need to log this particular error as some sort of special condition. Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Kees Cook <keescook(a)chromium.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof(a)suse.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Toshi Kani <toshi.kani(a)hp.com> Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1607081137020.24757@cbobk.fhfr.pm Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/pat.c | 5 +---- drivers/char/mem.c | 6 +----- 2 files changed, 2 insertions(+), 9 deletions(-) --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -750,11 +750,8 @@ static inline int range_is_allowed(unsig return 1; while (cursor < to) { - if (!devmem_is_allowed(pfn)) { - pr_info("x86/PAT: Program %s tried to access /dev/mem between [mem %#010Lx-%#010Lx], PAT prevents it\n", - current->comm, from, to - 1); + if (!devmem_is_allowed(pfn)) return 0; - } cursor += PAGE_SIZE; pfn++; } --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -70,12 +70,8 @@ static inline int range_is_allowed(unsig u64 cursor = from; while (cursor < to) { - if (!devmem_is_allowed(pfn)) { - printk(KERN_INFO - "Program %s tried to access /dev/mem between %Lx->%Lx.\n", - current->comm, from, to); + if (!devmem_is_allowed(pfn)) return 0; - } cursor += PAGE_SIZE; pfn++; } Patches currently in stable-queue which might be from jkosina(a)suse.cz are queue-4.4/x86-mm-pat-dev-mem-remove-superfluous-error-message.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] usbvision fix overflow of interfaces array" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] usbvision fix overflow of interfaces array to the 4.4-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: usbvision-fix-overflow-of-interfaces-array.patch and it can be found in the queue-4.4 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 588afcc1c0e45358159090d95bf7b246fb67565f Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Tue, 27 Oct 2015 09:51:34 -0200 Subject: [media] usbvision fix overflow of interfaces array From: Oliver Neukum <oneukum(a)suse.com> commit 588afcc1c0e45358159090d95bf7b246fb67565f upstream. This fixes the crash reported in: http://seclists.org/bugtraq/2015/Oct/35 The interface number needs a sanity check. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Cc: Vladis Dronov <vdronov(a)redhat.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/usbvision/usbvision-video.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/media/usb/usbvision/usbvision-video.c +++ b/drivers/media/usb/usbvision/usbvision-video.c @@ -1461,6 +1461,13 @@ static int usbvision_probe(struct usb_in printk(KERN_INFO "%s: %s found\n", __func__, usbvision_device_data[model].model_string); + /* + * this is a security check. + * an exploit using an incorrect bInterfaceNumber is known + */ + if (ifnum >= USB_MAXINTERFACES || !dev->actconfig->interface[ifnum]) + return -ENODEV; + if (usbvision_device_data[model].interface >= 0) interface = &dev->actconfig->interface[usbvision_device_data[model].interface]->altsetting[0]; else if (ifnum < dev->actconfig->desc.bNumInterfaces) Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/r8152-fix-the-wake-event.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/r8152-adjust-aldps-function.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/usbvision-fix-overflow-of-interfaces-array.patch queue-4.4/r8152-use-test_and_clear_bit.patch queue-4.4/usb-musb-ux500-fix-null-pointer-dereference-at-system-pm.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sysrq: Fix warning in sysrq generated crash." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sysrq: Fix warning in sysrq generated crash. to the 4.4-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: sysrq-fix-warning-in-sysrq-generated-crash.patch and it can be found in the queue-4.4 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 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b Mon Sep 17 00:00:00 2001 From: Ani Sinha <ani(a)arista.com> Date: Thu, 17 Dec 2015 17:15:10 -0800 Subject: sysrq: Fix warning in sysrq generated crash. From: Ani Sinha <ani(a)arista.com> commit 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b upstream. Commit 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") replaced spin_lock_irqsave() calls with rcu_read_lock() calls in sysrq. Since rcu_read_lock() does not disable preemption, faulthandler_disabled() in __do_page_fault() in x86/fault.c returns false. When the code later calls might_sleep() in the pagefault handler, we get the following warning: BUG: sleeping function called from invalid context at ../arch/x86/mm/fault.c:1187 in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash Preemption disabled at:[<ffffffff81484339>] printk+0x48/0x4a To fix this, we release the RCU read lock before we crash. Tested this patch on linux 3.18 by booting off one of our boards. Fixes: 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") Signed-off-by: Ani Sinha <ani(a)arista.com> Reviewed-by: Rik van Riel <riel(a)redhat.com> Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/sysrq.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/tty/sysrq.c +++ b/drivers/tty/sysrq.c @@ -133,6 +133,12 @@ static void sysrq_handle_crash(int key) { char *killer = NULL; + /* we need to release the RCU read lock here, + * otherwise we get an annoying + * 'BUG: sleeping function called from invalid context' + * complaint from the kernel before the panic. + */ + rcu_read_unlock(); panic_on_oops = 1; /* force panic */ wmb(); *killer = 1; Patches currently in stable-queue which might be from ani(a)arista.com are queue-4.4/sysrq-fix-warning-in-sysrq-generated-crash.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: ux500: Fix NULL pointer dereference at system PM" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: ux500: Fix NULL pointer dereference at system PM to the 4.4-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: usb-musb-ux500-fix-null-pointer-dereference-at-system-pm.patch and it can be found in the queue-4.4 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 79c5623f1cb85f33403eb9f1e45124e9f56181f8 Mon Sep 17 00:00:00 2001 From: Ulf Hansson <ulf.hansson(a)linaro.org> Date: Mon, 25 Jan 2016 13:01:29 +0100 Subject: usb: musb: ux500: Fix NULL pointer dereference at system PM From: Ulf Hansson <ulf.hansson(a)linaro.org> commit 79c5623f1cb85f33403eb9f1e45124e9f56181f8 upstream. The commit 7d32cdef5356 ("usb: musb: fail with error when no DMA controller set"), caused the core platform driver to correctly return an error code when fail probing. Unfurtante it also caused bug for a NULL pointer dereference, during system suspend for the ux500 driver. The reason is a lacking validation of the corresponding ->driver_data pointer, which won't be set when the musb core driver fails to probe (or haven't yet been probed). Fixes: 7d32cdef5356 ("usb: musb: fail with error when no DMA...") Acked-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Felipe Balbi <balbi(a)kernel.org> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/ux500.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/musb/ux500.c +++ b/drivers/usb/musb/ux500.c @@ -348,7 +348,9 @@ static int ux500_suspend(struct device * struct ux500_glue *glue = dev_get_drvdata(dev); struct musb *musb = glue_to_musb(glue); - usb_phy_set_suspend(musb->xceiv, 1); + if (musb) + usb_phy_set_suspend(musb->xceiv, 1); + clk_disable_unprepare(glue->clk); return 0; @@ -366,7 +368,8 @@ static int ux500_resume(struct device *d return ret; } - usb_phy_set_suspend(musb->xceiv, 0); + if (musb) + usb_phy_set_suspend(musb->xceiv, 0); return 0; } Patches currently in stable-queue which might be from ulf.hansson(a)linaro.org are queue-4.4/usb-musb-ux500-fix-null-pointer-dereference-at-system-pm.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "smsc75xx: use skb_cow_head() to deal with cloned skbs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled smsc75xx: use skb_cow_head() to deal with cloned skbs to the 4.4-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: smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.4 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 b7c6d2675899cfff0180412c63fc9cbd5bacdb4d Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:21 -0700 Subject: smsc75xx: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit b7c6d2675899cfff0180412c63fc9cbd5bacdb4d upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/smsc75xx.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) --- a/drivers/net/usb/smsc75xx.c +++ b/drivers/net/usb/smsc75xx.c @@ -2193,13 +2193,9 @@ static struct sk_buff *smsc75xx_tx_fixup { u32 tx_cmd_a, tx_cmd_b; - if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) { - struct sk_buff *skb2 = - skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags); + if (skb_cow_head(skb, SMSC75XX_TX_OVERHEAD)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } tx_cmd_a = (u32)(skb->len & TX_CMD_A_LEN) | TX_CMD_A_FCS; Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sr9700: use skb_cow_head() to deal with cloned skbs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sr9700: use skb_cow_head() to deal with cloned skbs to the 4.4-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: sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.4 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 d532c1082f68176363ed766d09bf187616e282fe Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:23 -0700 Subject: sr9700: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit d532c1082f68176363ed766d09bf187616e282fe upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/sr9700.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/drivers/net/usb/sr9700.c +++ b/drivers/net/usb/sr9700.c @@ -456,14 +456,9 @@ static struct sk_buff *sr9700_tx_fixup(s len = skb->len; - if (skb_headroom(skb) < SR_TX_OVERHEAD) { - struct sk_buff *skb2; - - skb2 = skb_copy_expand(skb, SR_TX_OVERHEAD, 0, flags); + if (skb_cow_head(skb, SR_TX_OVERHEAD)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } __skb_push(skb, SR_TX_OVERHEAD); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "r8152: fix the wake event" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled r8152: fix the wake event to the 4.4-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: r8152-fix-the-wake-event.patch and it can be found in the queue-4.4 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 5ee3c60c8d3b88cab6496c9b7d49a01576dd9cf9 Mon Sep 17 00:00:00 2001 From: hayeswang <hayeswang(a)realtek.com> Date: Thu, 7 Jan 2016 17:12:17 +0800 Subject: r8152: fix the wake event From: hayeswang <hayeswang(a)realtek.com> commit 5ee3c60c8d3b88cab6496c9b7d49a01576dd9cf9 upstream. When the autosuspend is enabled and occurs before system suspend, we should wake the device before running system syspend. Then, we could change the wake event for system suspend. Otherwise, the device would resume the system when receiving any packet. Signed-off-by: Hayes Wang <hayeswang(a)realtek.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/r8152.c | 40 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -25,12 +25,13 @@ #include <uapi/linux/mdio.h> #include <linux/mdio.h> #include <linux/usb/cdc.h> +#include <linux/suspend.h> /* Information for net-next */ #define NETNEXT_VERSION "08" /* Information for net */ -#define NET_VERSION "2" +#define NET_VERSION "3" #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION #define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd(a)realtek.com>" @@ -604,6 +605,9 @@ struct r8152 { struct delayed_work schedule; struct mii_if_info mii; struct mutex control; /* use for hw setting */ +#ifdef CONFIG_PM_SLEEP + struct notifier_block pm_notifier; +#endif struct rtl_ops { void (*init)(struct r8152 *); @@ -3060,6 +3064,33 @@ out1: usb_autopm_put_interface(tp->intf); } +#ifdef CONFIG_PM_SLEEP +static int rtl_notifier(struct notifier_block *nb, unsigned long action, + void *data) +{ + struct r8152 *tp = container_of(nb, struct r8152, pm_notifier); + + switch (action) { + case PM_HIBERNATION_PREPARE: + case PM_SUSPEND_PREPARE: + usb_autopm_get_interface(tp->intf); + break; + + case PM_POST_HIBERNATION: + case PM_POST_SUSPEND: + usb_autopm_put_interface(tp->intf); + break; + + case PM_POST_RESTORE: + case PM_RESTORE_PREPARE: + default: + break; + } + + return NOTIFY_DONE; +} +#endif + static int rtl8152_open(struct net_device *netdev) { struct r8152 *tp = netdev_priv(netdev); @@ -3102,6 +3133,10 @@ static int rtl8152_open(struct net_devic mutex_unlock(&tp->control); usb_autopm_put_interface(tp->intf); +#ifdef CONFIG_PM_SLEEP + tp->pm_notifier.notifier_call = rtl_notifier; + register_pm_notifier(&tp->pm_notifier); +#endif out: return res; @@ -3112,6 +3147,9 @@ static int rtl8152_close(struct net_devi struct r8152 *tp = netdev_priv(netdev); int res = 0; +#ifdef CONFIG_PM_SLEEP + unregister_pm_notifier(&tp->pm_notifier); +#endif napi_disable(&tp->napi); clear_bit(WORK_ENABLE, &tp->flags); usb_kill_urb(tp->intr_urb); Patches currently in stable-queue which might be from hayeswang(a)realtek.com are queue-4.4/r8152-fix-the-wake-event.patch queue-4.4/r8152-adjust-aldps-function.patch queue-4.4/r8152-use-test_and_clear_bit.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "r8152: adjust ALDPS function" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled r8152: adjust ALDPS function to the 4.4-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: r8152-adjust-aldps-function.patch and it can be found in the queue-4.4 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 cda9fb01dc3cafd718b2865b447e869bf6624ddd Mon Sep 17 00:00:00 2001 From: hayeswang <hayeswang(a)realtek.com> Date: Thu, 7 Jan 2016 17:51:12 +0800 Subject: r8152: adjust ALDPS function From: hayeswang <hayeswang(a)realtek.com> commit cda9fb01dc3cafd718b2865b447e869bf6624ddd upstream. Replace disable_aldps() and enable_aldps() with aldps_en(). Signed-off-by: Hayes Wang <hayeswang(a)realtek.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/r8152.c | 72 ++++++++++++++++++++++-------------------------- 1 file changed, 34 insertions(+), 38 deletions(-) --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -2461,23 +2461,23 @@ static void r8153_teredo_off(struct r815 ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0); } -static void r8152b_disable_aldps(struct r8152 *tp) +static void r8152_aldps_en(struct r8152 *tp, bool enable) { - ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPDNPS | LINKENA | DIS_SDSAVE); - msleep(20); -} - -static inline void r8152b_enable_aldps(struct r8152 *tp) -{ - ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPWRSAVE | ENPDNPS | - LINKENA | DIS_SDSAVE); + if (enable) { + ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPWRSAVE | ENPDNPS | + LINKENA | DIS_SDSAVE); + } else { + ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPDNPS | LINKENA | + DIS_SDSAVE); + msleep(20); + } } static void rtl8152_disable(struct r8152 *tp) { - r8152b_disable_aldps(tp); + r8152_aldps_en(tp, false); rtl_disable(tp); - r8152b_enable_aldps(tp); + r8152_aldps_en(tp, true); } static void r8152b_hw_phy_cfg(struct r8152 *tp) @@ -2789,30 +2789,26 @@ static void r8153_enter_oob(struct r8152 ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data); } -static void r8153_disable_aldps(struct r8152 *tp) +static void r8153_aldps_en(struct r8152 *tp, bool enable) { u16 data; data = ocp_reg_read(tp, OCP_POWER_CFG); - data &= ~EN_ALDPS; - ocp_reg_write(tp, OCP_POWER_CFG, data); - msleep(20); -} - -static void r8153_enable_aldps(struct r8152 *tp) -{ - u16 data; - - data = ocp_reg_read(tp, OCP_POWER_CFG); - data |= EN_ALDPS; - ocp_reg_write(tp, OCP_POWER_CFG, data); + if (enable) { + data |= EN_ALDPS; + ocp_reg_write(tp, OCP_POWER_CFG, data); + } else { + data &= ~EN_ALDPS; + ocp_reg_write(tp, OCP_POWER_CFG, data); + msleep(20); + } } static void rtl8153_disable(struct r8152 *tp) { - r8153_disable_aldps(tp); + r8153_aldps_en(tp, false); rtl_disable(tp); - r8153_enable_aldps(tp); + r8153_aldps_en(tp, true); usb_enable_lpm(tp->udev); } @@ -2909,9 +2905,9 @@ static void rtl8152_up(struct r8152 *tp) if (test_bit(RTL8152_UNPLUG, &tp->flags)) return; - r8152b_disable_aldps(tp); + r8152_aldps_en(tp, false); r8152b_exit_oob(tp); - r8152b_enable_aldps(tp); + r8152_aldps_en(tp, true); } static void rtl8152_down(struct r8152 *tp) @@ -2922,9 +2918,9 @@ static void rtl8152_down(struct r8152 *t } r8152_power_cut_en(tp, false); - r8152b_disable_aldps(tp); + r8152_aldps_en(tp, false); r8152b_enter_oob(tp); - r8152b_enable_aldps(tp); + r8152_aldps_en(tp, true); } static void rtl8153_up(struct r8152 *tp) @@ -2933,9 +2929,9 @@ static void rtl8153_up(struct r8152 *tp) return; r8153_u1u2en(tp, false); - r8153_disable_aldps(tp); + r8153_aldps_en(tp, false); r8153_first_init(tp); - r8153_enable_aldps(tp); + r8153_aldps_en(tp, true); r8153_u2p3en(tp, true); r8153_u1u2en(tp, true); usb_enable_lpm(tp->udev); @@ -2951,9 +2947,9 @@ static void rtl8153_down(struct r8152 *t r8153_u1u2en(tp, false); r8153_u2p3en(tp, false); r8153_power_cut_en(tp, false); - r8153_disable_aldps(tp); + r8153_aldps_en(tp, false); r8153_enter_oob(tp); - r8153_enable_aldps(tp); + r8153_aldps_en(tp, true); } static bool rtl8152_in_nway(struct r8152 *tp) @@ -3280,7 +3276,7 @@ static void r8152b_init(struct r8152 *tp if (test_bit(RTL8152_UNPLUG, &tp->flags)) return; - r8152b_disable_aldps(tp); + r8152_aldps_en(tp, false); if (tp->version == RTL_VER_01) { ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE); @@ -3302,7 +3298,7 @@ static void r8152b_init(struct r8152 *tp ocp_write_word(tp, MCU_TYPE_PLA, PLA_GPHY_INTR_IMR, ocp_data); r8152b_enable_eee(tp); - r8152b_enable_aldps(tp); + r8152_aldps_en(tp, true); r8152b_enable_fc(tp); rtl_tally_reset(tp); @@ -3320,7 +3316,7 @@ static void r8153_init(struct r8152 *tp) if (test_bit(RTL8152_UNPLUG, &tp->flags)) return; - r8153_disable_aldps(tp); + r8153_aldps_en(tp, false); r8153_u1u2en(tp, false); for (i = 0; i < 500; i++) { @@ -3409,7 +3405,7 @@ static void r8153_init(struct r8152 *tp) EEE_SPDWN_EN); r8153_enable_eee(tp); - r8153_enable_aldps(tp); + r8153_aldps_en(tp, true); r8152b_enable_fc(tp); rtl_tally_reset(tp); r8153_u2p3en(tp, true); Patches currently in stable-queue which might be from hayeswang(a)realtek.com are queue-4.4/r8152-fix-the-wake-event.patch queue-4.4/r8152-adjust-aldps-function.patch queue-4.4/r8152-use-test_and_clear_bit.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "r8152: use test_and_clear_bit" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled r8152: use test_and_clear_bit to the 4.4-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: r8152-use-test_and_clear_bit.patch and it can be found in the queue-4.4 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 216a8349d3a0dd1bc2afbcc821e374c8f929bd62 Mon Sep 17 00:00:00 2001 From: hayeswang <hayeswang(a)realtek.com> Date: Thu, 7 Jan 2016 17:51:11 +0800 Subject: r8152: use test_and_clear_bit From: hayeswang <hayeswang(a)realtek.com> commit 216a8349d3a0dd1bc2afbcc821e374c8f929bd62 upstream. Replace test_bit() followed by clear_bit() with test_and_clear_bit(). Signed-off-by: Hayes Wang <hayeswang(a)realtek.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/r8152.c | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1947,7 +1947,6 @@ static void _rtl8152_set_rx_mode(struct __le32 tmp[2]; u32 ocp_data; - clear_bit(RTL8152_SET_RX_MODE, &tp->flags); netif_stop_queue(netdev); ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR); ocp_data &= ~RCR_ACPT_ALL; @@ -2433,8 +2432,6 @@ static void rtl_phy_reset(struct r8152 * u16 data; int i; - clear_bit(PHY_RESET, &tp->flags); - data = r8152_mdio_read(tp, MII_BMCR); /* don't reset again before the previous one complete */ @@ -2893,10 +2890,9 @@ static int rtl8152_set_speed(struct r815 r8152_mdio_write(tp, MII_ADVERTISE, anar); r8152_mdio_write(tp, MII_BMCR, bmcr); - if (test_bit(PHY_RESET, &tp->flags)) { + if (test_and_clear_bit(PHY_RESET, &tp->flags)) { int i; - clear_bit(PHY_RESET, &tp->flags); for (i = 0; i < 50; i++) { msleep(20); if ((r8152_mdio_read(tp, MII_BMCR) & BMCR_RESET) == 0) @@ -2905,7 +2901,6 @@ static int rtl8152_set_speed(struct r815 } out: - return ret; } @@ -2992,7 +2987,6 @@ static void set_carrier(struct r8152 *tp struct net_device *netdev = tp->netdev; u8 speed; - clear_bit(RTL8152_LINK_CHG, &tp->flags); speed = rtl8152_get_speed(tp); if (speed & LINK_STATUS) { @@ -3042,20 +3036,18 @@ static void rtl_work_func_t(struct work_ goto out1; } - if (test_bit(RTL8152_LINK_CHG, &tp->flags)) + if (test_and_clear_bit(RTL8152_LINK_CHG, &tp->flags)) set_carrier(tp); - if (test_bit(RTL8152_SET_RX_MODE, &tp->flags)) + if (test_and_clear_bit(RTL8152_SET_RX_MODE, &tp->flags)) _rtl8152_set_rx_mode(tp->netdev); /* don't schedule napi before linking */ - if (test_bit(SCHEDULE_NAPI, &tp->flags) && - netif_carrier_ok(tp->netdev)) { - clear_bit(SCHEDULE_NAPI, &tp->flags); + if (test_and_clear_bit(SCHEDULE_NAPI, &tp->flags) && + netif_carrier_ok(tp->netdev)) napi_schedule(&tp->napi); - } - if (test_bit(PHY_RESET, &tp->flags)) + if (test_and_clear_bit(PHY_RESET, &tp->flags)) rtl_phy_reset(tp); mutex_unlock(&tp->control); Patches currently in stable-queue which might be from hayeswang(a)realtek.com are queue-4.4/r8152-fix-the-wake-event.patch queue-4.4/r8152-adjust-aldps-function.patch queue-4.4/r8152-use-test_and_clear_bit.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "lan78xx: use skb_cow_head() to deal with cloned skbs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lan78xx: use skb_cow_head() to deal with cloned skbs to the 4.4-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: lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.4 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 d4ca73591916b760478d2b04334d5dcadc028e9c Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:24 -0700 Subject: lan78xx: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit d4ca73591916b760478d2b04334d5dcadc028e9c upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Cc: Woojung Huh <woojung.huh(a)microchip.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/lan78xx.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -2050,14 +2050,9 @@ static struct sk_buff *lan78xx_tx_prep(s { u32 tx_cmd_a, tx_cmd_b; - if (skb_headroom(skb) < TX_OVERHEAD) { - struct sk_buff *skb2; - - skb2 = skb_copy_expand(skb, TX_OVERHEAD, 0, flags); + if (skb_cow_head(skb, TX_OVERHEAD)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } if (lan78xx_linearize(skb) < 0) Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "hwrng: core - sleep interruptible in read" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwrng: core - sleep interruptible in read to the 4.4-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: hwrng-core-sleep-interruptible-in-read.patch and it can be found in the queue-4.4 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 1ab87298cb59b649d8d648d25dc15b36ab865f5a Mon Sep 17 00:00:00 2001 From: Jiri Slaby <jslaby(a)suse.cz> Date: Fri, 27 Nov 2015 16:50:43 +0100 Subject: hwrng: core - sleep interruptible in read From: Jiri Slaby <jslaby(a)suse.cz> commit 1ab87298cb59b649d8d648d25dc15b36ab865f5a upstream. hwrng kthread can be waiting via hwrng_fillfn for some data from a rng like virtio-rng: hwrng D ffff880093e17798 0 382 2 0x00000000 ... Call Trace: [<ffffffff817339c6>] wait_for_completion_killable+0x96/0x210 [<ffffffffa00aa1b7>] virtio_read+0x57/0xf0 [virtio_rng] [<ffffffff814f4a35>] hwrng_fillfn+0x75/0x130 [<ffffffff810aa243>] kthread+0xf3/0x110 And when some user program tries to read the /dev node in this state, we get: rngd D ffff880093e17798 0 762 1 0x00000004 ... Call Trace: [<ffffffff817351ac>] mutex_lock_nested+0x15c/0x3e0 [<ffffffff814f478e>] rng_dev_read+0x6e/0x240 [<ffffffff81231958>] __vfs_read+0x28/0xe0 [<ffffffff81232393>] vfs_read+0x83/0x130 And this is indeed unkillable. So use mutex_lock_interruptible instead of mutex_lock in rng_dev_read and exit immediatelly when interrupted. And possibly return already read data, if any (as POSIX allows). v2: use ERESTARTSYS instead of EINTR Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Matt Mackall <mpm(a)selenic.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: <linux-crypto(a)vger.kernel.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/hw_random/core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@ -238,7 +238,10 @@ static ssize_t rng_dev_read(struct file goto out; } - mutex_lock(&reading_mutex); + if (mutex_lock_interruptible(&reading_mutex)) { + err = -ERESTARTSYS; + goto out_put; + } if (!data_avail) { bytes_read = rng_get_data(rng, rng_buffer, rng_buffer_size(), @@ -288,6 +291,7 @@ out: out_unlock_reading: mutex_unlock(&reading_mutex); +out_put: put_rng(rng); goto out; } Patches currently in stable-queue which might be from jslaby(a)suse.cz are queue-4.4/hwrng-core-sleep-interruptible-in-read.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "cx82310_eth: use skb_cow_head() to deal with cloned skbs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cx82310_eth: use skb_cow_head() to deal with cloned skbs to the 4.4-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: cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch and it can be found in the queue-4.4 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 a9e840a2081ed28c2b7caa6a9a0041c950b3c37d Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 19 Apr 2017 09:59:22 -0700 Subject: cx82310_eth: use skb_cow_head() to deal with cloned skbs From: Eric Dumazet <edumazet(a)google.com> commit a9e840a2081ed28c2b7caa6a9a0041c950b3c37d upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: James Hughes <james.hughes(a)raspberrypi.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cx82310_eth.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/drivers/net/usb/cx82310_eth.c +++ b/drivers/net/usb/cx82310_eth.c @@ -293,12 +293,9 @@ static struct sk_buff *cx82310_tx_fixup( { int len = skb->len; - if (skb_headroom(skb) < 2) { - struct sk_buff *skb2 = skb_copy_expand(skb, 2, 0, flags); + if (skb_cow_head(skb, 2)) { dev_kfree_skb_any(skb); - skb = skb2; - if (!skb) - return NULL; + return NULL; } skb_push(skb, 2); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch queue-4.4/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "zswap: don't param_set_charp while holding spinlock" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled zswap: don't param_set_charp while holding spinlock to the 4.9-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: zswap-don-t-param_set_charp-while-holding-spinlock.patch and it can be found in the queue-4.9 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 fd5bb66cd934987e49557455b6497fc006521940 Mon Sep 17 00:00:00 2001 From: Dan Streetman <ddstreet(a)ieee.org> Date: Mon, 27 Feb 2017 14:26:53 -0800 Subject: zswap: don't param_set_charp while holding spinlock From: Dan Streetman <ddstreet(a)ieee.org> commit fd5bb66cd934987e49557455b6497fc006521940 upstream. Change the zpool/compressor param callback function to release the zswap_pools_lock spinlock before calling param_set_charp, since that function may sleep when it calls kmalloc with GFP_KERNEL. While this problem has existed for a while, I wasn't able to trigger it using a tight loop changing either/both the zpool and compressor params; I think it's very unlikely to be an issue on the stable kernels, especially since most zswap users will change the compressor and/or zpool from sysfs only one time each boot - or zero times, if they add the params to the kernel boot. Fixes: c99b42c3529e ("zswap: use charp for zswap param strings") Link: http://lkml.kernel.org/r/20170126155821.4545-1-ddstreet@ieee.org Signed-off-by: Dan Streetman <dan.streetman(a)canonical.com> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/zswap.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/mm/zswap.c +++ b/mm/zswap.c @@ -752,18 +752,22 @@ static int __zswap_param_set(const char pool = zswap_pool_find_get(type, compressor); if (pool) { zswap_pool_debug("using existing", pool); + WARN_ON(pool == zswap_pool_current()); list_del_rcu(&pool->list); - } else { - spin_unlock(&zswap_pools_lock); - pool = zswap_pool_create(type, compressor); - spin_lock(&zswap_pools_lock); } + spin_unlock(&zswap_pools_lock); + + if (!pool) + pool = zswap_pool_create(type, compressor); + if (pool) ret = param_set_charp(s, kp); else ret = -EINVAL; + spin_lock(&zswap_pools_lock); + if (!ret) { put_pool = zswap_pool_current(); list_add_rcu(&pool->list, &zswap_pools); Patches currently in stable-queue which might be from ddstreet(a)ieee.org are queue-4.9/zswap-don-t-param_set_charp-while-holding-spinlock.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mm/zswap: use workqueue to destroy pool" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm/zswap: use workqueue to destroy pool to the 4.4-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: mm-zswap-use-workqueue-to-destroy-pool.patch and it can be found in the queue-4.4 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 200867af4dedfe7cb707f96773684de1d1fd21e6 Mon Sep 17 00:00:00 2001 From: Dan Streetman <ddstreet(a)ieee.org> Date: Fri, 20 May 2016 16:59:54 -0700 Subject: mm/zswap: use workqueue to destroy pool From: Dan Streetman <ddstreet(a)ieee.org> commit 200867af4dedfe7cb707f96773684de1d1fd21e6 upstream. Add a work_struct to struct zswap_pool, and change __zswap_pool_empty to use the workqueue instead of using call_rcu(). When zswap destroys a pool no longer in use, it uses call_rcu() to perform the destruction/freeing. Since that executes in softirq context, it must not sleep. However, actually destroying the pool involves freeing the per-cpu compressors (which requires locking the cpu_add_remove_lock mutex) and freeing the zpool, for which the implementation may sleep (e.g. zsmalloc calls kmem_cache_destroy, which locks the slab_mutex). So if either mutex is currently taken, or any other part of the compressor or zpool implementation sleeps, it will result in a BUG(). It's not easy to reproduce this when changing zswap's params normally. In testing with a loaded system, this does not fail: $ cd /sys/module/zswap/parameters $ echo lz4 > compressor ; echo zsmalloc > zpool nor does this: $ while true ; do > echo lzo > compressor ; echo zbud > zpool > sleep 1 > echo lz4 > compressor ; echo zsmalloc > zpool > sleep 1 > done although it's still possible either of those might fail, depending on whether anything else besides zswap has locked the mutexes. However, changing a parameter with no delay immediately causes the schedule while atomic BUG: $ while true ; do > echo lzo > compressor ; echo lz4 > compressor > done This is essentially the same as Yu Zhao's proposed patch to zsmalloc, but moved to zswap, to cover compressor and zpool freeing. Fixes: f1c54846ee45 ("zswap: dynamic pool creation") Signed-off-by: Dan Streetman <ddstreet(a)ieee.org> Reported-by: Yu Zhao <yuzhao(a)google.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Dan Streetman <dan.streetman(a)canonical.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/zswap.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/mm/zswap.c +++ b/mm/zswap.c @@ -123,7 +123,7 @@ struct zswap_pool { struct crypto_comp * __percpu *tfm; struct kref kref; struct list_head list; - struct rcu_head rcu_head; + struct work_struct work; struct notifier_block notifier; char tfm_name[CRYPTO_MAX_ALG_NAME]; }; @@ -667,9 +667,11 @@ static int __must_check zswap_pool_get(s return kref_get_unless_zero(&pool->kref); } -static void __zswap_pool_release(struct rcu_head *head) +static void __zswap_pool_release(struct work_struct *work) { - struct zswap_pool *pool = container_of(head, typeof(*pool), rcu_head); + struct zswap_pool *pool = container_of(work, typeof(*pool), work); + + synchronize_rcu(); /* nobody should have been able to get a kref... */ WARN_ON(kref_get_unless_zero(&pool->kref)); @@ -689,7 +691,9 @@ static void __zswap_pool_empty(struct kr WARN_ON(pool == zswap_pool_current()); list_del_rcu(&pool->list); - call_rcu(&pool->rcu_head, __zswap_pool_release); + + INIT_WORK(&pool->work, __zswap_pool_release); + schedule_work(&pool->work); spin_unlock(&zswap_pools_lock); } Patches currently in stable-queue which might be from ddstreet(a)ieee.org are queue-4.4/mm-zswap-use-workqueue-to-destroy-pool.patch queue-4.4/zswap-don-t-param_set_charp-while-holding-spinlock.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "zswap: don't param_set_charp while holding spinlock" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled zswap: don't param_set_charp while holding spinlock to the 4.4-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: zswap-don-t-param_set_charp-while-holding-spinlock.patch and it can be found in the queue-4.4 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 fd5bb66cd934987e49557455b6497fc006521940 Mon Sep 17 00:00:00 2001 From: Dan Streetman <ddstreet(a)ieee.org> Date: Mon, 27 Feb 2017 14:26:53 -0800 Subject: zswap: don't param_set_charp while holding spinlock From: Dan Streetman <ddstreet(a)ieee.org> commit fd5bb66cd934987e49557455b6497fc006521940 upstream. Change the zpool/compressor param callback function to release the zswap_pools_lock spinlock before calling param_set_charp, since that function may sleep when it calls kmalloc with GFP_KERNEL. While this problem has existed for a while, I wasn't able to trigger it using a tight loop changing either/both the zpool and compressor params; I think it's very unlikely to be an issue on the stable kernels, especially since most zswap users will change the compressor and/or zpool from sysfs only one time each boot - or zero times, if they add the params to the kernel boot. Fixes: c99b42c3529e ("zswap: use charp for zswap param strings") Link: http://lkml.kernel.org/r/20170126155821.4545-1-ddstreet@ieee.org Signed-off-by: Dan Streetman <dan.streetman(a)canonical.com> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/zswap.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/mm/zswap.c +++ b/mm/zswap.c @@ -752,18 +752,22 @@ static int __zswap_param_set(const char pool = zswap_pool_find_get(type, compressor); if (pool) { zswap_pool_debug("using existing", pool); + WARN_ON(pool == zswap_pool_current()); list_del_rcu(&pool->list); - } else { - spin_unlock(&zswap_pools_lock); - pool = zswap_pool_create(type, compressor); - spin_lock(&zswap_pools_lock); } + spin_unlock(&zswap_pools_lock); + + if (!pool) + pool = zswap_pool_create(type, compressor); + if (pool) ret = param_set_charp(s, kp); else ret = -EINVAL; + spin_lock(&zswap_pools_lock); + if (!ret) { put_pool = zswap_pool_current(); list_add_rcu(&pool->list, &zswap_pools); Patches currently in stable-queue which might be from ddstreet(a)ieee.org are queue-4.4/mm-zswap-use-workqueue-to-destroy-pool.patch queue-4.4/zswap-don-t-param_set_charp-while-holding-spinlock.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mm/page-writeback: fix dirty_ratelimit calculation" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm/page-writeback: fix dirty_ratelimit calculation to the 4.4-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: mm-page-writeback-fix-dirty_ratelimit-calculation.patch and it can be found in the queue-4.4 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 d59b1087a98e402ed9a7cc577f4da435f9a555f5 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Tue, 15 Mar 2016 14:55:27 -0700 Subject: mm/page-writeback: fix dirty_ratelimit calculation From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit d59b1087a98e402ed9a7cc577f4da435f9a555f5 upstream. Calculation of dirty_ratelimit sometimes is not correct. E.g. initial values of dirty_ratelimit == INIT_BW and step == 0, lead to the following result: UBSAN: Undefined behaviour in ../mm/page-writeback.c:1286:7 shift exponent 25600 is too large for 64-bit type 'long unsigned int' The fix is straightforward - make step 0 if the shift exponent is too big. Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Wu Fengguang <fengguang.wu(a)intel.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Mel Gorman <mgorman(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/page-writeback.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/mm/page-writeback.c +++ b/mm/page-writeback.c @@ -1162,6 +1162,7 @@ static void wb_update_dirty_ratelimit(st unsigned long balanced_dirty_ratelimit; unsigned long step; unsigned long x; + unsigned long shift; /* * The dirty rate will match the writeout rate in long term, except @@ -1286,11 +1287,11 @@ static void wb_update_dirty_ratelimit(st * rate itself is constantly fluctuating. So decrease the track speed * when it gets close to the target. Helps eliminate pointless tremors. */ - step >>= dirty_ratelimit / (2 * step + 1); - /* - * Limit the tracking speed to avoid overshooting. - */ - step = (step + 7) / 8; + shift = dirty_ratelimit / (2 * step + 1); + if (shift < BITS_PER_LONG) + step = DIV_ROUND_UP(step >> shift, 8); + else + step = 0; if (dirty_ratelimit < balanced_dirty_ratelimit) dirty_ratelimit += step; Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-4.4/net-mac80211-debugfs.c-prevent-build-failure-with-config_ubsan-y.patch queue-4.4/mm-page-writeback-fix-dirty_ratelimit-calculation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mm/compaction: pass only pageblock aligned range to pageblock_pfn_to_page" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm/compaction: pass only pageblock aligned range to pageblock_pfn_to_page to the 4.4-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: mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_page.patch and it can be found in the queue-4.4 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 e1409c325fdc1fef7b3d8025c51892355f065d15 Mon Sep 17 00:00:00 2001 From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Date: Tue, 15 Mar 2016 14:57:48 -0700 Subject: mm/compaction: pass only pageblock aligned range to pageblock_pfn_to_page From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> commit e1409c325fdc1fef7b3d8025c51892355f065d15 upstream. pageblock_pfn_to_page() is used to check there is valid pfn and all pages in the pageblock is in a single zone. If there is a hole in the pageblock, passing arbitrary position to pageblock_pfn_to_page() could cause to skip whole pageblock scanning, instead of just skipping the hole page. For deterministic behaviour, it's better to always pass pageblock aligned range to pageblock_pfn_to_page(). It will also help further optimization on pageblock_pfn_to_page() in the following patch. Signed-off-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Aaron Lu <aaron.lu(a)intel.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Mel Gorman <mgorman(a)suse.de> Cc: Rik van Riel <riel(a)redhat.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Mel Gorman <mgorman(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/compaction.c | 41 ++++++++++++++++++++++++++++++----------- 1 file changed, 30 insertions(+), 11 deletions(-) --- a/mm/compaction.c +++ b/mm/compaction.c @@ -553,13 +553,17 @@ unsigned long isolate_freepages_range(struct compact_control *cc, unsigned long start_pfn, unsigned long end_pfn) { - unsigned long isolated, pfn, block_end_pfn; + unsigned long isolated, pfn, block_start_pfn, block_end_pfn; LIST_HEAD(freelist); pfn = start_pfn; + block_start_pfn = pfn & ~(pageblock_nr_pages - 1); + if (block_start_pfn < cc->zone->zone_start_pfn) + block_start_pfn = cc->zone->zone_start_pfn; block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages); for (; pfn < end_pfn; pfn += isolated, + block_start_pfn = block_end_pfn, block_end_pfn += pageblock_nr_pages) { /* Protect pfn from changing by isolate_freepages_block */ unsigned long isolate_start_pfn = pfn; @@ -572,11 +576,13 @@ isolate_freepages_range(struct compact_c * scanning range to right one. */ if (pfn >= block_end_pfn) { + block_start_pfn = pfn & ~(pageblock_nr_pages - 1); block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages); block_end_pfn = min(block_end_pfn, end_pfn); } - if (!pageblock_pfn_to_page(pfn, block_end_pfn, cc->zone)) + if (!pageblock_pfn_to_page(block_start_pfn, + block_end_pfn, cc->zone)) break; isolated = isolate_freepages_block(cc, &isolate_start_pfn, @@ -862,18 +868,23 @@ unsigned long isolate_migratepages_range(struct compact_control *cc, unsigned long start_pfn, unsigned long end_pfn) { - unsigned long pfn, block_end_pfn; + unsigned long pfn, block_start_pfn, block_end_pfn; /* Scan block by block. First and last block may be incomplete */ pfn = start_pfn; + block_start_pfn = pfn & ~(pageblock_nr_pages - 1); + if (block_start_pfn < cc->zone->zone_start_pfn) + block_start_pfn = cc->zone->zone_start_pfn; block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages); for (; pfn < end_pfn; pfn = block_end_pfn, + block_start_pfn = block_end_pfn, block_end_pfn += pageblock_nr_pages) { block_end_pfn = min(block_end_pfn, end_pfn); - if (!pageblock_pfn_to_page(pfn, block_end_pfn, cc->zone)) + if (!pageblock_pfn_to_page(block_start_pfn, + block_end_pfn, cc->zone)) continue; pfn = isolate_migratepages_block(cc, pfn, block_end_pfn, @@ -1091,7 +1102,9 @@ int sysctl_compact_unevictable_allowed _ static isolate_migrate_t isolate_migratepages(struct zone *zone, struct compact_control *cc) { - unsigned long low_pfn, end_pfn; + unsigned long block_start_pfn; + unsigned long block_end_pfn; + unsigned long low_pfn; unsigned long isolate_start_pfn; struct page *page; const isolate_mode_t isolate_mode = @@ -1103,16 +1116,21 @@ static isolate_migrate_t isolate_migrate * initialized by compact_zone() */ low_pfn = cc->migrate_pfn; + block_start_pfn = cc->migrate_pfn & ~(pageblock_nr_pages - 1); + if (block_start_pfn < zone->zone_start_pfn) + block_start_pfn = zone->zone_start_pfn; /* Only scan within a pageblock boundary */ - end_pfn = ALIGN(low_pfn + 1, pageblock_nr_pages); + block_end_pfn = ALIGN(low_pfn + 1, pageblock_nr_pages); /* * Iterate over whole pageblocks until we find the first suitable. * Do not cross the free scanner. */ - for (; end_pfn <= cc->free_pfn; - low_pfn = end_pfn, end_pfn += pageblock_nr_pages) { + for (; block_end_pfn <= cc->free_pfn; + low_pfn = block_end_pfn, + block_start_pfn = block_end_pfn, + block_end_pfn += pageblock_nr_pages) { /* * This can potentially iterate a massively long zone with @@ -1123,7 +1141,8 @@ static isolate_migrate_t isolate_migrate && compact_should_abort(cc)) break; - page = pageblock_pfn_to_page(low_pfn, end_pfn, zone); + page = pageblock_pfn_to_page(block_start_pfn, block_end_pfn, + zone); if (!page) continue; @@ -1142,8 +1161,8 @@ static isolate_migrate_t isolate_migrate /* Perform the isolation */ isolate_start_pfn = low_pfn; - low_pfn = isolate_migratepages_block(cc, low_pfn, end_pfn, - isolate_mode); + low_pfn = isolate_migratepages_block(cc, low_pfn, + block_end_pfn, isolate_mode); if (!low_pfn || cc->contended) { acct_isolated(zone, cc); Patches currently in stable-queue which might be from iamjoonsoo.kim(a)lge.com are queue-4.4/mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_page.patch queue-4.4/mm-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "locks: don't check for race with close when setting OFD lock" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled locks: don't check for race with close when setting OFD lock to the 4.4-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: locks-don-t-check-for-race-with-close-when-setting-ofd-lock.patch and it can be found in the queue-4.4 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 0752ba807b04ccd69cb4bc8bbf829a80ee208a3c Mon Sep 17 00:00:00 2001 From: Jeff Layton <jeff.layton(a)primarydata.com> Date: Fri, 8 Jan 2016 07:30:43 -0500 Subject: locks: don't check for race with close when setting OFD lock From: Jeff Layton <jeff.layton(a)primarydata.com> commit 0752ba807b04ccd69cb4bc8bbf829a80ee208a3c upstream. We don't clean out OFD locks on close(), so there's no need to check for a race with them here. They'll get cleaned out at the same time that flock locks are. Signed-off-by: Jeff Layton <jeff.layton(a)primarydata.com> Acked-by: "J. Bruce Fields" <bfields(a)fieldses.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Mel Gorman <mgorman(a)suse.de> --- fs/locks.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) --- a/fs/locks.c +++ b/fs/locks.c @@ -2220,10 +2220,12 @@ int fcntl_setlk(unsigned int fd, struct error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by - * releasing the lock that was just acquired. + * Attempt to detect a close/fcntl race and recover by releasing the + * lock that was just acquired. There is no need to do that when we're + * unlocking though, or for OFD locks. */ - if (!error && file_lock->fl_type != F_UNLCK) { + if (!error && file_lock->fl_type != F_UNLCK && + !(file_lock->fl_flags & FL_OFDLCK)) { /* * We need that spin_lock here - it prevents reordering between * update of i_flctx->flc_posix and check for it done in @@ -2362,10 +2364,12 @@ int fcntl_setlk64(unsigned int fd, struc error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by - * releasing the lock that was just acquired. + * Attempt to detect a close/fcntl race and recover by releasing the + * lock that was just acquired. There is no need to do that when we're + * unlocking though, or for OFD locks. */ - if (!error && file_lock->fl_type != F_UNLCK) { + if (!error && file_lock->fl_type != F_UNLCK && + !(file_lock->fl_flags & FL_OFDLCK)) { /* * We need that spin_lock here - it prevents reordering between * update of i_flctx->flc_posix and check for it done in Patches currently in stable-queue which might be from jeff.layton(a)primarydata.com are queue-4.4/locks-don-t-check-for-race-with-close-when-setting-ofd-lock.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mm/compaction: fix invalid free_pfn and compact_cached_free_pfn" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm/compaction: fix invalid free_pfn and compact_cached_free_pfn to the 4.4-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: mm-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.patch and it can be found in the queue-4.4 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 623446e4dc45b37740268165107cc63abb3022f0 Mon Sep 17 00:00:00 2001 From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Date: Tue, 15 Mar 2016 14:57:45 -0700 Subject: mm/compaction: fix invalid free_pfn and compact_cached_free_pfn From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> commit 623446e4dc45b37740268165107cc63abb3022f0 upstream. free_pfn and compact_cached_free_pfn are the pointer that remember restart position of freepage scanner. When they are reset or invalid, we set them to zone_end_pfn because freepage scanner works in reverse direction. But, because zone range is defined as [zone_start_pfn, zone_end_pfn), zone_end_pfn is invalid to access. Therefore, we should not store it to free_pfn and compact_cached_free_pfn. Instead, we need to store zone_end_pfn - 1 to them. There is one more thing we should consider. Freepage scanner scan reversely by pageblock unit. If free_pfn and compact_cached_free_pfn are set to middle of pageblock, it regards that sitiation as that it already scans front part of pageblock so we lose opportunity to scan there. To fix-up, this patch do round_down() to guarantee that reset position will be pageblock aligned. Note that thanks to the current pageblock_pfn_to_page() implementation, actual access to zone_end_pfn doesn't happen until now. But, following patch will change pageblock_pfn_to_page() so this patch is needed from now on. Signed-off-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Acked-by: David Rientjes <rientjes(a)google.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Aaron Lu <aaron.lu(a)intel.com> Cc: Mel Gorman <mgorman(a)suse.de> Cc: Rik van Riel <riel(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Mel Gorman <mgorman(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/compaction.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/mm/compaction.c +++ b/mm/compaction.c @@ -200,7 +200,8 @@ static void reset_cached_positions(struc { zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn; zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn; - zone->compact_cached_free_pfn = zone_end_pfn(zone); + zone->compact_cached_free_pfn = + round_down(zone_end_pfn(zone) - 1, pageblock_nr_pages); } /* @@ -1358,11 +1359,11 @@ static int compact_zone(struct zone *zon */ cc->migrate_pfn = zone->compact_cached_migrate_pfn[sync]; cc->free_pfn = zone->compact_cached_free_pfn; - if (cc->free_pfn < start_pfn || cc->free_pfn > end_pfn) { - cc->free_pfn = end_pfn & ~(pageblock_nr_pages-1); + if (cc->free_pfn < start_pfn || cc->free_pfn >= end_pfn) { + cc->free_pfn = round_down(end_pfn - 1, pageblock_nr_pages); zone->compact_cached_free_pfn = cc->free_pfn; } - if (cc->migrate_pfn < start_pfn || cc->migrate_pfn > end_pfn) { + if (cc->migrate_pfn < start_pfn || cc->migrate_pfn >= end_pfn) { cc->migrate_pfn = start_pfn; zone->compact_cached_migrate_pfn[0] = cc->migrate_pfn; zone->compact_cached_migrate_pfn[1] = cc->migrate_pfn; Patches currently in stable-queue which might be from iamjoonsoo.kim(a)lge.com are queue-4.4/mm-compaction-pass-only-pageblock-aligned-range-to-pageblock_pfn_to_page.patch queue-4.4/mm-compaction-fix-invalid-free_pfn-and-compact_cached_free_pfn.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "locking/mutex: Allow next waiter lockless wakeup" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled locking/mutex: Allow next waiter lockless wakeup to the 4.4-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: locking-mutex-allow-next-waiter-lockless-wakeup.patch and it can be found in the queue-4.4 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 1329ce6fbbe4536592dfcfc8d64d61bfeb598fe6 Mon Sep 17 00:00:00 2001 From: Davidlohr Bueso <dave(a)stgolabs.net> Date: Sun, 24 Jan 2016 18:23:43 -0800 Subject: locking/mutex: Allow next waiter lockless wakeup From: Davidlohr Bueso <dave(a)stgolabs.net> commit 1329ce6fbbe4536592dfcfc8d64d61bfeb598fe6 upstream. Make use of wake-queues and enable the wakeup to occur after releasing the wait_lock. This is similar to what we do with rtmutex top waiter, slightly shortening the critical region and allow other waiters to acquire the wait_lock sooner. In low contention cases it can also help the recently woken waiter to find the wait_lock available (fastpath) when it continues execution. Reviewed-by: Waiman Long <Waiman.Long(a)hpe.com> Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Ding Tianhong <dingtianhong(a)huawei.com> Cc: Jason Low <jason.low2(a)hp.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Cc: Paul E. McKenney <paulmck(a)us.ibm.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tim Chen <tim.c.chen(a)linux.intel.com> Cc: Waiman Long <waiman.long(a)hpe.com> Cc: Will Deacon <Will.Deacon(a)arm.com> Link: http://lkml.kernel.org/r/20160125022343.GA3322@linux-uzut.site Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/locking/mutex.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -719,6 +719,7 @@ static inline void __mutex_unlock_common_slowpath(struct mutex *lock, int nested) { unsigned long flags; + WAKE_Q(wake_q); /* * As a performance measurement, release the lock before doing other @@ -746,11 +747,11 @@ __mutex_unlock_common_slowpath(struct mu struct mutex_waiter, list); debug_mutex_wake_waiter(lock, waiter); - - wake_up_process(waiter->task); + wake_q_add(&wake_q, waiter->task); } spin_unlock_mutex(&lock->wait_lock, flags); + wake_up_q(&wake_q); } /* Patches currently in stable-queue which might be from dave(a)stgolabs.net are queue-4.4/locking-mutex-allow-next-waiter-lockless-wakeup.patch queue-4.4/futex-replace-barrier-in-unqueue_me-with-read_once.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "futex: Replace barrier() in unqueue_me() with READ_ONCE()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled futex: Replace barrier() in unqueue_me() with READ_ONCE() to the 4.4-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: futex-replace-barrier-in-unqueue_me-with-read_once.patch and it can be found in the queue-4.4 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 29b75eb2d56a714190a93d7be4525e617591077a Mon Sep 17 00:00:00 2001 From: Jianyu Zhan <nasa4836(a)gmail.com> Date: Mon, 7 Mar 2016 09:32:24 +0800 Subject: futex: Replace barrier() in unqueue_me() with READ_ONCE() From: Jianyu Zhan <nasa4836(a)gmail.com> commit 29b75eb2d56a714190a93d7be4525e617591077a upstream. Commit e91467ecd1ef ("bug in futex unqueue_me") introduced a barrier() in unqueue_me() to prevent the compiler from rereading the lock pointer which might change after a check for NULL. Replace the barrier() with a READ_ONCE() for the following reasons: 1) READ_ONCE() is a weaker form of barrier() that affects only the specific load operation, while barrier() is a general compiler level memory barrier. READ_ONCE() was not available at the time when the barrier was added. 2) Aside of that READ_ONCE() is descriptive and self explainatory while a barrier without comment is not clear to the casual reader. No functional change. [ tglx: Massaged changelog ] Signed-off-by: Jianyu Zhan <nasa4836(a)gmail.com> Acked-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Acked-by: Darren Hart <dvhart(a)linux.intel.com> Cc: dave(a)stgolabs.net Cc: peterz(a)infradead.org Cc: linux(a)rasmusvillemoes.dk Cc: akpm(a)linux-foundation.org Cc: fengguang.wu(a)intel.com Cc: bigeasy(a)linutronix.de Link: http://lkml.kernel.org/r/1457314344-5685-1-git-send-email-nasa4836@gmail.com Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/futex.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1939,8 +1939,12 @@ static int unqueue_me(struct futex_q *q) /* In the common case we don't take the spinlock, which is nice. */ retry: - lock_ptr = q->lock_ptr; - barrier(); + /* + * q->lock_ptr can change between this read and the following spin_lock. + * Use READ_ONCE to forbid the compiler from reloading q->lock_ptr and + * optimizing lock_ptr out of the logic below. + */ + lock_ptr = READ_ONCE(q->lock_ptr); if (lock_ptr != NULL) { spin_lock(lock_ptr); /* Patches currently in stable-queue which might be from nasa4836(a)gmail.com are queue-4.4/futex-replace-barrier-in-unqueue_me-with-read_once.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror