* Patch "of: fix sparse warning in of_pci_range_parser_one" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 17:05 UTC (permalink / raw)
To: robh, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
of: fix sparse warning in of_pci_range_parser_one
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=summary
The filename of the patch is:
of-fix-sparse-warning-in-of_pci_range_parser_one.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@vger.kernel.org> know about it.
>From eb3100365791b06242b8bb5c3c2854ba41dabfbc Mon Sep 17 00:00:00 2001
From: Rob Herring <robh@kernel.org>
Date: Thu, 4 May 2017 12:34:30 -0500
Subject: of: fix sparse warning in of_pci_range_parser_one
From: Rob Herring <robh@kernel.org>
commit eb3100365791b06242b8bb5c3c2854ba41dabfbc upstream.
sparse gives the following warning for 'pci_space':
../drivers/of/address.c:266:26: warning: incorrect type in assignment (different base types)
../drivers/of/address.c:266:26: expected unsigned int [unsigned] [usertype] pci_space
../drivers/of/address.c:266:26: got restricted __be32 const [usertype] <noident>
It appears that pci_space is only ever accessed on powerpc, so the endian
swap is often not needed.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/of/address.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -263,7 +263,7 @@ struct of_pci_range *of_pci_range_parser
if (!parser->range || parser->range + parser->np > parser->end)
return NULL;
- range->pci_space = parser->range[0];
+ range->pci_space = be32_to_cpup(parser->range);
range->flags = of_bus_pci_get_flags(parser->range);
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
Patches currently in stable-queue which might be from robh@kernel.org are
queue-4.9/of-fix-sparse-warning-in-of_pci_range_parser_one.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/of-fix-cpus-reference-leak-in-of_numa_parse_cpu_nodes.patch
^ permalink raw reply
* Patch "ohci-pci: add qemu quirk" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 17:05 UTC (permalink / raw)
To: kraxel, gregkh, stern; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ohci-pci: add qemu quirk
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=summary
The filename of the patch is:
ohci-pci-add-qemu-quirk.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@vger.kernel.org> know about it.
>From 21a60f6e65181cad64fd66ccc8080d413721ba27 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 20 Mar 2017 09:11:49 +0100
Subject: ohci-pci: add qemu quirk
From: Gerd Hoffmann <kraxel@redhat.com>
commit 21a60f6e65181cad64fd66ccc8080d413721ba27 upstream.
On a loaded virtualization host (dozen guests booting at the same time)
it may happen that the ohci controller emulation doesn't manage to do
timely frame processing, with the result that the io watchdog fires and
considers the controller being dead, even though it's only the emulation
being unusual slow due to the load peak.
So, add a quirk for qemu and don't use the watchdog in case we figure we
are running on emulated ohci. The virtual ohci controller masquerades
as apple ohci controller, but we can identify it by subsystem id.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/ohci-hcd.c | 3 ++-
drivers/usb/host/ohci-pci.c | 16 ++++++++++++++++
drivers/usb/host/ohci.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -231,7 +231,8 @@ static int ohci_urb_enqueue (
/* Start up the I/O watchdog timer, if it's not running */
if (!timer_pending(&ohci->io_watchdog) &&
- list_empty(&ohci->eds_in_use)) {
+ list_empty(&ohci->eds_in_use) &&
+ !(ohci->flags & OHCI_QUIRK_QEMU)) {
ohci->prev_frame_no = ohci_frame_no(ohci);
mod_timer(&ohci->io_watchdog,
jiffies + IO_WATCHDOG_DELAY);
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -164,6 +164,15 @@ static int ohci_quirk_amd700(struct usb_
return 0;
}
+static int ohci_quirk_qemu(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+
+ ohci->flags |= OHCI_QUIRK_QEMU;
+ ohci_dbg(ohci, "enabled qemu quirk\n");
+ return 0;
+}
+
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -214,6 +223,13 @@ static const struct pci_device_id ohci_p
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
+ {
+ .vendor = PCI_VENDOR_ID_APPLE,
+ .device = 0x003f,
+ .subvendor = PCI_SUBVENDOR_ID_REDHAT_QUMRANET,
+ .subdevice = PCI_SUBDEVICE_ID_QEMU,
+ .driver_data = (unsigned long)ohci_quirk_qemu,
+ },
/* FIXME for some of the early AMD 760 southbridges, OHCI
* won't work at all. blacklist them.
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -418,6 +418,7 @@ struct ohci_hcd {
#define OHCI_QUIRK_AMD_PLL 0x200 /* AMD PLL quirk*/
#define OHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch for ISO transfer */
#define OHCI_QUIRK_GLOBAL_SUSPEND 0x800 /* must suspend ports */
+#define OHCI_QUIRK_QEMU 0x1000 /* relax timing expectations */
// there are also chip quirks/bugs in init logic
Patches currently in stable-queue which might be from kraxel@redhat.com are
queue-4.9/ohci-pci-add-qemu-quirk.patch
^ permalink raw reply
* Patch "proc: Fix unbalanced hard link numbers" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 17:05 UTC (permalink / raw)
To: tiwai, ebiederm, gregkh, tristan.ye; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
proc: Fix unbalanced hard link numbers
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=summary
The filename of the patch is:
proc-fix-unbalanced-hard-link-numbers.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@vger.kernel.org> know about it.
>From d66bb1607e2d8d384e53f3d93db5c18483c8c4f7 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Fri, 28 Apr 2017 15:00:15 +0200
Subject: proc: Fix unbalanced hard link numbers
From: Takashi Iwai <tiwai@suse.de>
commit d66bb1607e2d8d384e53f3d93db5c18483c8c4f7 upstream.
proc_create_mount_point() forgot to increase the parent's nlink, and
it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one
less than expected.
Fixes: eb6d38d5427b ("proc: Allow creating permanently empty directories...")
Reported-by: Tristan Ye <tristan.ye@suse.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/generic.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -471,6 +471,7 @@ struct proc_dir_entry *proc_create_mount
ent->data = NULL;
ent->proc_fops = NULL;
ent->proc_iops = NULL;
+ parent->nlink++;
if (proc_register(parent, ent) < 0) {
kfree(ent);
parent->nlink--;
Patches currently in stable-queue which might be from tiwai@suse.de are
queue-4.9/proc-fix-unbalanced-hard-link-numbers.patch
queue-4.9/alsa-hda-fix-cpu-lockup-when-stopping-the-cmd-dmas.patch
^ permalink raw reply
* Re: [PATCH 1/3] xfs: Fix missed holes in SEEK_HOLE implementation
From: Brian Foster @ 2017-05-22 17:50 UTC (permalink / raw)
To: Jan Kara; +Cc: Darrick J. Wong, linux-xfs, Eryu Guan, stable
In-Reply-To: <20170518104850.14508-2-jack@suse.cz>
On Thu, May 18, 2017 at 12:48:48PM +0200, Jan Kara wrote:
> XFS SEEK_HOLE implementation could miss a hole in an unwritten extent as
> can be seen by the following command:
>
> xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
> -c "seek -h 0" file
> wrote 57344/57344 bytes at offset 0
> 56 KiB, 14 ops; 0.0000 sec (49.312 MiB/sec and 12623.9856 ops/sec)
> wrote 8192/8192 bytes at offset 131072
> 8 KiB, 2 ops; 0.0000 sec (70.383 MiB/sec and 18018.0180 ops/sec)
> Whence Result
> HOLE 139264
>
> Where we can see that hole at offset 56k was just ignored by SEEK_HOLE
> implementation. The bug is in xfs_find_get_desired_pgoff() which does
> not properly detect the case when pages are not contiguous.
>
> Fix the problem by properly detecting when found page has larger offset
> than expected.
>
> CC: stable@vger.kernel.org
> Fixes: d126d43f631f996daeee5006714fed914be32368
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
Reviewed-by: Brian Foster <bfoster@redhat.com>
> fs/xfs/xfs_file.c | 29 +++++++++--------------------
> 1 file changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 35703a801372..f371812e20c6 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1076,17 +1076,6 @@ xfs_find_get_desired_pgoff(
> break;
> }
>
> - /*
> - * At lease we found one page. If this is the first time we
> - * step into the loop, and if the first page index offset is
> - * greater than the given search offset, a hole was found.
> - */
> - if (type == HOLE_OFF && lastoff == startoff &&
> - lastoff < page_offset(pvec.pages[0])) {
> - found = true;
> - break;
> - }
> -
> for (i = 0; i < nr_pages; i++) {
> struct page *page = pvec.pages[i];
> loff_t b_offset;
> @@ -1098,18 +1087,18 @@ xfs_find_get_desired_pgoff(
> * file mapping. However, page->index will not change
> * because we have a reference on the page.
> *
> - * Searching done if the page index is out of range.
> - * If the current offset is not reaches the end of
> - * the specified search range, there should be a hole
> - * between them.
> + * If current page offset is beyond where we've ended,
> + * we've found a hole.
> */
> - if (page->index > end) {
> - if (type == HOLE_OFF && lastoff < endoff) {
> - *offset = lastoff;
> - found = true;
> - }
> + if (type == HOLE_OFF && lastoff < endoff &&
> + lastoff < page_offset(pvec.pages[i])) {
> + found = true;
> + *offset = lastoff;
> goto out;
> }
> + /* Searching done if the page index is out of range. */
> + if (page->index > end)
> + goto out;
>
> lock_page(page);
> /*
> --
> 2.12.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] bonding: fix randomly populated arp target array
From: David Miller @ 2017-05-22 18:38 UTC (permalink / raw)
To: jarod; +Cc: linux-kernel, maheshb, j.vosburgh, vfalico, andy, netdev, stable
In-Reply-To: <20170519184646.42572-1-jarod@redhat.com>
From: Jarod Wilson <jarod@redhat.com>
Date: Fri, 19 May 2017 14:46:46 -0400
> In commit dc9c4d0fe023, the arp_target array moved from a static global
> to a local variable. By the nature of static globals, the array used to
> be initialized to all 0. At present, it's full of random data, which
> that gets interpreted as arp_target values, when none have actually been
> specified. Systems end up booting with spew along these lines:
...
> None of these were actually specified as ARP targets, and the driver does
> seem to clean up the mess okay, but it's rather noisy and confusing, leaks
> values to userspace, and the 255.255.255.255 spew shows up even when debug
> prints are disabled.
>
> The fix: just zero out arp_target at init time.
>
> While we're in here, init arp_all_targets_value in the right place.
>
> Fixes: dc9c4d0fe023 ("bonding: reduce scope of some global variables")
> CC: Mahesh Bandewar <maheshb@google.com>
> CC: Jay Vosburgh <j.vosburgh@gmail.com>
> CC: Veaceslav Falico <vfalico@gmail.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: netdev@vger.kernel.org
> CC: stable@vger.kernel.org
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
Whoops... applied, thanks Jarod.
^ permalink raw reply
* Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam @ 2017-05-22 18:52 UTC (permalink / raw)
To: Marek Vasut
Cc: Fabio Estevam, Stefan Agner, Sascha Hauer, DRI mailing list,
stable
In-Reply-To: <eda79c17-4e58-fd57-40ff-48079cff75a3@denx.de>
Hi Marek,
On Mon, May 22, 2017 at 11:20 AM, Marek Vasut <marex@denx.de> wrote:
> IMO it's OK.
>
> Reviewed-by: Marek Vasut <marex@denx.de>
Thanks for the feedback.
Do you plan to send Dave a pull request so that this one can reach 4.12-rc?
Thanks
^ permalink raw reply
* FAILED: patch "[PATCH] of: fdt: add missing allocation-failure check" failed to apply to 4.4-stable tree
From: gregkh @ 2017-05-22 19:17 UTC (permalink / raw)
To: johan, robh, stable; +Cc: stable
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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 49e67dd17649b60b4d54966e18ec9c80198227f0 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Wed, 17 May 2017 17:29:09 +0200
Subject: [PATCH] of: fdt: add missing allocation-failure check
The memory allocator passed to __unflatten_device_tree() (e.g. a wrapped
kzalloc) can fail so add the missing sanity check to avoid dereferencing
a NULL pointer.
Fixes: fe14042358fa ("of/flattree: Refactor unflatten_device_tree and add fdt_unflatten_tree")
Cc: stable <stable@vger.kernel.org> # 2.6.38
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a0972219ccfc..0373ae49d24d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -507,6 +507,9 @@ void *__unflatten_device_tree(const void *blob,
/* Allocate memory for the expanded device tree */
mem = dt_alloc(size + 4, __alignof__(struct device_node));
+ if (!mem)
+ return NULL;
+
memset(mem, 0, size);
*(__be32 *)(mem + size) = cpu_to_be32(0xdeadbeef);
^ permalink raw reply related
* Patch "pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-22 19:18 UTC (permalink / raw)
To: ktkhai, akpm, avagin, ebiederm, gorcunov, gregkh, luto, mhocko,
mingo, oleg, peterz, rppt, serge
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
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=summary
The filename of the patch is:
pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.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@vger.kernel.org> know about it.
>From 3fd37226216620c1a468afa999739d5016fbc349 Mon Sep 17 00:00:00 2001
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Fri, 12 May 2017 19:11:31 +0300
Subject: pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
From: Kirill Tkhai <ktkhai@virtuozzo.com>
commit 3fd37226216620c1a468afa999739d5016fbc349 upstream.
Imagine we have a pid namespace and a task from its parent's pid_ns,
which made setns() to the pid namespace. The task is doing fork(),
while the pid namespace's child reaper is dying. We have the race
between them:
Task from parent pid_ns Child reaper
copy_process() ..
alloc_pid() ..
.. zap_pid_ns_processes()
.. disable_pid_allocation()
.. read_lock(&tasklist_lock)
.. iterate over pids in pid_ns
.. kill tasks linked to pids
.. read_unlock(&tasklist_lock)
write_lock_irq(&tasklist_lock); ..
attach_pid(p, PIDTYPE_PID); ..
.. ..
So, just created task p won't receive SIGKILL signal,
and the pid namespace will be in contradictory state.
Only manual kill will help there, but does the userspace
care about this? I suppose, the most users just inject
a task into a pid namespace and wait a SIGCHLD from it.
The patch fixes the problem. It simply checks for
(pid_ns->nr_hashed & PIDNS_HASH_ADDING) in copy_process().
We do it under the tasklist_lock, and can't skip
PIDNS_HASH_ADDING as noted by Oleg:
"zap_pid_ns_processes() does disable_pid_allocation()
and then takes tasklist_lock to kill the whole namespace.
Given that copy_process() checks PIDNS_HASH_ADDING
under write_lock(tasklist) they can't race;
if copy_process() takes this lock first, the new child will
be killed, otherwise copy_process() can't miss
the change in ->nr_hashed."
If allocation is disabled, we just return -ENOMEM
like it's made for such cases in alloc_pid().
v2: Do not move disable_pid_allocation(), do not
introduce a new variable in copy_process() and simplify
the patch as suggested by Oleg Nesterov.
Account the problem with double irq enabling
found by Eric W. Biederman.
Fixes: c876ad768215 ("pidns: Stop pid allocation when init dies")
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Ingo Molnar <mingo@kernel.org>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Oleg Nesterov <oleg@redhat.com>
CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
CC: Michal Hocko <mhocko@suse.com>
CC: Andy Lutomirski <luto@kernel.org>
CC: "Eric W. Biederman" <ebiederm@xmission.com>
CC: Andrei Vagin <avagin@openvz.org>
CC: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Serge Hallyn <serge@hallyn.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1590,11 +1590,13 @@ static struct task_struct *copy_process(
*/
recalc_sigpending();
if (signal_pending(current)) {
- spin_unlock(¤t->sighand->siglock);
- write_unlock_irq(&tasklist_lock);
retval = -ERESTARTNOINTR;
goto bad_fork_cancel_cgroup;
}
+ if (unlikely(!(ns_of_pid(pid)->nr_hashed & PIDNS_HASH_ADDING))) {
+ retval = -ENOMEM;
+ goto bad_fork_cancel_cgroup;
+ }
if (likely(p->pid)) {
ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
@@ -1645,6 +1647,8 @@ static struct task_struct *copy_process(
return p;
bad_fork_cancel_cgroup:
+ spin_unlock(¤t->sighand->siglock);
+ write_unlock_irq(&tasklist_lock);
cgroup_cancel_fork(p, cgrp_ss_priv);
bad_fork_free_pid:
threadgroup_change_end(current);
Patches currently in stable-queue which might be from ktkhai@virtuozzo.com are
queue-4.4/pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
^ permalink raw reply
* Patch "pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-22 19:18 UTC (permalink / raw)
To: ebiederm, gregkh, linux, vovoy; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
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=summary
The filename of the patch is:
pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.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@vger.kernel.org> know about it.
>From b9a985db98961ae1ba0be169f19df1c567e4ffe0 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 11 May 2017 18:21:01 -0500
Subject: pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
From: Eric W. Biederman <ebiederm@xmission.com>
commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
The code can potentially sleep for an indefinite amount of time in
zap_pid_ns_processes triggering the hung task timeout, and increasing
the system average. This is undesirable. Sleep with a task state of
TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
undesirable side effects.
Apparently under heavy load this has been allowing Chrome to trigger
the hung time task timeout error and cause ChromeOS to reboot.
Reported-by: Vovo Yang <vovoy@google.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 6347e9009104 ("pidns: guarantee that the pidns init will be the last pidns process reaped")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/pid_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -255,7 +255,7 @@ void zap_pid_ns_processes(struct pid_nam
* if reparented.
*/
for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
+ set_current_state(TASK_INTERRUPTIBLE);
if (pid_ns->nr_hashed == init_pids)
break;
schedule();
Patches currently in stable-queue which might be from ebiederm@xmission.com are
queue-4.4/proc-fix-unbalanced-hard-link-numbers.patch
queue-4.4/pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.patch
queue-4.4/pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-22 19:18 UTC (permalink / raw)
To: andrey, gregkh, johan; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
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=summary
The filename of the patch is:
usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.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@vger.kernel.org> know about it.
>From 5f63424ab7daac840df2b12dd5bcc5b38d50f779 Mon Sep 17 00:00:00 2001
From: Andrey Korolyov <andrey@xdel.ru>
Date: Tue, 16 May 2017 23:54:41 +0300
Subject: USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
From: Andrey Korolyov <andrey@xdel.ru>
commit 5f63424ab7daac840df2b12dd5bcc5b38d50f779 upstream.
This patch adds support for recognition of ARM-USB-TINY(H) devices which
are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
and serial console.
By suggestion from Johan Hovold it is possible to replace
ftdi_jtag_quirk with a bit more generic construction. Since all
Olimex-ARM debuggers has exactly two ports, we could safely always use
only second port within the debugger family.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 8 ++++----
drivers/usb/serial/ftdi_sio_ids.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -809,10 +809,10 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
{ USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_H_PID, 1) },
{ USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -882,6 +882,8 @@
/* Olimex */
#define OLIMEX_VID 0x15BA
#define OLIMEX_ARM_USB_OCD_PID 0x0003
+#define OLIMEX_ARM_USB_TINY_PID 0x0004
+#define OLIMEX_ARM_USB_TINY_H_PID 0x002a
#define OLIMEX_ARM_USB_OCD_H_PID 0x002b
/*
Patches currently in stable-queue which might be from andrey@xdel.ru are
queue-4.4/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: fix setting latency for unprivileged users" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-22 19:18 UTC (permalink / raw)
To: anthony.mallet, gregkh, johan; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: fix setting latency for unprivileged users
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=summary
The filename of the patch is:
usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.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@vger.kernel.org> know about it.
>From bb246681b3ed0967489a7401ad528c1aaa1a4c2e Mon Sep 17 00:00:00 2001
From: Anthony Mallet <anthony.mallet@laas.fr>
Date: Fri, 5 May 2017 17:30:16 +0200
Subject: USB: serial: ftdi_sio: fix setting latency for unprivileged users
From: Anthony Mallet <anthony.mallet@laas.fr>
commit bb246681b3ed0967489a7401ad528c1aaa1a4c2e upstream.
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") enables unprivileged users to set the FTDI latency timer,
but there was a logic flaw that skipped sending the corresponding
USB control message to the device.
Specifically, the device latency timer would not be updated until next
open, something which was later also inadvertently broken by commit
c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port
probe").
A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme
low-latency setting") disabled the low-latency mode by default so we now
need this fix to allow unprivileged users to again enable it.
Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
[johan: amend commit message]
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe").
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1508,9 +1508,9 @@ static int set_serial_info(struct tty_st
(new_serial.flags & ASYNC_FLAGS));
priv->custom_divisor = new_serial.custom_divisor;
+check_and_exit:
write_latency_timer(port);
-check_and_exit:
if ((old_priv.flags & ASYNC_SPD_MASK) !=
(priv->flags & ASYNC_SPD_MASK)) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
Patches currently in stable-queue which might be from anthony.mallet@laas.fr are
queue-4.4/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
^ permalink raw reply
* Patch "pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-22 19:24 UTC (permalink / raw)
To: ebiederm, gregkh, linux, vovoy; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
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=summary
The filename of the patch is:
pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.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@vger.kernel.org> know about it.
>From b9a985db98961ae1ba0be169f19df1c567e4ffe0 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 11 May 2017 18:21:01 -0500
Subject: pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
From: Eric W. Biederman <ebiederm@xmission.com>
commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
The code can potentially sleep for an indefinite amount of time in
zap_pid_ns_processes triggering the hung task timeout, and increasing
the system average. This is undesirable. Sleep with a task state of
TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
undesirable side effects.
Apparently under heavy load this has been allowing Chrome to trigger
the hung time task timeout error and cause ChromeOS to reboot.
Reported-by: Vovo Yang <vovoy@google.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 6347e9009104 ("pidns: guarantee that the pidns init will be the last pidns process reaped")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/pid_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -234,7 +234,7 @@ void zap_pid_ns_processes(struct pid_nam
* Make sure they all go away, see free_pid().
*/
for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
+ set_current_state(TASK_INTERRUPTIBLE);
if (pid_ns->nr_hashed == init_pids)
break;
schedule();
Patches currently in stable-queue which might be from ebiederm@xmission.com are
queue-3.18/pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: fix setting latency for unprivileged users" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-22 19:24 UTC (permalink / raw)
To: anthony.mallet, gregkh, johan; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: fix setting latency for unprivileged users
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=summary
The filename of the patch is:
usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.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@vger.kernel.org> know about it.
>From bb246681b3ed0967489a7401ad528c1aaa1a4c2e Mon Sep 17 00:00:00 2001
From: Anthony Mallet <anthony.mallet@laas.fr>
Date: Fri, 5 May 2017 17:30:16 +0200
Subject: USB: serial: ftdi_sio: fix setting latency for unprivileged users
From: Anthony Mallet <anthony.mallet@laas.fr>
commit bb246681b3ed0967489a7401ad528c1aaa1a4c2e upstream.
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") enables unprivileged users to set the FTDI latency timer,
but there was a logic flaw that skipped sending the corresponding
USB control message to the device.
Specifically, the device latency timer would not be updated until next
open, something which was later also inadvertently broken by commit
c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port
probe").
A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme
low-latency setting") disabled the low-latency mode by default so we now
need this fix to allow unprivileged users to again enable it.
Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
[johan: amend commit message]
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe").
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1506,9 +1506,9 @@ static int set_serial_info(struct tty_st
(new_serial.flags & ASYNC_FLAGS));
priv->custom_divisor = new_serial.custom_divisor;
+check_and_exit:
write_latency_timer(port);
-check_and_exit:
if ((old_priv.flags & ASYNC_SPD_MASK) !=
(priv->flags & ASYNC_SPD_MASK)) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
Patches currently in stable-queue which might be from anthony.mallet@laas.fr are
queue-3.18/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-22 19:24 UTC (permalink / raw)
To: andrey, gregkh, johan; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
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=summary
The filename of the patch is:
usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.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@vger.kernel.org> know about it.
>From 5f63424ab7daac840df2b12dd5bcc5b38d50f779 Mon Sep 17 00:00:00 2001
From: Andrey Korolyov <andrey@xdel.ru>
Date: Tue, 16 May 2017 23:54:41 +0300
Subject: USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
From: Andrey Korolyov <andrey@xdel.ru>
commit 5f63424ab7daac840df2b12dd5bcc5b38d50f779 upstream.
This patch adds support for recognition of ARM-USB-TINY(H) devices which
are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
and serial console.
By suggestion from Johan Hovold it is possible to replace
ftdi_jtag_quirk with a bit more generic construction. Since all
Olimex-ARM debuggers has exactly two ports, we could safely always use
only second port within the debugger family.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 8 ++++----
drivers/usb/serial/ftdi_sio_ids.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -809,10 +809,10 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
{ USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_H_PID, 1) },
{ USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -876,6 +876,8 @@
/* Olimex */
#define OLIMEX_VID 0x15BA
#define OLIMEX_ARM_USB_OCD_PID 0x0003
+#define OLIMEX_ARM_USB_TINY_PID 0x0004
+#define OLIMEX_ARM_USB_TINY_H_PID 0x002a
#define OLIMEX_ARM_USB_OCD_H_PID 0x002b
/*
Patches currently in stable-queue which might be from andrey@xdel.ru are
queue-3.18/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
^ permalink raw reply
* Patch "IB/hfi1: Fix a subcontext memory leak" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: michael.j.ruhl, dennis.dalessandro, dledford, gregkh,
mike.marciniszyn
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/hfi1: Fix a subcontext memory leak
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-hfi1-fix-a-subcontext-memory-leak.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 224d71f910102c966cdcd782c97e096d5e26e4da Mon Sep 17 00:00:00 2001
From: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Date: Thu, 4 May 2017 05:14:34 -0700
Subject: IB/hfi1: Fix a subcontext memory leak
From: Michael J. Ruhl <michael.j.ruhl@intel.com>
commit 224d71f910102c966cdcd782c97e096d5e26e4da upstream.
The only context that frees user_exp_rcv data structures is the last
context closed (from a sub-context set). This leaks the allocations
from the other sub-contexts. Separate the common frees from the
specific frees and call them at the appropriate time.
Using KEDR to check for memory leaks we get:
Before test:
[leak_check] Possible leaks: 25
After test:
[leak_check] Possible leaks: 31 (6 leaked data structures)
After patch applied (before and after test have the same value)
[leak_check] Possible leaks: 25
Each leak is 192 + 13440 + 6720 = 20352 bytes per sub-context.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/file_ops.c | 5 +++-
drivers/infiniband/hw/hfi1/user_exp_rcv.c | 32 ++++++++++++++++--------------
drivers/infiniband/hw/hfi1/user_exp_rcv.h | 1
3 files changed, 23 insertions(+), 15 deletions(-)
--- a/drivers/infiniband/hw/hfi1/file_ops.c
+++ b/drivers/infiniband/hw/hfi1/file_ops.c
@@ -752,6 +752,9 @@ static int hfi1_file_close(struct inode
/* release the cpu */
hfi1_put_proc_affinity(fdata->rec_cpu_num);
+ /* clean up rcv side */
+ hfi1_user_exp_rcv_free(fdata);
+
/*
* Clear any left over, unhandled events so the next process that
* gets this context doesn't get confused.
@@ -791,7 +794,7 @@ static int hfi1_file_close(struct inode
dd->rcd[uctxt->ctxt] = NULL;
- hfi1_user_exp_rcv_free(fdata);
+ hfi1_user_exp_rcv_grp_free(uctxt);
hfi1_clear_ctxt_pkey(dd, uctxt->ctxt);
uctxt->rcvwait_to = 0;
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
@@ -251,36 +251,40 @@ done:
return ret;
}
+void hfi1_user_exp_rcv_grp_free(struct hfi1_ctxtdata *uctxt)
+{
+ struct tid_group *grp, *gptr;
+
+ list_for_each_entry_safe(grp, gptr, &uctxt->tid_group_list.list,
+ list) {
+ list_del_init(&grp->list);
+ kfree(grp);
+ }
+ hfi1_clear_tids(uctxt);
+}
+
int hfi1_user_exp_rcv_free(struct hfi1_filedata *fd)
{
struct hfi1_ctxtdata *uctxt = fd->uctxt;
- struct tid_group *grp, *gptr;
- if (!test_bit(HFI1_CTXT_SETUP_DONE, &uctxt->event_flags))
- return 0;
/*
* The notifier would have been removed when the process'es mm
* was freed.
*/
- if (fd->handler)
+ if (fd->handler) {
hfi1_mmu_rb_unregister(fd->handler);
-
- kfree(fd->invalid_tids);
-
- if (!uctxt->cnt) {
+ } else {
if (!EXP_TID_SET_EMPTY(uctxt->tid_full_list))
unlock_exp_tids(uctxt, &uctxt->tid_full_list, fd);
if (!EXP_TID_SET_EMPTY(uctxt->tid_used_list))
unlock_exp_tids(uctxt, &uctxt->tid_used_list, fd);
- list_for_each_entry_safe(grp, gptr, &uctxt->tid_group_list.list,
- list) {
- list_del_init(&grp->list);
- kfree(grp);
- }
- hfi1_clear_tids(uctxt);
}
+ kfree(fd->invalid_tids);
+ fd->invalid_tids = NULL;
+
kfree(fd->entry_to_rb);
+ fd->entry_to_rb = NULL;
return 0;
}
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.h
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.h
@@ -70,6 +70,7 @@
(tid) |= EXP_TID_SET(field, (value)); \
} while (0)
+void hfi1_user_exp_rcv_grp_free(struct hfi1_ctxtdata *uctxt);
int hfi1_user_exp_rcv_init(struct file *);
int hfi1_user_exp_rcv_free(struct hfi1_filedata *);
int hfi1_user_exp_rcv_setup(struct file *, struct hfi1_tid_info *);
Patches currently in stable-queue which might be from michael.j.ruhl@intel.com are
queue-4.11/ib-hfi1-return-an-error-on-memory-allocation-failure.patch
queue-4.11/ib-hfi1-fix-a-subcontext-memory-leak.patch
^ permalink raw reply
* Patch "IB/hfi1: Return an error on memory allocation failure" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: michael.j.ruhl, dennis.dalessandro, dledford, gregkh,
mike.marciniszyn
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/hfi1: Return an error on memory allocation failure
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-hfi1-return-an-error-on-memory-allocation-failure.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 94679061dcdddbafcf24e3bfb526e54dedcc2f2f Mon Sep 17 00:00:00 2001
From: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Date: Thu, 4 May 2017 05:14:28 -0700
Subject: IB/hfi1: Return an error on memory allocation failure
From: Michael J. Ruhl <michael.j.ruhl@intel.com>
commit 94679061dcdddbafcf24e3bfb526e54dedcc2f2f upstream.
If the eager buffer allocation fails, it is necessary to return
an error code.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/init.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/hw/hfi1/init.c
+++ b/drivers/infiniband/hw/hfi1/init.c
@@ -1758,6 +1758,7 @@ int hfi1_setup_eagerbufs(struct hfi1_ctx
!HFI1_CAP_KGET_MASK(rcd->flags, MULTI_PKT_EGR)) {
dd_dev_err(dd, "ctxt%u: Failed to allocate eager buffers\n",
rcd->ctxt);
+ ret = -ENOMEM;
goto bail_rcvegrbuf_phys;
}
Patches currently in stable-queue which might be from michael.j.ruhl@intel.com are
queue-4.11/ib-hfi1-return-an-error-on-memory-allocation-failure.patch
queue-4.11/ib-hfi1-fix-a-subcontext-memory-leak.patch
^ permalink raw reply
* Patch "Make stat/lstat/fstatat pass AT_NO_AUTOMOUNT to vfs_statx()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: dhowells, gregkh, raven, viro; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Make stat/lstat/fstatat pass AT_NO_AUTOMOUNT to vfs_statx()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
make-stat-lstat-fstatat-pass-at_no_automount-to-vfs_statx.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From deccf497d804a4c5fca2dbfad2f104675a6f9102 Mon Sep 17 00:00:00 2001
From: David Howells <dhowells@redhat.com>
Date: Thu, 4 May 2017 23:30:16 +0100
Subject: Make stat/lstat/fstatat pass AT_NO_AUTOMOUNT to vfs_statx()
From: David Howells <dhowells@redhat.com>
commit deccf497d804a4c5fca2dbfad2f104675a6f9102 upstream.
stat/lstat/fstatat need to pass AT_NO_AUTOMOUNT to vfs_statx() as the
pre-statx code didn't set LOOKUP_AUTOMOUNT, even though fstatat() accepted
the AT_NO_AUTOMOUNT flag.
Fixes: a528d35e8bfc ("statx: Add a system call to make enhanced file info available")
Reported-by: Ian Kent <raven@themaw.net>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Ian Kent <raven@themaw.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/fs.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2921,17 +2921,19 @@ extern int vfs_statx_fd(unsigned int, st
static inline int vfs_stat(const char __user *filename, struct kstat *stat)
{
- return vfs_statx(AT_FDCWD, filename, 0, stat, STATX_BASIC_STATS);
+ return vfs_statx(AT_FDCWD, filename, AT_NO_AUTOMOUNT,
+ stat, STATX_BASIC_STATS);
}
static inline int vfs_lstat(const char __user *name, struct kstat *stat)
{
- return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW,
+ return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT,
stat, STATX_BASIC_STATS);
}
static inline int vfs_fstatat(int dfd, const char __user *filename,
struct kstat *stat, int flags)
{
- return vfs_statx(dfd, filename, flags, stat, STATX_BASIC_STATS);
+ return vfs_statx(dfd, filename, flags | AT_NO_AUTOMOUNT,
+ stat, STATX_BASIC_STATS);
}
static inline int vfs_fstat(int fd, struct kstat *stat)
{
Patches currently in stable-queue which might be from dhowells@redhat.com are
queue-4.11/make-stat-lstat-fstatat-pass-at_no_automount-to-vfs_statx.patch
^ permalink raw reply
* Patch "pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: ebiederm, gregkh, linux, vovoy; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From b9a985db98961ae1ba0be169f19df1c567e4ffe0 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 11 May 2017 18:21:01 -0500
Subject: pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
From: Eric W. Biederman <ebiederm@xmission.com>
commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
The code can potentially sleep for an indefinite amount of time in
zap_pid_ns_processes triggering the hung task timeout, and increasing
the system average. This is undesirable. Sleep with a task state of
TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
undesirable side effects.
Apparently under heavy load this has been allowing Chrome to trigger
the hung time task timeout error and cause ChromeOS to reboot.
Reported-by: Vovo Yang <vovoy@google.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 6347e9009104 ("pidns: guarantee that the pidns init will be the last pidns process reaped")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/pid_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -277,7 +277,7 @@ void zap_pid_ns_processes(struct pid_nam
* if reparented.
*/
for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
+ set_current_state(TASK_INTERRUPTIBLE);
if (pid_ns->nr_hashed == init_pids)
break;
schedule();
Patches currently in stable-queue which might be from ebiederm@xmission.com are
queue-4.11/proc-fix-unbalanced-hard-link-numbers.patch
queue-4.11/pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.patch
queue-4.11/pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
^ permalink raw reply
* Patch "pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: ktkhai, akpm, avagin, ebiederm, gorcunov, gregkh, luto, mhocko,
mingo, oleg, peterz, rppt, serge
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 3fd37226216620c1a468afa999739d5016fbc349 Mon Sep 17 00:00:00 2001
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Fri, 12 May 2017 19:11:31 +0300
Subject: pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
From: Kirill Tkhai <ktkhai@virtuozzo.com>
commit 3fd37226216620c1a468afa999739d5016fbc349 upstream.
Imagine we have a pid namespace and a task from its parent's pid_ns,
which made setns() to the pid namespace. The task is doing fork(),
while the pid namespace's child reaper is dying. We have the race
between them:
Task from parent pid_ns Child reaper
copy_process() ..
alloc_pid() ..
.. zap_pid_ns_processes()
.. disable_pid_allocation()
.. read_lock(&tasklist_lock)
.. iterate over pids in pid_ns
.. kill tasks linked to pids
.. read_unlock(&tasklist_lock)
write_lock_irq(&tasklist_lock); ..
attach_pid(p, PIDTYPE_PID); ..
.. ..
So, just created task p won't receive SIGKILL signal,
and the pid namespace will be in contradictory state.
Only manual kill will help there, but does the userspace
care about this? I suppose, the most users just inject
a task into a pid namespace and wait a SIGCHLD from it.
The patch fixes the problem. It simply checks for
(pid_ns->nr_hashed & PIDNS_HASH_ADDING) in copy_process().
We do it under the tasklist_lock, and can't skip
PIDNS_HASH_ADDING as noted by Oleg:
"zap_pid_ns_processes() does disable_pid_allocation()
and then takes tasklist_lock to kill the whole namespace.
Given that copy_process() checks PIDNS_HASH_ADDING
under write_lock(tasklist) they can't race;
if copy_process() takes this lock first, the new child will
be killed, otherwise copy_process() can't miss
the change in ->nr_hashed."
If allocation is disabled, we just return -ENOMEM
like it's made for such cases in alloc_pid().
v2: Do not move disable_pid_allocation(), do not
introduce a new variable in copy_process() and simplify
the patch as suggested by Oleg Nesterov.
Account the problem with double irq enabling
found by Eric W. Biederman.
Fixes: c876ad768215 ("pidns: Stop pid allocation when init dies")
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Ingo Molnar <mingo@kernel.org>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Oleg Nesterov <oleg@redhat.com>
CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
CC: Michal Hocko <mhocko@suse.com>
CC: Andy Lutomirski <luto@kernel.org>
CC: "Eric W. Biederman" <ebiederm@xmission.com>
CC: Andrei Vagin <avagin@openvz.org>
CC: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Serge Hallyn <serge@hallyn.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1815,11 +1815,13 @@ static __latent_entropy struct task_stru
*/
recalc_sigpending();
if (signal_pending(current)) {
- spin_unlock(¤t->sighand->siglock);
- write_unlock_irq(&tasklist_lock);
retval = -ERESTARTNOINTR;
goto bad_fork_cancel_cgroup;
}
+ if (unlikely(!(ns_of_pid(pid)->nr_hashed & PIDNS_HASH_ADDING))) {
+ retval = -ENOMEM;
+ goto bad_fork_cancel_cgroup;
+ }
if (likely(p->pid)) {
ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
@@ -1877,6 +1879,8 @@ static __latent_entropy struct task_stru
return p;
bad_fork_cancel_cgroup:
+ spin_unlock(¤t->sighand->siglock);
+ write_unlock_irq(&tasklist_lock);
cgroup_cancel_fork(p);
bad_fork_free_pid:
cgroup_threadgroup_change_end(current);
Patches currently in stable-queue which might be from ktkhai@virtuozzo.com are
queue-4.11/pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: andrey, gregkh, johan; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 5f63424ab7daac840df2b12dd5bcc5b38d50f779 Mon Sep 17 00:00:00 2001
From: Andrey Korolyov <andrey@xdel.ru>
Date: Tue, 16 May 2017 23:54:41 +0300
Subject: USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
From: Andrey Korolyov <andrey@xdel.ru>
commit 5f63424ab7daac840df2b12dd5bcc5b38d50f779 upstream.
This patch adds support for recognition of ARM-USB-TINY(H) devices which
are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
and serial console.
By suggestion from Johan Hovold it is possible to replace
ftdi_jtag_quirk with a bit more generic construction. Since all
Olimex-ARM debuggers has exactly two ports, we could safely always use
only second port within the debugger family.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 8 ++++----
drivers/usb/serial/ftdi_sio_ids.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -809,10 +809,10 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
{ USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_H_PID, 1) },
{ USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -882,6 +882,8 @@
/* Olimex */
#define OLIMEX_VID 0x15BA
#define OLIMEX_ARM_USB_OCD_PID 0x0003
+#define OLIMEX_ARM_USB_TINY_PID 0x0004
+#define OLIMEX_ARM_USB_TINY_H_PID 0x002a
#define OLIMEX_ARM_USB_OCD_H_PID 0x002b
/*
Patches currently in stable-queue which might be from andrey@xdel.ru are
queue-4.11/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
^ permalink raw reply
* Patch "USB: chaoskey: fix Alea quirk on big-endian hosts" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:25 UTC (permalink / raw)
To: johan, bob.ham, gregkh, herbert, keithp; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: chaoskey: fix Alea quirk on big-endian hosts
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 63afd5cc78775018ea2dec4004428dafa5283e93 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Thu, 11 May 2017 11:36:01 +0200
Subject: USB: chaoskey: fix Alea quirk on big-endian hosts
From: Johan Hovold <johan@kernel.org>
commit 63afd5cc78775018ea2dec4004428dafa5283e93 upstream.
Add missing endianness conversion when applying the Alea timeout quirk.
Found using sparse:
warning: restricted __le16 degrades to integer
Fixes: e4a886e811cd ("hwrng: chaoskey - Fix URB warning due to timeout on Alea")
Cc: Bob Ham <bob.ham@collabora.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/misc/chaoskey.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/misc/chaoskey.c
+++ b/drivers/usb/misc/chaoskey.c
@@ -194,7 +194,7 @@ static int chaoskey_probe(struct usb_int
dev->in_ep = in_ep;
- if (udev->descriptor.idVendor != ALEA_VENDOR_ID)
+ if (le16_to_cpu(udev->descriptor.idVendor) != ALEA_VENDOR_ID)
dev->reads_started = 1;
dev->size = size;
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.11/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.11/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.11/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.11/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.11/of-fdt-add-missing-allocation-failure-check.patch
queue-4.11/ath9k_htc-fix-null-deref-at-probe.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: fix setting latency for unprivileged users" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-22 19:26 UTC (permalink / raw)
To: anthony.mallet, gregkh, johan; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: fix setting latency for unprivileged users
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From bb246681b3ed0967489a7401ad528c1aaa1a4c2e Mon Sep 17 00:00:00 2001
From: Anthony Mallet <anthony.mallet@laas.fr>
Date: Fri, 5 May 2017 17:30:16 +0200
Subject: USB: serial: ftdi_sio: fix setting latency for unprivileged users
From: Anthony Mallet <anthony.mallet@laas.fr>
commit bb246681b3ed0967489a7401ad528c1aaa1a4c2e upstream.
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") enables unprivileged users to set the FTDI latency timer,
but there was a logic flaw that skipped sending the corresponding
USB control message to the device.
Specifically, the device latency timer would not be updated until next
open, something which was later also inadvertently broken by commit
c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port
probe").
A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme
low-latency setting") disabled the low-latency mode by default so we now
need this fix to allow unprivileged users to again enable it.
Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
[johan: amend commit message]
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe").
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1506,9 +1506,9 @@ static int set_serial_info(struct tty_st
(new_serial.flags & ASYNC_FLAGS));
priv->custom_divisor = new_serial.custom_divisor;
+check_and_exit:
write_latency_timer(port);
-check_and_exit:
if ((old_priv.flags & ASYNC_SPD_MASK) !=
(priv->flags & ASYNC_SPD_MASK)) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
Patches currently in stable-queue which might be from anthony.mallet@laas.fr are
queue-4.11/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
^ permalink raw reply
* Patch "IB/hfi1: Fix a subcontext memory leak" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 UTC (permalink / raw)
To: michael.j.ruhl, dennis.dalessandro, dledford, gregkh,
mike.marciniszyn
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/hfi1: Fix a subcontext memory leak
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=summary
The filename of the patch is:
ib-hfi1-fix-a-subcontext-memory-leak.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@vger.kernel.org> know about it.
>From 224d71f910102c966cdcd782c97e096d5e26e4da Mon Sep 17 00:00:00 2001
From: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Date: Thu, 4 May 2017 05:14:34 -0700
Subject: IB/hfi1: Fix a subcontext memory leak
From: Michael J. Ruhl <michael.j.ruhl@intel.com>
commit 224d71f910102c966cdcd782c97e096d5e26e4da upstream.
The only context that frees user_exp_rcv data structures is the last
context closed (from a sub-context set). This leaks the allocations
from the other sub-contexts. Separate the common frees from the
specific frees and call them at the appropriate time.
Using KEDR to check for memory leaks we get:
Before test:
[leak_check] Possible leaks: 25
After test:
[leak_check] Possible leaks: 31 (6 leaked data structures)
After patch applied (before and after test have the same value)
[leak_check] Possible leaks: 25
Each leak is 192 + 13440 + 6720 = 20352 bytes per sub-context.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/file_ops.c | 5 +++-
drivers/infiniband/hw/hfi1/user_exp_rcv.c | 32 ++++++++++++++++--------------
drivers/infiniband/hw/hfi1/user_exp_rcv.h | 1
3 files changed, 23 insertions(+), 15 deletions(-)
--- a/drivers/infiniband/hw/hfi1/file_ops.c
+++ b/drivers/infiniband/hw/hfi1/file_ops.c
@@ -751,6 +751,9 @@ static int hfi1_file_close(struct inode
/* release the cpu */
hfi1_put_proc_affinity(fdata->rec_cpu_num);
+ /* clean up rcv side */
+ hfi1_user_exp_rcv_free(fdata);
+
/*
* Clear any left over, unhandled events so the next process that
* gets this context doesn't get confused.
@@ -790,7 +793,7 @@ static int hfi1_file_close(struct inode
dd->rcd[uctxt->ctxt] = NULL;
- hfi1_user_exp_rcv_free(fdata);
+ hfi1_user_exp_rcv_grp_free(uctxt);
hfi1_clear_ctxt_pkey(dd, uctxt->ctxt);
uctxt->rcvwait_to = 0;
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
@@ -250,36 +250,40 @@ done:
return ret;
}
+void hfi1_user_exp_rcv_grp_free(struct hfi1_ctxtdata *uctxt)
+{
+ struct tid_group *grp, *gptr;
+
+ list_for_each_entry_safe(grp, gptr, &uctxt->tid_group_list.list,
+ list) {
+ list_del_init(&grp->list);
+ kfree(grp);
+ }
+ hfi1_clear_tids(uctxt);
+}
+
int hfi1_user_exp_rcv_free(struct hfi1_filedata *fd)
{
struct hfi1_ctxtdata *uctxt = fd->uctxt;
- struct tid_group *grp, *gptr;
- if (!test_bit(HFI1_CTXT_SETUP_DONE, &uctxt->event_flags))
- return 0;
/*
* The notifier would have been removed when the process'es mm
* was freed.
*/
- if (fd->handler)
+ if (fd->handler) {
hfi1_mmu_rb_unregister(fd->handler);
-
- kfree(fd->invalid_tids);
-
- if (!uctxt->cnt) {
+ } else {
if (!EXP_TID_SET_EMPTY(uctxt->tid_full_list))
unlock_exp_tids(uctxt, &uctxt->tid_full_list, fd);
if (!EXP_TID_SET_EMPTY(uctxt->tid_used_list))
unlock_exp_tids(uctxt, &uctxt->tid_used_list, fd);
- list_for_each_entry_safe(grp, gptr, &uctxt->tid_group_list.list,
- list) {
- list_del_init(&grp->list);
- kfree(grp);
- }
- hfi1_clear_tids(uctxt);
}
+ kfree(fd->invalid_tids);
+ fd->invalid_tids = NULL;
+
kfree(fd->entry_to_rb);
+ fd->entry_to_rb = NULL;
return 0;
}
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.h
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.h
@@ -70,6 +70,7 @@
(tid) |= EXP_TID_SET(field, (value)); \
} while (0)
+void hfi1_user_exp_rcv_grp_free(struct hfi1_ctxtdata *uctxt);
int hfi1_user_exp_rcv_init(struct file *);
int hfi1_user_exp_rcv_free(struct hfi1_filedata *);
int hfi1_user_exp_rcv_setup(struct file *, struct hfi1_tid_info *);
Patches currently in stable-queue which might be from michael.j.ruhl@intel.com are
queue-4.9/ib-hfi1-return-an-error-on-memory-allocation-failure.patch
queue-4.9/ib-hfi1-fix-a-subcontext-memory-leak.patch
^ permalink raw reply
* Patch "IB/hfi1: Return an error on memory allocation failure" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 UTC (permalink / raw)
To: michael.j.ruhl, dennis.dalessandro, dledford, gregkh,
mike.marciniszyn
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/hfi1: Return an error on memory allocation failure
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=summary
The filename of the patch is:
ib-hfi1-return-an-error-on-memory-allocation-failure.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@vger.kernel.org> know about it.
>From 94679061dcdddbafcf24e3bfb526e54dedcc2f2f Mon Sep 17 00:00:00 2001
From: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Date: Thu, 4 May 2017 05:14:28 -0700
Subject: IB/hfi1: Return an error on memory allocation failure
From: Michael J. Ruhl <michael.j.ruhl@intel.com>
commit 94679061dcdddbafcf24e3bfb526e54dedcc2f2f upstream.
If the eager buffer allocation fails, it is necessary to return
an error code.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/init.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/hw/hfi1/init.c
+++ b/drivers/infiniband/hw/hfi1/init.c
@@ -1757,6 +1757,7 @@ int hfi1_setup_eagerbufs(struct hfi1_ctx
!HFI1_CAP_KGET_MASK(rcd->flags, MULTI_PKT_EGR)) {
dd_dev_err(dd, "ctxt%u: Failed to allocate eager buffers\n",
rcd->ctxt);
+ ret = -ENOMEM;
goto bail_rcvegrbuf_phys;
}
Patches currently in stable-queue which might be from michael.j.ruhl@intel.com are
queue-4.9/ib-hfi1-return-an-error-on-memory-allocation-failure.patch
queue-4.9/ib-hfi1-fix-a-subcontext-memory-leak.patch
^ permalink raw reply
* Patch "pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 UTC (permalink / raw)
To: ktkhai, akpm, avagin, ebiederm, gorcunov, gregkh, luto, mhocko,
mingo, oleg, peterz, rppt, serge
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
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=summary
The filename of the patch is:
pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.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@vger.kernel.org> know about it.
>From 3fd37226216620c1a468afa999739d5016fbc349 Mon Sep 17 00:00:00 2001
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Fri, 12 May 2017 19:11:31 +0300
Subject: pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
From: Kirill Tkhai <ktkhai@virtuozzo.com>
commit 3fd37226216620c1a468afa999739d5016fbc349 upstream.
Imagine we have a pid namespace and a task from its parent's pid_ns,
which made setns() to the pid namespace. The task is doing fork(),
while the pid namespace's child reaper is dying. We have the race
between them:
Task from parent pid_ns Child reaper
copy_process() ..
alloc_pid() ..
.. zap_pid_ns_processes()
.. disable_pid_allocation()
.. read_lock(&tasklist_lock)
.. iterate over pids in pid_ns
.. kill tasks linked to pids
.. read_unlock(&tasklist_lock)
write_lock_irq(&tasklist_lock); ..
attach_pid(p, PIDTYPE_PID); ..
.. ..
So, just created task p won't receive SIGKILL signal,
and the pid namespace will be in contradictory state.
Only manual kill will help there, but does the userspace
care about this? I suppose, the most users just inject
a task into a pid namespace and wait a SIGCHLD from it.
The patch fixes the problem. It simply checks for
(pid_ns->nr_hashed & PIDNS_HASH_ADDING) in copy_process().
We do it under the tasklist_lock, and can't skip
PIDNS_HASH_ADDING as noted by Oleg:
"zap_pid_ns_processes() does disable_pid_allocation()
and then takes tasklist_lock to kill the whole namespace.
Given that copy_process() checks PIDNS_HASH_ADDING
under write_lock(tasklist) they can't race;
if copy_process() takes this lock first, the new child will
be killed, otherwise copy_process() can't miss
the change in ->nr_hashed."
If allocation is disabled, we just return -ENOMEM
like it's made for such cases in alloc_pid().
v2: Do not move disable_pid_allocation(), do not
introduce a new variable in copy_process() and simplify
the patch as suggested by Oleg Nesterov.
Account the problem with double irq enabling
found by Eric W. Biederman.
Fixes: c876ad768215 ("pidns: Stop pid allocation when init dies")
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Ingo Molnar <mingo@kernel.org>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Oleg Nesterov <oleg@redhat.com>
CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
CC: Michal Hocko <mhocko@suse.com>
CC: Andy Lutomirski <luto@kernel.org>
CC: "Eric W. Biederman" <ebiederm@xmission.com>
CC: Andrei Vagin <avagin@openvz.org>
CC: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Serge Hallyn <serge@hallyn.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1773,11 +1773,13 @@ static __latent_entropy struct task_stru
*/
recalc_sigpending();
if (signal_pending(current)) {
- spin_unlock(¤t->sighand->siglock);
- write_unlock_irq(&tasklist_lock);
retval = -ERESTARTNOINTR;
goto bad_fork_cancel_cgroup;
}
+ if (unlikely(!(ns_of_pid(pid)->nr_hashed & PIDNS_HASH_ADDING))) {
+ retval = -ENOMEM;
+ goto bad_fork_cancel_cgroup;
+ }
if (likely(p->pid)) {
ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
@@ -1828,6 +1830,8 @@ static __latent_entropy struct task_stru
return p;
bad_fork_cancel_cgroup:
+ spin_unlock(¤t->sighand->siglock);
+ write_unlock_irq(&tasklist_lock);
cgroup_cancel_fork(p);
bad_fork_free_pid:
threadgroup_change_end(current);
Patches currently in stable-queue which might be from ktkhai@virtuozzo.com are
queue-4.9/pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox