This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
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:
kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.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 c93f5cf571e7795f97d49ef51b766cf25e328545 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Thu, 25 May 2017 19:38:17 +0900
Subject: kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
From: Masami Hiramatsu <mhiramat(a)kernel.org>
commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.
Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.
Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.
Link: http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 9 +++++++++
kernel/kprobes.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -51,6 +51,7 @@
#include <linux/ftrace.h>
#include <linux/frame.h>
#include <linux/kasan.h>
+#include <linux/moduleloader.h>
#include <asm/text-patching.h>
#include <asm/cacheflush.h>
@@ -405,6 +406,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
}
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+ set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+ set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+ module_memfree(page);
+}
+
static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
}
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
{
module_memfree(page);
}
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
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:
kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.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 c93f5cf571e7795f97d49ef51b766cf25e328545 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Thu, 25 May 2017 19:38:17 +0900
Subject: kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
From: Masami Hiramatsu <mhiramat(a)kernel.org>
commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.
Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.
Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.
Link: http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 9 +++++++++
kernel/kprobes.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -49,6 +49,7 @@
#include <linux/kdebug.h>
#include <linux/kallsyms.h>
#include <linux/ftrace.h>
+#include <linux/moduleloader.h>
#include <asm/cacheflush.h>
#include <asm/desc.h>
@@ -402,6 +403,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
}
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+ set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+ set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+ module_memfree(page);
+}
+
static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
}
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
{
module_memfree(page);
}
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.4/kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
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:
kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.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 c93f5cf571e7795f97d49ef51b766cf25e328545 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Thu, 25 May 2017 19:38:17 +0900
Subject: kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
From: Masami Hiramatsu <mhiramat(a)kernel.org>
commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.
Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.
Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.
Link: http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 9 +++++++++
kernel/kprobes.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -49,6 +49,7 @@
#include <linux/kdebug.h>
#include <linux/kallsyms.h>
#include <linux/ftrace.h>
+#include <linux/moduleloader.h>
#include <asm/cacheflush.h>
#include <asm/desc.h>
@@ -374,6 +375,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
}
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+ set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+ set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+ vfree(page);
+}
+
static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
}
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
{
module_free(NULL, page);
}
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-3.18/tracing-probeevent-fix-to-support-minus-offset-from-symbol.patch
queue-3.18/kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
This is a note to let you know that I've just added the patch titled
xhci: Fix ring leak in failure path of xhci_alloc_virt_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:
xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_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 3ae43090f13b7f6b6a8d4f4889727d2db4e81dd8 Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Date: Thu, 11 Jan 2018 17:01:36 +0000
Subject: xhci: Fix ring leak in failure path of xhci_alloc_virt_device()
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
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>
Cc: Mathias Nyman <mathias.nyman(a)intel.com>
Cc: Wang Han <wanghan1995315(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1032,7 +1032,8 @@ int xhci_alloc_virt_device(struct xhci_h
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)
Patches currently in stable-queue which might be from ben.hutchings(a)codethink.co.uk are
queue-3.18/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-3.18/revert-led-core-fix-brightness-setting-when-setting-delay_off-0.patch
queue-3.18/xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_device.patch
This is a note to let you know that I've just added the patch titled
Revert "led: core: Fix brightness setting when setting delay_off=0"
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-led-core-fix-brightness-setting-when-setting-delay_off-0.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 3f3437fbb2d8f780e84f507282d03facb4ccf248 Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Date: Thu, 8 Mar 2018 15:59:07 +0000
Subject: Revert "led: core: Fix brightness setting when setting delay_off=0"
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
This reverts commit 20f6d9c2af33da892a0e03ffd6249c7ab81edfb7, which
was commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c upstream.
The bug that it should fix was only introduced in Linux 4.7, and
in 4.4 it causes a regression.
Reported-by: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
Cc: Matthieu CASTET <matthieu.castet(a)parrot.com>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Cc: Wang Han <wanghan1995315(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -76,7 +76,7 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- led_stop_software_blink(led_cdev);
+ del_timer_sync(&led_cdev->blink_timer);
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
Patches currently in stable-queue which might be from ben.hutchings(a)codethink.co.uk are
queue-3.18/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-3.18/revert-led-core-fix-brightness-setting-when-setting-delay_off-0.patch
queue-3.18/xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_device.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
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-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.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 16b114a6d7973cf027e4c2b23eae1076eaf98c25 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:04 +0100
Subject: usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 16b114a6d7973cf027e4c2b23eae1076eaf98c25 upstream.
USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.
This patch also introduces usb_ep_align() which does always returns the
aligned buffer size for an endpoint. This is useful to be used by USB requests
allocator functions.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/usb/gadget.h | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -663,8 +663,20 @@ static inline struct usb_gadget *dev_to_
list_for_each_entry(tmp, &(gadget)->ep_list, ep_list)
/**
+ * usb_ep_align - returns @len aligned to ep's maxpacketsize.
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used to align buffer's size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align(struct usb_ep *ep, size_t len)
+{
+ return round_up(len, (size_t)le16_to_cpu(ep->desc->wMaxPacketSize));
+}
+
+/**
* usb_ep_align_maybe - returns @len aligned to ep's maxpacketsize if gadget
- * requires quirk_ep_out_aligned_size, otherwise reguens len.
+ * requires quirk_ep_out_aligned_size, otherwise returns len.
* @g: controller to check for quirk
* @ep: the endpoint whose maxpacketsize is used to align @len
* @len: buffer size's length to align to @ep's maxpacketsize
@@ -675,8 +687,7 @@ static inline struct usb_gadget *dev_to_
static inline size_t
usb_ep_align_maybe(struct usb_gadget *g, struct usb_ep *ep, size_t len)
{
- return !g->quirk_ep_out_aligned_size ? len :
- round_up(len, (size_t)ep->desc->wMaxPacketSize);
+ return g->quirk_ep_out_aligned_size ? usb_ep_align(ep, len) : len;
}
/**
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-4.4/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-4.4/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-4.4/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-4.4/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_hid: fix: Prevent accessing released memory
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-gadget-f_hid-fix-prevent-accessing-released-memory.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 aa65d11aa008f4de58a9cee7e121666d9d68505e Mon Sep 17 00:00:00 2001
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
Date: Thu, 19 Jan 2017 18:55:28 +0100
Subject: usb: gadget: f_hid: fix: Prevent accessing released memory
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
commit aa65d11aa008f4de58a9cee7e121666d9d68505e upstream.
When we unlock our spinlock to copy data to user we may get
disabled by USB host and free the whole list of completed out
requests including the one from which we are copying the data
to user memory.
To prevent from this let's remove our working element from
the list and place it back only if there is sth left when we
finish with it.
Fixes: 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT")
Cc: stable(a)vger.kernel.org
Tested-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Jerry Zhang <zhangjerry(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_hid.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -223,6 +223,13 @@ static ssize_t f_hidg_read(struct file *
/* pick the first one */
list = list_first_entry(&hidg->completed_out_req,
struct f_hidg_req_list, list);
+
+ /*
+ * Remove this from list to protect it from beign free()
+ * while host disables our function
+ */
+ list_del(&list->list);
+
req = list->req;
count = min_t(unsigned int, count, req->actual - list->pos);
spin_unlock_irqrestore(&hidg->spinlock, flags);
@@ -238,15 +245,20 @@ static ssize_t f_hidg_read(struct file *
* call, taking into account its current read position.
*/
if (list->pos == req->actual) {
- spin_lock_irqsave(&hidg->spinlock, flags);
- list_del(&list->list);
kfree(list);
- spin_unlock_irqrestore(&hidg->spinlock, flags);
req->length = hidg->report_length;
ret = usb_ep_queue(hidg->out_ep, req, GFP_KERNEL);
- if (ret < 0)
+ if (ret < 0) {
+ free_ep_req(hidg->out_ep, req);
return ret;
+ }
+ } else {
+ spin_lock_irqsave(&hidg->spinlock, flags);
+ list_add(&list->list, &hidg->completed_out_req);
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
+
+ wake_up(&hidg->read_queue);
}
return count;
@@ -490,14 +502,18 @@ static void hidg_disable(struct usb_func
{
struct f_hidg *hidg = func_to_hidg(f);
struct f_hidg_req_list *list, *next;
+ unsigned long flags;
usb_ep_disable(hidg->in_ep);
usb_ep_disable(hidg->out_ep);
+ spin_lock_irqsave(&hidg->spinlock, flags);
list_for_each_entry_safe(list, next, &hidg->completed_out_req, list) {
+ free_ep_req(hidg->out_ep, list->req);
list_del(&list->list);
kfree(list);
}
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
}
static int hidg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
Patches currently in stable-queue which might be from kopasiak90(a)gmail.com are
queue-4.4/usb-gadget-f_hid-fix-prevent-accessing-released-memory.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: change len to size_t on alloc_ep_req()
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-gadget-change-len-to-size_t-on-alloc_ep_req.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 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:05 +0100
Subject: usb: gadget: change len to size_t on alloc_ep_req()
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a upstream.
Length of buffers should be of type size_t whenever possible. Altough
recommended, this change has no real practical change, unless a driver has a
uses a huge or negative buffer size - it might help find these bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 2 +-
drivers/usb/gadget/u_f.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -13,7 +13,7 @@
#include "u_f.h"
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len)
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
struct usb_request *req;
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -48,7 +48,7 @@ struct usb_ep;
struct usb_request;
/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-4.4/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-4.4/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-4.4/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-4.4/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: align buffer size when allocating for OUT endpoint
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-gadget-align-buffer-size-when-allocating-for-out-endpoint.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 e0466156ee2e944fb47a3fa00932c3698a6d2c67 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:06 +0100
Subject: usb: gadget: align buffer size when allocating for OUT endpoint
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit e0466156ee2e944fb47a3fa00932c3698a6d2c67 upstream.
Using usb_ep_align() makes sure that the buffer size for OUT endpoints is
always aligned with wMaxPacketSize (512 usually). This makes sure
that no buffer has the wrong size, which can cause nasty bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 3 +++
drivers/usb/gadget/u_f.h | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -12,6 +12,7 @@
*/
#include "u_f.h"
+#include <linux/usb/ch9.h>
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
@@ -20,6 +21,8 @@ struct usb_request *alloc_ep_req(struct
req = usb_ep_alloc_request(ep, GFP_ATOMIC);
if (req) {
req->length = len ?: default_len;
+ if (usb_endpoint_dir_out(ep->desc))
+ req->length = usb_ep_align(ep, req->length);
req->buf = kmalloc(req->length, GFP_ATOMIC);
if (!req->buf) {
usb_ep_free_request(ep, req);
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,8 +47,22 @@
struct usb_ep;
struct usb_request;
-/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
+/**
+ * alloc_ep_req - returns a usb_request allocated by the gadget driver and
+ * allocates the request's buffer.
+ *
+ * @ep: the endpoint to allocate a usb_request
+ * @len: usb_requests's buffer suggested size
+ * @default_len: used if @len is not provided, ie, is 0
+ *
+ * In case @ep direction is OUT, the @len will be aligned to ep's
+ * wMaxPacketSize. In order to avoid memory leaks or drops, *always* use
+ * usb_requests's length (req->length) to refer to the allocated buffer size.
+ * Requests allocated via alloc_ep_req() *must* be freed by free_ep_req().
+ */
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
+
+/* Frees a usb_request previously allocated by alloc_ep_req() */
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-4.4/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-4.4/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-4.4/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-4.4/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
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-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.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 16b114a6d7973cf027e4c2b23eae1076eaf98c25 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:04 +0100
Subject: usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 16b114a6d7973cf027e4c2b23eae1076eaf98c25 upstream.
USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.
This patch also introduces usb_ep_align() which does always returns the
aligned buffer size for an endpoint. This is useful to be used by USB requests
allocator functions.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/usb/gadget.h | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -582,8 +582,20 @@ static inline struct usb_gadget *dev_to_
/**
+ * usb_ep_align - returns @len aligned to ep's maxpacketsize.
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used to align buffer's size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align(struct usb_ep *ep, size_t len)
+{
+ return round_up(len, (size_t)le16_to_cpu(ep->desc->wMaxPacketSize));
+}
+
+/**
* usb_ep_align_maybe - returns @len aligned to ep's maxpacketsize if gadget
- * requires quirk_ep_out_aligned_size, otherwise reguens len.
+ * requires quirk_ep_out_aligned_size, otherwise returns len.
* @g: controller to check for quirk
* @ep: the endpoint whose maxpacketsize is used to align @len
* @len: buffer size's length to align to @ep's maxpacketsize
@@ -594,8 +606,7 @@ static inline struct usb_gadget *dev_to_
static inline size_t
usb_ep_align_maybe(struct usb_gadget *g, struct usb_ep *ep, size_t len)
{
- return !g->quirk_ep_out_aligned_size ? len :
- round_up(len, (size_t)ep->desc->wMaxPacketSize);
+ return g->quirk_ep_out_aligned_size ? usb_ep_align(ep, len) : len;
}
/**
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-3.18/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-3.18/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-3.18/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-3.18/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: change len to size_t on alloc_ep_req()
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-gadget-change-len-to-size_t-on-alloc_ep_req.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 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:05 +0100
Subject: usb: gadget: change len to size_t on alloc_ep_req()
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a upstream.
Length of buffers should be of type size_t whenever possible. Altough
recommended, this change has no real practical change, unless a driver has a
uses a huge or negative buffer size - it might help find these bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 2 +-
drivers/usb/gadget/u_f.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -13,7 +13,7 @@
#include "u_f.h"
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len)
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
struct usb_request *req;
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -48,7 +48,7 @@ struct usb_ep;
struct usb_request;
/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-3.18/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-3.18/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-3.18/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-3.18/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_hid: fix: Prevent accessing released memory
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-gadget-f_hid-fix-prevent-accessing-released-memory.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 aa65d11aa008f4de58a9cee7e121666d9d68505e Mon Sep 17 00:00:00 2001
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
Date: Thu, 19 Jan 2017 18:55:28 +0100
Subject: usb: gadget: f_hid: fix: Prevent accessing released memory
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
commit aa65d11aa008f4de58a9cee7e121666d9d68505e upstream.
When we unlock our spinlock to copy data to user we may get
disabled by USB host and free the whole list of completed out
requests including the one from which we are copying the data
to user memory.
To prevent from this let's remove our working element from
the list and place it back only if there is sth left when we
finish with it.
Fixes: 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT")
Cc: stable(a)vger.kernel.org
Tested-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Jerry Zhang <zhangjerry(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_hid.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -197,6 +197,13 @@ static ssize_t f_hidg_read(struct file *
/* pick the first one */
list = list_first_entry(&hidg->completed_out_req,
struct f_hidg_req_list, list);
+
+ /*
+ * Remove this from list to protect it from beign free()
+ * while host disables our function
+ */
+ list_del(&list->list);
+
req = list->req;
count = min_t(unsigned int, count, req->actual - list->pos);
spin_unlock_irqrestore(&hidg->spinlock, flags);
@@ -212,15 +219,20 @@ static ssize_t f_hidg_read(struct file *
* call, taking into account its current read position.
*/
if (list->pos == req->actual) {
- spin_lock_irqsave(&hidg->spinlock, flags);
- list_del(&list->list);
kfree(list);
- spin_unlock_irqrestore(&hidg->spinlock, flags);
req->length = hidg->report_length;
ret = usb_ep_queue(hidg->out_ep, req, GFP_KERNEL);
- if (ret < 0)
+ if (ret < 0) {
+ free_ep_req(hidg->out_ep, req);
return ret;
+ }
+ } else {
+ spin_lock_irqsave(&hidg->spinlock, flags);
+ list_add(&list->list, &hidg->completed_out_req);
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
+
+ wake_up(&hidg->read_queue);
}
return count;
@@ -455,6 +467,7 @@ static void hidg_disable(struct usb_func
{
struct f_hidg *hidg = func_to_hidg(f);
struct f_hidg_req_list *list, *next;
+ unsigned long flags;
usb_ep_disable(hidg->in_ep);
hidg->in_ep->driver_data = NULL;
@@ -462,10 +475,13 @@ static void hidg_disable(struct usb_func
usb_ep_disable(hidg->out_ep);
hidg->out_ep->driver_data = NULL;
+ spin_lock_irqsave(&hidg->spinlock, flags);
list_for_each_entry_safe(list, next, &hidg->completed_out_req, list) {
+ free_ep_req(hidg->out_ep, list->req);
list_del(&list->list);
kfree(list);
}
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
}
static int hidg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
Patches currently in stable-queue which might be from kopasiak90(a)gmail.com are
queue-3.18/usb-gadget-f_hid-fix-prevent-accessing-released-memory.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: align buffer size when allocating for OUT endpoint
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-gadget-align-buffer-size-when-allocating-for-out-endpoint.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 e0466156ee2e944fb47a3fa00932c3698a6d2c67 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:06 +0100
Subject: usb: gadget: align buffer size when allocating for OUT endpoint
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit e0466156ee2e944fb47a3fa00932c3698a6d2c67 upstream.
Using usb_ep_align() makes sure that the buffer size for OUT endpoints is
always aligned with wMaxPacketSize (512 usually). This makes sure
that no buffer has the wrong size, which can cause nasty bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 3 +++
drivers/usb/gadget/u_f.h | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -12,6 +12,7 @@
*/
#include "u_f.h"
+#include <linux/usb/ch9.h>
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
@@ -20,6 +21,8 @@ struct usb_request *alloc_ep_req(struct
req = usb_ep_alloc_request(ep, GFP_ATOMIC);
if (req) {
req->length = len ?: default_len;
+ if (usb_endpoint_dir_out(ep->desc))
+ req->length = usb_ep_align(ep, req->length);
req->buf = kmalloc(req->length, GFP_ATOMIC);
if (!req->buf) {
usb_ep_free_request(ep, req);
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,8 +47,22 @@
struct usb_ep;
struct usb_request;
-/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
+/**
+ * alloc_ep_req - returns a usb_request allocated by the gadget driver and
+ * allocates the request's buffer.
+ *
+ * @ep: the endpoint to allocate a usb_request
+ * @len: usb_requests's buffer suggested size
+ * @default_len: used if @len is not provided, ie, is 0
+ *
+ * In case @ep direction is OUT, the @len will be aligned to ep's
+ * wMaxPacketSize. In order to avoid memory leaks or drops, *always* use
+ * usb_requests's length (req->length) to refer to the allocated buffer size.
+ * Requests allocated via alloc_ep_req() *must* be freed by free_ep_req().
+ */
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
+
+/* Frees a usb_request previously allocated by alloc_ep_req() */
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-3.18/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-3.18/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-3.18/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-3.18/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
On Mon, Apr 02, 2018 at 03:58:31PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval <osandov(a)fb.com>
>
> Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
> which uses memset() when the start and length are constants aligned to a
> byte. This is wrong on big-endian systems; our bitmaps are arrays of
> unsigned long, so bit n is not at byte n / 8 in memory. This was caught
> by the Btrfs selftests, but the bitmap selftests also fail when run on a
> big-endian machine.
>
> We can still use memset if the start and length are aligned to an
> unsigned long, so do that on big-endian. The same problem applies to the
> memcmp in bitmap_equal(), so fix it there, too.
>
> Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
> Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
> Cc: stable(a)kernel.org
This should be stable(a)vger.kernel.org, of course
This is a fix for a regression in 32 bit kernels caused by an
invalid check for pgoff overflow in hugetlbfs mmap setup. The
check incorrectly specified that the size of a loff_t was the
same as the size of a long. The regression prevents mapping
hugetlbfs files at offsets greater than 4GB on 32 bit kernels.
On 32 bit kernels conversion from a page based unsigned long can
not overflow a loff_t byte offset. Therefore, skip this check
if sizeof(unsigned long) != sizeof(loff_t).
Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow")
Cc: <stable(a)vger.kernel.org>
Reported-by: Dan Rue <dan.rue(a)linaro.org>
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
---
fs/hugetlbfs/inode.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index b9a254dcc0e7..d508c7844681 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -138,10 +138,14 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
/*
* page based offset in vm_pgoff could be sufficiently large to
- * overflow a (l)off_t when converted to byte offset.
+ * overflow a loff_t when converted to byte offset. This can
+ * only happen on architectures where sizeof(loff_t) ==
+ * sizeof(unsigned long). So, only check in those instances.
*/
- if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
- return -EINVAL;
+ if (sizeof(unsigned long) == sizeof(loff_t)) {
+ if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
+ return -EINVAL;
+ }
/* must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
--
2.13.6
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
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:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.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 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.9/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
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:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.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 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.4/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.15/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
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:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.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 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.14/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
The patch below was installed in Linux 4.16-rc1 as
commit 5f15684bd5e5ef39d4337988864fec8012471dda
It is a fix to the following 4.12-rc3 patch:
commit 223220356d5ebc05ead9a8d697abb0c0a906fc81
Please install the new patch wherever the old patch was installed.
--------------------------------------------------------------------------------
UFS partitions from newer versions of FreeBSD 10 and 11 use relative addressing
for their subpartitions. But older versions of FreeBSD still use absolute
addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to also
test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
---
--- a/block/partitions/msdos.c.orig 2017-11-05 13:05:14.000000000 -0800
+++ b/block/partitions/msdos.c 2017-11-06 09:46:00.148228242 -0800
@@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
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:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.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 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-3.18/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
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:
powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.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 ff6781fd1bb404d8a551c02c35c70cec1da17ff1 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 21 Mar 2018 12:22:28 +1000
Subject: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Nicholas Piggin <npiggin(a)gmail.com>
commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
force_external_irq_replay() can be called in the do_IRQ path with
interrupts hard enabled and soft disabled if may_hard_irq_enable() set
MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
store sequence. If a maskable interrupt hits during this sequence, it
will go to the masked handler to be marked pending in irq_happened.
This update will be lost when the interrupt returns and the store
instruction executes. This can result in unpredictable latencies,
timeouts, lockups, etc.
Fix this by ensuring hard interrupts are disabled before modifying
irq_happened.
This could cause any maskable asynchronous interrupt to get lost, but
it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
so very high external interrupt rate and high IPI rate. The hang was
bisected down to enabling doorbell interrupts for IPIs. These provided
an interrupt type that could run at high rates in the do_IRQ path,
stressing the race.
Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
Cc: stable(a)vger.kernel.org # v4.8+
Reported-by: Carol L. Soto <clsoto(a)us.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -372,6 +372,14 @@ void force_external_irq_replay(void)
*/
WARN_ON(!arch_irqs_disabled());
+ /*
+ * Interrupts must always be hard disabled before irq_happened is
+ * modified (to prevent lost update in case of interrupt between
+ * load and store).
+ */
+ __hard_irq_disable();
+ local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+
/* Indicate in the PACA that we have an interrupt to replay */
local_paca->irq_happened |= PACA_IRQ_EE;
}
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.9/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
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:
powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.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 52396500f97c53860164debc7d4f759077853423 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 23 Mar 2018 15:53:38 +1000
Subject: powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 52396500f97c53860164debc7d4f759077853423 upstream.
The SLB bad address handler's trap number fixup does not preserve the
low bit that indicates nonvolatile GPRs have not been saved. This
leads save_nvgprs to skip saving them, and subsequent functions and
return from interrupt will think they are saved.
This causes kernel branch-to-garbage debugging to not have correct
registers, can also cause userspace to have its registers clobbered
after a segfault.
Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
Cc: stable(a)vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -723,7 +723,7 @@ EXC_COMMON_BEGIN(bad_addr_slb)
ld r3, PACA_EXSLB+EX_DAR(r13)
std r3, _DAR(r1)
beq cr6, 2f
- li r10, 0x480 /* fix trap number for I-SLB miss */
+ li r10, 0x481 /* fix trap number for I-SLB miss */
std r10, _TRAP(r1)
2: bl save_nvgprs
addi r3, r1, STACK_FRAME_OVERHEAD
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.9/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
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:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.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 f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.9/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
queue-4.9/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
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:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.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 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.9/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ipc/shm.c: add split function to shm_vm_ops
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:
ipc-shm.c-add-split-function-to-shm_vm_ops.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 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Wed, 28 Mar 2018 16:01:01 -0700
Subject: ipc/shm.c: add split function to shm_vm_ops
From: Mike Kravetz <mike.kravetz(a)oracle.com>
commit 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 upstream.
If System V shmget/shmat operations are used to create a hugetlbfs
backed mapping, it is possible to munmap part of the mapping and split
the underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER: 20040000
CFAR: c00000000036ee44 SOFTE: 1
NIP __unmap_hugepage_range+0xa4/0x760
LR __unmap_hugepage_range_final+0x28/0x50
Call Trace:
0x7115e4e00000 (unreliable)
__unmap_hugepage_range_final+0x28/0x50
unmap_single_vma+0x11c/0x190
unmap_vmas+0x94/0x140
exit_mmap+0x9c/0x1d0
mmput+0xa8/0x1d0
do_exit+0x360/0xc80
do_group_exit+0x60/0x100
SyS_exit_group+0x24/0x30
system_call+0x58/0x6c
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
introduce ->split() to vm_operations_struct"). A split function was
added to vm_operations_struct to determine if a mapping can be split.
This was mostly for device-dax and hugetlbfs mappings which have
specific alignment constraints.
Mappings initiated via shmget/shmat have their original vm_ops
overwritten with shm_vm_ops. shm_vm_ops functions will call back to the
original vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -381,6 +381,17 @@ static int shm_fault(struct vm_area_stru
return sfd->vm_ops->fault(vma, vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -503,6 +514,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
Patches currently in stable-queue which might be from mike.kravetz(a)oracle.com are
queue-4.9/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
ceph: only dirty ITER_IOVEC pages for direct read
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:
ceph-only-dirty-iter_iovec-pages-for-direct-read.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 85784f9395987a422fa04263e7c0fb13da11eb5c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Fri, 16 Mar 2018 11:22:29 +0800
Subject: ceph: only dirty ITER_IOVEC pages for direct read
From: Yan, Zheng <zyan(a)redhat.com>
commit 85784f9395987a422fa04263e7c0fb13da11eb5c upstream.
If a page is already locked, attempting to dirty it leads to a deadlock
in lock_page(). This is what currently happens to ITER_BVEC pages when
a dio-enabled loop device is backed by ceph:
$ losetup --direct-io /dev/loop0 /mnt/cephfs/img
$ xfs_io -c 'pread 0 4k' /dev/loop0
Follow other file systems and only dirty ITER_IOVEC pages.
Cc: stable(a)kernel.org
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/file.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -598,7 +598,8 @@ static ssize_t ceph_sync_read(struct kio
struct ceph_aio_request {
struct kiocb *iocb;
size_t total_len;
- int write;
+ bool write;
+ bool should_dirty;
int error;
struct list_head osd_reqs;
unsigned num_reqs;
@@ -708,7 +709,7 @@ static void ceph_aio_complete_req(struct
}
}
- ceph_put_page_vector(osd_data->pages, num_pages, !aio_req->write);
+ ceph_put_page_vector(osd_data->pages, num_pages, aio_req->should_dirty);
ceph_osdc_put_request(req);
if (rc < 0)
@@ -890,6 +891,7 @@ ceph_direct_read_write(struct kiocb *ioc
size_t count = iov_iter_count(iter);
loff_t pos = iocb->ki_pos;
bool write = iov_iter_rw(iter) == WRITE;
+ bool should_dirty = !write && iter_is_iovec(iter);
if (write && ceph_snap(file_inode(file)) != CEPH_NOSNAP)
return -EROFS;
@@ -954,6 +956,7 @@ ceph_direct_read_write(struct kiocb *ioc
if (aio_req) {
aio_req->iocb = iocb;
aio_req->write = write;
+ aio_req->should_dirty = should_dirty;
INIT_LIST_HEAD(&aio_req->osd_reqs);
if (write) {
aio_req->mtime = mtime;
@@ -1012,7 +1015,7 @@ ceph_direct_read_write(struct kiocb *ioc
len = ret;
}
- ceph_put_page_vector(pages, num_pages, !write);
+ ceph_put_page_vector(pages, num_pages, should_dirty);
ceph_osdc_put_request(req);
if (ret < 0)
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.9/ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
This is a note to let you know that I've just added the patch titled
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
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:
arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.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 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a Mon Sep 17 00:00:00 2001
From: Fabio Estevam <festevam(a)gmail.com>
Date: Mon, 22 Jan 2018 12:20:26 +0100
Subject: ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
From: Fabio Estevam <festevam(a)gmail.com>
commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to clearing vfp_current_hw_state[].
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable(a)vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji(a)jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Patches currently in stable-queue which might be from festevam(a)gmail.com are
queue-4.9/arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add native DSD support for TEAC UD-301
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:
alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.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 b00214865d65100163574ba250008f182cf90869 Mon Sep 17 00:00:00 2001
From: Nobutaka Okabe <nob77413(a)gmail.com>
Date: Fri, 23 Mar 2018 19:49:44 +0900
Subject: ALSA: usb-audio: Add native DSD support for TEAC UD-301
From: Nobutaka Okabe <nob77413(a)gmail.com>
commit b00214865d65100163574ba250008f182cf90869 upstream.
Add native DSD support quirk for TEAC UD-301 DAC,
by adding the PID/VID 0644:804a.
Signed-off-by: Nobutaka Okabe <nob77413(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1175,6 +1175,7 @@ static bool is_teac_dsd_dac(unsigned int
switch (id) {
case USB_ID(0x0644, 0x8043): /* TEAC UD-501/UD-503/NT-503 */
case USB_ID(0x0644, 0x8044): /* Esoteric D-05X */
+ case USB_ID(0x0644, 0x804a): /* TEAC UD-301 */
return true;
}
return false;
Patches currently in stable-queue which might be from nob77413(a)gmail.com are
queue-4.9/alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
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:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.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 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3410,7 +3410,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.9/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
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:
alsa-pcm-potential-uninitialized-return-values.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 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1361,7 +1361,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1468,7 +1468,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
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:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.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 f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.4/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
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:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.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 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.4/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
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:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.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 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3408,7 +3408,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.4/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
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:
alsa-pcm-potential-uninitialized-return-values.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 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1361,7 +1361,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1468,7 +1468,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.4/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
x86/platform/uv/BAU: Add APIC idt entry
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-platform-uv-bau-add-apic-idt-entry.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 151ad17fbe5e56afa59709f41980508672c777ce Mon Sep 17 00:00:00 2001
From: Andrew Banman <abanman(a)hpe.com>
Date: Tue, 27 Mar 2018 17:09:06 -0500
Subject: x86/platform/uv/BAU: Add APIC idt entry
From: Andrew Banman <abanman(a)hpe.com>
commit 151ad17fbe5e56afa59709f41980508672c777ce upstream.
BAU uses the old alloc_initr_gate90 method to setup its interrupt. This
fails silently as the BAU vector is in the range of APIC vectors that are
registered to the spurious interrupt handler. As a consequence BAU
broadcasts are not handled, and the broadcast source CPU hangs.
Update BAU to use new idt structure.
Fixes: dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code")
Signed-off-by: Andrew Banman <abanman(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Mike Travis <mike.travis(a)hpe.com>
Cc: Dimitri Sivanich <sivanich(a)hpe.com>
Cc: Russ Anderson <rja(a)hpe.com>
Cc: stable(a)vger.kernel.org
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Link: https://lkml.kernel.org/r/1522188546-196177-1-git-send-email-abanman@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/hw_irq.h | 1 +
arch/x86/kernel/idt.c | 3 +++
arch/x86/platform/uv/tlb_uv.c | 2 --
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -36,6 +36,7 @@ extern asmlinkage void kvm_posted_intr_w
extern asmlinkage void kvm_posted_intr_nested_ipi(void);
extern asmlinkage void error_interrupt(void);
extern asmlinkage void irq_work_interrupt(void);
+extern asmlinkage void uv_bau_message_intr1(void);
extern asmlinkage void spurious_interrupt(void);
extern asmlinkage void thermal_interrupt(void);
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -140,6 +140,9 @@ static const __initconst struct idt_data
# ifdef CONFIG_IRQ_WORK
INTG(IRQ_WORK_VECTOR, irq_work_interrupt),
# endif
+#ifdef CONFIG_X86_UV
+ INTG(UV_BAU_MESSAGE, uv_bau_message_intr1),
+#endif
INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt),
INTG(ERROR_APIC_VECTOR, error_interrupt),
#endif
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void)
init_uvhub(uvhub, vector, uv_base_pnode);
}
- alloc_intr_gate(vector, uv_bau_message_intr1);
-
for_each_possible_blade(uvhub) {
if (uv_blade_nr_possible_cpus(uvhub)) {
unsigned long val;
Patches currently in stable-queue which might be from abanman(a)hpe.com are
queue-4.15/x86-platform-uv-bau-add-apic-idt-entry.patch
This is a note to let you know that I've just added the patch titled
powerpc/mm: Workaround Nest MMU bug with TLB invalidations
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-mm-workaround-nest-mmu-bug-with-tlb-invalidations.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 80a4ae202f2d319eced8bbf612a4e8b0f11c21f5 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Fri, 23 Mar 2018 09:29:06 +1100
Subject: powerpc/mm: Workaround Nest MMU bug with TLB invalidations
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
commit 80a4ae202f2d319eced8bbf612a4e8b0f11c21f5 upstream.
On POWER9 the Nest MMU may fail to invalidate some translations when
doing a tlbie "by PID" or "by LPID" that is targeted at the TLB only
and not the page walk cache.
This works around it by forcing such invalidations to escalate to
RIC=2 (full invalidation of TLB *and* PWC) when a coprocessor is in
use for the context.
Fixes: 03b8abedf4f4 ("cxl: Enable global TLBIs for cxl contexts")
Cc: stable(a)vger.kernel.org # v4.15+
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Signed-off-by: Balbir Singh <bsingharora(a)gmail.com>
[balbirs: fixed spelling and coding style to quiesce checkpatch.pl]
Tested-by: Balbir Singh <bsingharora(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/mm/tlb-radix.c | 50 +++++++++++++++++++++++++++++++++++++-------
1 file changed, 43 insertions(+), 7 deletions(-)
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -85,7 +85,23 @@ static inline void _tlbiel_pid(unsigned
static inline void _tlbie_pid(unsigned long pid, unsigned long ric)
{
asm volatile("ptesync": : :"memory");
- __tlbie_pid(pid, ric);
+
+ /*
+ * Workaround the fact that the "ric" argument to __tlbie_pid
+ * must be a compile-time contraint to match the "i" constraint
+ * in the asm statement.
+ */
+ switch (ric) {
+ case RIC_FLUSH_TLB:
+ __tlbie_pid(pid, RIC_FLUSH_TLB);
+ break;
+ case RIC_FLUSH_PWC:
+ __tlbie_pid(pid, RIC_FLUSH_PWC);
+ break;
+ case RIC_FLUSH_ALL:
+ default:
+ __tlbie_pid(pid, RIC_FLUSH_ALL);
+ }
asm volatile("eieio; tlbsync; ptesync": : :"memory");
}
@@ -245,6 +261,16 @@ void radix__local_flush_tlb_page(struct
}
EXPORT_SYMBOL(radix__local_flush_tlb_page);
+static bool mm_needs_flush_escalation(struct mm_struct *mm)
+{
+ /*
+ * P9 nest MMU has issues with the page walk cache
+ * caching PTEs and not flushing them properly when
+ * RIC = 0 for a PID/LPID invalidate
+ */
+ return atomic_read(&mm->context.copros) != 0;
+}
+
#ifdef CONFIG_SMP
void radix__flush_tlb_mm(struct mm_struct *mm)
{
@@ -255,9 +281,12 @@ void radix__flush_tlb_mm(struct mm_struc
return;
preempt_disable();
- if (!mm_is_thread_local(mm))
- _tlbie_pid(pid, RIC_FLUSH_TLB);
- else
+ if (!mm_is_thread_local(mm)) {
+ if (mm_needs_flush_escalation(mm))
+ _tlbie_pid(pid, RIC_FLUSH_ALL);
+ else
+ _tlbie_pid(pid, RIC_FLUSH_TLB);
+ } else
_tlbiel_pid(pid, RIC_FLUSH_TLB);
preempt_enable();
}
@@ -369,10 +398,14 @@ void radix__flush_tlb_range(struct vm_ar
}
if (full) {
- if (local)
+ if (local) {
_tlbiel_pid(pid, RIC_FLUSH_TLB);
- else
- _tlbie_pid(pid, RIC_FLUSH_TLB);
+ } else {
+ if (mm_needs_flush_escalation(mm))
+ _tlbie_pid(pid, RIC_FLUSH_ALL);
+ else
+ _tlbie_pid(pid, RIC_FLUSH_TLB);
+ }
} else {
bool hflush = false;
unsigned long hstart, hend;
@@ -482,6 +515,9 @@ static inline void __radix__flush_tlb_ra
}
if (full) {
+ if (!local && mm_needs_flush_escalation(mm))
+ also_pwc = true;
+
if (local)
_tlbiel_pid(pid, also_pwc ? RIC_FLUSH_ALL : RIC_FLUSH_TLB);
else
Patches currently in stable-queue which might be from benh(a)kernel.crashing.org are
queue-4.15/powerpc-mm-add-tracking-of-the-number-of-coprocessors-using-a-context.patch
queue-4.15/powerpc-mm-workaround-nest-mmu-bug-with-tlb-invalidations.patch
This is a note to let you know that I've just added the patch titled
powerpc/mm: Add tracking of the number of coprocessors using a context
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-mm-add-tracking-of-the-number-of-coprocessors-using-a-context.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From aff6f8cb3e2170b9e58b0932bce7bfb492775e23 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Fri, 23 Mar 2018 09:29:05 +1100
Subject: powerpc/mm: Add tracking of the number of coprocessors using a context
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
commit aff6f8cb3e2170b9e58b0932bce7bfb492775e23 upstream.
Currently, when using coprocessors (which use the Nest MMU), we
simply increment the active_cpu count to force all TLB invalidations
to be come broadcast.
Unfortunately, due to an errata in POWER9, we will need to know
more specifically that coprocessors are in use.
This maintains a separate copros counter in the MMU context for
that purpose.
NB. The commit mentioned in the fixes tag below is not at fault for
the bug we're fixing in this commit and the next, but this fix applies
on top the infrastructure it introduced.
Fixes: 03b8abedf4f4 ("cxl: Enable global TLBIs for cxl contexts")
Cc: stable(a)vger.kernel.org # v4.15+
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Tested-by: Balbir Singh <bsingharora(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/book3s/64/mmu.h | 3 +++
arch/powerpc/include/asm/mmu_context.h | 18 +++++++++++++-----
arch/powerpc/mm/mmu_context_book3s64.c | 1 +
3 files changed, 17 insertions(+), 5 deletions(-)
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -87,6 +87,9 @@ typedef struct {
/* Number of bits in the mm_cpumask */
atomic_t active_cpus;
+ /* Number of users of the external (Nest) MMU */
+ atomic_t copros;
+
/* NPU NMMU context */
struct npu_context *npu_context;
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -92,15 +92,23 @@ static inline void dec_mm_active_cpus(st
static inline void mm_context_add_copro(struct mm_struct *mm)
{
/*
- * On hash, should only be called once over the lifetime of
- * the context, as we can't decrement the active cpus count
- * and flush properly for the time being.
+ * If any copro is in use, increment the active CPU count
+ * in order to force TLB invalidations to be global as to
+ * propagate to the Nest MMU.
*/
- inc_mm_active_cpus(mm);
+ if (atomic_inc_return(&mm->context.copros) == 1)
+ inc_mm_active_cpus(mm);
}
static inline void mm_context_remove_copro(struct mm_struct *mm)
{
+ int c;
+
+ c = atomic_dec_if_positive(&mm->context.copros);
+
+ /* Detect imbalance between add and remove */
+ WARN_ON(c < 0);
+
/*
* Need to broadcast a global flush of the full mm before
* decrementing active_cpus count, as the next TLBI may be
@@ -111,7 +119,7 @@ static inline void mm_context_remove_cop
* for the time being. Invalidations will remain global if
* used on hash.
*/
- if (radix_enabled()) {
+ if (c == 0 && radix_enabled()) {
flush_all_mm(mm);
dec_mm_active_cpus(mm);
}
--- a/arch/powerpc/mm/mmu_context_book3s64.c
+++ b/arch/powerpc/mm/mmu_context_book3s64.c
@@ -171,6 +171,7 @@ int init_new_context(struct task_struct
mm_iommu_init(mm);
#endif
atomic_set(&mm->context.active_cpus, 0);
+ atomic_set(&mm->context.copros, 0);
return 0;
}
Patches currently in stable-queue which might be from benh(a)kernel.crashing.org are
queue-4.15/powerpc-mm-add-tracking-of-the-number-of-coprocessors-using-a-context.patch
queue-4.15/powerpc-mm-workaround-nest-mmu-bug-with-tlb-invalidations.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ff6781fd1bb404d8a551c02c35c70cec1da17ff1 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 21 Mar 2018 12:22:28 +1000
Subject: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Nicholas Piggin <npiggin(a)gmail.com>
commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
force_external_irq_replay() can be called in the do_IRQ path with
interrupts hard enabled and soft disabled if may_hard_irq_enable() set
MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
store sequence. If a maskable interrupt hits during this sequence, it
will go to the masked handler to be marked pending in irq_happened.
This update will be lost when the interrupt returns and the store
instruction executes. This can result in unpredictable latencies,
timeouts, lockups, etc.
Fix this by ensuring hard interrupts are disabled before modifying
irq_happened.
This could cause any maskable asynchronous interrupt to get lost, but
it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
so very high external interrupt rate and high IPI rate. The hang was
bisected down to enabling doorbell interrupts for IPIs. These provided
an interrupt type that could run at high rates in the do_IRQ path,
stressing the race.
Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
Cc: stable(a)vger.kernel.org # v4.8+
Reported-by: Carol L. Soto <clsoto(a)us.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -475,6 +475,14 @@ void force_external_irq_replay(void)
*/
WARN_ON(!arch_irqs_disabled());
+ /*
+ * Interrupts must always be hard disabled before irq_happened is
+ * modified (to prevent lost update in case of interrupt between
+ * load and store).
+ */
+ __hard_irq_disable();
+ local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+
/* Indicate in the PACA that we have an interrupt to replay */
local_paca->irq_happened |= PACA_IRQ_EE;
}
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.15/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.15/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 52396500f97c53860164debc7d4f759077853423 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 23 Mar 2018 15:53:38 +1000
Subject: powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 52396500f97c53860164debc7d4f759077853423 upstream.
The SLB bad address handler's trap number fixup does not preserve the
low bit that indicates nonvolatile GPRs have not been saved. This
leads save_nvgprs to skip saving them, and subsequent functions and
return from interrupt will think they are saved.
This causes kernel branch-to-garbage debugging to not have correct
registers, can also cause userspace to have its registers clobbered
after a segfault.
Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
Cc: stable(a)vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -706,7 +706,7 @@ EXC_COMMON_BEGIN(bad_addr_slb)
ld r3, PACA_EXSLB+EX_DAR(r13)
std r3, _DAR(r1)
beq cr6, 2f
- li r10, 0x480 /* fix trap number for I-SLB miss */
+ li r10, 0x481 /* fix trap number for I-SLB miss */
std r10, _TRAP(r1)
2: bl save_nvgprs
addi r3, r1, STACK_FRAME_OVERHEAD
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.15/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.15/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.15/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
queue-4.15/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: atmel: Fix get_sectorsize() function
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-nand-atmel-fix-get_sectorsize-function.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2b1b1b4ac716fd929a2d221bd4ade62263bed915 Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
Date: Tue, 27 Mar 2018 19:01:58 +0200
Subject: mtd: nand: atmel: Fix get_sectorsize() function
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
commit 2b1b1b4ac716fd929a2d221bd4ade62263bed915 upstream.
get_sectorsize() was not using the appropriate macro to extract the
ECC sector size from the config cache, which led to buggy ECC when
using 1024 byte sectors.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: <stable(a)vger.kernel.org>
Reported-by: Olivier Schonken <olivier.schonken(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Tested-by: Olivier Schonken <olivier.schonken(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/atmel/pmecc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/nand/atmel/pmecc.c
+++ b/drivers/mtd/nand/atmel/pmecc.c
@@ -426,7 +426,7 @@ static int get_strength(struct atmel_pme
static int get_sectorsize(struct atmel_pmecc_user *user)
{
- return user->cache.cfg & PMECC_LOOKUP_TABLE_SIZE_1024 ? 1024 : 512;
+ return user->cache.cfg & PMECC_CFG_SECTOR1024 ? 1024 : 512;
}
static void atmel_pmecc_gen_syndrome(struct atmel_pmecc_user *user, int sector)
Patches currently in stable-queue which might be from boris.brezillon(a)bootlin.com are
queue-4.15/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
queue-4.15/mtd-nand-atmel-fix-get_sectorsize-function.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.15/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ipc/shm.c: add split function to shm_vm_ops
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipc-shm.c-add-split-function-to-shm_vm_ops.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Wed, 28 Mar 2018 16:01:01 -0700
Subject: ipc/shm.c: add split function to shm_vm_ops
From: Mike Kravetz <mike.kravetz(a)oracle.com>
commit 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 upstream.
If System V shmget/shmat operations are used to create a hugetlbfs
backed mapping, it is possible to munmap part of the mapping and split
the underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER: 20040000
CFAR: c00000000036ee44 SOFTE: 1
NIP __unmap_hugepage_range+0xa4/0x760
LR __unmap_hugepage_range_final+0x28/0x50
Call Trace:
0x7115e4e00000 (unreliable)
__unmap_hugepage_range_final+0x28/0x50
unmap_single_vma+0x11c/0x190
unmap_vmas+0x94/0x140
exit_mmap+0x9c/0x1d0
mmput+0xa8/0x1d0
do_exit+0x360/0xc80
do_group_exit+0x60/0x100
SyS_exit_group+0x24/0x30
system_call+0x58/0x6c
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
introduce ->split() to vm_operations_struct"). A split function was
added to vm_operations_struct to determine if a mapping can be split.
This was mostly for device-dax and hugetlbfs mappings which have
specific alignment constraints.
Mappings initiated via shmget/shmat have their original vm_ops
overwritten with shm_vm_ops. shm_vm_ops functions will call back to the
original vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vm
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
Patches currently in stable-queue which might be from mike.kravetz(a)oracle.com are
queue-4.15/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
i2c: i2c-stm32f7: fix no check on returned setup
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i2c-i2c-stm32f7-fix-no-check-on-returned-setup.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 771b7bf05339081019d22452ebcab6929372e13e Mon Sep 17 00:00:00 2001
From: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
Date: Wed, 21 Mar 2018 17:48:40 +0100
Subject: i2c: i2c-stm32f7: fix no check on returned setup
From: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
commit 771b7bf05339081019d22452ebcab6929372e13e upstream.
Before assigning returned setup structure check if not null
Fixes: 463a9215f3ca7600b5ff ("i2c: stm32f7: fix setup structure")
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
Acked-by: Alexandre TORGUE <alexandre.torgue(a)st.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Cc: stable(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-stm32f7.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -888,6 +888,11 @@ static int stm32f7_i2c_probe(struct plat
}
setup = of_device_get_match_data(&pdev->dev);
+ if (!setup) {
+ dev_err(&pdev->dev, "Can't get device data\n");
+ ret = -ENODEV;
+ goto clk_free;
+ }
i2c_dev->setup = *setup;
ret = device_property_read_u32(i2c_dev->dev, "i2c-scl-rising-time-ns",
Patches currently in stable-queue which might be from pierre-yves.mordret(a)st.com are
queue-4.15/i2c-i2c-stm32f7-fix-no-check-on-returned-setup.patch
This is a note to let you know that I've just added the patch titled
ceph: only dirty ITER_IOVEC pages for direct read
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 85784f9395987a422fa04263e7c0fb13da11eb5c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Fri, 16 Mar 2018 11:22:29 +0800
Subject: ceph: only dirty ITER_IOVEC pages for direct read
From: Yan, Zheng <zyan(a)redhat.com>
commit 85784f9395987a422fa04263e7c0fb13da11eb5c upstream.
If a page is already locked, attempting to dirty it leads to a deadlock
in lock_page(). This is what currently happens to ITER_BVEC pages when
a dio-enabled loop device is backed by ceph:
$ losetup --direct-io /dev/loop0 /mnt/cephfs/img
$ xfs_io -c 'pread 0 4k' /dev/loop0
Follow other file systems and only dirty ITER_IOVEC pages.
Cc: stable(a)kernel.org
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/file.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -635,7 +635,8 @@ static ssize_t ceph_sync_read(struct kio
struct ceph_aio_request {
struct kiocb *iocb;
size_t total_len;
- int write;
+ bool write;
+ bool should_dirty;
int error;
struct list_head osd_reqs;
unsigned num_reqs;
@@ -745,7 +746,7 @@ static void ceph_aio_complete_req(struct
}
}
- ceph_put_page_vector(osd_data->pages, num_pages, !aio_req->write);
+ ceph_put_page_vector(osd_data->pages, num_pages, aio_req->should_dirty);
ceph_osdc_put_request(req);
if (rc < 0)
@@ -842,6 +843,7 @@ ceph_direct_read_write(struct kiocb *ioc
size_t count = iov_iter_count(iter);
loff_t pos = iocb->ki_pos;
bool write = iov_iter_rw(iter) == WRITE;
+ bool should_dirty = !write && iter_is_iovec(iter);
if (write && ceph_snap(file_inode(file)) != CEPH_NOSNAP)
return -EROFS;
@@ -909,6 +911,7 @@ ceph_direct_read_write(struct kiocb *ioc
if (aio_req) {
aio_req->iocb = iocb;
aio_req->write = write;
+ aio_req->should_dirty = should_dirty;
INIT_LIST_HEAD(&aio_req->osd_reqs);
if (write) {
aio_req->mtime = mtime;
@@ -966,7 +969,7 @@ ceph_direct_read_write(struct kiocb *ioc
len = ret;
}
- ceph_put_page_vector(pages, num_pages, !write);
+ ceph_put_page_vector(pages, num_pages, should_dirty);
ceph_osdc_put_request(req);
if (ret < 0)
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.15/ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP: Fix SRAM W+X mapping
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap-fix-sram-w-x-mapping.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From eb85a355c3afd9379f5953cfe2df73632d14c884 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony(a)atomide.com>
Date: Wed, 21 Mar 2018 08:16:29 -0700
Subject: ARM: OMAP: Fix SRAM W+X mapping
From: Tony Lindgren <tony(a)atomide.com>
commit eb85a355c3afd9379f5953cfe2df73632d14c884 upstream.
We are still using custom SRAM code for some SoCs and are not marking
the PM code mapped to SRAM as read-only and executable after we're
done. With CONFIG_DEBUG_WX=y, we will get "Found insecure W+X mapping
at address" warning.
Let's fix this issue the same way as commit 728bbe75c82f ("misc: sram:
Introduce support code for protect-exec sram type") is doing for
drivers/misc/sram-exec.c.
On omap3, we need to restore SRAM when returning from off mode after
idle, so init time configuration is not enough.
And as we no longer have users for omap_sram_push_address() we can
make it static while at it.
Note that eventually we should be using sram-exec.c for all SoCs.
Cc: stable(a)vger.kernel.org # v4.12+
Cc: Dave Gerlach <d-gerlach(a)ti.com>
Reported-by: Pavel Machek <pavel(a)ucw.cz>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/plat-omap/include/plat/sram.h | 11 ----------
arch/arm/plat-omap/sram.c | 36 ++++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 11 deletions(-)
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -5,13 +5,4 @@ void omap_map_sram(unsigned long start,
unsigned long skip, int cached);
void omap_sram_reset(void);
-extern void *omap_sram_push_address(unsigned long size);
-
-/* Macro to push a function to the internal SRAM, using the fncpy API */
-#define omap_sram_push(funcp, size) ({ \
- typeof(&(funcp)) _res = NULL; \
- void *_sram_address = omap_sram_push_address(size); \
- if (_sram_address) \
- _res = fncpy(_sram_address, &(funcp), size); \
- _res; \
-})
+extern void *omap_sram_push(void *funcp, unsigned long size);
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -23,6 +23,7 @@
#include <asm/fncpy.h>
#include <asm/tlb.h>
#include <asm/cacheflush.h>
+#include <asm/set_memory.h>
#include <asm/mach/map.h>
@@ -42,7 +43,7 @@ static void __iomem *omap_sram_ceil;
* Note that fncpy requires the returned address to be aligned
* to an 8-byte boundary.
*/
-void *omap_sram_push_address(unsigned long size)
+static void *omap_sram_push_address(unsigned long size)
{
unsigned long available, new_ceil = (unsigned long)omap_sram_ceil;
@@ -60,6 +61,30 @@ void *omap_sram_push_address(unsigned lo
return (void *)omap_sram_ceil;
}
+void *omap_sram_push(void *funcp, unsigned long size)
+{
+ void *sram;
+ unsigned long base;
+ int pages;
+ void *dst = NULL;
+
+ sram = omap_sram_push_address(size);
+ if (!sram)
+ return NULL;
+
+ base = (unsigned long)sram & PAGE_MASK;
+ pages = PAGE_ALIGN(size) / PAGE_SIZE;
+
+ set_memory_rw(base, pages);
+
+ dst = fncpy(sram, funcp, size);
+
+ set_memory_ro(base, pages);
+ set_memory_x(base, pages);
+
+ return dst;
+}
+
/*
* The SRAM context is lost during off-idle and stack
* needs to be reset.
@@ -75,6 +100,9 @@ void omap_sram_reset(void)
void __init omap_map_sram(unsigned long start, unsigned long size,
unsigned long skip, int cached)
{
+ unsigned long base;
+ int pages;
+
if (size == 0)
return;
@@ -95,4 +123,10 @@ void __init omap_map_sram(unsigned long
*/
memset_io(omap_sram_base + omap_sram_skip, 0,
omap_sram_size - omap_sram_skip);
+
+ base = (unsigned long)omap_sram_base;
+ pages = PAGE_ALIGN(omap_sram_size) / PAGE_SIZE;
+
+ set_memory_ro(base, pages);
+ set_memory_x(base, pages);
}
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.15/arm-omap-fix-sram-w-x-mapping.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-sun6i-a31s-bpi-m2-improve-pmic-properties.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf Mon Sep 17 00:00:00 2001
From: Philipp Rossak <embed3d(a)gmail.com>
Date: Wed, 14 Feb 2018 15:10:24 +0100
Subject: ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
From: Philipp Rossak <embed3d(a)gmail.com>
commit b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf upstream.
The eldoin is supplied from the dcdc1 regulator. The N_VBUSEN pin is
connected to an external power regulator (SY6280AAC).
With this commit we update the pmic binding properties to support
those features.
Fixes: 7daa21370075 ("ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Philipp Rossak <embed3d(a)gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -163,6 +163,8 @@
reg = <0x68>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <®_dcdc1>;
+ x-powers,drive-vbus-en;
};
};
Patches currently in stable-queue which might be from embed3d(a)gmail.com are
queue-4.15/arm-dts-sun6i-a31s-bpi-m2-improve-pmic-properties.patch
queue-4.15/arm-dts-sun6i-a31s-bpi-m2-add-missing-regulators.patch
This is a note to let you know that I've just added the patch titled
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a Mon Sep 17 00:00:00 2001
From: Fabio Estevam <festevam(a)gmail.com>
Date: Mon, 22 Jan 2018 12:20:26 +0100
Subject: ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
From: Fabio Estevam <festevam(a)gmail.com>
commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to clearing vfp_current_hw_state[].
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable(a)vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji(a)jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Patches currently in stable-queue which might be from festevam(a)gmail.com are
queue-4.15/arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3422,7 +3422,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.15/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add native DSD support for TEAC UD-301
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b00214865d65100163574ba250008f182cf90869 Mon Sep 17 00:00:00 2001
From: Nobutaka Okabe <nob77413(a)gmail.com>
Date: Fri, 23 Mar 2018 19:49:44 +0900
Subject: ALSA: usb-audio: Add native DSD support for TEAC UD-301
From: Nobutaka Okabe <nob77413(a)gmail.com>
commit b00214865d65100163574ba250008f182cf90869 upstream.
Add native DSD support quirk for TEAC UD-301 DAC,
by adding the PID/VID 0644:804a.
Signed-off-by: Nobutaka Okabe <nob77413(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1171,6 +1171,7 @@ static bool is_teac_dsd_dac(unsigned int
switch (id) {
case USB_ID(0x0644, 0x8043): /* TEAC UD-501/UD-503/NT-503 */
case USB_ID(0x0644, 0x8044): /* Esoteric D-05X */
+ case USB_ID(0x0644, 0x804a): /* TEAC UD-301 */
return true;
}
return false;
Patches currently in stable-queue which might be from nob77413(a)gmail.com are
queue-4.15/alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-potential-uninitialized-return-values.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1326,7 +1326,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1433,7 +1433,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
x86/platform/uv/BAU: Add APIC idt entry
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-platform-uv-bau-add-apic-idt-entry.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 151ad17fbe5e56afa59709f41980508672c777ce Mon Sep 17 00:00:00 2001
From: Andrew Banman <abanman(a)hpe.com>
Date: Tue, 27 Mar 2018 17:09:06 -0500
Subject: x86/platform/uv/BAU: Add APIC idt entry
From: Andrew Banman <abanman(a)hpe.com>
commit 151ad17fbe5e56afa59709f41980508672c777ce upstream.
BAU uses the old alloc_initr_gate90 method to setup its interrupt. This
fails silently as the BAU vector is in the range of APIC vectors that are
registered to the spurious interrupt handler. As a consequence BAU
broadcasts are not handled, and the broadcast source CPU hangs.
Update BAU to use new idt structure.
Fixes: dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code")
Signed-off-by: Andrew Banman <abanman(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Mike Travis <mike.travis(a)hpe.com>
Cc: Dimitri Sivanich <sivanich(a)hpe.com>
Cc: Russ Anderson <rja(a)hpe.com>
Cc: stable(a)vger.kernel.org
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Link: https://lkml.kernel.org/r/1522188546-196177-1-git-send-email-abanman@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/hw_irq.h | 1 +
arch/x86/kernel/idt.c | 3 +++
arch/x86/platform/uv/tlb_uv.c | 2 --
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -34,6 +34,7 @@ extern asmlinkage void kvm_posted_intr_w
extern asmlinkage void kvm_posted_intr_nested_ipi(void);
extern asmlinkage void error_interrupt(void);
extern asmlinkage void irq_work_interrupt(void);
+extern asmlinkage void uv_bau_message_intr1(void);
extern asmlinkage void spurious_interrupt(void);
extern asmlinkage void thermal_interrupt(void);
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -140,6 +140,9 @@ static const __initconst struct idt_data
# ifdef CONFIG_IRQ_WORK
INTG(IRQ_WORK_VECTOR, irq_work_interrupt),
# endif
+#ifdef CONFIG_X86_UV
+ INTG(UV_BAU_MESSAGE, uv_bau_message_intr1),
+#endif
INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt),
INTG(ERROR_APIC_VECTOR, error_interrupt),
#endif
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void)
init_uvhub(uvhub, vector, uv_base_pnode);
}
- alloc_intr_gate(vector, uv_bau_message_intr1);
-
for_each_possible_blade(uvhub) {
if (uv_blade_nr_possible_cpus(uvhub)) {
unsigned long val;
Patches currently in stable-queue which might be from abanman(a)hpe.com are
queue-4.14/x86-platform-uv-bau-add-apic-idt-entry.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
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:
powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.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 ff6781fd1bb404d8a551c02c35c70cec1da17ff1 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 21 Mar 2018 12:22:28 +1000
Subject: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Nicholas Piggin <npiggin(a)gmail.com>
commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
force_external_irq_replay() can be called in the do_IRQ path with
interrupts hard enabled and soft disabled if may_hard_irq_enable() set
MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
store sequence. If a maskable interrupt hits during this sequence, it
will go to the masked handler to be marked pending in irq_happened.
This update will be lost when the interrupt returns and the store
instruction executes. This can result in unpredictable latencies,
timeouts, lockups, etc.
Fix this by ensuring hard interrupts are disabled before modifying
irq_happened.
This could cause any maskable asynchronous interrupt to get lost, but
it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
so very high external interrupt rate and high IPI rate. The hang was
bisected down to enabling doorbell interrupts for IPIs. These provided
an interrupt type that could run at high rates in the do_IRQ path,
stressing the race.
Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
Cc: stable(a)vger.kernel.org # v4.8+
Reported-by: Carol L. Soto <clsoto(a)us.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -430,6 +430,14 @@ void force_external_irq_replay(void)
*/
WARN_ON(!arch_irqs_disabled());
+ /*
+ * Interrupts must always be hard disabled before irq_happened is
+ * modified (to prevent lost update in case of interrupt between
+ * load and store).
+ */
+ __hard_irq_disable();
+ local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+
/* Indicate in the PACA that we have an interrupt to replay */
local_paca->irq_happened |= PACA_IRQ_EE;
}
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.14/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
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:
powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.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 52396500f97c53860164debc7d4f759077853423 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 23 Mar 2018 15:53:38 +1000
Subject: powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 52396500f97c53860164debc7d4f759077853423 upstream.
The SLB bad address handler's trap number fixup does not preserve the
low bit that indicates nonvolatile GPRs have not been saved. This
leads save_nvgprs to skip saving them, and subsequent functions and
return from interrupt will think they are saved.
This causes kernel branch-to-garbage debugging to not have correct
registers, can also cause userspace to have its registers clobbered
after a segfault.
Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
Cc: stable(a)vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -704,7 +704,7 @@ EXC_COMMON_BEGIN(bad_addr_slb)
ld r3, PACA_EXSLB+EX_DAR(r13)
std r3, _DAR(r1)
beq cr6, 2f
- li r10, 0x480 /* fix trap number for I-SLB miss */
+ li r10, 0x481 /* fix trap number for I-SLB miss */
std r10, _TRAP(r1)
2: bl save_nvgprs
addi r3, r1, STACK_FRAME_OVERHEAD
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.14/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
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:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.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 f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.14/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
queue-4.14/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: atmel: Fix get_sectorsize() function
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:
mtd-nand-atmel-fix-get_sectorsize-function.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 2b1b1b4ac716fd929a2d221bd4ade62263bed915 Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
Date: Tue, 27 Mar 2018 19:01:58 +0200
Subject: mtd: nand: atmel: Fix get_sectorsize() function
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
commit 2b1b1b4ac716fd929a2d221bd4ade62263bed915 upstream.
get_sectorsize() was not using the appropriate macro to extract the
ECC sector size from the config cache, which led to buggy ECC when
using 1024 byte sectors.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: <stable(a)vger.kernel.org>
Reported-by: Olivier Schonken <olivier.schonken(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Tested-by: Olivier Schonken <olivier.schonken(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/atmel/pmecc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/nand/atmel/pmecc.c
+++ b/drivers/mtd/nand/atmel/pmecc.c
@@ -426,7 +426,7 @@ static int get_strength(struct atmel_pme
static int get_sectorsize(struct atmel_pmecc_user *user)
{
- return user->cache.cfg & PMECC_LOOKUP_TABLE_SIZE_1024 ? 1024 : 512;
+ return user->cache.cfg & PMECC_CFG_SECTOR1024 ? 1024 : 512;
}
static void atmel_pmecc_gen_syndrome(struct atmel_pmecc_user *user, int sector)
Patches currently in stable-queue which might be from boris.brezillon(a)bootlin.com are
queue-4.14/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
queue-4.14/mtd-nand-atmel-fix-get_sectorsize-function.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
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:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.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 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.14/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ipc/shm.c: add split function to shm_vm_ops
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:
ipc-shm.c-add-split-function-to-shm_vm_ops.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 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Wed, 28 Mar 2018 16:01:01 -0700
Subject: ipc/shm.c: add split function to shm_vm_ops
From: Mike Kravetz <mike.kravetz(a)oracle.com>
commit 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 upstream.
If System V shmget/shmat operations are used to create a hugetlbfs
backed mapping, it is possible to munmap part of the mapping and split
the underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER: 20040000
CFAR: c00000000036ee44 SOFTE: 1
NIP __unmap_hugepage_range+0xa4/0x760
LR __unmap_hugepage_range_final+0x28/0x50
Call Trace:
0x7115e4e00000 (unreliable)
__unmap_hugepage_range_final+0x28/0x50
unmap_single_vma+0x11c/0x190
unmap_vmas+0x94/0x140
exit_mmap+0x9c/0x1d0
mmput+0xa8/0x1d0
do_exit+0x360/0xc80
do_group_exit+0x60/0x100
SyS_exit_group+0x24/0x30
system_call+0x58/0x6c
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
introduce ->split() to vm_operations_struct"). A split function was
added to vm_operations_struct to determine if a mapping can be split.
This was mostly for device-dax and hugetlbfs mappings which have
specific alignment constraints.
Mappings initiated via shmget/shmat have their original vm_ops
overwritten with shm_vm_ops. shm_vm_ops functions will call back to the
original vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vm
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
Patches currently in stable-queue which might be from mike.kravetz(a)oracle.com are
queue-4.14/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
i2c: i2c-stm32f7: fix no check on returned setup
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:
i2c-i2c-stm32f7-fix-no-check-on-returned-setup.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 771b7bf05339081019d22452ebcab6929372e13e Mon Sep 17 00:00:00 2001
From: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
Date: Wed, 21 Mar 2018 17:48:40 +0100
Subject: i2c: i2c-stm32f7: fix no check on returned setup
From: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
commit 771b7bf05339081019d22452ebcab6929372e13e upstream.
Before assigning returned setup structure check if not null
Fixes: 463a9215f3ca7600b5ff ("i2c: stm32f7: fix setup structure")
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
Acked-by: Alexandre TORGUE <alexandre.torgue(a)st.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Cc: stable(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-stm32f7.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -887,6 +887,11 @@ static int stm32f7_i2c_probe(struct plat
}
setup = of_device_get_match_data(&pdev->dev);
+ if (!setup) {
+ dev_err(&pdev->dev, "Can't get device data\n");
+ ret = -ENODEV;
+ goto clk_free;
+ }
i2c_dev->setup = *setup;
ret = device_property_read_u32(i2c_dev->dev, "i2c-scl-rising-time-ns",
Patches currently in stable-queue which might be from pierre-yves.mordret(a)st.com are
queue-4.14/i2c-i2c-stm32f7-fix-no-check-on-returned-setup.patch
This is a note to let you know that I've just added the patch titled
ceph: only dirty ITER_IOVEC pages for direct read
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:
ceph-only-dirty-iter_iovec-pages-for-direct-read.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 85784f9395987a422fa04263e7c0fb13da11eb5c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Fri, 16 Mar 2018 11:22:29 +0800
Subject: ceph: only dirty ITER_IOVEC pages for direct read
From: Yan, Zheng <zyan(a)redhat.com>
commit 85784f9395987a422fa04263e7c0fb13da11eb5c upstream.
If a page is already locked, attempting to dirty it leads to a deadlock
in lock_page(). This is what currently happens to ITER_BVEC pages when
a dio-enabled loop device is backed by ceph:
$ losetup --direct-io /dev/loop0 /mnt/cephfs/img
$ xfs_io -c 'pread 0 4k' /dev/loop0
Follow other file systems and only dirty ITER_IOVEC pages.
Cc: stable(a)kernel.org
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/file.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -635,7 +635,8 @@ static ssize_t ceph_sync_read(struct kio
struct ceph_aio_request {
struct kiocb *iocb;
size_t total_len;
- int write;
+ bool write;
+ bool should_dirty;
int error;
struct list_head osd_reqs;
unsigned num_reqs;
@@ -745,7 +746,7 @@ static void ceph_aio_complete_req(struct
}
}
- ceph_put_page_vector(osd_data->pages, num_pages, !aio_req->write);
+ ceph_put_page_vector(osd_data->pages, num_pages, aio_req->should_dirty);
ceph_osdc_put_request(req);
if (rc < 0)
@@ -842,6 +843,7 @@ ceph_direct_read_write(struct kiocb *ioc
size_t count = iov_iter_count(iter);
loff_t pos = iocb->ki_pos;
bool write = iov_iter_rw(iter) == WRITE;
+ bool should_dirty = !write && iter_is_iovec(iter);
if (write && ceph_snap(file_inode(file)) != CEPH_NOSNAP)
return -EROFS;
@@ -909,6 +911,7 @@ ceph_direct_read_write(struct kiocb *ioc
if (aio_req) {
aio_req->iocb = iocb;
aio_req->write = write;
+ aio_req->should_dirty = should_dirty;
INIT_LIST_HEAD(&aio_req->osd_reqs);
if (write) {
aio_req->mtime = mtime;
@@ -966,7 +969,7 @@ ceph_direct_read_write(struct kiocb *ioc
len = ret;
}
- ceph_put_page_vector(pages, num_pages, !write);
+ ceph_put_page_vector(pages, num_pages, should_dirty);
ceph_osdc_put_request(req);
if (ret < 0)
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.14/ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP: Fix SRAM W+X mapping
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:
arm-omap-fix-sram-w-x-mapping.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 eb85a355c3afd9379f5953cfe2df73632d14c884 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony(a)atomide.com>
Date: Wed, 21 Mar 2018 08:16:29 -0700
Subject: ARM: OMAP: Fix SRAM W+X mapping
From: Tony Lindgren <tony(a)atomide.com>
commit eb85a355c3afd9379f5953cfe2df73632d14c884 upstream.
We are still using custom SRAM code for some SoCs and are not marking
the PM code mapped to SRAM as read-only and executable after we're
done. With CONFIG_DEBUG_WX=y, we will get "Found insecure W+X mapping
at address" warning.
Let's fix this issue the same way as commit 728bbe75c82f ("misc: sram:
Introduce support code for protect-exec sram type") is doing for
drivers/misc/sram-exec.c.
On omap3, we need to restore SRAM when returning from off mode after
idle, so init time configuration is not enough.
And as we no longer have users for omap_sram_push_address() we can
make it static while at it.
Note that eventually we should be using sram-exec.c for all SoCs.
Cc: stable(a)vger.kernel.org # v4.12+
Cc: Dave Gerlach <d-gerlach(a)ti.com>
Reported-by: Pavel Machek <pavel(a)ucw.cz>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/plat-omap/include/plat/sram.h | 11 ----------
arch/arm/plat-omap/sram.c | 36 ++++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 11 deletions(-)
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -5,13 +5,4 @@ void omap_map_sram(unsigned long start,
unsigned long skip, int cached);
void omap_sram_reset(void);
-extern void *omap_sram_push_address(unsigned long size);
-
-/* Macro to push a function to the internal SRAM, using the fncpy API */
-#define omap_sram_push(funcp, size) ({ \
- typeof(&(funcp)) _res = NULL; \
- void *_sram_address = omap_sram_push_address(size); \
- if (_sram_address) \
- _res = fncpy(_sram_address, &(funcp), size); \
- _res; \
-})
+extern void *omap_sram_push(void *funcp, unsigned long size);
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -23,6 +23,7 @@
#include <asm/fncpy.h>
#include <asm/tlb.h>
#include <asm/cacheflush.h>
+#include <asm/set_memory.h>
#include <asm/mach/map.h>
@@ -42,7 +43,7 @@ static void __iomem *omap_sram_ceil;
* Note that fncpy requires the returned address to be aligned
* to an 8-byte boundary.
*/
-void *omap_sram_push_address(unsigned long size)
+static void *omap_sram_push_address(unsigned long size)
{
unsigned long available, new_ceil = (unsigned long)omap_sram_ceil;
@@ -60,6 +61,30 @@ void *omap_sram_push_address(unsigned lo
return (void *)omap_sram_ceil;
}
+void *omap_sram_push(void *funcp, unsigned long size)
+{
+ void *sram;
+ unsigned long base;
+ int pages;
+ void *dst = NULL;
+
+ sram = omap_sram_push_address(size);
+ if (!sram)
+ return NULL;
+
+ base = (unsigned long)sram & PAGE_MASK;
+ pages = PAGE_ALIGN(size) / PAGE_SIZE;
+
+ set_memory_rw(base, pages);
+
+ dst = fncpy(sram, funcp, size);
+
+ set_memory_ro(base, pages);
+ set_memory_x(base, pages);
+
+ return dst;
+}
+
/*
* The SRAM context is lost during off-idle and stack
* needs to be reset.
@@ -75,6 +100,9 @@ void omap_sram_reset(void)
void __init omap_map_sram(unsigned long start, unsigned long size,
unsigned long skip, int cached)
{
+ unsigned long base;
+ int pages;
+
if (size == 0)
return;
@@ -95,4 +123,10 @@ void __init omap_map_sram(unsigned long
*/
memset_io(omap_sram_base + omap_sram_skip, 0,
omap_sram_size - omap_sram_skip);
+
+ base = (unsigned long)omap_sram_base;
+ pages = PAGE_ALIGN(omap_sram_size) / PAGE_SIZE;
+
+ set_memory_ro(base, pages);
+ set_memory_x(base, pages);
}
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.14/arm-omap-fix-sram-w-x-mapping.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
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:
arm-dts-sun6i-a31s-bpi-m2-improve-pmic-properties.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 b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf Mon Sep 17 00:00:00 2001
From: Philipp Rossak <embed3d(a)gmail.com>
Date: Wed, 14 Feb 2018 15:10:24 +0100
Subject: ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
From: Philipp Rossak <embed3d(a)gmail.com>
commit b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf upstream.
The eldoin is supplied from the dcdc1 regulator. The N_VBUSEN pin is
connected to an external power regulator (SY6280AAC).
With this commit we update the pmic binding properties to support
those features.
Fixes: 7daa21370075 ("ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Philipp Rossak <embed3d(a)gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -163,6 +163,8 @@
reg = <0x68>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <®_dcdc1>;
+ x-powers,drive-vbus-en;
};
};
Patches currently in stable-queue which might be from embed3d(a)gmail.com are
queue-4.14/arm-dts-sun6i-a31s-bpi-m2-improve-pmic-properties.patch
queue-4.14/arm-dts-sun6i-a31s-bpi-m2-add-missing-regulators.patch
This is a note to let you know that I've just added the patch titled
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
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:
arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.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 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a Mon Sep 17 00:00:00 2001
From: Fabio Estevam <festevam(a)gmail.com>
Date: Mon, 22 Jan 2018 12:20:26 +0100
Subject: ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
From: Fabio Estevam <festevam(a)gmail.com>
commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to clearing vfp_current_hw_state[].
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable(a)vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji(a)jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Patches currently in stable-queue which might be from festevam(a)gmail.com are
queue-4.14/arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add native DSD support for TEAC UD-301
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:
alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.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 b00214865d65100163574ba250008f182cf90869 Mon Sep 17 00:00:00 2001
From: Nobutaka Okabe <nob77413(a)gmail.com>
Date: Fri, 23 Mar 2018 19:49:44 +0900
Subject: ALSA: usb-audio: Add native DSD support for TEAC UD-301
From: Nobutaka Okabe <nob77413(a)gmail.com>
commit b00214865d65100163574ba250008f182cf90869 upstream.
Add native DSD support quirk for TEAC UD-301 DAC,
by adding the PID/VID 0644:804a.
Signed-off-by: Nobutaka Okabe <nob77413(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1177,6 +1177,7 @@ static bool is_teac_dsd_dac(unsigned int
switch (id) {
case USB_ID(0x0644, 0x8043): /* TEAC UD-501/UD-503/NT-503 */
case USB_ID(0x0644, 0x8044): /* Esoteric D-05X */
+ case USB_ID(0x0644, 0x804a): /* TEAC UD-301 */
return true;
}
return false;
Patches currently in stable-queue which might be from nob77413(a)gmail.com are
queue-4.14/alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
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:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.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 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3424,7 +3424,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.14/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
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:
alsa-pcm-potential-uninitialized-return-values.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 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1326,7 +1326,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1433,7 +1433,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.14/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
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:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.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 f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-3.18/tty-vt-fix-up-tabstops-properly.patch
queue-3.18/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
queue-3.18/kvm-x86-fix-icebp-instruction-handling.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
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:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.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 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-3.18/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
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:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.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 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3394,7 +3394,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#elif defined(CONFIG_MIPS) && defined(CONFIG_DMA_NONCOHERENT)
if (substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV &&
!plat_device_is_coherent(substream->dma_buffer.dev.dev))
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-3.18/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
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:
alsa-pcm-potential-uninitialized-return-values.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 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1362,7 +1362,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1469,7 +1469,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-3.18/alsa-pcm-potential-uninitialized-return-values.patch
queue-3.18/staging-ncpfs-memory-corruption-in-ncp_read_kernel.patch
Hi!
4.16-rc7 doesn't seem to be in stable.git yet. Am I too impatient or perhaps having a git-pull-problem here?
Thanks!
Rainer Fiebig
--
The truth always turns out to be simpler than you thought.
Richard Feynman
On 03/31/2018 01:38 PM, Jason Andryuk wrote:
> On Wed, Mar 21, 2018, 5:12 PM Boris Ostrovsky
> <boris.ostrovsky(a)oracle.com <mailto:boris.ostrovsky@oracle.com>> wrote:
>
> On 03/19/2018 12:58 PM, Jason Andryuk wrote:
> > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings")
> introduced a
> > call to get_cpu_cap, which is fstack-protected. This is works on
> x86-64
> > as commit 4f277295e54c ("x86/xen: init %gs very early to avoid page
> > faults with stack protector") ensures the stack protector is
> configured,
> > but it it did not cover x86-32.
> >
> > Delay calling get_cpu_cap until after xen_setup_gdt has
> initialized the
> > stack canary. Without this, a 32bit PV machine crashes early
> > in boot.
> > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > (XEN) ----[ Xen-4.6.6-xc x86_64 debug=n Tainted: C ]----
> > (XEN) CPU: 0
> > (XEN) RIP: e019:[<00000000c10362f8>]
> >
> > And the PV kernel IP corresponds to init_scattered_cpuid_features
> > 0xc10362f8 <+24>: mov %gs:0x14,%eax
> >
> > Fixes 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings")
> >
> > Signed-off-by: Jason Andryuk <jandryuk(a)gmail.com
> <mailto:jandryuk@gmail.com>>
> >
>
>
> Applied to for-linus-4.17
>
>
> Thanks. If it's not too late, can this be cc: stable?
We can always try ;-)
This is 4.15 and 4.16 only, I believe.
-boris
> If not, I'll
> submit the request after it is in Linus's tree.
>
> -Jason
>
I'm announcing the release of the 4.4.126 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 -
drivers/net/ethernet/arc/emac_rockchip.c | 6 +++--
drivers/net/ethernet/broadcom/bcmsysport.c | 33 +++++++++++++----------------
drivers/net/ethernet/broadcom/bcmsysport.h | 2 -
drivers/net/ethernet/freescale/fec_main.c | 2 +
drivers/net/ethernet/ti/cpsw.c | 3 +-
drivers/net/team/team.c | 4 +--
drivers/s390/net/qeth_core_main.c | 21 +++++++++++++-----
drivers/s390/net/qeth_l2_main.c | 2 -
drivers/s390/net/qeth_l3_main.c | 2 -
drivers/scsi/sg.c | 5 ++--
kernel/irq/manage.c | 4 ---
net/core/skbuff.c | 2 -
net/dccp/proto.c | 5 ++++
net/ieee802154/6lowpan/core.c | 12 +++++++---
net/ipv4/inet_fragment.c | 3 ++
net/ipv4/ip_sockglue.c | 6 +++--
net/ipv6/ndisc.c | 3 +-
net/iucv/af_iucv.c | 4 ++-
net/l2tp/l2tp_core.c | 8 +++++--
net/netlink/genetlink.c | 2 -
21 files changed, 81 insertions(+), 50 deletions(-)
Alexey Kodanev (1):
dccp: check sk for closed state in dccp_sendmsg()
Arkadi Sharshevsky (1):
team: Fix double free in error path
Arvind Yadav (1):
net/iucv: Free memory obtained by kzalloc
Christophe JAILLET (1):
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
David Ahern (1):
net: Only honor ifindex in IP_PKTINFO if non-0
Eric Dumazet (2):
l2tp: do not accept arbitrary sockets
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
Florian Fainelli (2):
net: fec: Fix unbalanced PM runtime calls
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
Greg Kroah-Hartman (2):
Revert "genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs"
Linux 4.4.126
Johannes Thumshirn (1):
scsi: sg: don't return bogus Sg_requests
Julian Wiedmann (4):
s390/qeth: free netdevice when removing a card
s390/qeth: when thread completes, wake up all waiters
s390/qeth: lock read device while queueing next buffer
s390/qeth: on channel error, reject further cmd requests
Kirill Tkhai (1):
net: Fix hlist corruptions in inet_evict_bucket()
Lorenzo Bianconi (1):
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
Nicolas Dichtel (1):
netlink: avoid a double skb free in genlmsg_mcast()
SZ Lin (林上智) (1):
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
Vinicius Costa Gomes (1):
skbuff: Fix not waking applications when errors are enqueued
This is a note to let you know that I've just added the patch titled
[PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
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:
revert-genirq-use-irqd_get_trigger_type-to-compare-the.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 5512cca5c518c20037b10369a4725327202dd80b Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 30 Mar 2018 10:53:44 +0200
Subject: [PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
trigger type for shared IRQs"
This reverts commit f2596a9808acfd02ce1ee389f0e1c37e64aec5f6 which is
commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 upstream.
It causes too many problems with the stable tree, and would require too
many other things to be backported, so just revert it.
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/manage.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1210,10 +1210,8 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
-
if (!((old->flags & new->flags) & IRQF_SHARED) ||
- (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
+ ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
((old->flags ^ new->flags) & IRQF_ONESHOT))
goto mismatch;
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/net-fix-hlist-corruptions-in-inet_evict_bucket.patch
queue-4.9/ppp-avoid-loop-in-xmit-recursion-detection-code.patch
queue-4.9/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.9/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
queue-4.9/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.9/rhashtable-fix-rhlist-duplicates-insertion.patch
queue-4.9/kcm-lock-lower-socket-in-kcm_attach.patch
queue-4.9/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.9/sch_netem-fix-skb-leak-in-netem_enqueue.patch
queue-4.9/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.9/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.9/revert-genirq-use-irqd_get_trigger_type-to-compare-the.patch
queue-4.9/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.9/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-4.9/team-fix-double-free-in-error-path.patch
queue-4.9/net-use-skb_to_full_sk-in-skb_update_prio.patch
queue-4.9/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
queue-4.9/net-hns-fix-a-skb-used-after-free-bug.patch
queue-4.9/soc-fsl-qbman-fix-issue-in-qman_delete_cgr_safe.patch
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.9/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
queue-4.9/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.9/scsi-sg-don-t-return-bogus-sg_requests.patch
queue-4.9/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
queue-4.9/net-fec-fix-unbalanced-pm-runtime-calls.patch
queue-4.9/net-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.patch
queue-4.9/net-sched-actions-return-explicit-error-when-tunnel_key-mode-is-not-specified.patch
queue-4.9/s390-qeth-free-netdevice-when-removing-a-card.patch
This is the start of the stable review cycle for the 4.15.15 release.
There are 47 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 Sat Mar 31 17:57:05 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.15-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.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.15.15-rc1
Arkadi Sharshevsky <arkadis(a)mellanox.com>
team: Fix double free in error path
Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
skbuff: Fix not waking applications when errors are enqueued
Michal Kalderon <Michal.Kalderon(a)cavium.com>
qede: Fix qedr link update
Florian Fainelli <f.fainelli(a)gmail.com>
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
David Ahern <dsahern(a)gmail.com>
net: Only honor ifindex in IP_PKTINFO if non-0
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
netlink: avoid a double skb free in genlmsg_mcast()
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
net/iucv: Free memory obtained by kzalloc
Florian Fainelli <f.fainelli(a)gmail.com>
net: fec: Fix unbalanced PM runtime calls
SZ Lin (林上智) <sz.lin(a)moxa.com>
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
Eric Dumazet <edumazet(a)google.com>
l2tp: do not accept arbitrary sockets
Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: check sk for closed state in dccp_sendmsg()
Camelia Groza <camelia.groza(a)nxp.com>
dpaa_eth: remove duplicate increment of the tx_errors counter
Camelia Groza <camelia.groza(a)nxp.com>
dpaa_eth: increment the RX dropped counter when needed
Camelia Groza <camelia.groza(a)nxp.com>
dpaa_eth: remove duplicate initialization
Madalin Bucur <madalin.bucur(a)nxp.com>
dpaa_eth: fix error in dpaa_remove()
Madalin Bucur <madalin.bucur(a)nxp.com>
soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: on channel error, reject further cmd requests
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: lock read device while queueing next buffer
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: when thread completes, wake up all waiters
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: free netdevice when removing a card
Kirill Tkhai <ktkhai(a)virtuozzo.com>
net: Fix hlist corruptions in inet_evict_bucket()
Eric Dumazet <edumazet(a)google.com>
net: use skb_to_full_sk() in skb_update_prio()
Eric Dumazet <edumazet(a)google.com>
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sch_netem: fix skb leak in netem_enqueue()
Tom Herbert <tom(a)quantonium.net>
kcm: lock lower socket in kcm_attach
Paul Blakey <paulb(a)mellanox.com>
test_rhashtable: add test case for rhltable with duplicate objects
Paul Blakey <paulb(a)mellanox.com>
rhashtable: Fix rhlist duplicates insertion
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: avoid loop in xmit recursion detection code
Roman Mashak <mrv(a)mojatatu.com>
net sched actions: return explicit error when tunnel_key mode is not specified
Stefano Brivio <sbrivio(a)redhat.com>
ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes
Brad Mouring <brad.mouring(a)ni.com>
net: phy: Tell caller result of phy_change()
Ido Schimmel <idosch(a)mellanox.com>
mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic
David Lebrun <dlebrun(a)google.com>
ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
David Lebrun <dlebrun(a)google.com>
ipv6: sr: fix NULL pointer dereference when setting encap source address
Stefano Brivio <sbrivio(a)redhat.com>
ipv6: old_dport should be a __be16 in __ip6_datagram_connect()
Paolo Abeni <pabeni(a)redhat.com>
net: ipv6: keep sk status consistent after datagram connect failure
Shannon Nelson <shannon.nelson(a)oracle.com>
macvlan: filter out unsupported feature flags
Arkadi Sharshevsky <arkadis(a)mellanox.com>
devlink: Remove redundant free on error path
Grygorii Strashko <grygorii.strashko(a)ti.com>
net: phy: relax error checking when creating sysfs link netdev->phydev
Grygorii Strashko <grygorii.strashko(a)ti.com>
sysfs: symlink: export sysfs_create_link_nowarn()
Michal Kalderon <Michal.Kalderon(a)cavium.com>
qed: Fix non TCP packets should be dropped on iWARP ll2 connection
Soheil Hassas Yeganeh <soheil(a)google.com>
tcp: purge write queue upon aborting the connection
Michal Kalderon <Michal.Kalderon(a)cavium.com>
qed: Fix MPA unalign flow in case header is split across two packets.
zhangliping <zhangliping02(a)baidu.com>
openvswitch: meter: fix the incorrect calculation of max delta_t
Florian Fainelli <f.fainelli(a)gmail.com>
net: dsa: Fix dsa_is_user_port() test inversion
-------------
Diffstat:
Makefile | 4 +-
drivers/net/ethernet/arc/emac_rockchip.c | 6 +-
drivers/net/ethernet/broadcom/bcmsysport.c | 33 ++--
drivers/net/ethernet/broadcom/bcmsysport.h | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 12 +-
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 17 +-
drivers/net/ethernet/qlogic/qede/qede_main.c | 4 +-
drivers/net/ethernet/ti/cpsw.c | 3 +-
drivers/net/macvlan.c | 2 +-
drivers/net/phy/phy.c | 173 ++++++++++-----------
drivers/net/phy/phy_device.c | 15 +-
drivers/net/ppp/ppp_generic.c | 26 ++--
drivers/net/team/team.c | 4 +-
drivers/s390/net/qeth_core_main.c | 21 ++-
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
drivers/soc/fsl/qbman/qman.c | 28 +---
fs/sysfs/symlink.c | 1 +
include/linux/cgroup-defs.h | 4 +-
include/linux/phy.h | 1 -
include/linux/rhashtable.h | 4 +-
include/net/sch_generic.h | 19 +++
lib/rhashtable.c | 4 +-
lib/test_rhashtable.c | 134 ++++++++++++++++
net/core/dev.c | 22 ++-
net/core/devlink.c | 16 +-
net/core/skbuff.c | 2 +-
net/dccp/proto.c | 5 +
net/dsa/legacy.c | 2 +-
net/ieee802154/6lowpan/core.c | 12 +-
net/ipv4/inet_fragment.c | 3 +
net/ipv4/ip_sockglue.c | 6 +-
net/ipv4/tcp.c | 1 +
net/ipv4/tcp_timer.c | 1 +
net/ipv6/datagram.c | 21 ++-
net/ipv6/ndisc.c | 3 +-
net/ipv6/route.c | 71 +++++----
net/ipv6/seg6_iptunnel.c | 7 +-
net/iucv/af_iucv.c | 4 +-
net/kcm/kcmsock.c | 33 ++--
net/l2tp/l2tp_core.c | 8 +-
net/netlink/genetlink.c | 2 +-
net/openvswitch/meter.c | 12 +-
net/sched/act_tunnel_key.c | 1 +
net/sched/sch_netem.c | 2 +-
47 files changed, 501 insertions(+), 264 deletions(-)
This is the start of the stable review cycle for the 4.4.126 release.
There are 20 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 Sat Mar 31 17:57:30 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.126-rc…
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.126-rc1
Florian Fainelli <f.fainelli(a)gmail.com>
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
Florian Fainelli <f.fainelli(a)gmail.com>
net: fec: Fix unbalanced PM runtime calls
Eric Dumazet <edumazet(a)google.com>
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: on channel error, reject further cmd requests
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: lock read device while queueing next buffer
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: when thread completes, wake up all waiters
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: free netdevice when removing a card
Arkadi Sharshevsky <arkadis(a)mellanox.com>
team: Fix double free in error path
Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
skbuff: Fix not waking applications when errors are enqueued
David Ahern <dsahern(a)gmail.com>
net: Only honor ifindex in IP_PKTINFO if non-0
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
netlink: avoid a double skb free in genlmsg_mcast()
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
net/iucv: Free memory obtained by kzalloc
SZ Lin (林上智) <sz.lin(a)moxa.com>
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
Eric Dumazet <edumazet(a)google.com>
l2tp: do not accept arbitrary sockets
Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: check sk for closed state in dccp_sendmsg()
Kirill Tkhai <ktkhai(a)virtuozzo.com>
net: Fix hlist corruptions in inet_evict_bucket()
Marc Zyngier <marc.zyngier(a)arm.com>
genirq: Track whether the trigger type has been set
Johannes Thumshirn <jthumshirn(a)suse.de>
scsi: sg: don't return bogus Sg_requests
-------------
Diffstat:
Makefile | 4 ++--
drivers/net/ethernet/arc/emac_rockchip.c | 6 ++++--
drivers/net/ethernet/broadcom/bcmsysport.c | 33 ++++++++++++++----------------
drivers/net/ethernet/broadcom/bcmsysport.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 2 ++
drivers/net/ethernet/ti/cpsw.c | 3 ++-
drivers/net/team/team.c | 4 ++--
drivers/s390/net/qeth_core_main.c | 21 +++++++++++++------
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
drivers/scsi/sg.c | 5 +++--
include/linux/irq.h | 11 +++++++++-
kernel/irq/manage.c | 13 +++++++++++-
net/core/skbuff.c | 2 +-
net/dccp/proto.c | 5 +++++
net/ieee802154/6lowpan/core.c | 12 +++++++----
net/ipv4/inet_fragment.c | 3 +++
net/ipv4/ip_sockglue.c | 6 ++++--
net/ipv6/ndisc.c | 3 ++-
net/iucv/af_iucv.c | 4 +++-
net/l2tp/l2tp_core.c | 8 ++++++--
net/netlink/genetlink.c | 2 +-
22 files changed, 103 insertions(+), 50 deletions(-)
From: Eric Biggers <ebiggers(a)google.com>
ext4 isn't validating the sizes of xattrs. This is problematic
because ->e_value_size is a u32, but ext4_xattr_get() returns an int.
A very large size is misinterpreted as an error code, which
ext4_get_acl() translates into a bogus ERR_PTR() for which IS_ERR()
returns false, causing a crash.
Fix this by validating that all xattrs are <= INT_MAX bytes. Also add
explicit checks in ext4_xattr_block_get() and ext4_xattr_ibody_get()
just in case the xattr block is corrupted in memory.
Also if the xattr block is corrupted, mark the file system as
containing an error.
This issue has been assigned CVE-2018-1095.
https://bugzilla.kernel.org/show_bug.cgi?id=199185https://bugzilla.redhat.com/show_bug.cgi?id=1560793
Reported-by: Wen Xu <wen.xu(a)gatech.edu>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)vger.kernel.org
---
fs/ext4/xattr.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 63656dbafdc4..d2a9b078e121 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -195,10 +195,14 @@ ext4_xattr_check_entries(struct ext4_xattr_entry *entry, void *end,
/* Check the values */
while (!IS_LAST_ENTRY(entry)) {
+ u32 size = le32_to_cpu(entry->e_value_size);
+
+ if (size > INT_MAX)
+ return -EFSCORRUPTED;
+
if (entry->e_value_size != 0 &&
entry->e_value_inum == 0) {
u16 offs = le16_to_cpu(entry->e_value_offs);
- u32 size = le32_to_cpu(entry->e_value_size);
void *value;
/*
@@ -523,8 +527,10 @@ ext4_xattr_block_get(struct inode *inode, int name_index, const char *name,
if (error)
goto cleanup;
size = le32_to_cpu(entry->e_value_size);
+ error = -ERANGE;
+ if (unlikely(size > INT_MAX))
+ goto cleanup;
if (buffer) {
- error = -ERANGE;
if (size > buffer_size)
goto cleanup;
if (entry->e_value_inum) {
@@ -572,8 +578,10 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
if (error)
goto cleanup;
size = le32_to_cpu(entry->e_value_size);
+ error = -ERANGE;
+ if (unlikely(size > INT_MAX))
+ goto cleanup;
if (buffer) {
- error = -ERANGE;
if (size > buffer_size)
goto cleanup;
if (entry->e_value_inum) {
--
2.16.1.72.g5be1f00a9a
The patch titled
Subject: hugetlbfs: fix bug in pgoff overflow checking
has been added to the -mm tree. Its filename is
hugetlbfs-fix-bug-in-pgoff-overflow-checking.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/hugetlbfs-fix-bug-in-pgoff-overflo…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/hugetlbfs-fix-bug-in-pgoff-overflo…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: hugetlbfs: fix bug in pgoff overflow checking
This is a fix for a regression in 32 bit kernels caused by an invalid
check for pgoff overflow in hugetlbfs mmap setup. The check incorrectly
specified that the size of a loff_t was the same as the size of a long.
The regression prevents mapping hugetlbfs files at offsets greater than
4GB on 32 bit kernels.
On 32 bit kernels conversion from a page based unsigned long can not
overflow a loff_t byte offset. Therefore, skip this check if
sizeof(unsigned long) != sizeof(loff_t).
Link: http://lkml.kernel.org/r/20180330145402.5053-1-mike.kravetz@oracle.com
Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow")
Reported-by: Dan Rue <dan.rue(a)linaro.org>
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Nic Losby <blurbdust(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/hugetlbfs/inode.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff -puN fs/hugetlbfs/inode.c~hugetlbfs-fix-bug-in-pgoff-overflow-checking fs/hugetlbfs/inode.c
--- a/fs/hugetlbfs/inode.c~hugetlbfs-fix-bug-in-pgoff-overflow-checking
+++ a/fs/hugetlbfs/inode.c
@@ -138,10 +138,14 @@ static int hugetlbfs_file_mmap(struct fi
/*
* page based offset in vm_pgoff could be sufficiently large to
- * overflow a (l)off_t when converted to byte offset.
+ * overflow a loff_t when converted to byte offset. This can
+ * only happen on architectures where sizeof(loff_t) ==
+ * sizeof(unsigned long). So, only check in those instances.
*/
- if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
- return -EINVAL;
+ if (sizeof(unsigned long) == sizeof(loff_t)) {
+ if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
+ return -EINVAL;
+ }
/* must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
_
Patches currently in -mm which might be from mike.kravetz(a)oracle.com are
hugetlbfs-fix-bug-in-pgoff-overflow-checking.patch
mm-hugetlbfs-move-hugetlbfs_i-outside-ifdef-config_hugetlbfs.patch
mm-memfd-split-out-memfd-for-use-by-multiple-filesystems.patch
mm-memfd-remove-memfd-code-from-shmem-files-and-use-new-memfd-files.patch
mm-make-start_isolate_page_range-fail-if-already-isolated.patch
The patch titled
Subject: mm/memblock: fix potential issue in memblock_search_pfn_nid()
has been added to the -mm tree. Its filename is
mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memblock-fix-potential-issue-in…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memblock-fix-potential-issue-in…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Wei Yang <richard.weiyang(a)gmail.com>
Subject: mm/memblock: fix potential issue in memblock_search_pfn_nid()
memblock_search_pfn_nid() returns the nid and the [start|end]_pfn of the
memory region where pfn sits in. While the calculation of start_pfn has
potential issue when the regions base is not page aligned.
For example, we assume PAGE_SHIFT is 12 and base is 0x1234. Current
implementation would return 1 while this is not correct.
This patch fixes this by using PFN_UP().
The original commit is commit e76b63f80d93 ("memblock, numa: binary search
node id") and merged in v3.12.
Link: http://lkml.kernel.org/r/20180330033055.22340-1-richard.weiyang@gmail.com
Fixes: e76b63f80d93 ("memblock, numa: binary search node id")
Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Yinghai Lu <yinghai(a)kernel.org>
Cc: Jia He <hejianet(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/memblock.c~mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid mm/memblock.c
--- a/mm/memblock.c~mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid
+++ a/mm/memblock.c
@@ -1646,7 +1646,7 @@ int __init_memblock memblock_search_pfn_
if (mid == -1)
return -1;
- *start_pfn = PFN_DOWN(type->regions[mid].base);
+ *start_pfn = PFN_UP(type->regions[mid].base);
*end_pfn = PFN_DOWN(type->regions[mid].base + type->regions[mid].size);
return type->regions[mid].nid;
_
Patches currently in -mm which might be from richard.weiyang(a)gmail.com are
mm-check-__highest_present_sectioin_nr-directly-in-memory_dev_init.patch
mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid.patch
The patch titled
Subject: ipc/shm.c: add split function to shm_vm_ops
has been removed from the -mm tree. Its filename was
shm-add-split-function-to-shm_vm_ops.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: ipc/shm.c: add split function to shm_vm_ops
If System V shmget/shmat operations are used to create a hugetlbfs backed
mapping, it is possible to munmap part of the mapping and split the
underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
8<--8<--8<--8< snip 8<--8<--8<--8<
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E
4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E
(4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER:
20040000
CFAR: c00000000036ee44 SOFTE: 1
GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40
GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000
GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000
GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554
GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40
GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950
NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760
LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50
Call Trace:
[c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable)
[c000003fbcdcfb50] [c00000000036ee48]
__unmap_hugepage_range_final+0x28/0x50
[c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190
[c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140
[c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0
[c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0
[c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80
[c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100
[c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30
[c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c
Instruction dump:
552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010
7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by 31383c6865a5 ("mm, hugetlbfs: introduce
->split() to vm_operations_struct"). A split function was added to
vm_operations_struct to determine if a mapping can be split. This was
mostly for device-dax and hugetlbfs mappings which have specific alignment
constraints.
Mappings initiated via shmget/shmat have their original vm_ops overwritten
with shm_vm_ops. shm_vm_ops functions will call back to the original
vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff -puN ipc/shm.c~shm-add-split-function-to-shm_vm_ops ipc/shm.c
--- a/ipc/shm.c~shm-add-split-function-to-shm_vm_ops
+++ a/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vm
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
_
Patches currently in -mm which might be from mike.kravetz(a)oracle.com are
mm-hugetlbfs-move-hugetlbfs_i-outside-ifdef-config_hugetlbfs.patch
mm-memfd-split-out-memfd-for-use-by-multiple-filesystems.patch
mm-memfd-remove-memfd-code-from-shmem-files-and-use-new-memfd-files.patch
mm-make-start_isolate_page_range-fail-if-already-isolated.patch
Hi again EXT4 ML!
Here's a mail that would be sent as a result of an autoselection. It
will note the "score" of the patch, and will run the same tests we
do for patches tagged for stable.
As before, please let me know your thoughts on this. Thanks!
===
Hi Eryu Guan,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 59.259)
The bot has tested the following trees: v4.15.12, v4.14.29, v4.9.89, v4.4.123, v4.1.50, v3.18.101.
v4.15.12: Build OK!
v4.14.29: Build OK!
v4.9.89: Build OK!
v4.4.123: Failed to apply! Possible dependencies:
914f82a32d02: ("ext4: refactor direct IO code")
705965bd6dfa: ("ext4: rename and split get blocks functions")
ba5843f51d46: ("ext4: use pre-zeroed blocks for DAX page faults")
c86d8db33a92: ("ext4: implement allocation of pre-zeroed blocks")
2dcba4781fa3: ("ext4: get rid of EXT4_GET_BLOCKS_NO_LOCK flag")
v4.1.50: Failed to apply! Possible dependencies:
914f82a32d02: ("ext4: refactor direct IO code")
705965bd6dfa: ("ext4: rename and split get blocks functions")
ba5843f51d46: ("ext4: use pre-zeroed blocks for DAX page faults")
ed923b5776a2: ("ext4: add ext4_get_block_dax()")
e676a4c19165: ("ext4: use ext4_get_block_write() for DAX")
11bd1a9ecdd6: ("ext4: huge page fault support")
e676a4c19165: ("ext4: use ext4_get_block_write() for DAX")
01a33b4ace68: ("ext4: start transaction before calling into DAX")
ed923b5776a2: ("ext4: add ext4_get_block_dax()")
e676a4c19165: ("ext4: use ext4_get_block_write() for DAX")
11bd1a9ecdd6: ("ext4: huge page fault support")
11bd1a9ecdd6: ("ext4: huge page fault support")
v3.18.101: Failed to apply! Possible dependencies:
914f82a32d02: ("ext4: refactor direct IO code")
6f67376318ab: ("direct_IO: use iov_iter_rw() instead of rw everywhere")
ef96fdddcd38: ("staging: lustre: lustre: llite: use DIV_ROUND_UP")
42b1ab979d92: ("9p: get rid of v9fs_direct_file_read()")
9565a5445240: ("9p: get rid of v9fs_direct_file_write()")
9abb40830700: ("fs/affs/file.c: add support to O_DIRECT")
92b20708f9f0: ("fs/affs/file.c: fix direct IO writes beyond EOF")
9abb40830700: ("fs/affs/file.c: add support to O_DIRECT")
17f8c842d24a: ("Remove rw from {,__,do_}blockdev_direct_IO()")
92b20708f9f0: ("fs/affs/file.c: fix direct IO writes beyond EOF")
9abb40830700: ("fs/affs/file.c: add support to O_DIRECT")
9abb40830700: ("fs/affs/file.c: add support to O_DIRECT")
EXT4 Specific tests:
v4.15.12 (http://stable-bot.westus2.cloudapp.azure.com/ext4-test2/v4.15.12/tests/):
Tests complete.
v4.14.29 (http://stable-bot.westus2.cloudapp.azure.com/ext4-test2/v4.14.29/tests/):
Tests complete.
v4.9.89 (http://stable-bot.westus2.cloudapp.azure.com/ext4-test2/v4.9.89/tests/):
Tests complete.
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks,
Sasha
This is the start of the stable review cycle for the 4.9.92 release.
There are 28 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 Sat Mar 31 17:57:18 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.92-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.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.9.92-rc1
Yunsheng Lin <linyunsheng(a)huawei.com>
net: hns: Fix a skb used after free bug
Tom Herbert <tom(a)quantonium.net>
kcm: lock lower socket in kcm_attach
Florian Fainelli <f.fainelli(a)gmail.com>
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: on channel error, reject further cmd requests
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: lock read device while queueing next buffer
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: when thread completes, wake up all waiters
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: free netdevice when removing a card
Madalin Bucur <madalin.bucur(a)nxp.com>
soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
Arkadi Sharshevsky <arkadis(a)mellanox.com>
team: Fix double free in error path
Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
skbuff: Fix not waking applications when errors are enqueued
David Ahern <dsahern(a)gmail.com>
net: Only honor ifindex in IP_PKTINFO if non-0
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
netlink: avoid a double skb free in genlmsg_mcast()
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
net/iucv: Free memory obtained by kzalloc
Florian Fainelli <f.fainelli(a)gmail.com>
net: fec: Fix unbalanced PM runtime calls
SZ Lin (林上智) <sz.lin(a)moxa.com>
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
Eric Dumazet <edumazet(a)google.com>
l2tp: do not accept arbitrary sockets
Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: check sk for closed state in dccp_sendmsg()
Kirill Tkhai <ktkhai(a)virtuozzo.com>
net: Fix hlist corruptions in inet_evict_bucket()
Eric Dumazet <edumazet(a)google.com>
net: use skb_to_full_sk() in skb_update_prio()
Eric Dumazet <edumazet(a)google.com>
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sch_netem: fix skb leak in netem_enqueue()
Paul Blakey <paulb(a)mellanox.com>
rhashtable: Fix rhlist duplicates insertion
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: avoid loop in xmit recursion detection code
Roman Mashak <mrv(a)mojatatu.com>
net sched actions: return explicit error when tunnel_key mode is not specified
Marc Zyngier <marc.zyngier(a)arm.com>
genirq: Track whether the trigger type has been set
Johannes Thumshirn <jthumshirn(a)suse.de>
scsi: sg: don't return bogus Sg_requests
-------------
Diffstat:
Makefile | 4 ++--
drivers/net/ethernet/arc/emac_rockchip.c | 6 +++--
drivers/net/ethernet/broadcom/bcmsysport.c | 33 ++++++++++++---------------
drivers/net/ethernet/broadcom/bcmsysport.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 2 ++
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 22 ++++++++----------
drivers/net/ethernet/hisilicon/hns/hns_enet.h | 6 ++---
drivers/net/ethernet/ti/cpsw.c | 3 ++-
drivers/net/ppp/ppp_generic.c | 26 +++++++++++----------
drivers/net/team/team.c | 4 ++--
drivers/s390/net/qeth_core_main.c | 21 ++++++++++++-----
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
drivers/scsi/sg.c | 5 ++--
drivers/soc/fsl/qbman/qman.c | 28 ++++-------------------
include/linux/cgroup-defs.h | 4 ++--
include/linux/irq.h | 11 ++++++++-
include/linux/rhashtable.h | 4 +++-
include/net/sch_generic.h | 19 +++++++++++++++
kernel/irq/manage.c | 13 ++++++++++-
lib/rhashtable.c | 4 +++-
net/core/dev.c | 22 ++++++++++++------
net/core/skbuff.c | 2 +-
net/dccp/proto.c | 5 ++++
net/ieee802154/6lowpan/core.c | 12 ++++++----
net/ipv4/inet_fragment.c | 3 +++
net/ipv4/ip_sockglue.c | 6 +++--
net/ipv6/ndisc.c | 3 ++-
net/iucv/af_iucv.c | 4 +++-
net/kcm/kcmsock.c | 33 +++++++++++++++++++--------
net/l2tp/l2tp_core.c | 8 +++++--
net/netlink/genetlink.c | 2 +-
net/sched/act_tunnel_key.c | 1 +
net/sched/sch_netem.c | 2 +-
34 files changed, 202 insertions(+), 122 deletions(-)
This is the start of the stable review cycle for the 4.14.32 release.
There are 43 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 Sat Mar 31 17:57:12 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.32-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.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.14.32-rc1
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: on channel error, reject further cmd requests
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: lock read device while queueing next buffer
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: when thread completes, wake up all waiters
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: free netdevice when removing a card
Camelia Groza <camelia.groza(a)nxp.com>
dpaa_eth: remove duplicate increment of the tx_errors counter
Camelia Groza <camelia.groza(a)nxp.com>
dpaa_eth: increment the RX dropped counter when needed
Camelia Groza <camelia.groza(a)nxp.com>
dpaa_eth: remove duplicate initialization
Madalin Bucur <madalin.bucur(a)nxp.com>
dpaa_eth: fix error in dpaa_remove()
Madalin Bucur <madalin.bucur(a)nxp.com>
soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
Arkadi Sharshevsky <arkadis(a)mellanox.com>
team: Fix double free in error path
Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
skbuff: Fix not waking applications when errors are enqueued
Michal Kalderon <Michal.Kalderon(a)cavium.com>
qede: Fix qedr link update
Florian Fainelli <f.fainelli(a)gmail.com>
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
David Ahern <dsahern(a)gmail.com>
net: Only honor ifindex in IP_PKTINFO if non-0
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
netlink: avoid a double skb free in genlmsg_mcast()
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
net/iucv: Free memory obtained by kzalloc
Florian Fainelli <f.fainelli(a)gmail.com>
net: fec: Fix unbalanced PM runtime calls
SZ Lin (林上智) <sz.lin(a)moxa.com>
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
Eric Dumazet <edumazet(a)google.com>
l2tp: do not accept arbitrary sockets
Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: check sk for closed state in dccp_sendmsg()
Kirill Tkhai <ktkhai(a)virtuozzo.com>
net: Fix hlist corruptions in inet_evict_bucket()
Eric Dumazet <edumazet(a)google.com>
net: use skb_to_full_sk() in skb_update_prio()
Eric Dumazet <edumazet(a)google.com>
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sch_netem: fix skb leak in netem_enqueue()
Tom Herbert <tom(a)quantonium.net>
kcm: lock lower socket in kcm_attach
Paul Blakey <paulb(a)mellanox.com>
rhashtable: Fix rhlist duplicates insertion
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: avoid loop in xmit recursion detection code
Roman Mashak <mrv(a)mojatatu.com>
net sched actions: return explicit error when tunnel_key mode is not specified
Brad Mouring <brad.mouring(a)ni.com>
net: phy: Tell caller result of phy_change()
Ido Schimmel <idosch(a)mellanox.com>
mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic
David Lebrun <dlebrun(a)google.com>
ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
David Lebrun <dlebrun(a)google.com>
ipv6: sr: fix NULL pointer dereference when setting encap source address
Stefano Brivio <sbrivio(a)redhat.com>
ipv6: old_dport should be a __be16 in __ip6_datagram_connect()
Paolo Abeni <pabeni(a)redhat.com>
net: ipv6: keep sk status consistent after datagram connect failure
Shannon Nelson <shannon.nelson(a)oracle.com>
macvlan: filter out unsupported feature flags
Arkadi Sharshevsky <arkadis(a)mellanox.com>
devlink: Remove redundant free on error path
Grygorii Strashko <grygorii.strashko(a)ti.com>
net: phy: relax error checking when creating sysfs link netdev->phydev
Grygorii Strashko <grygorii.strashko(a)ti.com>
sysfs: symlink: export sysfs_create_link_nowarn()
Michal Kalderon <Michal.Kalderon(a)cavium.com>
qed: Fix non TCP packets should be dropped on iWARP ll2 connection
Soheil Hassas Yeganeh <soheil(a)google.com>
tcp: purge write queue upon aborting the connection
Soheil Hassas Yeganeh <soheil(a)google.com>
tcp: reset sk_send_head in tcp_write_queue_purge
-------------
Diffstat:
Makefile | 4 +-
drivers/net/ethernet/arc/emac_rockchip.c | 6 +-
drivers/net/ethernet/broadcom/bcmsysport.c | 33 ++--
drivers/net/ethernet/broadcom/bcmsysport.h | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 12 +-
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 15 ++
drivers/net/ethernet/qlogic/qede/qede_main.c | 4 +-
drivers/net/ethernet/ti/cpsw.c | 3 +-
drivers/net/macvlan.c | 2 +-
drivers/net/phy/phy.c | 173 ++++++++++-----------
drivers/net/phy/phy_device.c | 15 +-
drivers/net/ppp/ppp_generic.c | 26 ++--
drivers/net/team/team.c | 4 +-
drivers/s390/net/qeth_core_main.c | 21 ++-
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
drivers/soc/fsl/qbman/qman.c | 28 +---
fs/sysfs/symlink.c | 1 +
include/linux/cgroup-defs.h | 4 +-
include/linux/phy.h | 1 -
include/linux/rhashtable.h | 4 +-
include/net/sch_generic.h | 19 +++
include/net/tcp.h | 11 +-
lib/rhashtable.c | 4 +-
net/core/dev.c | 22 ++-
net/core/devlink.c | 16 +-
net/core/skbuff.c | 2 +-
net/dccp/proto.c | 5 +
net/ieee802154/6lowpan/core.c | 12 +-
net/ipv4/inet_fragment.c | 3 +
net/ipv4/ip_sockglue.c | 6 +-
net/ipv4/tcp.c | 1 +
net/ipv4/tcp_timer.c | 1 +
net/ipv6/datagram.c | 21 ++-
net/ipv6/ndisc.c | 3 +-
net/ipv6/seg6_iptunnel.c | 7 +-
net/iucv/af_iucv.c | 4 +-
net/kcm/kcmsock.c | 33 ++--
net/l2tp/l2tp_core.c | 8 +-
net/netlink/genetlink.c | 2 +-
net/sched/act_tunnel_key.c | 1 +
net/sched/sch_netem.c | 2 +-
44 files changed, 320 insertions(+), 235 deletions(-)
USB controller ASM1042 stops working after commit de3ef1eb1cd0 ("PM /
core: Drop run_wake flag from struct dev_pm_info").
The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended, so it does not
respond to any PME#.
usb_hcd_pci_probe() mandatorily calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.
So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.
Fixes: de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info")
Cc: stable(a)vger.kernel.org # 4.13+
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
---
v2: Explicitly check dev->pme_support.
drivers/pci/pci.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..52821a21fc07 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2125,16 +2125,16 @@ bool pci_dev_run_wake(struct pci_dev *dev)
{
struct pci_bus *bus = dev->bus;
- if (device_can_wakeup(&dev->dev))
- return true;
-
if (!dev->pme_support)
return false;
/* PME-capable in principle, but not from the target power state */
- if (!pci_pme_capable(dev, pci_target_state(dev, false)))
+ if (!pci_pme_capable(dev, pci_target_state(dev, true)))
return false;
+ if (device_can_wakeup(&dev->dev))
+ return true;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
--
2.15.1
Hi Greg,
commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger
type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed
upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has
been set"). Please apply that patch to v4.4.y at your earliest convenience.
The patch does not apply cleanly; you'll get a conflict include/linux/irq.h.
The fix is simple - just take the version introduced by the patch. It adds
a couple of extra defines, but those don't hurt and just keep the code aligned
with upstream.
Thanks,
Guenter
This is a note to let you know that I've just added the patch titled
[PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
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-genirq-use-irqd_get_trigger_type-to-compare-the.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 6ac05ec9c1bdefb8a88aefd4681869814b3f6c73 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 30 Mar 2018 10:56:51 +0200
Subject: [PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
trigger type for shared IRQs"
This reverts commit 093c265afffb0a91a7611c3bb74d0883731a807b which is
commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 upstream.
It causes too many problems with the stable tree, and would require too
many other things to be backported, so just revert it.
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/manage.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1058,10 +1058,8 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
-
if (!((old->flags & new->flags) & IRQF_SHARED) ||
- (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
+ ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
((old->flags ^ new->flags) & IRQF_ONESHOT))
goto mismatch;
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-3.18/tty-vt-fix-up-tabstops-properly.patch
queue-3.18/alsa-aloop-fix-access-to-not-yet-ready-substream-via-cable.patch
queue-3.18/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-3.18/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
queue-3.18/libata-disable-lpm-for-crucial-bx100-ssd-500gb-drive.patch
queue-3.18/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-3.18/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-3.18/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-3.18/libata-fix-length-validation-of-atapi-relayed-scsi-commands.patch
queue-3.18/tracing-probeevent-fix-to-support-minus-offset-from-symbol.patch
queue-3.18/can-cc770-fix-use-after-free-in-cc770_tx_interrupt.patch
queue-3.18/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-3.18/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-3.18/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-3.18/revert-genirq-use-irqd_get_trigger_type-to-compare-the.patch
queue-3.18/l2tp-do-not-accept-arbitrary-sockets.patch
queue-3.18/can-cc770-fix-queue-stall-dropped-rtr-reply.patch
queue-3.18/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-3.18/libata-enable-queued-trim-for-samsung-ssd-860.patch
queue-3.18/staging-ncpfs-memory-corruption-in-ncp_read_kernel.patch
queue-3.18/drm-udl-properly-check-framebuffer-mmap-offsets.patch
queue-3.18/can-cc770-fix-stalls-on-rt-linux-remove-redundant-irq-ack.patch
queue-3.18/team-fix-double-free-in-error-path.patch
queue-3.18/brcmfmac-fix-p2p_device-ethernet-address-generation.patch
queue-3.18/alsa-usb-audio-fix-parsing-descriptor-of-uac2-processing-unit.patch
queue-3.18/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-3.18/alsa-aloop-sync-stale-timer-before-release.patch
queue-3.18/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
queue-3.18/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-3.18/scsi-sg-don-t-return-bogus-sg_requests.patch
queue-3.18/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
queue-3.18/net-fec-fix-unbalanced-pm-runtime-calls.patch
queue-3.18/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
queue-3.18/libata-remove-warn-for-dma-or-pio-command-without-data.patch
queue-3.18/s390-qeth-free-netdevice-when-removing-a-card.patch
queue-3.18/kvm-x86-fix-icebp-instruction-handling.patch
This is a note to let you know that I've just added the patch titled
[PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
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-genirq-use-irqd_get_trigger_type-to-compare-the.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 5512cca5c518c20037b10369a4725327202dd80b Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 30 Mar 2018 10:53:44 +0200
Subject: [PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
trigger type for shared IRQs"
This reverts commit 9d0273bb1c4b645817eccfe5c5975ea29add3300 which is
commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 upstream.
It causes too many problems with the stable tree, and would require too
many other things to be backported, so just revert it.
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/manage.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1189,10 +1189,8 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
-
if (!((old->flags & new->flags) & IRQF_SHARED) ||
- (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
+ ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
((old->flags ^ new->flags) & IRQF_ONESHOT))
goto mismatch;
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.4/net-fix-hlist-corruptions-in-inet_evict_bucket.patch
queue-4.4/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.4/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
queue-4.4/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.4/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.4/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.4/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.4/revert-genirq-use-irqd_get_trigger_type-to-compare-the.patch
queue-4.4/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.4/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-4.4/team-fix-double-free-in-error-path.patch
queue-4.4/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
queue-4.4/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.4/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
queue-4.4/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.4/scsi-sg-don-t-return-bogus-sg_requests.patch
queue-4.4/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
queue-4.4/net-fec-fix-unbalanced-pm-runtime-calls.patch
queue-4.4/net-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.patch
queue-4.4/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
[PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
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:
revert-genirq-use-irqd_get_trigger_type-to-compare-the.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 399af491b3f604277121f817ab0da9be6801bcef Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 30 Mar 2018 10:43:30 +0200
Subject: [PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the
trigger type for shared IRQs"
This reverts commit f2596a9808acfd02ce1ee389f0e1c37e64aec5f6 which is
commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 upstream.
It causes too many problems with the stable tree, and would require too
many other things to be backported, so just revert it.
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/manage.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1210,10 +1210,8 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
-
if (!((old->flags & new->flags) & IRQF_SHARED) ||
- (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
+ ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
((old->flags ^ new->flags) & IRQF_ONESHOT))
goto mismatch;
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/net-fix-hlist-corruptions-in-inet_evict_bucket.patch
queue-4.9/ppp-avoid-loop-in-xmit-recursion-detection-code.patch
queue-4.9/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.9/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
queue-4.9/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.9/rhashtable-fix-rhlist-duplicates-insertion.patch
queue-4.9/kcm-lock-lower-socket-in-kcm_attach.patch
queue-4.9/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.9/sch_netem-fix-skb-leak-in-netem_enqueue.patch
queue-4.9/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.9/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.9/revert-genirq-use-irqd_get_trigger_type-to-compare-the.patch
queue-4.9/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.9/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-4.9/team-fix-double-free-in-error-path.patch
queue-4.9/net-use-skb_to_full_sk-in-skb_update_prio.patch
queue-4.9/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
queue-4.9/net-hns-fix-a-skb-used-after-free-bug.patch
queue-4.9/soc-fsl-qbman-fix-issue-in-qman_delete_cgr_safe.patch
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.9/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
queue-4.9/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.9/scsi-sg-don-t-return-bogus-sg_requests.patch
queue-4.9/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
queue-4.9/net-fec-fix-unbalanced-pm-runtime-calls.patch
queue-4.9/net-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.patch
queue-4.9/net-sched-actions-return-explicit-error-when-tunnel_key-mode-is-not-specified.patch
queue-4.9/s390-qeth-free-netdevice-when-removing-a-card.patch
memblock_search_pfn_nid() returns the nid and the [start|end]_pfn of the
memory region where pfn sits in. While the calculation of start_pfn has
potential issue when the regions base is not page aligned.
For example, we assume PAGE_SHIFT is 12 and base is 0x1234. Current
implementation would return 1 while this is not correct.
This patch fixes this by using PFN_UP().
The original commit is commit e76b63f80d93 ("memblock, numa: binary search
node id") and merged in v3.12.
Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com>
Cc: 3.12 <stable(a)vger.kernel.org>
---
mm/memblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index b6ba6b7adadc..de768307696d 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1673,7 +1673,7 @@ int __init_memblock memblock_search_pfn_nid(unsigned long pfn,
if (mid == -1)
return -1;
- *start_pfn = PFN_DOWN(type->regions[mid].base);
+ *start_pfn = PFN_UP(type->regions[mid].base);
*end_pfn = PFN_DOWN(type->regions[mid].base + type->regions[mid].size);
return type->regions[mid].nid;
--
2.15.1
From: Eric Biggers <ebiggers(a)google.com>
ext4 isn't validating the sizes of xattrs. This is problematic
because ->e_value_size is a u32, but ext4_xattr_get() returns an int.
A very large size is misinterpreted as an error code, which
ext4_get_acl() translates into a bogus ERR_PTR() for which IS_ERR()
returns false, causing a crash.
Fix this by validating that all xattrs are <= INT_MAX bytes. Also add
explicit checks in ext4_xattr_block_get() and ext4_xattr_ibody_get()
just in case the xattr block is corrupted in memory.
This issue has been assigned CVE-2018-1095.
https://bugzilla.kernel.org/show_bug.cgi?id=199185https://bugzilla.redhat.com/show_bug.cgi?id=1560793
Reported-by: Wen Xu <wen.xu(a)gatech.edu>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)vger.kernel.org
---
fs/ext4/xattr.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 63656dbafdc4..fea1108c3bea 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -201,6 +201,9 @@ ext4_xattr_check_entries(struct ext4_xattr_entry *entry, void *end,
u32 size = le32_to_cpu(entry->e_value_size);
void *value;
+ if (size > INT_MAX)
+ return -EFSCORRUPTED;
+
/*
* The value cannot overlap the names, and the value
* with padding cannot extend beyond 'end'. Check both
@@ -523,8 +526,10 @@ ext4_xattr_block_get(struct inode *inode, int name_index, const char *name,
if (error)
goto cleanup;
size = le32_to_cpu(entry->e_value_size);
+ error = -ERANGE;
+ if (unlikely(size > INT_MAX))
+ goto cleanup;
if (buffer) {
- error = -ERANGE;
if (size > buffer_size)
goto cleanup;
if (entry->e_value_inum) {
@@ -572,8 +577,10 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
if (error)
goto cleanup;
size = le32_to_cpu(entry->e_value_size);
+ error = -ERANGE;
+ if (unlikely(size > INT_MAX))
+ goto cleanup;
if (buffer) {
- error = -ERANGE;
if (size > buffer_size)
goto cleanup;
if (entry->e_value_inum) {
--
2.16.1.72.g5be1f00a9a
This is a note to let you know that I've just added the patch titled
Revert "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870"
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 5267c5e09c25e2ee6242b37833a9bdf9d97f54a2 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Thu, 29 Mar 2018 14:35:40 +0200
Subject: Revert "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870"
This reverts commit 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee.
Turns out this is not an FTDI device after all.
Fixes: 79a0b33165d8 ("USB: serial: ftdi_sio: add Id for Physik Instrumente E-870")
Reported-by: Martin Teichmann <martin.teichmann(a)xfel.eu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 1 -
drivers/usb/serial/ftdi_sio_ids.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 566f25781ea0..87202ad5a50d 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -894,7 +894,6 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
- { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h
index f7790758de7c..975d02666c5a 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -981,7 +981,6 @@
#define PI_1014_PID 0x1014 /* PI Device */
#define PI_1015_PID 0x1015 /* PI Device */
#define PI_1016_PID 0x1016 /* PI Digital Servo Module */
-#define PI_E870_PID 0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
This is a note to let you know that I've just added the patch titled
usb: musb: gadget: misplaced out of bounds check
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 af6f8529098aeb0e56a68671b450cf74e7a64fcd Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Date: Thu, 29 Mar 2018 10:48:28 -0500
Subject: usb: musb: gadget: misplaced out of bounds check
musb->endpoints[] has array size MUSB_C_NUM_EPS.
We must check array bounds before accessing the array and not afterwards.
Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/musb_gadget_ep0.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c b/drivers/usb/musb/musb_gadget_ep0.c
index 18da4873e52e..91a5027b5c1f 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -89,15 +89,19 @@ static int service_tx_status_request(
}
is_in = epnum & USB_DIR_IN;
- if (is_in) {
- epnum &= 0x0f;
+ epnum &= 0x0f;
+ if (epnum >= MUSB_C_NUM_EPS) {
+ handled = -EINVAL;
+ break;
+ }
+
+ if (is_in)
ep = &musb->endpoints[epnum].ep_in;
- } else {
+ else
ep = &musb->endpoints[epnum].ep_out;
- }
regs = musb->endpoints[epnum].regs;
- if (epnum >= MUSB_C_NUM_EPS || !ep->desc) {
+ if (!ep->desc) {
handled = -EINVAL;
break;
}
--
2.16.3
This is a note to let you know that I've just added the patch titled
Revert "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870"
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 5267c5e09c25e2ee6242b37833a9bdf9d97f54a2 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Thu, 29 Mar 2018 14:35:40 +0200
Subject: Revert "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870"
This reverts commit 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee.
Turns out this is not an FTDI device after all.
Fixes: 79a0b33165d8 ("USB: serial: ftdi_sio: add Id for Physik Instrumente E-870")
Reported-by: Martin Teichmann <martin.teichmann(a)xfel.eu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 1 -
drivers/usb/serial/ftdi_sio_ids.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 566f25781ea0..87202ad5a50d 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -894,7 +894,6 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
- { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h
index f7790758de7c..975d02666c5a 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -981,7 +981,6 @@
#define PI_1014_PID 0x1014 /* PI Device */
#define PI_1015_PID 0x1015 /* PI Device */
#define PI_1016_PID 0x1016 /* PI Digital Servo Module */
-#define PI_E870_PID 0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
This is a note to let you know that I've just added the patch titled
usb: musb: gadget: misplaced out of bounds check
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 af6f8529098aeb0e56a68671b450cf74e7a64fcd Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Date: Thu, 29 Mar 2018 10:48:28 -0500
Subject: usb: musb: gadget: misplaced out of bounds check
musb->endpoints[] has array size MUSB_C_NUM_EPS.
We must check array bounds before accessing the array and not afterwards.
Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/musb_gadget_ep0.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c b/drivers/usb/musb/musb_gadget_ep0.c
index 18da4873e52e..91a5027b5c1f 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -89,15 +89,19 @@ static int service_tx_status_request(
}
is_in = epnum & USB_DIR_IN;
- if (is_in) {
- epnum &= 0x0f;
+ epnum &= 0x0f;
+ if (epnum >= MUSB_C_NUM_EPS) {
+ handled = -EINVAL;
+ break;
+ }
+
+ if (is_in)
ep = &musb->endpoints[epnum].ep_in;
- } else {
+ else
ep = &musb->endpoints[epnum].ep_out;
- }
regs = musb->endpoints[epnum].regs;
- if (epnum >= MUSB_C_NUM_EPS || !ep->desc) {
+ if (!ep->desc) {
handled = -EINVAL;
break;
}
--
2.16.3
This is a fix for a regression in 32 bit kernels caused by an
invalid check for pgoff overflow in hugetlbfs mmap setup. The
check incorrectly specified that the size of a loff_t was the
same as the size of a long. The regression prevents mapping
hugetlbfs files at offset greater than 4GB on 32 bit kernels.
Fix the check by using sizeof(loff_t) to get size. In addition,
make sure pgoff + length can be represented by a signed long
huge page offset. This check is only necessary on 32 bit kernels.
Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow")
Cc: <stable(a)vger.kernel.org>
Reported-by: Dan Rue <dan.rue(a)linaro.org>
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
---
fs/hugetlbfs/inode.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index b9a254dcc0e7..8450a1d75dfa 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -116,7 +116,8 @@ static void huge_pagevec_release(struct pagevec *pvec)
* bit into account.
*/
#define PGOFF_LOFFT_MAX \
- (((1UL << (PAGE_SHIFT + 1)) - 1) << (BITS_PER_LONG - (PAGE_SHIFT + 1)))
+ (((1UL << (PAGE_SHIFT + 1)) - 1) << \
+ ((sizeof(loff_t) * BITS_PER_BYTE) - (PAGE_SHIFT + 1)))
static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
@@ -138,21 +139,32 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
/*
* page based offset in vm_pgoff could be sufficiently large to
- * overflow a (l)off_t when converted to byte offset.
+ * overflow a loff_t when converted to byte offset.
*/
- if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
+ if ((loff_t)vma->vm_pgoff & (loff_t)PGOFF_LOFFT_MAX)
return -EINVAL;
- /* must be huge page aligned */
+ /* vm_pgoff must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
return -EINVAL;
+ /*
+ * Compute file offset of the end of this mapping
+ */
vma_len = (loff_t)(vma->vm_end - vma->vm_start);
len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
- /* check for overflow */
+
+ /* Check to ensure this did not overflow loff_t */
if (len < vma_len)
return -EINVAL;
+ /*
+ * On 32 bit systems, this check is necessary to ensure the last page
+ * of mapping can be represented as a signed long huge page index.
+ */
+ if ((len >> huge_page_shift(h)) > LONG_MAX)
+ return -EINVAL;
+
inode_lock(inode);
file_accessed(file);
--
2.13.6
From: Victor Gu <xigu(a)marvell.com>
The PCI configuration space read/write functions were special casing
the situation where PCI_SLOT(devfn) != 0, and returned
PCIBIOS_DEVICE_NOT_FOUND in this case.
However, while this is what is intended for the root bus, it is not
intended for the child busses, as it prevents discovering devices with
PCI_SLOT(x) != 0. Therefore, we return PCIBIOS_DEVICE_NOT_FOUND only
if we're on the root bus.
Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Victor Gu <xigu(a)marvell.com>
Reviewed-by: Wilson Ding <dingwei(a)marvell.com>
Reviewed-by: Nadav Haklai <nadavh(a)marvell.com>
[Thomas: tweak commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com>
---
Changes since v2:
- The logic has been factorized into a advk_pcie_valid_device()
helper in a previous patch, so this patch was adjusted accordingly.
---
drivers/pci/host/pci-aardvark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 82bff709a4b3..9d7f9f1c6837 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -433,7 +433,7 @@ static int advk_pcie_wait_pio(struct advk_pcie *pcie)
static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
int devfn)
{
- if (PCI_SLOT(devfn) != 0)
+ if ((bus->number == pcie->root_bus_nr) && PCI_SLOT(devfn) != 0)
return false;
return true;
--
2.14.3
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Id for Physik Instrumente E-870
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 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee Mon Sep 17 00:00:00 2001
From: "Teichmann, Martin" <martin.teichmann(a)xfel.eu>
Date: Thu, 29 Mar 2018 08:39:37 +0200
Subject: USB: serial: ftdi_sio: add Id for Physik Instrumente E-870
This adds support for the Physik Instrumente E-870 PIShift Drive
Electronics, a Piezo motor driver.
Signed-off-by: Martin Teichmann <martin.teichmann(a)xfel.eu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index f58c4ff6b387..85774cf4cc8f 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -893,6 +893,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
+ { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h
index 8b4ecd2bd297..14dff44a2a93 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -978,6 +978,7 @@
#define PI_1014_PID 0x1014 /* PI Device */
#define PI_1015_PID 0x1015 /* PI Device */
#define PI_1016_PID 0x1016 /* PI Digital Servo Module */
+#define PI_E870_PID 0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
This reverts commit 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee.
Turns out this is not an FTDI device after all.
Reported-by: Martin Teichmann <martin.teichmann(a)xfel.eu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
Greg,
I included the stable tag above as the offending patch had it, but I
will try to remember to speak out in case it gets added to the stable
queue in the first place.
Thanks,
Johan
drivers/usb/serial/ftdi_sio.c | 1 -
drivers/usb/serial/ftdi_sio_ids.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 85774cf4cc8f..f58c4ff6b387 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -893,7 +893,6 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
- { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h
index 14dff44a2a93..8b4ecd2bd297 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -978,7 +978,6 @@
#define PI_1014_PID 0x1014 /* PI Device */
#define PI_1015_PID 0x1015 /* PI Device */
#define PI_1016_PID 0x1016 /* PI Digital Servo Module */
-#define PI_E870_PID 0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Id for Physik Instrumente E-870
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 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee Mon Sep 17 00:00:00 2001
From: "Teichmann, Martin" <martin.teichmann(a)xfel.eu>
Date: Thu, 29 Mar 2018 08:39:37 +0200
Subject: USB: serial: ftdi_sio: add Id for Physik Instrumente E-870
This adds support for the Physik Instrumente E-870 PIShift Drive
Electronics, a Piezo motor driver.
Signed-off-by: Martin Teichmann <martin.teichmann(a)xfel.eu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index f58c4ff6b387..85774cf4cc8f 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -893,6 +893,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
+ { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h
index 8b4ecd2bd297..14dff44a2a93 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -978,6 +978,7 @@
#define PI_1014_PID 0x1014 /* PI Device */
#define PI_1015_PID 0x1015 /* PI Device */
#define PI_1016_PID 0x1016 /* PI Digital Servo Module */
+#define PI_E870_PID 0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
Driver currently crashes due to NULL pointer deference
while updating PHY tune register if nvmem cell is NULL.
Since, fused value for Tune1/2 register is optional,
we'd rather bail out.
Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
Reviewed-by: Vivek Gautam <vivek.gautam(a)codeaurora.org>
Reviewed-by: Evan Green <evgreen(a)chromium.org>
Cc: stable <stable(a)vger.kernel.org> # 4.14+
Signed-off-by: Manu Gautam <mgautam(a)codeaurora.org>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 94afeac..40fdef8 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -315,6 +315,10 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy)
const struct qusb2_phy_cfg *cfg = qphy->cfg;
u8 *val;
+ /* efuse register is optional */
+ if (!qphy->cell)
+ return;
+
/*
* Read efuse register having TUNE2/1 parameter's high nibble.
* If efuse register shows value as 0x0, or if we fail to find
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
From: Michael Kelley <mhkelley(a)outlook.com>
Fix bugs in signaling the Hyper-V host when freeing space in the
host->guest ring buffer:
1. The interrupt_mask must not be used to determine whether to signal
on the host->guest ring buffer
2. The ring buffer write_index must be read (via hv_get_bytes_to_write)
*after* pending_send_sz is read in order to avoid a race condition
3. Comparisons with pending_send_sz must treat the "equals" case as
not-enough-space
4. Don't signal if the pending_send_sz feature is not present. Older
versions of Hyper-V that don't implement this feature will poll.
Fixes: 03bad714a161 ("vmbus: more host signalling avoidance")
Cc: Stable <stable(a)vger.kernel.org> # 4.14 and above
Signed-off-by: Michael Kelley <mhkelley(a)outlook.com>
Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com>
---
drivers/hv/ring_buffer.c | 52 ++++++++++++++++++++++++++++++++----------------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 1aa17795727b..3cd7f29906ae 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -376,13 +376,24 @@ __hv_pkt_iter_next(struct vmbus_channel *channel,
}
EXPORT_SYMBOL_GPL(__hv_pkt_iter_next);
+/* How many bytes were read in this iterator cycle */
+static u32 hv_pkt_iter_bytes_read(const struct hv_ring_buffer_info *rbi,
+ u32 start_read_index)
+{
+ if (rbi->priv_read_index >= start_read_index)
+ return rbi->priv_read_index - start_read_index;
+ else
+ return rbi->ring_datasize - start_read_index +
+ rbi->priv_read_index;
+}
+
/*
* Update host ring buffer after iterating over packets.
*/
void hv_pkt_iter_close(struct vmbus_channel *channel)
{
struct hv_ring_buffer_info *rbi = &channel->inbound;
- u32 orig_write_sz = hv_get_bytes_to_write(rbi);
+ u32 curr_write_sz, pending_sz, bytes_read, start_read_index;
/*
* Make sure all reads are done before we update the read index since
@@ -390,8 +401,12 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
* is updated.
*/
virt_rmb();
+ start_read_index = rbi->ring_buffer->read_index;
rbi->ring_buffer->read_index = rbi->priv_read_index;
+ if (!rbi->ring_buffer->feature_bits.feat_pending_send_sz)
+ return;
+
/*
* Issue a full memory barrier before making the signaling decision.
* Here is the reason for having this barrier:
@@ -405,26 +420,29 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
*/
virt_mb();
- /* If host has disabled notifications then skip */
- if (rbi->ring_buffer->interrupt_mask)
+ pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
+ if (!pending_sz)
return;
- if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
- u32 pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
+ /*
+ * Ensure the read of write_index in hv_get_bytes_to_write()
+ * happens after the read of pending_send_sz.
+ */
+ virt_rmb();
+ curr_write_sz = hv_get_bytes_to_write(rbi);
+ bytes_read = hv_pkt_iter_bytes_read(rbi, start_read_index);
- /*
- * If there was space before we began iteration,
- * then host was not blocked. Also handles case where
- * pending_sz is zero then host has nothing pending
- * and does not need to be signaled.
- */
- if (orig_write_sz > pending_sz)
- return;
+ /*
+ * If there was space before we began iteration,
+ * then host was not blocked.
+ */
- /* If pending write will not fit, don't give false hope. */
- if (hv_get_bytes_to_write(rbi) < pending_sz)
- return;
- }
+ if (curr_write_sz - bytes_read > pending_sz)
+ return;
+
+ /* If pending write will not fit, don't give false hope. */
+ if (curr_write_sz <= pending_sz)
+ return;
vmbus_setevent(channel);
}
--
2.15.1
This is a note to let you know that I've just added the patch titled
team: Fix double free in error path
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:
team-fix-double-free-in-error-path.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 Thu Mar 29 08:33:08 CEST 2018
From: Arkadi Sharshevsky <arkadis(a)mellanox.com>
Date: Thu, 8 Mar 2018 12:42:10 +0200
Subject: team: Fix double free in error path
From: Arkadi Sharshevsky <arkadis(a)mellanox.com>
[ Upstream commit cbcc607e18422555db569b593608aec26111cb0b ]
The __send_and_alloc_skb() receives a skb ptr as a parameter but in
case it fails the skb is not valid:
- Send failed and released the skb internally.
- Allocation failed.
The current code tries to release the skb in case of failure which
causes redundant freeing.
Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
Signed-off-by: Arkadi Sharshevsky <arkadis(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>
---
drivers/net/team/team.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2380,7 +2380,7 @@ send_done:
if (!nlh) {
err = __send_and_alloc_skb(&skb, team, portid, send_func);
if (err)
- goto errout;
+ return err;
goto send_done;
}
@@ -2660,7 +2660,7 @@ send_done:
if (!nlh) {
err = __send_and_alloc_skb(&skb, team, portid, send_func);
if (err)
- goto errout;
+ return err;
goto send_done;
}
Patches currently in stable-queue which might be from arkadis(a)mellanox.com are
queue-4.4/team-fix-double-free-in-error-path.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: when thread completes, wake up all waiters
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:
s390-qeth-when-thread-completes-wake-up-all-waiters.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 Thu Mar 29 08:33:08 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:13 +0100
Subject: s390/qeth: when thread completes, wake up all waiters
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 1063e432bb45be209427ed3f1ca3908e4aa3c7d7 ]
qeth_wait_for_threads() is potentially called by multiple users, make
sure to notify all of them after qeth_clear_thread_running_bit()
adjusted the thread_running_mask. With no timeout, callers would
otherwise stall.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -952,7 +952,7 @@ void qeth_clear_thread_running_bit(struc
spin_lock_irqsave(&card->thread_mask_lock, flags);
card->thread_running_mask &= ~thread;
spin_unlock_irqrestore(&card->thread_mask_lock, flags);
- wake_up(&card->wait_q);
+ wake_up_all(&card->wait_q);
}
EXPORT_SYMBOL_GPL(qeth_clear_thread_running_bit);
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.4/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.4/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.4/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.4/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.4/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
skbuff: Fix not waking applications when errors are enqueued
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:
skbuff-fix-not-waking-applications-when-errors-are-enqueued.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 Thu Mar 29 08:33:08 CEST 2018
From: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
Date: Wed, 14 Mar 2018 13:32:09 -0700
Subject: skbuff: Fix not waking applications when errors are enqueued
From: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
[ Upstream commit 6e5d58fdc9bedd0255a8781b258f10bbdc63e975 ]
When errors are enqueued to the error queue via sock_queue_err_skb()
function, it is possible that the waiting application is not notified.
Calling 'sk->sk_data_ready()' would not notify applications that
selected only POLLERR events in poll() (for example).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Randy E. Witt <randy.e.witt(a)intel.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3571,7 +3571,7 @@ int sock_queue_err_skb(struct sock *sk,
skb_queue_tail(&sk->sk_error_queue, skb);
if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_data_ready(sk);
+ sk->sk_error_report(sk);
return 0;
}
EXPORT_SYMBOL(sock_queue_err_skb);
Patches currently in stable-queue which might be from vinicius.gomes(a)intel.com are
queue-4.4/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: on channel error, reject further cmd requests
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:
s390-qeth-on-channel-error-reject-further-cmd-requests.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 Thu Mar 29 08:33:08 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:15 +0100
Subject: s390/qeth: on channel error, reject further cmd requests
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit a6c3d93963e4b333c764fde69802c3ea9eaa9d5c ]
When the IRQ handler determines that one of the cmd IO channels has
failed and schedules recovery, block any further cmd requests from
being submitted. The request would inevitably stall, and prevent the
recovery from making progress until the request times out.
This sort of error was observed after Live Guest Relocation, where
the pending IO on the READ channel intentionally gets terminated to
kick-start recovery. Simultaneously the guest executed SIOCETHTOOL,
triggering qeth to issue a QUERY CARD INFO command. The command
then stalled in the inoperabel WRITE channel.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -1166,6 +1166,7 @@ static void qeth_irq(struct ccw_device *
}
rc = qeth_get_problem(cdev, irb);
if (rc) {
+ card->read_or_write_problem = 1;
qeth_clear_ipacmd_list(card);
qeth_schedule_recovery(card);
goto out;
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.4/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.4/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.4/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.4/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.4/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: lock read device while queueing next buffer
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:
s390-qeth-lock-read-device-while-queueing-next-buffer.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 Thu Mar 29 08:33:08 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:14 +0100
Subject: s390/qeth: lock read device while queueing next buffer
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 17bf8c9b3d499d5168537c98b61eb7a1fcbca6c2 ]
For calling ccw_device_start(), issue_next_read() needs to hold the
device's ccwlock.
This is satisfied for the IRQ handler path (where qeth_irq() gets called
under the ccwlock), but we need explicit locking for the initial call by
the MPC initialization.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -517,8 +517,7 @@ static inline int qeth_is_cq(struct qeth
queue == card->qdio.no_in_queues - 1;
}
-
-static int qeth_issue_next_read(struct qeth_card *card)
+static int __qeth_issue_next_read(struct qeth_card *card)
{
int rc;
struct qeth_cmd_buffer *iob;
@@ -549,6 +548,17 @@ static int qeth_issue_next_read(struct q
return rc;
}
+static int qeth_issue_next_read(struct qeth_card *card)
+{
+ int ret;
+
+ spin_lock_irq(get_ccwdev_lock(CARD_RDEV(card)));
+ ret = __qeth_issue_next_read(card);
+ spin_unlock_irq(get_ccwdev_lock(CARD_RDEV(card)));
+
+ return ret;
+}
+
static struct qeth_reply *qeth_alloc_reply(struct qeth_card *card)
{
struct qeth_reply *reply;
@@ -1174,7 +1184,7 @@ static void qeth_irq(struct ccw_device *
return;
if (channel == &card->read &&
channel->state == CH_STATE_UP)
- qeth_issue_next_read(card);
+ __qeth_issue_next_read(card);
iob = channel->iob;
index = channel->buf_no;
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.4/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.4/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.4/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.4/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.4/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: free netdevice when removing a card
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:
s390-qeth-free-netdevice-when-removing-a-card.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 Thu Mar 29 08:33:08 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:12 +0100
Subject: s390/qeth: free netdevice when removing a card
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 6be687395b3124f002a653c1a50b3260222b3cd7 ]
On removal, a qeth card's netdevice is currently not properly freed
because the call chain looks as follows:
qeth_core_remove_device(card)
lx_remove_device(card)
unregister_netdev(card->dev)
card->dev = NULL !!!
qeth_core_free_card(card)
if (card->dev) !!!
free_netdev(card->dev)
Fix it by free'ing the netdev straight after unregistering. This also
fixes the sysfs-driven layer switch case (qeth_dev_layer2_store()),
where the need to free the current netdevice was not considered at all.
Note that free_netdev() takes care of the netif_napi_del() for us too.
Fixes: 4a71df50047f ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Reviewed-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 2 --
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -4969,8 +4969,6 @@ static void qeth_core_free_card(struct q
QETH_DBF_HEX(SETUP, 2, &card, sizeof(void *));
qeth_clean_channel(&card->read);
qeth_clean_channel(&card->write);
- if (card->dev)
- free_netdev(card->dev);
kfree(card->ip_tbd_list);
qeth_free_qdio_buffers(card);
unregister_service_level(&card->qeth_service_level);
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -1062,8 +1062,8 @@ static void qeth_l2_remove_device(struct
qeth_l2_set_offline(cgdev);
if (card->dev) {
- netif_napi_del(&card->napi);
unregister_netdev(card->dev);
+ free_netdev(card->dev);
card->dev = NULL;
}
return;
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -3243,8 +3243,8 @@ static void qeth_l3_remove_device(struct
qeth_l3_set_offline(cgdev);
if (card->dev) {
- netif_napi_del(&card->napi);
unregister_netdev(card->dev);
+ free_netdev(card->dev);
card->dev = NULL;
}
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.4/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.4/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.4/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.4/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.4/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
netlink: avoid a double skb free in genlmsg_mcast()
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:
netlink-avoid-a-double-skb-free-in-genlmsg_mcast.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 Thu Mar 29 08:33:08 CEST 2018
From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Date: Wed, 14 Mar 2018 21:10:23 +0100
Subject: netlink: avoid a double skb free in genlmsg_mcast()
From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
[ Upstream commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb ]
nlmsg_multicast() consumes always the skb, thus the original skb must be
freed only when this function is called with a clone.
Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netlink/genetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -1143,7 +1143,7 @@ static int genlmsg_mcast(struct sk_buff
if (!err)
delivered = true;
else if (err != -ESRCH)
- goto error;
+ return err;
return delivered ? 0 : -ESRCH;
error:
kfree_skb(skb);
Patches currently in stable-queue which might be from nicolas.dichtel(a)6wind.com are
queue-4.4/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
This is a note to let you know that I've just added the patch titled
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
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-systemport-rewrite-__bcm_sysport_tx_reclaim.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 Wed Mar 28 20:16:33 CEST 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 13 Mar 2018 14:45:07 -0700
Subject: net: systemport: Rewrite __bcm_sysport_tx_reclaim()
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 484d802d0f2f29c335563fcac2a8facf174a1bbc ]
There is no need for complex checking between the last consumed index
and current consumed index, a simple subtraction will do.
This also eliminates the possibility of a permanent transmit queue stall
under the following conditions:
- one CPU bursts ring->size worth of traffic (up to 256 buffers), to the
point where we run out of free descriptors, so we stop the transmit
queue at the end of bcm_sysport_xmit()
- because of our locking, we have the transmit process disable
interrupts which means we can be blocking the TX reclamation process
- when TX reclamation finally runs, we will be computing the difference
between ring->c_index (last consumed index by SW) and what the HW
reports through its register
- this register is masked with (ring->size - 1) = 0xff, which will lead
to stripping the upper bits of the index (register is 16-bits wide)
- we will be computing last_tx_cn as 0, which means there is no work to
be done, and we never wake-up the transmit queue, leaving it
permanently disabled
A practical example is e.g: ring->c_index aka last_c_index = 12, we
pushed 256 entries, HW consumer index = 268, we mask it with 0xff = 12,
so last_tx_cn == 0, nothing happens.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-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/ethernet/broadcom/bcmsysport.c | 33 +++++++++++++----------------
drivers/net/ethernet/broadcom/bcmsysport.h | 2 -
2 files changed, 16 insertions(+), 19 deletions(-)
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -729,37 +729,33 @@ static unsigned int __bcm_sysport_tx_rec
struct bcm_sysport_tx_ring *ring)
{
struct net_device *ndev = priv->netdev;
- unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
unsigned int pkts_compl = 0, bytes_compl = 0;
+ unsigned int txbds_processed = 0;
struct bcm_sysport_cb *cb;
+ unsigned int txbds_ready;
+ unsigned int c_index;
u32 hw_ind;
/* Compute how many descriptors have been processed since last call */
hw_ind = tdma_readl(priv, TDMA_DESC_RING_PROD_CONS_INDEX(ring->index));
c_index = (hw_ind >> RING_CONS_INDEX_SHIFT) & RING_CONS_INDEX_MASK;
- ring->p_index = (hw_ind & RING_PROD_INDEX_MASK);
-
- last_c_index = ring->c_index;
- num_tx_cbs = ring->size;
-
- c_index &= (num_tx_cbs - 1);
-
- if (c_index >= last_c_index)
- last_tx_cn = c_index - last_c_index;
- else
- last_tx_cn = num_tx_cbs - last_c_index + c_index;
+ txbds_ready = (c_index - ring->c_index) & RING_CONS_INDEX_MASK;
netif_dbg(priv, tx_done, ndev,
- "ring=%d c_index=%d last_tx_cn=%d last_c_index=%d\n",
- ring->index, c_index, last_tx_cn, last_c_index);
+ "ring=%d old_c_index=%u c_index=%u txbds_ready=%u\n",
+ ring->index, ring->c_index, c_index, txbds_ready);
- while (last_tx_cn-- > 0) {
- cb = ring->cbs + last_c_index;
+ while (txbds_processed < txbds_ready) {
+ cb = &ring->cbs[ring->clean_index];
bcm_sysport_tx_reclaim_one(priv, cb, &bytes_compl, &pkts_compl);
ring->desc_count++;
- last_c_index++;
- last_c_index &= (num_tx_cbs - 1);
+ txbds_processed++;
+
+ if (likely(ring->clean_index < ring->size - 1))
+ ring->clean_index++;
+ else
+ ring->clean_index = 0;
}
ring->c_index = c_index;
@@ -1229,6 +1225,7 @@ static int bcm_sysport_init_tx_ring(stru
netif_napi_add(priv->netdev, &ring->napi, bcm_sysport_tx_poll, 64);
ring->index = index;
ring->size = size;
+ ring->clean_index = 0;
ring->alloc_size = ring->size;
ring->desc_cpu = p;
ring->desc_count = ring->size;
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -638,7 +638,7 @@ struct bcm_sysport_tx_ring {
unsigned int desc_count; /* Number of descriptors */
unsigned int curr_desc; /* Current descriptor */
unsigned int c_index; /* Last consumer index */
- unsigned int p_index; /* Current producer index */
+ unsigned int clean_index; /* Current clean index */
struct bcm_sysport_cb *cbs; /* Transmit control blocks */
struct dma_desc *desc_cpu; /* CPU view of the descriptor */
struct bcm_sysport_priv *priv; /* private context backpointer */
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.4/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.4/net-fec-fix-unbalanced-pm-runtime-calls.patch
This is a note to let you know that I've just added the patch titled
net/iucv: Free memory obtained by kzalloc
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-iucv-free-memory-obtained-by-kzalloc.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 Thu Mar 29 08:33:08 CEST 2018
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Tue, 13 Mar 2018 16:50:06 +0100
Subject: net/iucv: Free memory obtained by kzalloc
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit fa6a91e9b907231d2e38ea5ed89c537b3525df3d ]
Free memory by calling put_device(), if afiucv_iucv_init is not
successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Ursula Braun <ursula.braun(a)de.ibm.com>
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/iucv/af_iucv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -2381,9 +2381,11 @@ static int afiucv_iucv_init(void)
af_iucv_dev->driver = &af_iucv_driver;
err = device_register(af_iucv_dev);
if (err)
- goto out_driver;
+ goto out_iucv_dev;
return 0;
+out_iucv_dev:
+ put_device(af_iucv_dev);
out_driver:
driver_unregister(&af_iucv_driver);
out_iucv:
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.4/net-iucv-free-memory-obtained-by-kzalloc.patch
This is a note to let you know that I've just added the patch titled
net: Only honor ifindex in IP_PKTINFO if non-0
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-only-honor-ifindex-in-ip_pktinfo-if-non-0.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 Thu Mar 29 08:33:08 CEST 2018
From: David Ahern <dsahern(a)gmail.com>
Date: Fri, 16 Feb 2018 11:03:03 -0800
Subject: net: Only honor ifindex in IP_PKTINFO if non-0
From: David Ahern <dsahern(a)gmail.com>
[ Upstream commit 2cbb4ea7de167b02ffa63e9cdfdb07a7e7094615 ]
Only allow ifindex from IP_PKTINFO to override SO_BINDTODEVICE settings
if the index is actually set in the message.
Signed-off-by: David Ahern <dsahern(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -241,7 +241,8 @@ int ip_cmsg_send(struct net *net, struct
src_info = (struct in6_pktinfo *)CMSG_DATA(cmsg);
if (!ipv6_addr_v4mapped(&src_info->ipi6_addr))
return -EINVAL;
- ipc->oif = src_info->ipi6_ifindex;
+ if (src_info->ipi6_ifindex)
+ ipc->oif = src_info->ipi6_ifindex;
ipc->addr = src_info->ipi6_addr.s6_addr32[3];
continue;
}
@@ -264,7 +265,8 @@ int ip_cmsg_send(struct net *net, struct
if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct in_pktinfo)))
return -EINVAL;
info = (struct in_pktinfo *)CMSG_DATA(cmsg);
- ipc->oif = info->ipi_ifindex;
+ if (info->ipi_ifindex)
+ ipc->oif = info->ipi_ifindex;
ipc->addr = info->ipi_spec_dst.s_addr;
break;
}
Patches currently in stable-queue which might be from dsahern(a)gmail.com are
queue-4.4/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
This is a note to let you know that I've just added the patch titled
net: Fix hlist corruptions in inet_evict_bucket()
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-fix-hlist-corruptions-in-inet_evict_bucket.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 Thu Mar 29 08:33:08 CEST 2018
From: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Date: Tue, 6 Mar 2018 18:46:39 +0300
Subject: net: Fix hlist corruptions in inet_evict_bucket()
From: Kirill Tkhai <ktkhai(a)virtuozzo.com>
[ Upstream commit a560002437d3646dafccecb1bf32d1685112ddda ]
inet_evict_bucket() iterates global list, and
several tasks may call it in parallel. All of
them hash the same fq->list_evictor to different
lists, which leads to list corruption.
This patch makes fq be hashed to expired list
only if this has not been made yet by another
task. Since inet_frag_alloc() allocates fq
using kmem_cache_zalloc(), we may rely on
list_evictor is initially unhashed.
The problem seems to exist before async
pernet_operations, as there was possible to have
exit method to be executed in parallel with
inet_frags::frags_work, so I add two Fixes tags.
This also may go to stable.
Fixes: d1fe19444d82 "inet: frag: don't re-use chainlist for evictor"
Fixes: f84c6821aa54 "net: Convert pernet_subsys, registered from inet_init()"
Signed-off-by: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/inet_fragment.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -119,6 +119,9 @@ out:
static bool inet_fragq_should_evict(const struct inet_frag_queue *q)
{
+ if (!hlist_unhashed(&q->list_evictor))
+ return false;
+
return q->net->low_thresh == 0 ||
frag_mem_limit(q->net) >= q->net->low_thresh;
}
Patches currently in stable-queue which might be from ktkhai(a)virtuozzo.com are
queue-4.4/net-fix-hlist-corruptions-in-inet_evict_bucket.patch
This is a note to let you know that I've just added the patch titled
net: fec: Fix unbalanced PM runtime 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:
net-fec-fix-unbalanced-pm-runtime-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 foo@baz Thu Mar 29 08:33:08 CEST 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Sun, 18 Mar 2018 12:49:51 -0700
Subject: net: fec: Fix unbalanced PM runtime calls
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit a069215cf5985f3aa1bba550264907d6bd05c5f7 ]
When unbinding/removing the driver, we will run into the following warnings:
[ 259.655198] fec 400d1000.ethernet: 400d1000.ethernet supply phy not found, using dummy regulator
[ 259.665065] fec 400d1000.ethernet: Unbalanced pm_runtime_enable!
[ 259.672770] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
[ 259.683062] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: f2:3e:93:b7:29:c1
[ 259.696239] libphy: fec_enet_mii_bus: probed
Avoid these warnings by balancing the runtime PM calls during fec_drv_remove().
Signed-off-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/ethernet/freescale/fec_main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3539,6 +3539,8 @@ fec_drv_remove(struct platform_device *p
fec_enet_mii_remove(fep);
if (fep->reg_phy)
regulator_disable(fep->reg_phy);
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
of_node_put(fep->phy_node);
free_netdev(ndev);
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.4/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.4/net-fec-fix-unbalanced-pm-runtime-calls.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
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-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.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 Thu Mar 29 08:33:08 CEST 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 18 Mar 2018 23:59:36 +0100
Subject: net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 00777fac28ba3e126b9e63e789a613e8bd2cab25 ]
If the optional regulator is deferred, we must release some resources.
They will be re-allocated when the probe function will be called again.
Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_rockchip.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -150,8 +150,10 @@ static int emac_rockchip_probe(struct pl
/* Optional regulator for PHY */
priv->regulator = devm_regulator_get_optional(dev, "phy");
if (IS_ERR(priv->regulator)) {
- if (PTR_ERR(priv->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(priv->regulator) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto out_clk_disable;
+ }
dev_err(dev, "no regulator found\n");
priv->regulator = NULL;
}
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.4/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
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-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.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 Thu Mar 29 08:33:08 CEST 2018
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
Date: Fri, 16 Mar 2018 00:56:01 +0800
Subject: net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
[ Upstream commit f9db50691db4a7d860fce985f080bb3fc23a7ede ]
According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
available when PHY is configured in RGMII mode with 10Mbps speed. It will
cause some networking issues without RGMII mode, such as carrier sense
errors and low throughput. TI also mentioned this issue in their forum[4].
This patch adds the check mechanism for PHY interface with RGMII interface
type, the in-band mode can only be set in RGMII mode with 10Mbps speed.
References:
[1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
[2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
[3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf
[4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155
Suggested-by: Holsety Chen (陳憲輝) <Holsety.Chen(a)moxa.com>
Signed-off-by: SZ Lin (林上智) <sz.lin(a)moxa.com>
Signed-off-by: Schuyler Patton <spatton(a)ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko(a)ti.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/ti/cpsw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -878,7 +878,8 @@ static void _cpsw_adjust_link(struct cps
/* set speed_in input in case RMII mode is used in 100Mbps */
if (phy->speed == 100)
mac_control |= BIT(15);
- else if (phy->speed == 10)
+ /* in band mode only works in 10Mbps RGMII mode */
+ else if ((phy->speed == 10) && phy_interface_is_rgmii(phy))
mac_control |= BIT(18); /* In Band mode */
if (priv->rx_pause)
Patches currently in stable-queue which might be from sz.lin(a)moxa.com are
queue-4.4/net-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.patch
This is a note to let you know that I've just added the patch titled
l2tp: do not accept arbitrary sockets
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:
l2tp-do-not-accept-arbitrary-sockets.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 Thu Mar 29 08:33:08 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Tue, 6 Mar 2018 07:54:53 -0800
Subject: l2tp: do not accept arbitrary sockets
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 17cfe79a65f98abe535261856c5aef14f306dff7 ]
syzkaller found an issue caused by lack of sufficient checks
in l2tp_tunnel_create()
RAW sockets can not be considered as UDP ones for instance.
In another patch, we shall replace all pr_err() by less intrusive
pr_debug() so that syzkaller can find other bugs faster.
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Acked-by: James Chapman <jchapman(a)katalix.com>
==================================================================
BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
dst_release: dst:00000000d53d0d0f refcnt:-1
Write of size 1 at addr ffff8801d013b798 by task syz-executor3/6242
CPU: 1 PID: 6242 Comm: syz-executor3 Not tainted 4.16.0-rc2+ #253
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23b/0x360 mm/kasan/report.c:412
__asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
l2tp_tunnel_create+0x1354/0x17f0 net/l2tp/l2tp_core.c:1596
pppol2tp_connect+0x14b1/0x1dd0 net/l2tp/l2tp_ppp.c:707
SYSC_connect+0x213/0x4a0 net/socket.c:1640
SyS_connect+0x24/0x30 net/socket.c:1621
do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1518,9 +1518,14 @@ int l2tp_tunnel_create(struct net *net,
encap = cfg->encap;
/* Quick sanity checks */
+ err = -EPROTONOSUPPORT;
+ if (sk->sk_type != SOCK_DGRAM) {
+ pr_debug("tunl %hu: fd %d wrong socket type\n",
+ tunnel_id, fd);
+ goto err;
+ }
switch (encap) {
case L2TP_ENCAPTYPE_UDP:
- err = -EPROTONOSUPPORT;
if (sk->sk_protocol != IPPROTO_UDP) {
pr_err("tunl %hu: fd %d wrong protocol, got %d, expected %d\n",
tunnel_id, fd, sk->sk_protocol, IPPROTO_UDP);
@@ -1528,7 +1533,6 @@ int l2tp_tunnel_create(struct net *net,
}
break;
case L2TP_ENCAPTYPE_IP:
- err = -EPROTONOSUPPORT;
if (sk->sk_protocol != IPPROTO_L2TP) {
pr_err("tunl %hu: fd %d wrong protocol, got %d, expected %d\n",
tunnel_id, fd, sk->sk_protocol, IPPROTO_L2TP);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.4/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.4/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.4/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
This is a note to let you know that I've just added the patch titled
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
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-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.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 Thu Mar 29 08:33:08 CEST 2018
From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Date: Thu, 8 Mar 2018 17:00:02 +0100
Subject: ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
[ Upstream commit 9f62c15f28b0d1d746734666d88a79f08ba1e43e ]
Fix the following slab-out-of-bounds kasan report in
ndisc_fill_redirect_hdr_option when the incoming ipv6 packet is not
linear and the accessed data are not in the linear data region of orig_skb.
[ 1503.122508] ==================================================================
[ 1503.122832] BUG: KASAN: slab-out-of-bounds in ndisc_send_redirect+0x94e/0x990
[ 1503.123036] Read of size 1184 at addr ffff8800298ab6b0 by task netperf/1932
[ 1503.123220] CPU: 0 PID: 1932 Comm: netperf Not tainted 4.16.0-rc2+ #124
[ 1503.123347] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
[ 1503.123527] Call Trace:
[ 1503.123579] <IRQ>
[ 1503.123638] print_address_description+0x6e/0x280
[ 1503.123849] kasan_report+0x233/0x350
[ 1503.123946] memcpy+0x1f/0x50
[ 1503.124037] ndisc_send_redirect+0x94e/0x990
[ 1503.125150] ip6_forward+0x1242/0x13b0
[...]
[ 1503.153890] Allocated by task 1932:
[ 1503.153982] kasan_kmalloc+0x9f/0xd0
[ 1503.154074] __kmalloc_track_caller+0xb5/0x160
[ 1503.154198] __kmalloc_reserve.isra.41+0x24/0x70
[ 1503.154324] __alloc_skb+0x130/0x3e0
[ 1503.154415] sctp_packet_transmit+0x21a/0x1810
[ 1503.154533] sctp_outq_flush+0xc14/0x1db0
[ 1503.154624] sctp_do_sm+0x34e/0x2740
[ 1503.154715] sctp_primitive_SEND+0x57/0x70
[ 1503.154807] sctp_sendmsg+0xaa6/0x1b10
[ 1503.154897] sock_sendmsg+0x68/0x80
[ 1503.154987] ___sys_sendmsg+0x431/0x4b0
[ 1503.155078] __sys_sendmsg+0xa4/0x130
[ 1503.155168] do_syscall_64+0x171/0x3f0
[ 1503.155259] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 1503.155436] Freed by task 1932:
[ 1503.155527] __kasan_slab_free+0x134/0x180
[ 1503.155618] kfree+0xbc/0x180
[ 1503.155709] skb_release_data+0x27f/0x2c0
[ 1503.155800] consume_skb+0x94/0xe0
[ 1503.155889] sctp_chunk_put+0x1aa/0x1f0
[ 1503.155979] sctp_inq_pop+0x2f8/0x6e0
[ 1503.156070] sctp_assoc_bh_rcv+0x6a/0x230
[ 1503.156164] sctp_inq_push+0x117/0x150
[ 1503.156255] sctp_backlog_rcv+0xdf/0x4a0
[ 1503.156346] __release_sock+0x142/0x250
[ 1503.156436] release_sock+0x80/0x180
[ 1503.156526] sctp_sendmsg+0xbb0/0x1b10
[ 1503.156617] sock_sendmsg+0x68/0x80
[ 1503.156708] ___sys_sendmsg+0x431/0x4b0
[ 1503.156799] __sys_sendmsg+0xa4/0x130
[ 1503.156889] do_syscall_64+0x171/0x3f0
[ 1503.156980] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 1503.157158] The buggy address belongs to the object at ffff8800298ab600
which belongs to the cache kmalloc-1024 of size 1024
[ 1503.157444] The buggy address is located 176 bytes inside of
1024-byte region [ffff8800298ab600, ffff8800298aba00)
[ 1503.157702] The buggy address belongs to the page:
[ 1503.157820] page:ffffea0000a62a00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
[ 1503.158053] flags: 0x4000000000008100(slab|head)
[ 1503.158171] raw: 4000000000008100 0000000000000000 0000000000000000 00000001800e000e
[ 1503.158350] raw: dead000000000100 dead000000000200 ffff880036002600 0000000000000000
[ 1503.158523] page dumped because: kasan: bad access detected
[ 1503.158698] Memory state around the buggy address:
[ 1503.158816] ffff8800298ab900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1503.158988] ffff8800298ab980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1503.159165] >ffff8800298aba00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 1503.159338] ^
[ 1503.159436] ffff8800298aba80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1503.159610] ffff8800298abb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1503.159785] ==================================================================
[ 1503.159964] Disabling lock debugging due to kernel taint
The test scenario to trigger the issue consists of 4 devices:
- H0: data sender, connected to LAN0
- H1: data receiver, connected to LAN1
- GW0 and GW1: routers between LAN0 and LAN1. Both of them have an
ethernet connection on LAN0 and LAN1
On H{0,1} set GW0 as default gateway while on GW0 set GW1 as next hop for
data from LAN0 to LAN1.
Moreover create an ip6ip6 tunnel between H0 and H1 and send 3 concurrent
data streams (TCP/UDP/SCTP) from H0 to H1 through ip6ip6 tunnel (send
buffer size is set to 16K). While data streams are active flush the route
cache on HA multiple times.
I have not been able to identify a given commit that introduced the issue
since, using the reproducer described above, the kasan report has been
triggered from 4.14 and I have not gone back further.
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ndisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1478,7 +1478,8 @@ static void ndisc_fill_redirect_hdr_opti
*(opt++) = (rd_len >> 3);
opt += 6;
- memcpy(opt, ipv6_hdr(orig_skb), rd_len - 8);
+ skb_copy_bits(orig_skb, skb_network_offset(orig_skb), opt,
+ rd_len - 8);
}
void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
Patches currently in stable-queue which might be from lorenzo.bianconi(a)redhat.com are
queue-4.4/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
This is a note to let you know that I've just added the patch titled
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_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:
ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_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 foo@baz Thu Mar 29 08:33:08 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Mon, 5 Mar 2018 08:51:03 -0800
Subject: ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit ca0edb131bdf1e6beaeb2b8289fd6b374b74147d ]
A tun device type can trivially be set to arbitrary value using
TUNSETLINK ioctl().
Therefore, lowpan_device_event() must really check that ieee802154_ptr
is not NULL.
Fixes: 2c88b5283f60d ("ieee802154: 6lowpan: remove check on null")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: Alexander Aring <alex.aring(a)gmail.com>
Cc: Stefan Schmidt <stefan(a)osg.samsung.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Stefan Schmidt <stefan(a)osg.samsung.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ieee802154/6lowpan/core.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -206,9 +206,13 @@ static inline void lowpan_netlink_fini(v
static int lowpan_device_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
- struct net_device *wdev = netdev_notifier_info_to_dev(ptr);
+ struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
+ struct wpan_dev *wpan_dev;
- if (wdev->type != ARPHRD_IEEE802154)
+ if (ndev->type != ARPHRD_IEEE802154)
+ return NOTIFY_DONE;
+ wpan_dev = ndev->ieee802154_ptr;
+ if (!wpan_dev)
goto out;
switch (event) {
@@ -217,8 +221,8 @@ static int lowpan_device_event(struct no
* also delete possible lowpan interfaces which belongs
* to the wpan interface.
*/
- if (wdev->ieee802154_ptr->lowpan_dev)
- lowpan_dellink(wdev->ieee802154_ptr->lowpan_dev, NULL);
+ if (wpan_dev->lowpan_dev)
+ lowpan_dellink(wpan_dev->lowpan_dev, NULL);
break;
default:
break;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.4/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.4/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.4/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
This is a note to let you know that I've just added the patch titled
dccp: check sk for closed state in dccp_sendmsg()
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:
dccp-check-sk-for-closed-state-in-dccp_sendmsg.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 Thu Mar 29 08:33:08 CEST 2018
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Date: Tue, 6 Mar 2018 22:57:01 +0300
Subject: dccp: check sk for closed state in dccp_sendmsg()
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
[ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ]
dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL,
therefore if DCCP socket is disconnected and dccp_sendmsg() is
called after it, it will cause a NULL pointer dereference in
dccp_write_xmit().
This crash and the reproducer was reported by syzbot. Looks like
it is reproduced if commit 69c64866ce07 ("dccp: CVE-2017-8824:
use-after-free in DCCP code") is applied.
Reported-by: syzbot+f99ab3887ab65d70f816(a)syzkaller.appspotmail.com
Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/dccp/proto.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -789,6 +789,11 @@ int dccp_sendmsg(struct sock *sk, struct
if (skb == NULL)
goto out_release;
+ if (sk->sk_state == DCCP_CLOSED) {
+ rc = -ENOTCONN;
+ goto out_discard;
+ }
+
skb_reserve(skb, sk->sk_prot->max_header);
rc = memcpy_from_msg(skb_put(skb, len), msg, len);
if (rc != 0)
Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are
queue-4.4/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
team: Fix double free in error path
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:
team-fix-double-free-in-error-path.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 Thu Mar 29 08:53:48 CEST 2018
From: Arkadi Sharshevsky <arkadis(a)mellanox.com>
Date: Thu, 8 Mar 2018 12:42:10 +0200
Subject: team: Fix double free in error path
From: Arkadi Sharshevsky <arkadis(a)mellanox.com>
[ Upstream commit cbcc607e18422555db569b593608aec26111cb0b ]
The __send_and_alloc_skb() receives a skb ptr as a parameter but in
case it fails the skb is not valid:
- Send failed and released the skb internally.
- Allocation failed.
The current code tries to release the skb in case of failure which
causes redundant freeing.
Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
Signed-off-by: Arkadi Sharshevsky <arkadis(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>
---
drivers/net/team/team.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2368,7 +2368,7 @@ send_done:
if (!nlh) {
err = __send_and_alloc_skb(&skb, team, portid, send_func);
if (err)
- goto errout;
+ return err;
goto send_done;
}
@@ -2648,7 +2648,7 @@ send_done:
if (!nlh) {
err = __send_and_alloc_skb(&skb, team, portid, send_func);
if (err)
- goto errout;
+ return err;
goto send_done;
}
Patches currently in stable-queue which might be from arkadis(a)mellanox.com are
queue-3.18/team-fix-double-free-in-error-path.patch
This is a note to let you know that I've just added the patch titled
skbuff: Fix not waking applications when errors are enqueued
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:
skbuff-fix-not-waking-applications-when-errors-are-enqueued.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 Thu Mar 29 08:53:48 CEST 2018
From: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
Date: Wed, 14 Mar 2018 13:32:09 -0700
Subject: skbuff: Fix not waking applications when errors are enqueued
From: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
[ Upstream commit 6e5d58fdc9bedd0255a8781b258f10bbdc63e975 ]
When errors are enqueued to the error queue via sock_queue_err_skb()
function, it is possible that the waiting application is not notified.
Calling 'sk->sk_data_ready()' would not notify applications that
selected only POLLERR events in poll() (for example).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Randy E. Witt <randy.e.witt(a)intel.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3527,7 +3527,7 @@ int sock_queue_err_skb(struct sock *sk,
skb_queue_tail(&sk->sk_error_queue, skb);
if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_data_ready(sk);
+ sk->sk_error_report(sk);
return 0;
}
EXPORT_SYMBOL(sock_queue_err_skb);
Patches currently in stable-queue which might be from vinicius.gomes(a)intel.com are
queue-3.18/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: when thread completes, wake up all waiters
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:
s390-qeth-when-thread-completes-wake-up-all-waiters.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 Thu Mar 29 08:53:48 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:13 +0100
Subject: s390/qeth: when thread completes, wake up all waiters
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 1063e432bb45be209427ed3f1ca3908e4aa3c7d7 ]
qeth_wait_for_threads() is potentially called by multiple users, make
sure to notify all of them after qeth_clear_thread_running_bit()
adjusted the thread_running_mask. With no timeout, callers would
otherwise stall.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -944,7 +944,7 @@ void qeth_clear_thread_running_bit(struc
spin_lock_irqsave(&card->thread_mask_lock, flags);
card->thread_running_mask &= ~thread;
spin_unlock_irqrestore(&card->thread_mask_lock, flags);
- wake_up(&card->wait_q);
+ wake_up_all(&card->wait_q);
}
EXPORT_SYMBOL_GPL(qeth_clear_thread_running_bit);
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-3.18/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-3.18/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-3.18/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-3.18/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-3.18/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: on channel error, reject further cmd requests
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:
s390-qeth-on-channel-error-reject-further-cmd-requests.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 Thu Mar 29 08:53:48 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:15 +0100
Subject: s390/qeth: on channel error, reject further cmd requests
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit a6c3d93963e4b333c764fde69802c3ea9eaa9d5c ]
When the IRQ handler determines that one of the cmd IO channels has
failed and schedules recovery, block any further cmd requests from
being submitted. The request would inevitably stall, and prevent the
recovery from making progress until the request times out.
This sort of error was observed after Live Guest Relocation, where
the pending IO on the READ channel intentionally gets terminated to
kick-start recovery. Simultaneously the guest executed SIOCETHTOOL,
triggering qeth to issue a QUERY CARD INFO command. The command
then stalled in the inoperabel WRITE channel.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -1158,6 +1158,7 @@ static void qeth_irq(struct ccw_device *
}
rc = qeth_get_problem(cdev, irb);
if (rc) {
+ card->read_or_write_problem = 1;
qeth_clear_ipacmd_list(card);
qeth_schedule_recovery(card);
goto out;
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-3.18/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-3.18/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-3.18/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-3.18/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-3.18/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: lock read device while queueing next buffer
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:
s390-qeth-lock-read-device-while-queueing-next-buffer.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 Thu Mar 29 08:53:48 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:14 +0100
Subject: s390/qeth: lock read device while queueing next buffer
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 17bf8c9b3d499d5168537c98b61eb7a1fcbca6c2 ]
For calling ccw_device_start(), issue_next_read() needs to hold the
device's ccwlock.
This is satisfied for the IRQ handler path (where qeth_irq() gets called
under the ccwlock), but we need explicit locking for the initial call by
the MPC initialization.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -517,8 +517,7 @@ static inline int qeth_is_cq(struct qeth
queue == card->qdio.no_in_queues - 1;
}
-
-static int qeth_issue_next_read(struct qeth_card *card)
+static int __qeth_issue_next_read(struct qeth_card *card)
{
int rc;
struct qeth_cmd_buffer *iob;
@@ -549,6 +548,17 @@ static int qeth_issue_next_read(struct q
return rc;
}
+static int qeth_issue_next_read(struct qeth_card *card)
+{
+ int ret;
+
+ spin_lock_irq(get_ccwdev_lock(CARD_RDEV(card)));
+ ret = __qeth_issue_next_read(card);
+ spin_unlock_irq(get_ccwdev_lock(CARD_RDEV(card)));
+
+ return ret;
+}
+
static struct qeth_reply *qeth_alloc_reply(struct qeth_card *card)
{
struct qeth_reply *reply;
@@ -1166,7 +1176,7 @@ static void qeth_irq(struct ccw_device *
return;
if (channel == &card->read &&
channel->state == CH_STATE_UP)
- qeth_issue_next_read(card);
+ __qeth_issue_next_read(card);
iob = channel->iob;
index = channel->buf_no;
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-3.18/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-3.18/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-3.18/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-3.18/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-3.18/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
netlink: avoid a double skb free in genlmsg_mcast()
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:
netlink-avoid-a-double-skb-free-in-genlmsg_mcast.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 Thu Mar 29 08:53:48 CEST 2018
From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Date: Wed, 14 Mar 2018 21:10:23 +0100
Subject: netlink: avoid a double skb free in genlmsg_mcast()
From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
[ Upstream commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb ]
nlmsg_multicast() consumes always the skb, thus the original skb must be
freed only when this function is called with a clone.
Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netlink/genetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -1083,7 +1083,7 @@ static int genlmsg_mcast(struct sk_buff
if (!err)
delivered = true;
else if (err != -ESRCH)
- goto error;
+ return err;
return delivered ? 0 : -ESRCH;
error:
kfree_skb(skb);
Patches currently in stable-queue which might be from nicolas.dichtel(a)6wind.com are
queue-3.18/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: free netdevice when removing a card
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:
s390-qeth-free-netdevice-when-removing-a-card.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 Thu Mar 29 08:33:08 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:12 +0100
Subject: s390/qeth: free netdevice when removing a card
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 6be687395b3124f002a653c1a50b3260222b3cd7 ]
On removal, a qeth card's netdevice is currently not properly freed
because the call chain looks as follows:
qeth_core_remove_device(card)
lx_remove_device(card)
unregister_netdev(card->dev)
card->dev = NULL !!!
qeth_core_free_card(card)
if (card->dev) !!!
free_netdev(card->dev)
Fix it by free'ing the netdev straight after unregistering. This also
fixes the sysfs-driven layer switch case (qeth_dev_layer2_store()),
where the need to free the current netdevice was not considered at all.
Note that free_netdev() takes care of the netif_napi_del() for us too.
Fixes: 4a71df50047f ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Reviewed-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 2 --
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -4937,8 +4937,6 @@ static void qeth_core_free_card(struct q
QETH_DBF_HEX(SETUP, 2, &card, sizeof(void *));
qeth_clean_channel(&card->read);
qeth_clean_channel(&card->write);
- if (card->dev)
- free_netdev(card->dev);
kfree(card->ip_tbd_list);
qeth_free_qdio_buffers(card);
unregister_service_level(&card->qeth_service_level);
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -922,8 +922,8 @@ static void qeth_l2_remove_device(struct
qeth_l2_set_offline(cgdev);
if (card->dev) {
- netif_napi_del(&card->napi);
unregister_netdev(card->dev);
+ free_netdev(card->dev);
card->dev = NULL;
}
return;
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -3333,8 +3333,8 @@ static void qeth_l3_remove_device(struct
qeth_l3_set_offline(cgdev);
if (card->dev) {
- netif_napi_del(&card->napi);
unregister_netdev(card->dev);
+ free_netdev(card->dev);
card->dev = NULL;
}
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-3.18/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-3.18/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-3.18/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-3.18/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-3.18/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
net/iucv: Free memory obtained by kzalloc
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-iucv-free-memory-obtained-by-kzalloc.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 Thu Mar 29 08:53:48 CEST 2018
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Tue, 13 Mar 2018 16:50:06 +0100
Subject: net/iucv: Free memory obtained by kzalloc
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit fa6a91e9b907231d2e38ea5ed89c537b3525df3d ]
Free memory by calling put_device(), if afiucv_iucv_init is not
successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Ursula Braun <ursula.braun(a)de.ibm.com>
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/iucv/af_iucv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -2383,9 +2383,11 @@ static int afiucv_iucv_init(void)
af_iucv_dev->driver = &af_iucv_driver;
err = device_register(af_iucv_dev);
if (err)
- goto out_driver;
+ goto out_iucv_dev;
return 0;
+out_iucv_dev:
+ put_device(af_iucv_dev);
out_driver:
driver_unregister(&af_iucv_driver);
out_iucv:
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-3.18/net-iucv-free-memory-obtained-by-kzalloc.patch
This is a note to let you know that I've just added the patch titled
net: fec: Fix unbalanced PM runtime calls
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-fec-fix-unbalanced-pm-runtime-calls.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 Thu Mar 29 08:53:48 CEST 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Sun, 18 Mar 2018 12:49:51 -0700
Subject: net: fec: Fix unbalanced PM runtime calls
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit a069215cf5985f3aa1bba550264907d6bd05c5f7 ]
When unbinding/removing the driver, we will run into the following warnings:
[ 259.655198] fec 400d1000.ethernet: 400d1000.ethernet supply phy not found, using dummy regulator
[ 259.665065] fec 400d1000.ethernet: Unbalanced pm_runtime_enable!
[ 259.672770] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
[ 259.683062] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: f2:3e:93:b7:29:c1
[ 259.696239] libphy: fec_enet_mii_bus: probed
Avoid these warnings by balancing the runtime PM calls during fec_drv_remove().
Signed-off-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/ethernet/freescale/fec_main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3339,6 +3339,8 @@ fec_drv_remove(struct platform_device *p
if (fep->reg_phy)
regulator_disable(fep->reg_phy);
fec_enet_clk_enable(ndev, false);
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
of_node_put(fep->phy_node);
free_netdev(ndev);
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-3.18/net-fec-fix-unbalanced-pm-runtime-calls.patch
This is a note to let you know that I've just added the patch titled
net: Only honor ifindex in IP_PKTINFO if non-0
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-only-honor-ifindex-in-ip_pktinfo-if-non-0.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 Thu Mar 29 08:53:48 CEST 2018
From: David Ahern <dsahern(a)gmail.com>
Date: Fri, 16 Feb 2018 11:03:03 -0800
Subject: net: Only honor ifindex in IP_PKTINFO if non-0
From: David Ahern <dsahern(a)gmail.com>
[ Upstream commit 2cbb4ea7de167b02ffa63e9cdfdb07a7e7094615 ]
Only allow ifindex from IP_PKTINFO to override SO_BINDTODEVICE settings
if the index is actually set in the message.
Signed-off-by: David Ahern <dsahern(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -206,7 +206,8 @@ int ip_cmsg_send(struct net *net, struct
src_info = (struct in6_pktinfo *)CMSG_DATA(cmsg);
if (!ipv6_addr_v4mapped(&src_info->ipi6_addr))
return -EINVAL;
- ipc->oif = src_info->ipi6_ifindex;
+ if (src_info->ipi6_ifindex)
+ ipc->oif = src_info->ipi6_ifindex;
ipc->addr = src_info->ipi6_addr.s6_addr32[3];
continue;
}
@@ -227,7 +228,8 @@ int ip_cmsg_send(struct net *net, struct
if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct in_pktinfo)))
return -EINVAL;
info = (struct in_pktinfo *)CMSG_DATA(cmsg);
- ipc->oif = info->ipi_ifindex;
+ if (info->ipi_ifindex)
+ ipc->oif = info->ipi_ifindex;
ipc->addr = info->ipi_spec_dst.s_addr;
break;
}
Patches currently in stable-queue which might be from dsahern(a)gmail.com are
queue-3.18/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
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-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.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 Thu Mar 29 08:53:48 CEST 2018
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
Date: Fri, 16 Mar 2018 00:56:01 +0800
Subject: net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
[ Upstream commit f9db50691db4a7d860fce985f080bb3fc23a7ede ]
According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
available when PHY is configured in RGMII mode with 10Mbps speed. It will
cause some networking issues without RGMII mode, such as carrier sense
errors and low throughput. TI also mentioned this issue in their forum[4].
This patch adds the check mechanism for PHY interface with RGMII interface
type, the in-band mode can only be set in RGMII mode with 10Mbps speed.
References:
[1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
[2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
[3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf
[4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155
Suggested-by: Holsety Chen (陳憲輝) <Holsety.Chen(a)moxa.com>
Signed-off-by: SZ Lin (林上智) <sz.lin(a)moxa.com>
Signed-off-by: Schuyler Patton <spatton(a)ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko(a)ti.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/ti/cpsw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -872,7 +872,8 @@ static void _cpsw_adjust_link(struct cps
/* set speed_in input in case RMII mode is used in 100Mbps */
if (phy->speed == 100)
mac_control |= BIT(15);
- else if (phy->speed == 10)
+ /* in band mode only works in 10Mbps RGMII mode */
+ else if ((phy->speed == 10) && phy_interface_is_rgmii(phy))
mac_control |= BIT(18); /* In Band mode */
if (priv->rx_pause)
Patches currently in stable-queue which might be from sz.lin(a)moxa.com are
queue-3.18/net-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
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-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.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 Thu Mar 29 08:53:48 CEST 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 18 Mar 2018 23:59:36 +0100
Subject: net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 00777fac28ba3e126b9e63e789a613e8bd2cab25 ]
If the optional regulator is deferred, we must release some resources.
They will be re-allocated when the probe function will be called again.
Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_rockchip.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -150,8 +150,10 @@ static int emac_rockchip_probe(struct pl
/* Optional regulator for PHY */
priv->regulator = devm_regulator_get_optional(dev, "phy");
if (IS_ERR(priv->regulator)) {
- if (PTR_ERR(priv->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(priv->regulator) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto out_clk_disable;
+ }
dev_err(dev, "no regulator found\n");
priv->regulator = NULL;
}
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-3.18/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
This is a note to let you know that I've just added the patch titled
l2tp: do not accept arbitrary sockets
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:
l2tp-do-not-accept-arbitrary-sockets.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 Thu Mar 29 08:53:48 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Tue, 6 Mar 2018 07:54:53 -0800
Subject: l2tp: do not accept arbitrary sockets
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 17cfe79a65f98abe535261856c5aef14f306dff7 ]
syzkaller found an issue caused by lack of sufficient checks
in l2tp_tunnel_create()
RAW sockets can not be considered as UDP ones for instance.
In another patch, we shall replace all pr_err() by less intrusive
pr_debug() so that syzkaller can find other bugs faster.
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Acked-by: James Chapman <jchapman(a)katalix.com>
==================================================================
BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
dst_release: dst:00000000d53d0d0f refcnt:-1
Write of size 1 at addr ffff8801d013b798 by task syz-executor3/6242
CPU: 1 PID: 6242 Comm: syz-executor3 Not tainted 4.16.0-rc2+ #253
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23b/0x360 mm/kasan/report.c:412
__asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
l2tp_tunnel_create+0x1354/0x17f0 net/l2tp/l2tp_core.c:1596
pppol2tp_connect+0x14b1/0x1dd0 net/l2tp/l2tp_ppp.c:707
SYSC_connect+0x213/0x4a0 net/socket.c:1640
SyS_connect+0x24/0x30 net/socket.c:1621
do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1517,9 +1517,14 @@ int l2tp_tunnel_create(struct net *net,
encap = cfg->encap;
/* Quick sanity checks */
+ err = -EPROTONOSUPPORT;
+ if (sk->sk_type != SOCK_DGRAM) {
+ pr_debug("tunl %hu: fd %d wrong socket type\n",
+ tunnel_id, fd);
+ goto err;
+ }
switch (encap) {
case L2TP_ENCAPTYPE_UDP:
- err = -EPROTONOSUPPORT;
if (sk->sk_protocol != IPPROTO_UDP) {
pr_err("tunl %hu: fd %d wrong protocol, got %d, expected %d\n",
tunnel_id, fd, sk->sk_protocol, IPPROTO_UDP);
@@ -1527,7 +1532,6 @@ int l2tp_tunnel_create(struct net *net,
}
break;
case L2TP_ENCAPTYPE_IP:
- err = -EPROTONOSUPPORT;
if (sk->sk_protocol != IPPROTO_L2TP) {
pr_err("tunl %hu: fd %d wrong protocol, got %d, expected %d\n",
tunnel_id, fd, sk->sk_protocol, IPPROTO_L2TP);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-3.18/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-3.18/l2tp-do-not-accept-arbitrary-sockets.patch
This is a note to let you know that I've just added the patch titled
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
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:
ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.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 Thu Mar 29 08:53:48 CEST 2018
From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Date: Thu, 8 Mar 2018 17:00:02 +0100
Subject: ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
[ Upstream commit 9f62c15f28b0d1d746734666d88a79f08ba1e43e ]
Fix the following slab-out-of-bounds kasan report in
ndisc_fill_redirect_hdr_option when the incoming ipv6 packet is not
linear and the accessed data are not in the linear data region of orig_skb.
[ 1503.122508] ==================================================================
[ 1503.122832] BUG: KASAN: slab-out-of-bounds in ndisc_send_redirect+0x94e/0x990
[ 1503.123036] Read of size 1184 at addr ffff8800298ab6b0 by task netperf/1932
[ 1503.123220] CPU: 0 PID: 1932 Comm: netperf Not tainted 4.16.0-rc2+ #124
[ 1503.123347] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
[ 1503.123527] Call Trace:
[ 1503.123579] <IRQ>
[ 1503.123638] print_address_description+0x6e/0x280
[ 1503.123849] kasan_report+0x233/0x350
[ 1503.123946] memcpy+0x1f/0x50
[ 1503.124037] ndisc_send_redirect+0x94e/0x990
[ 1503.125150] ip6_forward+0x1242/0x13b0
[...]
[ 1503.153890] Allocated by task 1932:
[ 1503.153982] kasan_kmalloc+0x9f/0xd0
[ 1503.154074] __kmalloc_track_caller+0xb5/0x160
[ 1503.154198] __kmalloc_reserve.isra.41+0x24/0x70
[ 1503.154324] __alloc_skb+0x130/0x3e0
[ 1503.154415] sctp_packet_transmit+0x21a/0x1810
[ 1503.154533] sctp_outq_flush+0xc14/0x1db0
[ 1503.154624] sctp_do_sm+0x34e/0x2740
[ 1503.154715] sctp_primitive_SEND+0x57/0x70
[ 1503.154807] sctp_sendmsg+0xaa6/0x1b10
[ 1503.154897] sock_sendmsg+0x68/0x80
[ 1503.154987] ___sys_sendmsg+0x431/0x4b0
[ 1503.155078] __sys_sendmsg+0xa4/0x130
[ 1503.155168] do_syscall_64+0x171/0x3f0
[ 1503.155259] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 1503.155436] Freed by task 1932:
[ 1503.155527] __kasan_slab_free+0x134/0x180
[ 1503.155618] kfree+0xbc/0x180
[ 1503.155709] skb_release_data+0x27f/0x2c0
[ 1503.155800] consume_skb+0x94/0xe0
[ 1503.155889] sctp_chunk_put+0x1aa/0x1f0
[ 1503.155979] sctp_inq_pop+0x2f8/0x6e0
[ 1503.156070] sctp_assoc_bh_rcv+0x6a/0x230
[ 1503.156164] sctp_inq_push+0x117/0x150
[ 1503.156255] sctp_backlog_rcv+0xdf/0x4a0
[ 1503.156346] __release_sock+0x142/0x250
[ 1503.156436] release_sock+0x80/0x180
[ 1503.156526] sctp_sendmsg+0xbb0/0x1b10
[ 1503.156617] sock_sendmsg+0x68/0x80
[ 1503.156708] ___sys_sendmsg+0x431/0x4b0
[ 1503.156799] __sys_sendmsg+0xa4/0x130
[ 1503.156889] do_syscall_64+0x171/0x3f0
[ 1503.156980] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 1503.157158] The buggy address belongs to the object at ffff8800298ab600
which belongs to the cache kmalloc-1024 of size 1024
[ 1503.157444] The buggy address is located 176 bytes inside of
1024-byte region [ffff8800298ab600, ffff8800298aba00)
[ 1503.157702] The buggy address belongs to the page:
[ 1503.157820] page:ffffea0000a62a00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
[ 1503.158053] flags: 0x4000000000008100(slab|head)
[ 1503.158171] raw: 4000000000008100 0000000000000000 0000000000000000 00000001800e000e
[ 1503.158350] raw: dead000000000100 dead000000000200 ffff880036002600 0000000000000000
[ 1503.158523] page dumped because: kasan: bad access detected
[ 1503.158698] Memory state around the buggy address:
[ 1503.158816] ffff8800298ab900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1503.158988] ffff8800298ab980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1503.159165] >ffff8800298aba00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 1503.159338] ^
[ 1503.159436] ffff8800298aba80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1503.159610] ffff8800298abb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1503.159785] ==================================================================
[ 1503.159964] Disabling lock debugging due to kernel taint
The test scenario to trigger the issue consists of 4 devices:
- H0: data sender, connected to LAN0
- H1: data receiver, connected to LAN1
- GW0 and GW1: routers between LAN0 and LAN1. Both of them have an
ethernet connection on LAN0 and LAN1
On H{0,1} set GW0 as default gateway while on GW0 set GW1 as next hop for
data from LAN0 to LAN1.
Moreover create an ip6ip6 tunnel between H0 and H1 and send 3 concurrent
data streams (TCP/UDP/SCTP) from H0 to H1 through ip6ip6 tunnel (send
buffer size is set to 16K). While data streams are active flush the route
cache on HA multiple times.
I have not been able to identify a given commit that introduced the issue
since, using the reproducer described above, the kasan report has been
triggered from 4.14 and I have not gone back further.
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ndisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1443,7 +1443,8 @@ static void ndisc_fill_redirect_hdr_opti
*(opt++) = (rd_len >> 3);
opt += 6;
- memcpy(opt, ipv6_hdr(orig_skb), rd_len - 8);
+ skb_copy_bits(orig_skb, skb_network_offset(orig_skb), opt,
+ rd_len - 8);
}
void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
Patches currently in stable-queue which might be from lorenzo.bianconi(a)redhat.com are
queue-3.18/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
This is a note to let you know that I've just added the patch titled
dccp: check sk for closed state in dccp_sendmsg()
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:
dccp-check-sk-for-closed-state-in-dccp_sendmsg.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 Thu Mar 29 08:53:48 CEST 2018
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Date: Tue, 6 Mar 2018 22:57:01 +0300
Subject: dccp: check sk for closed state in dccp_sendmsg()
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
[ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ]
dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL,
therefore if DCCP socket is disconnected and dccp_sendmsg() is
called after it, it will cause a NULL pointer dereference in
dccp_write_xmit().
This crash and the reproducer was reported by syzbot. Looks like
it is reproduced if commit 69c64866ce07 ("dccp: CVE-2017-8824:
use-after-free in DCCP code") is applied.
Reported-by: syzbot+f99ab3887ab65d70f816(a)syzkaller.appspotmail.com
Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/dccp/proto.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -792,6 +792,11 @@ int dccp_sendmsg(struct kiocb *iocb, str
if (skb == NULL)
goto out_release;
+ if (sk->sk_state == DCCP_CLOSED) {
+ rc = -ENOTCONN;
+ goto out_discard;
+ }
+
skb_reserve(skb, sk->sk_prot->max_header);
rc = memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len);
if (rc != 0)
Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are
queue-3.18/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
The patch below does not apply to the 4.4-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 4dcb31d4649df36297296b819437709f5407059c Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 14 Mar 2018 09:04:16 -0700
Subject: [PATCH] net: use skb_to_full_sk() in skb_update_prio()
Andrei Vagin reported a KASAN: slab-out-of-bounds error in
skb_update_prio()
Since SYNACK might be attached to a request socket, we need to
get back to the listener socket.
Since this listener is manipulated without locks, add const
qualifiers to sock_cgroup_prioidx() so that the const can also
be used in skb_update_prio()
Also add the const qualifier to sock_cgroup_classid() for consistency.
Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Andrei Vagin <avagin(a)virtuozzo.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 9f242b876fde..f8e76d01a5ad 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -755,13 +755,13 @@ struct sock_cgroup_data {
* updaters and return part of the previous pointer as the prioidx or
* classid. Such races are short-lived and the result isn't critical.
*/
-static inline u16 sock_cgroup_prioidx(struct sock_cgroup_data *skcd)
+static inline u16 sock_cgroup_prioidx(const struct sock_cgroup_data *skcd)
{
/* fallback to 1 which is always the ID of the root cgroup */
return (skcd->is_data & 1) ? skcd->prioidx : 1;
}
-static inline u32 sock_cgroup_classid(struct sock_cgroup_data *skcd)
+static inline u32 sock_cgroup_classid(const struct sock_cgroup_data *skcd)
{
/* fallback to 0 which is the unconfigured default classid */
return (skcd->is_data & 1) ? skcd->classid : 0;
diff --git a/net/core/dev.c b/net/core/dev.c
index 2cedf520cb28..12be20535714 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3278,15 +3278,23 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
#if IS_ENABLED(CONFIG_CGROUP_NET_PRIO)
static void skb_update_prio(struct sk_buff *skb)
{
- struct netprio_map *map = rcu_dereference_bh(skb->dev->priomap);
+ const struct netprio_map *map;
+ const struct sock *sk;
+ unsigned int prioidx;
- if (!skb->priority && skb->sk && map) {
- unsigned int prioidx =
- sock_cgroup_prioidx(&skb->sk->sk_cgrp_data);
+ if (skb->priority)
+ return;
+ map = rcu_dereference_bh(skb->dev->priomap);
+ if (!map)
+ return;
+ sk = skb_to_full_sk(skb);
+ if (!sk)
+ return;
- if (prioidx < map->priomap_len)
- skb->priority = map->priomap[prioidx];
- }
+ prioidx = sock_cgroup_prioidx(&sk->sk_cgrp_data);
+
+ if (prioidx < map->priomap_len)
+ skb->priority = map->priomap[prioidx];
}
#else
#define skb_update_prio(skb)
This is a note to let you know that I've just added the patch titled
genirq: Track whether the trigger type has been set
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:
genirq-track-whether-the-trigger-type-has-been-set.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 4f8413a3a799c958f7a10a6310a451e6b8aef5ad Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 9 Nov 2017 14:17:59 +0000
Subject: genirq: Track whether the trigger type has been set
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 4f8413a3a799c958f7a10a6310a451e6b8aef5ad upstream.
When requesting a shared interrupt, we assume that the firmware
support code (DT or ACPI) has called irqd_set_trigger_type
already, so that we can retrieve it and check that the requester
is being reasonnable.
Unfortunately, we still have non-DT, non-ACPI systems around,
and these guys won't call irqd_set_trigger_type before requesting
the interrupt. The consequence is that we fail the request that
would have worked before.
We can either chase all these use cases (boring), or address it
in core code (easier). Let's have a per-irq_desc flag that
indicates whether irqd_set_trigger_type has been called, and
let's just check it when checking for a shared interrupt.
If it hasn't been set, just take whatever the interrupt
requester asks.
Fixes: 382bd4de6182 ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs")
Cc: stable(a)vger.kernel.org
Reported-and-tested-by: Petr Cvek <petrcvekcz(a)gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/irq.h | 11 ++++++++++-
kernel/irq/manage.c | 13 ++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -175,6 +175,7 @@ struct irq_data {
* IRQD_IRQ_MASKED - Masked state of the interrupt
* IRQD_IRQ_INPROGRESS - In progress state of the interrupt
* IRQD_WAKEUP_ARMED - Wakeup mode armed
+ * IRQD_DEFAULT_TRIGGER_SET - Expected trigger already been set
*/
enum {
IRQD_TRIGGER_MASK = 0xf,
@@ -189,6 +190,7 @@ enum {
IRQD_IRQ_MASKED = (1 << 17),
IRQD_IRQ_INPROGRESS = (1 << 18),
IRQD_WAKEUP_ARMED = (1 << 19),
+ IRQD_DEFAULT_TRIGGER_SET = (1 << 25),
};
static inline bool irqd_is_setaffinity_pending(struct irq_data *d)
@@ -216,18 +218,25 @@ static inline void irqd_mark_affinity_wa
d->state_use_accessors |= IRQD_AFFINITY_SET;
}
+static inline bool irqd_trigger_type_was_set(struct irq_data *d)
+{
+ return d->state_use_accessors & IRQD_DEFAULT_TRIGGER_SET;
+}
+
static inline u32 irqd_get_trigger_type(struct irq_data *d)
{
return d->state_use_accessors & IRQD_TRIGGER_MASK;
}
/*
- * Must only be called inside irq_chip.irq_set_type() functions.
+ * Must only be called inside irq_chip.irq_set_type() functions or
+ * from the DT/ACPI setup code.
*/
static inline void irqd_set_trigger_type(struct irq_data *d, u32 type)
{
d->state_use_accessors &= ~IRQD_TRIGGER_MASK;
d->state_use_accessors |= type & IRQD_TRIGGER_MASK;
+ d->state_use_accessors |= IRQD_DEFAULT_TRIGGER_SET;
}
static inline bool irqd_is_level_type(struct irq_data *d)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1058,7 +1058,18 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
+ unsigned int oldtype;
+
+ /*
+ * If nobody did set the configuration before, inherit
+ * the one provided by the requester.
+ */
+ if (irqd_trigger_type_was_set(&desc->irq_data)) {
+ oldtype = irqd_get_trigger_type(&desc->irq_data);
+ } else {
+ oldtype = new->flags & IRQF_TRIGGER_MASK;
+ irqd_set_trigger_type(&desc->irq_data, oldtype);
+ }
if (!((old->flags & new->flags) & IRQF_SHARED) ||
(oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-3.18/genirq-track-whether-the-trigger-type-has-been-set.patch
This is a note to let you know that I've just added the patch titled
soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
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:
soc-fsl-qbman-fix-issue-in-qman_delete_cgr_safe.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 Wed Mar 28 20:16:33 CEST 2018
From: Madalin Bucur <madalin.bucur(a)nxp.com>
Date: Wed, 14 Mar 2018 08:37:28 -0500
Subject: soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
From: Madalin Bucur <madalin.bucur(a)nxp.com>
[ Upstream commit 96f413f47677366e0ae03797409bfcc4151dbf9e ]
The wait_for_completion() call in qman_delete_cgr_safe()
was triggering a scheduling while atomic bug, replacing the
kthread with a smp_call_function_single() call to fix it.
Signed-off-by: Madalin Bucur <madalin.bucur(a)nxp.com>
Signed-off-by: Roy Pledge <roy.pledge(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/soc/fsl/qbman/qman.c | 28 +++++-----------------------
1 file changed, 5 insertions(+), 23 deletions(-)
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2429,39 +2429,21 @@ struct cgr_comp {
struct completion completion;
};
-static int qman_delete_cgr_thread(void *p)
+static void qman_delete_cgr_smp_call(void *p)
{
- struct cgr_comp *cgr_comp = (struct cgr_comp *)p;
- int ret;
-
- ret = qman_delete_cgr(cgr_comp->cgr);
- complete(&cgr_comp->completion);
-
- return ret;
+ qman_delete_cgr((struct qman_cgr *)p);
}
void qman_delete_cgr_safe(struct qman_cgr *cgr)
{
- struct task_struct *thread;
- struct cgr_comp cgr_comp;
-
preempt_disable();
if (qman_cgr_cpus[cgr->cgrid] != smp_processor_id()) {
- init_completion(&cgr_comp.completion);
- cgr_comp.cgr = cgr;
- thread = kthread_create(qman_delete_cgr_thread, &cgr_comp,
- "cgr_del");
-
- if (IS_ERR(thread))
- goto out;
-
- kthread_bind(thread, qman_cgr_cpus[cgr->cgrid]);
- wake_up_process(thread);
- wait_for_completion(&cgr_comp.completion);
+ smp_call_function_single(qman_cgr_cpus[cgr->cgrid],
+ qman_delete_cgr_smp_call, cgr, true);
preempt_enable();
return;
}
-out:
+
qman_delete_cgr(cgr);
preempt_enable();
}
Patches currently in stable-queue which might be from madalin.bucur(a)nxp.com are
queue-4.9/soc-fsl-qbman-fix-issue-in-qman_delete_cgr_safe.patch
This is a note to let you know that I've just added the patch titled
team: Fix double free in error path
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:
team-fix-double-free-in-error-path.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 Wed Mar 28 20:16:33 CEST 2018
From: Arkadi Sharshevsky <arkadis(a)mellanox.com>
Date: Thu, 8 Mar 2018 12:42:10 +0200
Subject: team: Fix double free in error path
From: Arkadi Sharshevsky <arkadis(a)mellanox.com>
[ Upstream commit cbcc607e18422555db569b593608aec26111cb0b ]
The __send_and_alloc_skb() receives a skb ptr as a parameter but in
case it fails the skb is not valid:
- Send failed and released the skb internally.
- Allocation failed.
The current code tries to release the skb in case of failure which
causes redundant freeing.
Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
Signed-off-by: Arkadi Sharshevsky <arkadis(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>
---
drivers/net/team/team.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2403,7 +2403,7 @@ send_done:
if (!nlh) {
err = __send_and_alloc_skb(&skb, team, portid, send_func);
if (err)
- goto errout;
+ return err;
goto send_done;
}
@@ -2688,7 +2688,7 @@ send_done:
if (!nlh) {
err = __send_and_alloc_skb(&skb, team, portid, send_func);
if (err)
- goto errout;
+ return err;
goto send_done;
}
Patches currently in stable-queue which might be from arkadis(a)mellanox.com are
queue-4.9/team-fix-double-free-in-error-path.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: don't return bogus Sg_requests
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:
scsi-sg-don-t-return-bogus-sg_requests.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 48ae8484e9fc324b4968d33c585e54bc98e44d61 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Wed, 10 May 2017 09:53:40 +0200
Subject: scsi: sg: don't return bogus Sg_requests
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 48ae8484e9fc324b4968d33c585e54bc98e44d61 upstream.
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in
sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case
the list search doesn't find a valid request.
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Gilbert <dgilbert(a)interlog.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.de>
Acked-by: Doug Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Tony Battersby <tonyb(a)cybernetics.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -2064,11 +2064,12 @@ sg_get_rq_mark(Sg_fd * sfp, int pack_id)
if ((1 == resp->done) && (!resp->sg_io_owned) &&
((-1 == pack_id) || (resp->header.pack_id == pack_id))) {
resp->done = 2; /* guard against other readers */
- break;
+ write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
+ return resp;
}
}
write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
- return resp;
+ return NULL;
}
/* always adds to end of list */
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.9/scsi-sg-don-t-return-bogus-sg_requests.patch
This is a note to let you know that I've just added the patch titled
skbuff: Fix not waking applications when errors are enqueued
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:
skbuff-fix-not-waking-applications-when-errors-are-enqueued.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 Wed Mar 28 20:16:33 CEST 2018
From: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
Date: Wed, 14 Mar 2018 13:32:09 -0700
Subject: skbuff: Fix not waking applications when errors are enqueued
From: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
[ Upstream commit 6e5d58fdc9bedd0255a8781b258f10bbdc63e975 ]
When errors are enqueued to the error queue via sock_queue_err_skb()
function, it is possible that the waiting application is not notified.
Calling 'sk->sk_data_ready()' would not notify applications that
selected only POLLERR events in poll() (for example).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Randy E. Witt <randy.e.witt(a)intel.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3717,7 +3717,7 @@ int sock_queue_err_skb(struct sock *sk,
skb_queue_tail(&sk->sk_error_queue, skb);
if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_data_ready(sk);
+ sk->sk_error_report(sk);
return 0;
}
EXPORT_SYMBOL(sock_queue_err_skb);
Patches currently in stable-queue which might be from vinicius.gomes(a)intel.com are
queue-4.9/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
This is a note to let you know that I've just added the patch titled
sch_netem: fix skb leak in netem_enqueue()
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:
sch_netem-fix-skb-leak-in-netem_enqueue.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 Wed Mar 28 20:16:33 CEST 2018
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Date: Mon, 5 Mar 2018 20:52:54 +0300
Subject: sch_netem: fix skb leak in netem_enqueue()
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
[ Upstream commit 35d889d10b649fda66121891ec05eca88150059d ]
When we exceed current packets limit and we have more than one
segment in the list returned by skb_gso_segment(), netem drops
only the first one, skipping the rest, hence kmemleak reports:
unreferenced object 0xffff880b5d23b600 (size 1024):
comm "softirq", pid 0, jiffies 4384527763 (age 2770.629s)
hex dump (first 32 bytes):
00 80 23 5d 0b 88 ff ff 00 00 00 00 00 00 00 00 ..#]............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000d8a19b9d>] __alloc_skb+0xc9/0x520
[<000000001709b32f>] skb_segment+0x8c8/0x3710
[<00000000c7b9bb88>] tcp_gso_segment+0x331/0x1830
[<00000000c921cba1>] inet_gso_segment+0x476/0x1370
[<000000008b762dd4>] skb_mac_gso_segment+0x1f9/0x510
[<000000002182660a>] __skb_gso_segment+0x1dd/0x620
[<00000000412651b9>] netem_enqueue+0x1536/0x2590 [sch_netem]
[<0000000005d3b2a9>] __dev_queue_xmit+0x1167/0x2120
[<00000000fc5f7327>] ip_finish_output2+0x998/0xf00
[<00000000d309e9d3>] ip_output+0x1aa/0x2c0
[<000000007ecbd3a4>] tcp_transmit_skb+0x18db/0x3670
[<0000000042d2a45f>] tcp_write_xmit+0x4d4/0x58c0
[<0000000056a44199>] tcp_tasklet_func+0x3d9/0x540
[<0000000013d06d02>] tasklet_action+0x1ca/0x250
[<00000000fcde0b8b>] __do_softirq+0x1b4/0x5a3
[<00000000e7ed027c>] irq_exit+0x1e2/0x210
Fix it by adding the rest of the segments, if any, to skb 'to_free'
list. Add new __qdisc_drop_all() and qdisc_drop_all() functions
because they can be useful in the future if we need to drop segmented
GSO packets in other places.
Fixes: 6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/sch_generic.h | 19 +++++++++++++++++++
net/sched/sch_netem.c | 2 +-
2 files changed, 20 insertions(+), 1 deletion(-)
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -675,6 +675,16 @@ static inline void __qdisc_drop(struct s
*to_free = skb;
}
+static inline void __qdisc_drop_all(struct sk_buff *skb,
+ struct sk_buff **to_free)
+{
+ if (skb->prev)
+ skb->prev->next = *to_free;
+ else
+ skb->next = *to_free;
+ *to_free = skb;
+}
+
static inline unsigned int __qdisc_queue_drop_head(struct Qdisc *sch,
struct qdisc_skb_head *qh,
struct sk_buff **to_free)
@@ -793,6 +803,15 @@ static inline int qdisc_drop(struct sk_b
qdisc_qstats_drop(sch);
return NET_XMIT_DROP;
+}
+
+static inline int qdisc_drop_all(struct sk_buff *skb, struct Qdisc *sch,
+ struct sk_buff **to_free)
+{
+ __qdisc_drop_all(skb, to_free);
+ qdisc_qstats_drop(sch);
+
+ return NET_XMIT_DROP;
}
/* Length to Time (L2T) lookup in a qdisc_rate_table, to determine how
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -513,7 +513,7 @@ static int netem_enqueue(struct sk_buff
}
if (unlikely(sch->q.qlen >= sch->limit))
- return qdisc_drop(skb, sch, to_free);
+ return qdisc_drop_all(skb, sch, to_free);
qdisc_qstats_backlog_inc(sch, skb);
Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are
queue-4.9/sch_netem-fix-skb-leak-in-netem_enqueue.patch
queue-4.9/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: when thread completes, wake up all waiters
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:
s390-qeth-when-thread-completes-wake-up-all-waiters.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 Wed Mar 28 20:16:33 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:13 +0100
Subject: s390/qeth: when thread completes, wake up all waiters
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 1063e432bb45be209427ed3f1ca3908e4aa3c7d7 ]
qeth_wait_for_threads() is potentially called by multiple users, make
sure to notify all of them after qeth_clear_thread_running_bit()
adjusted the thread_running_mask. With no timeout, callers would
otherwise stall.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -957,7 +957,7 @@ void qeth_clear_thread_running_bit(struc
spin_lock_irqsave(&card->thread_mask_lock, flags);
card->thread_running_mask &= ~thread;
spin_unlock_irqrestore(&card->thread_mask_lock, flags);
- wake_up(&card->wait_q);
+ wake_up_all(&card->wait_q);
}
EXPORT_SYMBOL_GPL(qeth_clear_thread_running_bit);
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.9/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.9/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.9/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.9/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: on channel error, reject further cmd requests
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:
s390-qeth-on-channel-error-reject-further-cmd-requests.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 Wed Mar 28 20:16:33 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:15 +0100
Subject: s390/qeth: on channel error, reject further cmd requests
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit a6c3d93963e4b333c764fde69802c3ea9eaa9d5c ]
When the IRQ handler determines that one of the cmd IO channels has
failed and schedules recovery, block any further cmd requests from
being submitted. The request would inevitably stall, and prevent the
recovery from making progress until the request times out.
This sort of error was observed after Live Guest Relocation, where
the pending IO on the READ channel intentionally gets terminated to
kick-start recovery. Simultaneously the guest executed SIOCETHTOOL,
triggering qeth to issue a QUERY CARD INFO command. The command
then stalled in the inoperabel WRITE channel.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -1171,6 +1171,7 @@ static void qeth_irq(struct ccw_device *
}
rc = qeth_get_problem(cdev, irb);
if (rc) {
+ card->read_or_write_problem = 1;
qeth_clear_ipacmd_list(card);
qeth_schedule_recovery(card);
goto out;
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.9/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.9/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.9/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.9/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: lock read device while queueing next buffer
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:
s390-qeth-lock-read-device-while-queueing-next-buffer.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 Wed Mar 28 20:16:33 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:14 +0100
Subject: s390/qeth: lock read device while queueing next buffer
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 17bf8c9b3d499d5168537c98b61eb7a1fcbca6c2 ]
For calling ccw_device_start(), issue_next_read() needs to hold the
device's ccwlock.
This is satisfied for the IRQ handler path (where qeth_irq() gets called
under the ccwlock), but we need explicit locking for the initial call by
the MPC initialization.
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -522,8 +522,7 @@ static inline int qeth_is_cq(struct qeth
queue == card->qdio.no_in_queues - 1;
}
-
-static int qeth_issue_next_read(struct qeth_card *card)
+static int __qeth_issue_next_read(struct qeth_card *card)
{
int rc;
struct qeth_cmd_buffer *iob;
@@ -554,6 +553,17 @@ static int qeth_issue_next_read(struct q
return rc;
}
+static int qeth_issue_next_read(struct qeth_card *card)
+{
+ int ret;
+
+ spin_lock_irq(get_ccwdev_lock(CARD_RDEV(card)));
+ ret = __qeth_issue_next_read(card);
+ spin_unlock_irq(get_ccwdev_lock(CARD_RDEV(card)));
+
+ return ret;
+}
+
static struct qeth_reply *qeth_alloc_reply(struct qeth_card *card)
{
struct qeth_reply *reply;
@@ -1179,7 +1189,7 @@ static void qeth_irq(struct ccw_device *
return;
if (channel == &card->read &&
channel->state == CH_STATE_UP)
- qeth_issue_next_read(card);
+ __qeth_issue_next_read(card);
iob = channel->iob;
index = channel->buf_no;
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.9/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.9/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.9/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.9/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: free netdevice when removing a card
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:
s390-qeth-free-netdevice-when-removing-a-card.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 Wed Mar 28 20:16:33 CEST 2018
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Date: Tue, 20 Mar 2018 07:59:12 +0100
Subject: s390/qeth: free netdevice when removing a card
From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
[ Upstream commit 6be687395b3124f002a653c1a50b3260222b3cd7 ]
On removal, a qeth card's netdevice is currently not properly freed
because the call chain looks as follows:
qeth_core_remove_device(card)
lx_remove_device(card)
unregister_netdev(card->dev)
card->dev = NULL !!!
qeth_core_free_card(card)
if (card->dev) !!!
free_netdev(card->dev)
Fix it by free'ing the netdev straight after unregistering. This also
fixes the sysfs-driven layer switch case (qeth_dev_layer2_store()),
where the need to free the current netdevice was not considered at all.
Note that free_netdev() takes care of the netif_napi_del() for us too.
Fixes: 4a71df50047f ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Reviewed-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_core_main.c | 2 --
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -4989,8 +4989,6 @@ static void qeth_core_free_card(struct q
QETH_DBF_HEX(SETUP, 2, &card, sizeof(void *));
qeth_clean_channel(&card->read);
qeth_clean_channel(&card->write);
- if (card->dev)
- free_netdev(card->dev);
qeth_free_qdio_buffers(card);
unregister_service_level(&card->qeth_service_level);
kfree(card);
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -1057,8 +1057,8 @@ static void qeth_l2_remove_device(struct
qeth_l2_set_offline(cgdev);
if (card->dev) {
- netif_napi_del(&card->napi);
unregister_netdev(card->dev);
+ free_netdev(card->dev);
card->dev = NULL;
}
return;
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -3192,8 +3192,8 @@ static void qeth_l3_remove_device(struct
qeth_l3_set_offline(cgdev);
if (card->dev) {
- netif_napi_del(&card->napi);
unregister_netdev(card->dev);
+ free_netdev(card->dev);
card->dev = NULL;
}
Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are
queue-4.9/s390-qeth-when-thread-completes-wake-up-all-waiters.patch
queue-4.9/s390-qeth-lock-read-device-while-queueing-next-buffer.patch
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
queue-4.9/s390-qeth-on-channel-error-reject-further-cmd-requests.patch
queue-4.9/s390-qeth-free-netdevice-when-removing-a-card.patch
This is a note to let you know that I've just added the patch titled
rhashtable: Fix rhlist duplicates insertion
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:
rhashtable-fix-rhlist-duplicates-insertion.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 Wed Mar 28 20:16:33 CEST 2018
From: Paul Blakey <paulb(a)mellanox.com>
Date: Sun, 4 Mar 2018 17:29:48 +0200
Subject: rhashtable: Fix rhlist duplicates insertion
From: Paul Blakey <paulb(a)mellanox.com>
[ Upstream commit d3dcf8eb615537526bd42ff27a081d46d337816e ]
When inserting duplicate objects (those with the same key),
current rhlist implementation messes up the chain pointers by
updating the bucket pointer instead of prev next pointer to the
newly inserted node. This causes missing elements on removal and
travesal.
Fix that by properly updating pprev pointer to point to
the correct rhash_head next pointer.
Issue: 1241076
Change-Id: I86b2c140bcb4aeb10b70a72a267ff590bb2b17e7
Fixes: ca26893f05e8 ('rhashtable: Add rhlist interface')
Signed-off-by: Paul Blakey <paulb(a)mellanox.com>
Acked-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/rhashtable.h | 4 +++-
lib/rhashtable.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -706,8 +706,10 @@ slow_path:
if (!key ||
(params.obj_cmpfn ?
params.obj_cmpfn(&arg, rht_obj(ht, head)) :
- rhashtable_compare(&arg, rht_obj(ht, head))))
+ rhashtable_compare(&arg, rht_obj(ht, head)))) {
+ pprev = &head->next;
continue;
+ }
data = rht_obj(ht, head);
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -448,8 +448,10 @@ static void *rhashtable_lookup_one(struc
if (!key ||
(ht->p.obj_cmpfn ?
ht->p.obj_cmpfn(&arg, rht_obj(ht, head)) :
- rhashtable_compare(&arg, rht_obj(ht, head))))
+ rhashtable_compare(&arg, rht_obj(ht, head)))) {
+ pprev = &head->next;
continue;
+ }
if (!ht->rhlist)
return rht_obj(ht, head);
Patches currently in stable-queue which might be from paulb(a)mellanox.com are
queue-4.9/rhashtable-fix-rhlist-duplicates-insertion.patch
This is a note to let you know that I've just added the patch titled
ppp: avoid loop in xmit recursion detection code
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:
ppp-avoid-loop-in-xmit-recursion-detection-code.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 Wed Mar 28 20:16:33 CEST 2018
From: Guillaume Nault <g.nault(a)alphalink.fr>
Date: Tue, 20 Mar 2018 16:49:26 +0100
Subject: ppp: avoid loop in xmit recursion detection code
From: Guillaume Nault <g.nault(a)alphalink.fr>
[ Upstream commit 6d066734e9f09cdea4a3b9cb76136db3f29cfb02 ]
We already detect situations where a PPP channel sends packets back to
its upper PPP device. While this is enough to avoid deadlocking on xmit
locks, this doesn't prevent packets from looping between the channel
and the unit.
The problem is that ppp_start_xmit() enqueues packets in ppp->file.xq
before checking for xmit recursion. Therefore, __ppp_xmit_process()
might dequeue a packet from ppp->file.xq and send it on the channel
which, in turn, loops it back on the unit. Then ppp_start_xmit()
queues the packet back to ppp->file.xq and __ppp_xmit_process() picks
it up and sends it again through the channel. Therefore, the packet
will loop between __ppp_xmit_process() and ppp_start_xmit() until some
other part of the xmit path drops it.
For L2TP, we rapidly fill the skb's headroom and pppol2tp_xmit() drops
the packet after a few iterations. But PPTP reallocates the headroom
if necessary, letting the loop run and exhaust the machine resources
(as reported in https://bugzilla.kernel.org/show_bug.cgi?id=199109).
Fix this by letting __ppp_xmit_process() enqueue the skb to
ppp->file.xq, so that we can check for recursion before adding it to
the queue. Now ppp_xmit_process() can drop the packet when recursion is
detected.
__ppp_channel_push() is a bit special. It calls __ppp_xmit_process()
without having any actual packet to send. This is used by
ppp_output_wakeup() to re-enable transmission on the parent unit (for
implementations like ppp_async.c, where the .start_xmit() function
might not consume the skb, leaving it in ppp->xmit_pending and
disabling transmission).
Therefore, __ppp_xmit_process() needs to handle the case where skb is
NULL, dequeuing as many packets as possible from ppp->file.xq.
Reported-by: xu heng <xuheng333(a)zoho.com>
Fixes: 55454a565836 ("ppp: avoid dealock on recursive xmit")
Signed-off-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ppp/ppp_generic.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -255,7 +255,7 @@ struct ppp_net {
/* Prototypes. */
static int ppp_unattached_ioctl(struct net *net, struct ppp_file *pf,
struct file *file, unsigned int cmd, unsigned long arg);
-static void ppp_xmit_process(struct ppp *ppp);
+static void ppp_xmit_process(struct ppp *ppp, struct sk_buff *skb);
static void ppp_send_frame(struct ppp *ppp, struct sk_buff *skb);
static void ppp_push(struct ppp *ppp);
static void ppp_channel_push(struct channel *pch);
@@ -511,13 +511,12 @@ static ssize_t ppp_write(struct file *fi
goto out;
}
- skb_queue_tail(&pf->xq, skb);
-
switch (pf->kind) {
case INTERFACE:
- ppp_xmit_process(PF_TO_PPP(pf));
+ ppp_xmit_process(PF_TO_PPP(pf), skb);
break;
case CHANNEL:
+ skb_queue_tail(&pf->xq, skb);
ppp_channel_push(PF_TO_CHANNEL(pf));
break;
}
@@ -1261,8 +1260,8 @@ ppp_start_xmit(struct sk_buff *skb, stru
put_unaligned_be16(proto, pp);
skb_scrub_packet(skb, !net_eq(ppp->ppp_net, dev_net(dev)));
- skb_queue_tail(&ppp->file.xq, skb);
- ppp_xmit_process(ppp);
+ ppp_xmit_process(ppp, skb);
+
return NETDEV_TX_OK;
outf:
@@ -1416,13 +1415,14 @@ static void ppp_setup(struct net_device
*/
/* Called to do any work queued up on the transmit side that can now be done */
-static void __ppp_xmit_process(struct ppp *ppp)
+static void __ppp_xmit_process(struct ppp *ppp, struct sk_buff *skb)
{
- struct sk_buff *skb;
-
ppp_xmit_lock(ppp);
if (!ppp->closing) {
ppp_push(ppp);
+
+ if (skb)
+ skb_queue_tail(&ppp->file.xq, skb);
while (!ppp->xmit_pending &&
(skb = skb_dequeue(&ppp->file.xq)))
ppp_send_frame(ppp, skb);
@@ -1436,7 +1436,7 @@ static void __ppp_xmit_process(struct pp
ppp_xmit_unlock(ppp);
}
-static void ppp_xmit_process(struct ppp *ppp)
+static void ppp_xmit_process(struct ppp *ppp, struct sk_buff *skb)
{
local_bh_disable();
@@ -1444,7 +1444,7 @@ static void ppp_xmit_process(struct ppp
goto err;
(*this_cpu_ptr(ppp->xmit_recursion))++;
- __ppp_xmit_process(ppp);
+ __ppp_xmit_process(ppp, skb);
(*this_cpu_ptr(ppp->xmit_recursion))--;
local_bh_enable();
@@ -1454,6 +1454,8 @@ static void ppp_xmit_process(struct ppp
err:
local_bh_enable();
+ kfree_skb(skb);
+
if (net_ratelimit())
netdev_err(ppp->dev, "recursion detected\n");
}
@@ -1938,7 +1940,7 @@ static void __ppp_channel_push(struct ch
if (skb_queue_empty(&pch->file.xq)) {
ppp = pch->ppp;
if (ppp)
- __ppp_xmit_process(ppp);
+ __ppp_xmit_process(ppp, NULL);
}
}
Patches currently in stable-queue which might be from g.nault(a)alphalink.fr are
queue-4.9/ppp-avoid-loop-in-xmit-recursion-detection-code.patch
queue-4.9/l2tp-do-not-accept-arbitrary-sockets.patch
This is a note to let you know that I've just added the patch titled
netlink: avoid a double skb free in genlmsg_mcast()
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:
netlink-avoid-a-double-skb-free-in-genlmsg_mcast.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 Wed Mar 28 20:16:33 CEST 2018
From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Date: Wed, 14 Mar 2018 21:10:23 +0100
Subject: netlink: avoid a double skb free in genlmsg_mcast()
From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
[ Upstream commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb ]
nlmsg_multicast() consumes always the skb, thus the original skb must be
freed only when this function is called with a clone.
Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netlink/genetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -1128,7 +1128,7 @@ static int genlmsg_mcast(struct sk_buff
if (!err)
delivered = true;
else if (err != -ESRCH)
- goto error;
+ return err;
return delivered ? 0 : -ESRCH;
error:
kfree_skb(skb);
Patches currently in stable-queue which might be from nicolas.dichtel(a)6wind.com are
queue-4.9/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
This is a note to let you know that I've just added the patch titled
net: use skb_to_full_sk() in skb_update_prio()
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-use-skb_to_full_sk-in-skb_update_prio.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 Wed Mar 28 20:16:33 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 14 Mar 2018 09:04:16 -0700
Subject: net: use skb_to_full_sk() in skb_update_prio()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 4dcb31d4649df36297296b819437709f5407059c ]
Andrei Vagin reported a KASAN: slab-out-of-bounds error in
skb_update_prio()
Since SYNACK might be attached to a request socket, we need to
get back to the listener socket.
Since this listener is manipulated without locks, add const
qualifiers to sock_cgroup_prioidx() so that the const can also
be used in skb_update_prio()
Also add the const qualifier to sock_cgroup_classid() for consistency.
Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Andrei Vagin <avagin(a)virtuozzo.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/cgroup-defs.h | 4 ++--
net/core/dev.c | 22 +++++++++++++++-------
2 files changed, 17 insertions(+), 9 deletions(-)
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -609,13 +609,13 @@ struct sock_cgroup_data {
* updaters and return part of the previous pointer as the prioidx or
* classid. Such races are short-lived and the result isn't critical.
*/
-static inline u16 sock_cgroup_prioidx(struct sock_cgroup_data *skcd)
+static inline u16 sock_cgroup_prioidx(const struct sock_cgroup_data *skcd)
{
/* fallback to 1 which is always the ID of the root cgroup */
return (skcd->is_data & 1) ? skcd->prioidx : 1;
}
-static inline u32 sock_cgroup_classid(struct sock_cgroup_data *skcd)
+static inline u32 sock_cgroup_classid(const struct sock_cgroup_data *skcd)
{
/* fallback to 0 which is the unconfigured default classid */
return (skcd->is_data & 1) ? skcd->classid : 0;
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3179,15 +3179,23 @@ static inline int __dev_xmit_skb(struct
#if IS_ENABLED(CONFIG_CGROUP_NET_PRIO)
static void skb_update_prio(struct sk_buff *skb)
{
- struct netprio_map *map = rcu_dereference_bh(skb->dev->priomap);
+ const struct netprio_map *map;
+ const struct sock *sk;
+ unsigned int prioidx;
- if (!skb->priority && skb->sk && map) {
- unsigned int prioidx =
- sock_cgroup_prioidx(&skb->sk->sk_cgrp_data);
+ if (skb->priority)
+ return;
+ map = rcu_dereference_bh(skb->dev->priomap);
+ if (!map)
+ return;
+ sk = skb_to_full_sk(skb);
+ if (!sk)
+ return;
- if (prioidx < map->priomap_len)
- skb->priority = map->priomap[prioidx];
- }
+ prioidx = sock_cgroup_prioidx(&sk->sk_cgrp_data);
+
+ if (prioidx < map->priomap_len)
+ skb->priority = map->priomap[prioidx];
}
#else
#define skb_update_prio(skb)
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.9/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.9/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.9/net-use-skb_to_full_sk-in-skb_update_prio.patch
queue-4.9/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
This is a note to let you know that I've just added the patch titled
net: systemport: Rewrite __bcm_sysport_tx_reclaim()
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-systemport-rewrite-__bcm_sysport_tx_reclaim.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 Wed Mar 28 20:16:33 CEST 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 13 Mar 2018 14:45:07 -0700
Subject: net: systemport: Rewrite __bcm_sysport_tx_reclaim()
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 484d802d0f2f29c335563fcac2a8facf174a1bbc ]
There is no need for complex checking between the last consumed index
and current consumed index, a simple subtraction will do.
This also eliminates the possibility of a permanent transmit queue stall
under the following conditions:
- one CPU bursts ring->size worth of traffic (up to 256 buffers), to the
point where we run out of free descriptors, so we stop the transmit
queue at the end of bcm_sysport_xmit()
- because of our locking, we have the transmit process disable
interrupts which means we can be blocking the TX reclamation process
- when TX reclamation finally runs, we will be computing the difference
between ring->c_index (last consumed index by SW) and what the HW
reports through its register
- this register is masked with (ring->size - 1) = 0xff, which will lead
to stripping the upper bits of the index (register is 16-bits wide)
- we will be computing last_tx_cn as 0, which means there is no work to
be done, and we never wake-up the transmit queue, leaving it
permanently disabled
A practical example is e.g: ring->c_index aka last_c_index = 12, we
pushed 256 entries, HW consumer index = 268, we mask it with 0xff = 12,
so last_tx_cn == 0, nothing happens.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-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/ethernet/broadcom/bcmsysport.c | 33 +++++++++++++----------------
drivers/net/ethernet/broadcom/bcmsysport.h | 2 -
2 files changed, 16 insertions(+), 19 deletions(-)
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -707,37 +707,33 @@ static unsigned int __bcm_sysport_tx_rec
struct bcm_sysport_tx_ring *ring)
{
struct net_device *ndev = priv->netdev;
- unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
unsigned int pkts_compl = 0, bytes_compl = 0;
+ unsigned int txbds_processed = 0;
struct bcm_sysport_cb *cb;
+ unsigned int txbds_ready;
+ unsigned int c_index;
u32 hw_ind;
/* Compute how many descriptors have been processed since last call */
hw_ind = tdma_readl(priv, TDMA_DESC_RING_PROD_CONS_INDEX(ring->index));
c_index = (hw_ind >> RING_CONS_INDEX_SHIFT) & RING_CONS_INDEX_MASK;
- ring->p_index = (hw_ind & RING_PROD_INDEX_MASK);
-
- last_c_index = ring->c_index;
- num_tx_cbs = ring->size;
-
- c_index &= (num_tx_cbs - 1);
-
- if (c_index >= last_c_index)
- last_tx_cn = c_index - last_c_index;
- else
- last_tx_cn = num_tx_cbs - last_c_index + c_index;
+ txbds_ready = (c_index - ring->c_index) & RING_CONS_INDEX_MASK;
netif_dbg(priv, tx_done, ndev,
- "ring=%d c_index=%d last_tx_cn=%d last_c_index=%d\n",
- ring->index, c_index, last_tx_cn, last_c_index);
+ "ring=%d old_c_index=%u c_index=%u txbds_ready=%u\n",
+ ring->index, ring->c_index, c_index, txbds_ready);
- while (last_tx_cn-- > 0) {
- cb = ring->cbs + last_c_index;
+ while (txbds_processed < txbds_ready) {
+ cb = &ring->cbs[ring->clean_index];
bcm_sysport_tx_reclaim_one(priv, cb, &bytes_compl, &pkts_compl);
ring->desc_count++;
- last_c_index++;
- last_c_index &= (num_tx_cbs - 1);
+ txbds_processed++;
+
+ if (likely(ring->clean_index < ring->size - 1))
+ ring->clean_index++;
+ else
+ ring->clean_index = 0;
}
ring->c_index = c_index;
@@ -1207,6 +1203,7 @@ static int bcm_sysport_init_tx_ring(stru
netif_tx_napi_add(priv->netdev, &ring->napi, bcm_sysport_tx_poll, 64);
ring->index = index;
ring->size = size;
+ ring->clean_index = 0;
ring->alloc_size = ring->size;
ring->desc_cpu = p;
ring->desc_count = ring->size;
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -638,7 +638,7 @@ struct bcm_sysport_tx_ring {
unsigned int desc_count; /* Number of descriptors */
unsigned int curr_desc; /* Current descriptor */
unsigned int c_index; /* Last consumer index */
- unsigned int p_index; /* Current producer index */
+ unsigned int clean_index; /* Current clean index */
struct bcm_sysport_cb *cbs; /* Transmit control blocks */
struct dma_desc *desc_cpu; /* CPU view of the descriptor */
struct bcm_sysport_priv *priv; /* private context backpointer */
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.9/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.9/net-fec-fix-unbalanced-pm-runtime-calls.patch
This is a note to let you know that I've just added the patch titled
net/iucv: Free memory obtained by kzalloc
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-iucv-free-memory-obtained-by-kzalloc.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 Wed Mar 28 20:16:33 CEST 2018
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Tue, 13 Mar 2018 16:50:06 +0100
Subject: net/iucv: Free memory obtained by kzalloc
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit fa6a91e9b907231d2e38ea5ed89c537b3525df3d ]
Free memory by calling put_device(), if afiucv_iucv_init is not
successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Ursula Braun <ursula.braun(a)de.ibm.com>
Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/iucv/af_iucv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -2418,9 +2418,11 @@ static int afiucv_iucv_init(void)
af_iucv_dev->driver = &af_iucv_driver;
err = device_register(af_iucv_dev);
if (err)
- goto out_driver;
+ goto out_iucv_dev;
return 0;
+out_iucv_dev:
+ put_device(af_iucv_dev);
out_driver:
driver_unregister(&af_iucv_driver);
out_iucv:
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/net-iucv-free-memory-obtained-by-kzalloc.patch
This is a note to let you know that I've just added the patch titled
net: Only honor ifindex in IP_PKTINFO if non-0
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-only-honor-ifindex-in-ip_pktinfo-if-non-0.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 Wed Mar 28 20:16:33 CEST 2018
From: David Ahern <dsahern(a)gmail.com>
Date: Fri, 16 Feb 2018 11:03:03 -0800
Subject: net: Only honor ifindex in IP_PKTINFO if non-0
From: David Ahern <dsahern(a)gmail.com>
[ Upstream commit 2cbb4ea7de167b02ffa63e9cdfdb07a7e7094615 ]
Only allow ifindex from IP_PKTINFO to override SO_BINDTODEVICE settings
if the index is actually set in the message.
Signed-off-by: David Ahern <dsahern(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -242,7 +242,8 @@ int ip_cmsg_send(struct sock *sk, struct
src_info = (struct in6_pktinfo *)CMSG_DATA(cmsg);
if (!ipv6_addr_v4mapped(&src_info->ipi6_addr))
return -EINVAL;
- ipc->oif = src_info->ipi6_ifindex;
+ if (src_info->ipi6_ifindex)
+ ipc->oif = src_info->ipi6_ifindex;
ipc->addr = src_info->ipi6_addr.s6_addr32[3];
continue;
}
@@ -272,7 +273,8 @@ int ip_cmsg_send(struct sock *sk, struct
if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct in_pktinfo)))
return -EINVAL;
info = (struct in_pktinfo *)CMSG_DATA(cmsg);
- ipc->oif = info->ipi_ifindex;
+ if (info->ipi_ifindex)
+ ipc->oif = info->ipi_ifindex;
ipc->addr = info->ipi_spec_dst.s_addr;
break;
}
Patches currently in stable-queue which might be from dsahern(a)gmail.com are
queue-4.9/net-only-honor-ifindex-in-ip_pktinfo-if-non-0.patch
This is a note to let you know that I've just added the patch titled
net: fec: Fix unbalanced PM runtime 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:
net-fec-fix-unbalanced-pm-runtime-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 foo@baz Wed Mar 28 20:16:33 CEST 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Sun, 18 Mar 2018 12:49:51 -0700
Subject: net: fec: Fix unbalanced PM runtime calls
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit a069215cf5985f3aa1bba550264907d6bd05c5f7 ]
When unbinding/removing the driver, we will run into the following warnings:
[ 259.655198] fec 400d1000.ethernet: 400d1000.ethernet supply phy not found, using dummy regulator
[ 259.665065] fec 400d1000.ethernet: Unbalanced pm_runtime_enable!
[ 259.672770] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
[ 259.683062] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: f2:3e:93:b7:29:c1
[ 259.696239] libphy: fec_enet_mii_bus: probed
Avoid these warnings by balancing the runtime PM calls during fec_drv_remove().
Signed-off-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/ethernet/freescale/fec_main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3533,6 +3533,8 @@ fec_drv_remove(struct platform_device *p
fec_enet_mii_remove(fep);
if (fep->reg_phy)
regulator_disable(fep->reg_phy);
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
if (of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
of_node_put(fep->phy_node);
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.9/net-systemport-rewrite-__bcm_sysport_tx_reclaim.patch
queue-4.9/net-fec-fix-unbalanced-pm-runtime-calls.patch
This is a note to let you know that I've just added the patch titled
net: Fix hlist corruptions in inet_evict_bucket()
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-fix-hlist-corruptions-in-inet_evict_bucket.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 Wed Mar 28 20:16:33 CEST 2018
From: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Date: Tue, 6 Mar 2018 18:46:39 +0300
Subject: net: Fix hlist corruptions in inet_evict_bucket()
From: Kirill Tkhai <ktkhai(a)virtuozzo.com>
[ Upstream commit a560002437d3646dafccecb1bf32d1685112ddda ]
inet_evict_bucket() iterates global list, and
several tasks may call it in parallel. All of
them hash the same fq->list_evictor to different
lists, which leads to list corruption.
This patch makes fq be hashed to expired list
only if this has not been made yet by another
task. Since inet_frag_alloc() allocates fq
using kmem_cache_zalloc(), we may rely on
list_evictor is initially unhashed.
The problem seems to exist before async
pernet_operations, as there was possible to have
exit method to be executed in parallel with
inet_frags::frags_work, so I add two Fixes tags.
This also may go to stable.
Fixes: d1fe19444d82 "inet: frag: don't re-use chainlist for evictor"
Fixes: f84c6821aa54 "net: Convert pernet_subsys, registered from inet_init()"
Signed-off-by: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/inet_fragment.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -119,6 +119,9 @@ out:
static bool inet_fragq_should_evict(const struct inet_frag_queue *q)
{
+ if (!hlist_unhashed(&q->list_evictor))
+ return false;
+
return q->net->low_thresh == 0 ||
frag_mem_limit(q->net) >= q->net->low_thresh;
}
Patches currently in stable-queue which might be from ktkhai(a)virtuozzo.com are
queue-4.9/net-fix-hlist-corruptions-in-inet_evict_bucket.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
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-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.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 Wed Mar 28 20:16:33 CEST 2018
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
Date: Fri, 16 Mar 2018 00:56:01 +0800
Subject: net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
[ Upstream commit f9db50691db4a7d860fce985f080bb3fc23a7ede ]
According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
available when PHY is configured in RGMII mode with 10Mbps speed. It will
cause some networking issues without RGMII mode, such as carrier sense
errors and low throughput. TI also mentioned this issue in their forum[4].
This patch adds the check mechanism for PHY interface with RGMII interface
type, the in-band mode can only be set in RGMII mode with 10Mbps speed.
References:
[1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
[2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
[3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf
[4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155
Suggested-by: Holsety Chen (陳憲輝) <Holsety.Chen(a)moxa.com>
Signed-off-by: SZ Lin (林上智) <sz.lin(a)moxa.com>
Signed-off-by: Schuyler Patton <spatton(a)ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko(a)ti.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/ti/cpsw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -901,7 +901,8 @@ static void _cpsw_adjust_link(struct cps
/* set speed_in input in case RMII mode is used in 100Mbps */
if (phy->speed == 100)
mac_control |= BIT(15);
- else if (phy->speed == 10)
+ /* in band mode only works in 10Mbps RGMII mode */
+ else if ((phy->speed == 10) && phy_interface_is_rgmii(phy))
mac_control |= BIT(18); /* In Band mode */
if (priv->rx_pause)
Patches currently in stable-queue which might be from sz.lin(a)moxa.com are
queue-4.9/net-ethernet-ti-cpsw-add-check-for-in-band-mode-setting-with-rgmii-phy-interface.patch
This is a note to let you know that I've just added the patch titled
l2tp: do not accept arbitrary sockets
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:
l2tp-do-not-accept-arbitrary-sockets.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 Wed Mar 28 20:16:33 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Tue, 6 Mar 2018 07:54:53 -0800
Subject: l2tp: do not accept arbitrary sockets
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 17cfe79a65f98abe535261856c5aef14f306dff7 ]
syzkaller found an issue caused by lack of sufficient checks
in l2tp_tunnel_create()
RAW sockets can not be considered as UDP ones for instance.
In another patch, we shall replace all pr_err() by less intrusive
pr_debug() so that syzkaller can find other bugs faster.
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Acked-by: James Chapman <jchapman(a)katalix.com>
==================================================================
BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
dst_release: dst:00000000d53d0d0f refcnt:-1
Write of size 1 at addr ffff8801d013b798 by task syz-executor3/6242
CPU: 1 PID: 6242 Comm: syz-executor3 Not tainted 4.16.0-rc2+ #253
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23b/0x360 mm/kasan/report.c:412
__asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
l2tp_tunnel_create+0x1354/0x17f0 net/l2tp/l2tp_core.c:1596
pppol2tp_connect+0x14b1/0x1dd0 net/l2tp/l2tp_ppp.c:707
SYSC_connect+0x213/0x4a0 net/socket.c:1640
SyS_connect+0x24/0x30 net/socket.c:1621
do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1612,9 +1612,14 @@ int l2tp_tunnel_create(struct net *net,
encap = cfg->encap;
/* Quick sanity checks */
+ err = -EPROTONOSUPPORT;
+ if (sk->sk_type != SOCK_DGRAM) {
+ pr_debug("tunl %hu: fd %d wrong socket type\n",
+ tunnel_id, fd);
+ goto err;
+ }
switch (encap) {
case L2TP_ENCAPTYPE_UDP:
- err = -EPROTONOSUPPORT;
if (sk->sk_protocol != IPPROTO_UDP) {
pr_err("tunl %hu: fd %d wrong protocol, got %d, expected %d\n",
tunnel_id, fd, sk->sk_protocol, IPPROTO_UDP);
@@ -1622,7 +1627,6 @@ int l2tp_tunnel_create(struct net *net,
}
break;
case L2TP_ENCAPTYPE_IP:
- err = -EPROTONOSUPPORT;
if (sk->sk_protocol != IPPROTO_L2TP) {
pr_err("tunl %hu: fd %d wrong protocol, got %d, expected %d\n",
tunnel_id, fd, sk->sk_protocol, IPPROTO_L2TP);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.9/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.9/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.9/net-use-skb_to_full_sk-in-skb_update_prio.patch
queue-4.9/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
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-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.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 Wed Mar 28 20:16:33 CEST 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 18 Mar 2018 23:59:36 +0100
Subject: net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 00777fac28ba3e126b9e63e789a613e8bd2cab25 ]
If the optional regulator is deferred, we must release some resources.
They will be re-allocated when the probe function will be called again.
Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_rockchip.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -169,8 +169,10 @@ static int emac_rockchip_probe(struct pl
/* Optional regulator for PHY */
priv->regulator = devm_regulator_get_optional(dev, "phy");
if (IS_ERR(priv->regulator)) {
- if (PTR_ERR(priv->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(priv->regulator) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto out_clk_disable;
+ }
dev_err(dev, "no regulator found\n");
priv->regulator = NULL;
}
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.9/net-ethernet-arc-fix-a-potential-memory-leak-if-an-optional-regulator-is-deferred.patch
This is a note to let you know that I've just added the patch titled
kcm: lock lower socket in kcm_attach
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:
kcm-lock-lower-socket-in-kcm_attach.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 Wed Mar 28 20:16:33 CEST 2018
From: Tom Herbert <tom(a)quantonium.net>
Date: Tue, 13 Mar 2018 12:01:43 -0700
Subject: kcm: lock lower socket in kcm_attach
From: Tom Herbert <tom(a)quantonium.net>
[ Upstream commit 2cc683e88c0c993ac3721d9b702cb0630abe2879 ]
Need to lock lower socket in order to provide mutual exclusion
with kcm_unattach.
v2: Add Reported-by for syzbot
Fixes: ab7ac4eb9832e32a09f4e804 ("kcm: Kernel Connection Multiplexor module")
Reported-by: syzbot+ea75c0ffcd353d32515f064aaebefc5279e6161e(a)syzkaller.appspotmail.com
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1375,24 +1375,32 @@ static int kcm_attach(struct socket *soc
struct list_head *head;
int index = 0;
struct strp_callbacks cb;
- int err;
+ int err = 0;
csk = csock->sk;
if (!csk)
return -EINVAL;
+ lock_sock(csk);
+
/* Only allow TCP sockets to be attached for now */
if ((csk->sk_family != AF_INET && csk->sk_family != AF_INET6) ||
- csk->sk_protocol != IPPROTO_TCP)
- return -EOPNOTSUPP;
+ csk->sk_protocol != IPPROTO_TCP) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
/* Don't allow listeners or closed sockets */
- if (csk->sk_state == TCP_LISTEN || csk->sk_state == TCP_CLOSE)
- return -EOPNOTSUPP;
+ if (csk->sk_state == TCP_LISTEN || csk->sk_state == TCP_CLOSE) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
psock = kmem_cache_zalloc(kcm_psockp, GFP_KERNEL);
- if (!psock)
- return -ENOMEM;
+ if (!psock) {
+ err = -ENOMEM;
+ goto out;
+ }
psock->mux = mux;
psock->sk = csk;
@@ -1406,7 +1414,7 @@ static int kcm_attach(struct socket *soc
err = strp_init(&psock->strp, csk, &cb);
if (err) {
kmem_cache_free(kcm_psockp, psock);
- return err;
+ goto out;
}
write_lock_bh(&csk->sk_callback_lock);
@@ -1418,7 +1426,8 @@ static int kcm_attach(struct socket *soc
write_unlock_bh(&csk->sk_callback_lock);
strp_done(&psock->strp);
kmem_cache_free(kcm_psockp, psock);
- return -EALREADY;
+ err = -EALREADY;
+ goto out;
}
psock->save_data_ready = csk->sk_data_ready;
@@ -1454,7 +1463,10 @@ static int kcm_attach(struct socket *soc
/* Schedule RX work in case there are already bytes queued */
strp_check_rcv(&psock->strp);
- return 0;
+out:
+ release_sock(csk);
+
+ return err;
}
static int kcm_attach_ioctl(struct socket *sock, struct kcm_attach *info)
@@ -1506,6 +1518,7 @@ static void kcm_unattach(struct kcm_psoc
if (WARN_ON(psock->rx_kcm)) {
write_unlock_bh(&csk->sk_callback_lock);
+ release_sock(csk);
return;
}
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.9/kcm-lock-lower-socket-in-kcm_attach.patch
This is a note to let you know that I've just added the patch titled
ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
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-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.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 Wed Mar 28 20:16:33 CEST 2018
From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Date: Thu, 8 Mar 2018 17:00:02 +0100
Subject: ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
[ Upstream commit 9f62c15f28b0d1d746734666d88a79f08ba1e43e ]
Fix the following slab-out-of-bounds kasan report in
ndisc_fill_redirect_hdr_option when the incoming ipv6 packet is not
linear and the accessed data are not in the linear data region of orig_skb.
[ 1503.122508] ==================================================================
[ 1503.122832] BUG: KASAN: slab-out-of-bounds in ndisc_send_redirect+0x94e/0x990
[ 1503.123036] Read of size 1184 at addr ffff8800298ab6b0 by task netperf/1932
[ 1503.123220] CPU: 0 PID: 1932 Comm: netperf Not tainted 4.16.0-rc2+ #124
[ 1503.123347] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
[ 1503.123527] Call Trace:
[ 1503.123579] <IRQ>
[ 1503.123638] print_address_description+0x6e/0x280
[ 1503.123849] kasan_report+0x233/0x350
[ 1503.123946] memcpy+0x1f/0x50
[ 1503.124037] ndisc_send_redirect+0x94e/0x990
[ 1503.125150] ip6_forward+0x1242/0x13b0
[...]
[ 1503.153890] Allocated by task 1932:
[ 1503.153982] kasan_kmalloc+0x9f/0xd0
[ 1503.154074] __kmalloc_track_caller+0xb5/0x160
[ 1503.154198] __kmalloc_reserve.isra.41+0x24/0x70
[ 1503.154324] __alloc_skb+0x130/0x3e0
[ 1503.154415] sctp_packet_transmit+0x21a/0x1810
[ 1503.154533] sctp_outq_flush+0xc14/0x1db0
[ 1503.154624] sctp_do_sm+0x34e/0x2740
[ 1503.154715] sctp_primitive_SEND+0x57/0x70
[ 1503.154807] sctp_sendmsg+0xaa6/0x1b10
[ 1503.154897] sock_sendmsg+0x68/0x80
[ 1503.154987] ___sys_sendmsg+0x431/0x4b0
[ 1503.155078] __sys_sendmsg+0xa4/0x130
[ 1503.155168] do_syscall_64+0x171/0x3f0
[ 1503.155259] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 1503.155436] Freed by task 1932:
[ 1503.155527] __kasan_slab_free+0x134/0x180
[ 1503.155618] kfree+0xbc/0x180
[ 1503.155709] skb_release_data+0x27f/0x2c0
[ 1503.155800] consume_skb+0x94/0xe0
[ 1503.155889] sctp_chunk_put+0x1aa/0x1f0
[ 1503.155979] sctp_inq_pop+0x2f8/0x6e0
[ 1503.156070] sctp_assoc_bh_rcv+0x6a/0x230
[ 1503.156164] sctp_inq_push+0x117/0x150
[ 1503.156255] sctp_backlog_rcv+0xdf/0x4a0
[ 1503.156346] __release_sock+0x142/0x250
[ 1503.156436] release_sock+0x80/0x180
[ 1503.156526] sctp_sendmsg+0xbb0/0x1b10
[ 1503.156617] sock_sendmsg+0x68/0x80
[ 1503.156708] ___sys_sendmsg+0x431/0x4b0
[ 1503.156799] __sys_sendmsg+0xa4/0x130
[ 1503.156889] do_syscall_64+0x171/0x3f0
[ 1503.156980] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 1503.157158] The buggy address belongs to the object at ffff8800298ab600
which belongs to the cache kmalloc-1024 of size 1024
[ 1503.157444] The buggy address is located 176 bytes inside of
1024-byte region [ffff8800298ab600, ffff8800298aba00)
[ 1503.157702] The buggy address belongs to the page:
[ 1503.157820] page:ffffea0000a62a00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
[ 1503.158053] flags: 0x4000000000008100(slab|head)
[ 1503.158171] raw: 4000000000008100 0000000000000000 0000000000000000 00000001800e000e
[ 1503.158350] raw: dead000000000100 dead000000000200 ffff880036002600 0000000000000000
[ 1503.158523] page dumped because: kasan: bad access detected
[ 1503.158698] Memory state around the buggy address:
[ 1503.158816] ffff8800298ab900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1503.158988] ffff8800298ab980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1503.159165] >ffff8800298aba00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 1503.159338] ^
[ 1503.159436] ffff8800298aba80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1503.159610] ffff8800298abb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 1503.159785] ==================================================================
[ 1503.159964] Disabling lock debugging due to kernel taint
The test scenario to trigger the issue consists of 4 devices:
- H0: data sender, connected to LAN0
- H1: data receiver, connected to LAN1
- GW0 and GW1: routers between LAN0 and LAN1. Both of them have an
ethernet connection on LAN0 and LAN1
On H{0,1} set GW0 as default gateway while on GW0 set GW1 as next hop for
data from LAN0 to LAN1.
Moreover create an ip6ip6 tunnel between H0 and H1 and send 3 concurrent
data streams (TCP/UDP/SCTP) from H0 to H1 through ip6ip6 tunnel (send
buffer size is set to 16K). While data streams are active flush the route
cache on HA multiple times.
I have not been able to identify a given commit that introduced the issue
since, using the reproducer described above, the kasan report has been
triggered from 4.14 and I have not gone back further.
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ndisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1516,7 +1516,8 @@ static void ndisc_fill_redirect_hdr_opti
*(opt++) = (rd_len >> 3);
opt += 6;
- memcpy(opt, ipv6_hdr(orig_skb), rd_len - 8);
+ skb_copy_bits(orig_skb, skb_network_offset(orig_skb), opt,
+ rd_len - 8);
}
void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
Patches currently in stable-queue which might be from lorenzo.bianconi(a)redhat.com are
queue-4.9/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
This is a note to let you know that I've just added the patch titled
genirq: Track whether the trigger type has been set
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:
genirq-track-whether-the-trigger-type-has-been-set.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 4f8413a3a799c958f7a10a6310a451e6b8aef5ad Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 9 Nov 2017 14:17:59 +0000
Subject: genirq: Track whether the trigger type has been set
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 4f8413a3a799c958f7a10a6310a451e6b8aef5ad upstream.
When requesting a shared interrupt, we assume that the firmware
support code (DT or ACPI) has called irqd_set_trigger_type
already, so that we can retrieve it and check that the requester
is being reasonnable.
Unfortunately, we still have non-DT, non-ACPI systems around,
and these guys won't call irqd_set_trigger_type before requesting
the interrupt. The consequence is that we fail the request that
would have worked before.
We can either chase all these use cases (boring), or address it
in core code (easier). Let's have a per-irq_desc flag that
indicates whether irqd_set_trigger_type has been called, and
let's just check it when checking for a shared interrupt.
If it hasn't been set, just take whatever the interrupt
requester asks.
Fixes: 382bd4de6182 ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs")
Cc: stable(a)vger.kernel.org
Reported-and-tested-by: Petr Cvek <petrcvekcz(a)gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/irq.h | 11 ++++++++++-
kernel/irq/manage.c | 13 ++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -199,6 +199,7 @@ struct irq_data {
* IRQD_WAKEUP_ARMED - Wakeup mode armed
* IRQD_FORWARDED_TO_VCPU - The interrupt is forwarded to a VCPU
* IRQD_AFFINITY_MANAGED - Affinity is auto-managed by the kernel
+ * IRQD_DEFAULT_TRIGGER_SET - Expected trigger already been set
*/
enum {
IRQD_TRIGGER_MASK = 0xf,
@@ -216,6 +217,7 @@ enum {
IRQD_WAKEUP_ARMED = (1 << 19),
IRQD_FORWARDED_TO_VCPU = (1 << 20),
IRQD_AFFINITY_MANAGED = (1 << 21),
+ IRQD_DEFAULT_TRIGGER_SET = (1 << 25),
};
#define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -245,18 +247,25 @@ static inline void irqd_mark_affinity_wa
__irqd_to_state(d) |= IRQD_AFFINITY_SET;
}
+static inline bool irqd_trigger_type_was_set(struct irq_data *d)
+{
+ return __irqd_to_state(d) & IRQD_DEFAULT_TRIGGER_SET;
+}
+
static inline u32 irqd_get_trigger_type(struct irq_data *d)
{
return __irqd_to_state(d) & IRQD_TRIGGER_MASK;
}
/*
- * Must only be called inside irq_chip.irq_set_type() functions.
+ * Must only be called inside irq_chip.irq_set_type() functions or
+ * from the DT/ACPI setup code.
*/
static inline void irqd_set_trigger_type(struct irq_data *d, u32 type)
{
__irqd_to_state(d) &= ~IRQD_TRIGGER_MASK;
__irqd_to_state(d) |= type & IRQD_TRIGGER_MASK;
+ __irqd_to_state(d) |= IRQD_DEFAULT_TRIGGER_SET;
}
static inline bool irqd_is_level_type(struct irq_data *d)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1210,7 +1210,18 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
+ unsigned int oldtype;
+
+ /*
+ * If nobody did set the configuration before, inherit
+ * the one provided by the requester.
+ */
+ if (irqd_trigger_type_was_set(&desc->irq_data)) {
+ oldtype = irqd_get_trigger_type(&desc->irq_data);
+ } else {
+ oldtype = new->flags & IRQF_TRIGGER_MASK;
+ irqd_set_trigger_type(&desc->irq_data, oldtype);
+ }
if (!((old->flags & new->flags) & IRQF_SHARED) ||
(oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.9/genirq-track-whether-the-trigger-type-has-been-set.patch
This is a note to let you know that I've just added the patch titled
ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
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:
ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.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 Wed Mar 28 20:16:33 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Mon, 5 Mar 2018 08:51:03 -0800
Subject: ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit ca0edb131bdf1e6beaeb2b8289fd6b374b74147d ]
A tun device type can trivially be set to arbitrary value using
TUNSETLINK ioctl().
Therefore, lowpan_device_event() must really check that ieee802154_ptr
is not NULL.
Fixes: 2c88b5283f60d ("ieee802154: 6lowpan: remove check on null")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: Alexander Aring <alex.aring(a)gmail.com>
Cc: Stefan Schmidt <stefan(a)osg.samsung.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Stefan Schmidt <stefan(a)osg.samsung.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ieee802154/6lowpan/core.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -204,9 +204,13 @@ static inline void lowpan_netlink_fini(v
static int lowpan_device_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
- struct net_device *wdev = netdev_notifier_info_to_dev(ptr);
+ struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
+ struct wpan_dev *wpan_dev;
- if (wdev->type != ARPHRD_IEEE802154)
+ if (ndev->type != ARPHRD_IEEE802154)
+ return NOTIFY_DONE;
+ wpan_dev = ndev->ieee802154_ptr;
+ if (!wpan_dev)
return NOTIFY_DONE;
switch (event) {
@@ -215,8 +219,8 @@ static int lowpan_device_event(struct no
* also delete possible lowpan interfaces which belongs
* to the wpan interface.
*/
- if (wdev->ieee802154_ptr->lowpan_dev)
- lowpan_dellink(wdev->ieee802154_ptr->lowpan_dev, NULL);
+ if (wpan_dev->lowpan_dev)
+ lowpan_dellink(wpan_dev->lowpan_dev, NULL);
break;
default:
return NOTIFY_DONE;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch
queue-4.9/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch
queue-4.9/l2tp-do-not-accept-arbitrary-sockets.patch
queue-4.9/net-use-skb_to_full_sk-in-skb_update_prio.patch
queue-4.9/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch
This is a note to let you know that I've just added the patch titled
dccp: check sk for closed state in dccp_sendmsg()
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:
dccp-check-sk-for-closed-state-in-dccp_sendmsg.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 Wed Mar 28 20:16:33 CEST 2018
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Date: Tue, 6 Mar 2018 22:57:01 +0300
Subject: dccp: check sk for closed state in dccp_sendmsg()
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
[ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ]
dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL,
therefore if DCCP socket is disconnected and dccp_sendmsg() is
called after it, it will cause a NULL pointer dereference in
dccp_write_xmit().
This crash and the reproducer was reported by syzbot. Looks like
it is reproduced if commit 69c64866ce07 ("dccp: CVE-2017-8824:
use-after-free in DCCP code") is applied.
Reported-by: syzbot+f99ab3887ab65d70f816(a)syzkaller.appspotmail.com
Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/dccp/proto.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -789,6 +789,11 @@ int dccp_sendmsg(struct sock *sk, struct
if (skb == NULL)
goto out_release;
+ if (sk->sk_state == DCCP_CLOSED) {
+ rc = -ENOTCONN;
+ goto out_discard;
+ }
+
skb_reserve(skb, sk->sk_prot->max_header);
rc = memcpy_from_msg(skb_put(skb, len), msg, len);
if (rc != 0)
Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are
queue-4.9/sch_netem-fix-skb-leak-in-netem_enqueue.patch
queue-4.9/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: don't return bogus Sg_requests
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:
scsi-sg-don-t-return-bogus-sg_requests.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 48ae8484e9fc324b4968d33c585e54bc98e44d61 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Wed, 10 May 2017 09:53:40 +0200
Subject: scsi: sg: don't return bogus Sg_requests
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 48ae8484e9fc324b4968d33c585e54bc98e44d61 upstream.
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in
sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case
the list search doesn't find a valid request.
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Gilbert <dgilbert(a)interlog.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.de>
Acked-by: Doug Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Tony Battersby <tonyb(a)cybernetics.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -2121,11 +2121,12 @@ sg_get_rq_mark(Sg_fd * sfp, int pack_id)
if ((1 == resp->done) && (!resp->sg_io_owned) &&
((-1 == pack_id) || (resp->header.pack_id == pack_id))) {
resp->done = 2; /* guard against other readers */
- break;
+ write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
+ return resp;
}
}
write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
- return resp;
+ return NULL;
}
/* always adds to end of list */
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-3.18/scsi-sg-don-t-return-bogus-sg_requests.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: don't return bogus Sg_requests
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:
scsi-sg-don-t-return-bogus-sg_requests.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 48ae8484e9fc324b4968d33c585e54bc98e44d61 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Wed, 10 May 2017 09:53:40 +0200
Subject: scsi: sg: don't return bogus Sg_requests
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 48ae8484e9fc324b4968d33c585e54bc98e44d61 upstream.
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in
sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case
the list search doesn't find a valid request.
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Gilbert <dgilbert(a)interlog.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.de>
Acked-by: Doug Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Tony Battersby <tonyb(a)cybernetics.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -2074,11 +2074,12 @@ sg_get_rq_mark(Sg_fd * sfp, int pack_id)
if ((1 == resp->done) && (!resp->sg_io_owned) &&
((-1 == pack_id) || (resp->header.pack_id == pack_id))) {
resp->done = 2; /* guard against other readers */
- break;
+ write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
+ return resp;
}
}
write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
- return resp;
+ return NULL;
}
/* always adds to end of list */
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.4/scsi-sg-don-t-return-bogus-sg_requests.patch
This is a note to let you know that I've just added the patch titled
genirq: Track whether the trigger type has been set
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:
genirq-track-whether-the-trigger-type-has-been-set.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 4f8413a3a799c958f7a10a6310a451e6b8aef5ad Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 9 Nov 2017 14:17:59 +0000
Subject: genirq: Track whether the trigger type has been set
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 4f8413a3a799c958f7a10a6310a451e6b8aef5ad upstream.
When requesting a shared interrupt, we assume that the firmware
support code (DT or ACPI) has called irqd_set_trigger_type
already, so that we can retrieve it and check that the requester
is being reasonnable.
Unfortunately, we still have non-DT, non-ACPI systems around,
and these guys won't call irqd_set_trigger_type before requesting
the interrupt. The consequence is that we fail the request that
would have worked before.
We can either chase all these use cases (boring), or address it
in core code (easier). Let's have a per-irq_desc flag that
indicates whether irqd_set_trigger_type has been called, and
let's just check it when checking for a shared interrupt.
If it hasn't been set, just take whatever the interrupt
requester asks.
Fixes: 382bd4de6182 ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs")
Cc: stable(a)vger.kernel.org
Reported-and-tested-by: Petr Cvek <petrcvekcz(a)gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/irq.h | 11 ++++++++++-
kernel/irq/manage.c | 13 ++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -191,6 +191,7 @@ struct irq_data {
* IRQD_IRQ_INPROGRESS - In progress state of the interrupt
* IRQD_WAKEUP_ARMED - Wakeup mode armed
* IRQD_FORWARDED_TO_VCPU - The interrupt is forwarded to a VCPU
+ * IRQD_DEFAULT_TRIGGER_SET - Expected trigger already been set
*/
enum {
IRQD_TRIGGER_MASK = 0xf,
@@ -206,6 +207,7 @@ enum {
IRQD_IRQ_INPROGRESS = (1 << 18),
IRQD_WAKEUP_ARMED = (1 << 19),
IRQD_FORWARDED_TO_VCPU = (1 << 20),
+ IRQD_DEFAULT_TRIGGER_SET = (1 << 25),
};
#define __irqd_to_state(d) ((d)->common->state_use_accessors)
@@ -235,18 +237,25 @@ static inline void irqd_mark_affinity_wa
__irqd_to_state(d) |= IRQD_AFFINITY_SET;
}
+static inline bool irqd_trigger_type_was_set(struct irq_data *d)
+{
+ return __irqd_to_state(d) & IRQD_DEFAULT_TRIGGER_SET;
+}
+
static inline u32 irqd_get_trigger_type(struct irq_data *d)
{
return __irqd_to_state(d) & IRQD_TRIGGER_MASK;
}
/*
- * Must only be called inside irq_chip.irq_set_type() functions.
+ * Must only be called inside irq_chip.irq_set_type() functions or
+ * from the DT/ACPI setup code.
*/
static inline void irqd_set_trigger_type(struct irq_data *d, u32 type)
{
__irqd_to_state(d) &= ~IRQD_TRIGGER_MASK;
__irqd_to_state(d) |= type & IRQD_TRIGGER_MASK;
+ __irqd_to_state(d) |= IRQD_DEFAULT_TRIGGER_SET;
}
static inline bool irqd_is_level_type(struct irq_data *d)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1189,7 +1189,18 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
+ unsigned int oldtype;
+
+ /*
+ * If nobody did set the configuration before, inherit
+ * the one provided by the requester.
+ */
+ if (irqd_trigger_type_was_set(&desc->irq_data)) {
+ oldtype = irqd_get_trigger_type(&desc->irq_data);
+ } else {
+ oldtype = new->flags & IRQF_TRIGGER_MASK;
+ irqd_set_trigger_type(&desc->irq_data, oldtype);
+ }
if (!((old->flags & new->flags) & IRQF_SHARED) ||
(oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.4/genirq-track-whether-the-trigger-type-has-been-set.patch
The SCSI generic driver is currently broken in the 3.18, 4.1, 4.4, and
4.9 stable kernels. This is the problematic commit:
109bade9c625 ("scsi: sg: use standard lists for sg_requests")
(all commit ids are from upstream git, not stable.git)
There have already been a number of fixes backported to -stable to fix
problems introduced by that commit:
bd46fc406b30 ("scsi: sg: off by one in sg_ioctl()")
4759df905a47 ("scsi: sg: factor out sg_fill_request_table()")
3e0097499839 ("scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE")
587c3c9f286c ("scsi: sg: Re-fix off by one in sg_fill_request_table()")
I am not sure why 109bade9c625 was added to -stable to begin with. My
guess is that the "infoleak" fix was flagged as being appropriate for
-stable, and it depended on the original commit 109bade9c625. But if
you take a close look, the original commit 109bade9c625 is what
introduced the infoleak in the first place. Or maybe there was some
other reason. But I digress.
There is one more fix for 109bade9c625 that has not yet been backported:
48ae8484e9fc ("scsi: sg: don't return bogus Sg_requests")
Without the fix above, sg oopses as soon as I try to use it. So please
add 48ae8484e9fc to -stable.
The following -stable kernels already have 48ae8484e9fc:
4.14.31
4.15.14
The following -stable kernels need 48ae8484e9fc:
3.18.102
4.1.51
4.4.125
4.9.91
The following -stable kernels are not affected because they have not had
the problematic commit backported:
3.2.101
3.16.56
Related bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=198081
Thanks!
Tony Battersby
Cybernetics
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: ipc/shm.c: add split function to shm_vm_ops
If System V shmget/shmat operations are used to create a hugetlbfs backed
mapping, it is possible to munmap part of the mapping and split the
underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
8<--8<--8<--8< snip 8<--8<--8<--8<
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E
4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E
(4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER:
20040000
CFAR: c00000000036ee44 SOFTE: 1
GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40
GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000
GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000
GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554
GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40
GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950
NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760
LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50
Call Trace:
[c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable)
[c000003fbcdcfb50] [c00000000036ee48]
__unmap_hugepage_range_final+0x28/0x50
[c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190
[c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140
[c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0
[c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0
[c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80
[c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100
[c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30
[c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c
Instruction dump:
552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010
7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by 31383c6865a5 ("mm, hugetlbfs: introduce
->split() to vm_operations_struct"). A split function was added to
vm_operations_struct to determine if a mapping can be split. This was
mostly for device-dax and hugetlbfs mappings which have specific alignment
constraints.
Mappings initiated via shmget/shmat have their original vm_ops overwritten
with shm_vm_ops. shm_vm_ops functions will call back to the original
vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff -puN ipc/shm.c~shm-add-split-function-to-shm_vm_ops ipc/shm.c
--- a/ipc/shm.c~shm-add-split-function-to-shm_vm_ops
+++ a/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vm
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
_
The patch titled
Subject: zboot: fix stack protector in compressed boot phase
has been added to the -mm tree. Its filename is
zboot-fix-stack-protector-in-compressed-boot-phase.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zboot-fix-stack-protector-in-compr…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zboot-fix-stack-protector-in-compr…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huacai Chen <chenhc(a)lemote.com>
Subject: zboot: fix stack protector in compressed boot phase
Call __stack_chk_guard_setup() in decompress_kernel() is too late that
stack checking always fails for decompress_kernel() itself. So remove
__stack_chk_guard_setup() and initialize __stack_chk_guard before we call
decompress_kernel().
Original code comes from ARM but also used for MIPS and SH, so fix them
together. If without this fix, compressed booting of these archs will
fail because stack checking is enabled by default (>=4.16).
Link: http://lkml.kernel.org/r/1522226933-29317-1-git-send-email-chenhc@lemote.com
Fixes: 8779657d29c0 ("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG")
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
Acked-by: James Hogan <jhogan(a)kernel.org>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Rich Felker <dalias(a)libc.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Russell King <linux(a)arm.linux.org.uk>
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Ingo Molnar <mingo(a)elte.hu>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/arm/boot/compressed/misc.c | 9 +--------
arch/mips/boot/compressed/decompress.c | 9 +--------
arch/sh/boot/compressed/misc.c | 9 +--------
3 files changed, 3 insertions(+), 24 deletions(-)
diff -puN arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/arm/boot/compressed/misc.c
--- a/arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase
+++ a/arch/arm/boot/compressed/misc.c
@@ -128,12 +128,7 @@ asmlinkage void __div0(void)
error("Attempting division by 0!");
}
-unsigned long __stack_chk_guard;
-
-void __stack_chk_guard_setup(void)
-{
- __stack_chk_guard = 0x000a0dff;
-}
+const unsigned long __stack_chk_guard = 0x000a0dff;
void __stack_chk_fail(void)
{
@@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_s
{
int ret;
- __stack_chk_guard_setup();
-
output_data = (unsigned char *)output_start;
free_mem_ptr = free_mem_ptr_p;
free_mem_end_ptr = free_mem_ptr_end_p;
diff -puN arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/mips/boot/compressed/decompress.c
--- a/arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase
+++ a/arch/mips/boot/compressed/decompress.c
@@ -76,12 +76,7 @@ void error(char *x)
#include "../../../../lib/decompress_unxz.c"
#endif
-unsigned long __stack_chk_guard;
-
-void __stack_chk_guard_setup(void)
-{
- __stack_chk_guard = 0x000a0dff;
-}
+const unsigned long __stack_chk_guard = 0x000a0dff;
void __stack_chk_fail(void)
{
@@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boo
{
unsigned long zimage_start, zimage_size;
- __stack_chk_guard_setup();
-
zimage_start = (unsigned long)(&__image_begin);
zimage_size = (unsigned long)(&__image_end) -
(unsigned long)(&__image_begin);
diff -puN arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/sh/boot/compressed/misc.c
--- a/arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase
+++ a/arch/sh/boot/compressed/misc.c
@@ -104,12 +104,7 @@ static void error(char *x)
while(1); /* Halt */
}
-unsigned long __stack_chk_guard;
-
-void __stack_chk_guard_setup(void)
-{
- __stack_chk_guard = 0x000a0dff;
-}
+const unsigned long __stack_chk_guard = 0x000a0dff;
void __stack_chk_fail(void)
{
@@ -130,8 +125,6 @@ void decompress_kernel(void)
{
unsigned long output_addr;
- __stack_chk_guard_setup();
-
#ifdef CONFIG_SUPERH64
output_addr = (CONFIG_MEMORY_START + 0x2000);
#else
_
Patches currently in -mm which might be from chenhc(a)lemote.com are
zboot-fix-stack-protector-in-compressed-boot-phase.patch