* 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
* Patch "USB: chaoskey: fix Alea quirk on big-endian hosts" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 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.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:
usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.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 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.9/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/ath9k_htc-fix-null-deref-at-probe.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 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.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:
usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.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 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.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
^ permalink raw reply
* Patch "pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 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.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-sleep-in-task_interruptible-in-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 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
@@ -274,7 +274,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.9/proc-fix-unbalanced-hard-link-numbers.patch
queue-4.9/pid_ns-sleep-in-task_interruptible-in-zap_pid_ns_processes.patch
queue-4.9/pid_ns-fix-race-between-setns-ed-fork-and-zap_pid_ns_processes.patch
^ permalink raw reply
* Patch "USB: serial: ftdi_sio: fix setting latency for unprivileged users" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 19:27 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.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:
usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.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 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.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
^ permalink raw reply
* Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries
From: Ross Zwisler @ 2017-05-22 19:43 UTC (permalink / raw)
To: Jan Kara
Cc: Ross Zwisler, Andrew Morton, linux-kernel, Darrick J. Wong,
Alexander Viro, Christoph Hellwig, Dan Williams, Dave Hansen,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170522144457.GE25118@quack2.suse.cz>
On Mon, May 22, 2017 at 04:44:57PM +0200, Jan Kara wrote:
> On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> > We currently have two related PMD vs PTE races in the DAX code. These can
> > both be easily triggered by having two threads reading and writing
> > simultaneously to the same private mapping, with the key being that private
> > mapping reads can be handled with PMDs but private mapping writes are
> > always handled with PTEs so that we can COW.
> >
> > Here is the first race:
> >
> > CPU 0 CPU 1
> >
> > (private mapping write)
> > __handle_mm_fault()
> > create_huge_pmd() - FALLBACK
> > handle_pte_fault()
> > passes check for pmd_devmap()
> >
> > (private mapping read)
> > __handle_mm_fault()
> > create_huge_pmd()
> > dax_iomap_pmd_fault() inserts PMD
> >
> > dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> > installed in our page tables at this spot.
> >
> > Here's the second race:
> >
> > CPU 0 CPU 1
> >
> > (private mapping write)
> > __handle_mm_fault()
> > create_huge_pmd() - FALLBACK
> > (private mapping read)
> > __handle_mm_fault()
> > passes check for pmd_none()
> > create_huge_pmd()
> >
> > handle_pte_fault()
> > dax_iomap_pte_fault() inserts PTE
> > dax_iomap_pmd_fault() inserts PMD,
> > but we already have a PTE at
> > this spot.
> >
> > The core of the issue is that while there is isolation between faults to
> > the same range in the DAX fault handlers via our DAX entry locking, there
> > is no isolation between faults in the code in mm/memory.c. This means for
> > instance that this code in __handle_mm_fault() can run:
> >
> > if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
> > ret = create_huge_pmd(&vmf);
> >
> > But by the time we actually get to run the fault handler called by
> > create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
> > fault has installed a normal PMD here as a parent. This is the cause of
> > the 2nd race. The first race is similar - there is the following check in
> > handle_pte_fault():
> >
> > } else {
> > /* See comment in pte_alloc_one_map() */
> > if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> > return 0;
> >
> > So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
> > will bail and retry the fault. This is correct, but there is nothing
> > preventing the PMD from being installed after this check but before we
> > actually get to the DAX PTE fault handlers.
> >
> > In my testing these races result in the following types of errors:
> >
> > BUG: Bad rss-counter state mm:ffff8800a817d280 idx:1 val:1
> > BUG: non-zero nr_ptes on freeing mm: 15
> >
> > Fix this issue by having the DAX fault handlers verify that it is safe to
> > continue their fault after they have taken an entry lock to block other
> > racing faults.
> >
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Reported-by: Pawel Lebioda <pawel.lebioda@intel.com>
> > Cc: stable@vger.kernel.org
> >
> > ---
> >
> > I've written a new xfstest for this race, which I will send in response to
> > this patch series. This series has also survived an xfstest run without
> > any new issues.
> >
> > ---
> > fs/dax.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/fs/dax.c b/fs/dax.c
> > index c22eaf1..3cc02d1 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -1155,6 +1155,15 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> > }
> >
> > /*
> > + * It is possible, particularly with mixed reads & writes to private
> > + * mappings, that we have raced with a PMD fault that overlaps with
> > + * the PTE we need to set up. Now that we have a locked mapping entry
> > + * we can safely unmap the huge PMD so that we can install our PTE in
> > + * our page tables.
> > + */
> > + split_huge_pmd(vmf->vma, vmf->pmd, vmf->address);
> > +
>
> Can we just check the PMD and if is isn't as we want it, bail out and retry
> the fault? IMHO it will be more obvious that way (and also more in line
> like these races are handled for the classical THP). Otherwise the patch
> looks good to me.
Yep, that works as well. I'll do this for v2.
Thanks for the review.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries
From: Ross Zwisler @ 2017-05-22 19:44 UTC (permalink / raw)
To: Jan Kara
Cc: Ross Zwisler, Andrew Morton, linux-kernel, Darrick J. Wong,
Alexander Viro, Christoph Hellwig, Dan Williams, Dave Hansen,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170522143748.GC25118@quack2.suse.cz>
On Mon, May 22, 2017 at 04:37:48PM +0200, Jan Kara wrote:
> On Thu 18-05-17 15:29:39, Ross Zwisler wrote:
> > On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote:
> > > On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
<>
> > > The first scenario seems to be possible. dax_iomap_pmd_fault() will create
> > > PMD entry in the radix tree. Then dax_iomap_pte_fault() will come, do
> > > grab_mapping_entry(), there it sees entry is PMD but we are doing PTE fault
> > > so I'd think that pmd_downgrade = true... But actually the condition there
> > > doesn't trigger in this case. And that's a catch that although we asked
> > > grab_mapping_entry() for PTE, we've got PMD back and that screws us later.
> >
> > Yep, it was a concious decision when implementing the PMD support to allow one
> > thread to use PMDs and another to use PTEs in the same range, as long as the
> > thread faulting in PMDs is the first to insert into the radix tree. A PMD
> > radix tree entry will be inserted and used for locking and dirty tracking, and
> > each thread or process can fault in either PTEs or PMDs into its own address
> > space as needed.
>
> Well, for *threads* it doesn't really make good sense to mix PMDs and PTEs
> as they share page tables. However for *processes* it makes some sense to
> allow one process to use PTEs and another process to use PMDs. And I
> remember we were discussing this in the past.
Ugh, I was super sloppy with my use of "thread" and "process" in my previous
email. Sorry, and thanks for the clarifications. I think we're on the same
page, even if I had trouble articulating it. :)
> So normal fault path uses alloc_set_pte() for installing new PTE. And that
> uses pte_alloc_one_map() which checks whether PMD is still suitable for
> inserting a PTE. If not, we return VM_FAULT_NOPAGE. Probably it would be
> cleanest to factor our common parts of PTE and PMD insertion so that we can
> use these functions both from DAX and generic fault paths.
Makes sense, thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* patch "iio: trigger: fix NULL pointer dereference in" added to staging-linus
From: gregkh @ 2017-05-22 19:54 UTC (permalink / raw)
To: m.niestroj, Stable, jic23
This is a note to let you know that I've just added the patch titled
iio: trigger: fix NULL pointer dereference in
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 4eecbe81885180c9f6217ecfd679b1f285967218 Mon Sep 17 00:00:00 2001
From: Marcin Niestroj <m.niestroj@grinn-global.com>
Date: Thu, 18 May 2017 09:12:06 +0200
Subject: iio: trigger: fix NULL pointer dereference in
iio_trigger_write_current()
In case oldtrig == trig == NULL (which happens when we set none
trigger, when there is already none set) there is a NULL pointer
dereference during iio_trigger_put(trig). Below is kernel output when
this occurs:
[ 26.741790] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 26.750179] pgd = cacc0000
[ 26.752936] [00000000] *pgd=8adc6835, *pte=00000000, *ppte=00000000
[ 26.759531] Internal error: Oops: 17 [#1] SMP ARM
[ 26.764261] Modules linked in: usb_f_ncm u_ether usb_f_acm u_serial usb_f_fs libcomposite configfs evbug
[ 26.773844] CPU: 0 PID: 152 Comm: synchro Not tainted 4.12.0-rc1 #2
[ 26.780128] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 26.786329] task: cb1de200 task.stack: cac92000
[ 26.790892] PC is at iio_trigger_write_current+0x188/0x1f4
[ 26.796403] LR is at lock_release+0xf8/0x20c
[ 26.800696] pc : [<c0736f34>] lr : [<c016efb0>] psr: 600d0013
[ 26.800696] sp : cac93e30 ip : cac93db0 fp : cac93e5c
[ 26.812193] r10: c0e64fe8 r9 : 00000000 r8 : 00000001
[ 26.817436] r7 : cb190810 r6 : 00000010 r5 : 00000001 r4 : 00000000
[ 26.823982] r3 : 00000000 r2 : 00000000 r1 : cb1de200 r0 : 00000000
[ 26.830528] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 26.837683] Control: 10c5387d Table: 8acc006a DAC: 00000051
[ 26.843448] Process synchro (pid: 152, stack limit = 0xcac92210)
[ 26.849475] Stack: (0xcac93e30 to 0xcac94000)
[ 26.853857] 3e20: 00000001 c0736dac c054033c cae6b680
[ 26.862060] 3e40: cae6b680 00000000 00000001 cb3f8610 cac93e74 cac93e60 c054035c c0736db8
[ 26.870264] 3e60: 00000001 c054033c cac93e94 cac93e78 c029bf34 c0540348 00000000 00000000
[ 26.878469] 3e80: cb3f8600 cae6b680 cac93ed4 cac93e98 c029b320 c029bef0 00000000 00000000
[ 26.886672] 3ea0: 00000000 cac93f78 cb2d41fc caed3280 c029b214 cac93f78 00000001 000e20f8
[ 26.894874] 3ec0: 00000001 00000000 cac93f44 cac93ed8 c0221dcc c029b220 c0e1ca39 cb2d41fc
[ 26.903079] 3ee0: cac93f04 cac93ef0 c0183ef0 c0183ab0 cb2d41fc 00000000 cac93f44 cac93f08
[ 26.911282] 3f00: c0225eec c0183ebc 00000001 00000000 c0223728 00000000 c0245454 00000001
[ 26.919485] 3f20: 00000001 caed3280 000e20f8 cac93f78 000e20f8 00000001 cac93f74 cac93f48
[ 26.927690] 3f40: c0223680 c0221da4 c0246520 c0245460 caed3283 caed3280 00000000 00000000
[ 26.935893] 3f60: 000e20f8 00000001 cac93fa4 cac93f78 c0224520 c02235e4 00000000 00000000
[ 26.944096] 3f80: 00000001 000e20f8 00000001 00000004 c0107f84 cac92000 00000000 cac93fa8
[ 26.952299] 3fa0: c0107de0 c02244e8 00000001 000e20f8 0000000e 000e20f8 00000001 fbad2484
[ 26.960502] 3fc0: 00000001 000e20f8 00000001 00000004 beb6b698 00064260 0006421c beb6b4b4
[ 26.968705] 3fe0: 00000000 beb6b450 b6f219a0 b6e2f268 800d0010 0000000e cac93ff4 cac93ffc
[ 26.976896] Backtrace:
[ 26.979388] [<c0736dac>] (iio_trigger_write_current) from [<c054035c>] (dev_attr_store+0x20/0x2c)
[ 26.988289] r10:cb3f8610 r9:00000001 r8:00000000 r7:cae6b680 r6:cae6b680 r5:c054033c
[ 26.996138] r4:c0736dac r3:00000001
[ 26.999747] [<c054033c>] (dev_attr_store) from [<c029bf34>] (sysfs_kf_write+0x50/0x54)
[ 27.007686] r5:c054033c r4:00000001
[ 27.011290] [<c029bee4>] (sysfs_kf_write) from [<c029b320>] (kernfs_fop_write+0x10c/0x224)
[ 27.019579] r7:cae6b680 r6:cb3f8600 r5:00000000 r4:00000000
[ 27.025271] [<c029b214>] (kernfs_fop_write) from [<c0221dcc>] (__vfs_write+0x34/0x120)
[ 27.033214] r10:00000000 r9:00000001 r8:000e20f8 r7:00000001 r6:cac93f78 r5:c029b214
[ 27.041059] r4:caed3280
[ 27.043622] [<c0221d98>] (__vfs_write) from [<c0223680>] (vfs_write+0xa8/0x170)
[ 27.050959] r9:00000001 r8:000e20f8 r7:cac93f78 r6:000e20f8 r5:caed3280 r4:00000001
[ 27.058731] [<c02235d8>] (vfs_write) from [<c0224520>] (SyS_write+0x44/0x98)
[ 27.065806] r9:00000001 r8:000e20f8 r7:00000000 r6:00000000 r5:caed3280 r4:caed3283
[ 27.073582] [<c02244dc>] (SyS_write) from [<c0107de0>] (ret_fast_syscall+0x0/0x1c)
[ 27.081179] r9:cac92000 r8:c0107f84 r7:00000004 r6:00000001 r5:000e20f8 r4:00000001
[ 27.088947] Code: 1a000009 e1a04009 e3a06010 e1a05008 (e5943000)
[ 27.095244] ---[ end trace 06d1dab86d6e6bab ]---
To fix that problem call iio_trigger_put(trig) only when trig is not
NULL.
Fixes: d5d24bcc0a10 ("iio: trigger: close race condition in acquiring trigger reference")
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/iio/industrialio-trigger.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
index 978e1592c2a3..4061fed93f1f 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -451,7 +451,8 @@ static ssize_t iio_trigger_write_current(struct device *dev,
return len;
out_trigger_put:
- iio_trigger_put(trig);
+ if (trig)
+ iio_trigger_put(trig);
return ret;
}
--
2.13.0
^ permalink raw reply related
* patch "iio: light: ltr501 Fix interchanged als/ps register field" added to staging-linus
From: gregkh @ 2017-05-22 19:54 UTC (permalink / raw)
To: franziska.naepelt, Stable, jic23, pmeerw
This is a note to let you know that I've just added the patch titled
iio: light: ltr501 Fix interchanged als/ps register field
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7cc3bff4efe6164a0c8163331c8aa55454799f42 Mon Sep 17 00:00:00 2001
From: Franziska Naepelt <franziska.naepelt@idt.com>
Date: Wed, 17 May 2017 12:41:19 +0200
Subject: iio: light: ltr501 Fix interchanged als/ps register field
The register mapping for the IIO driver for the Liteon Light and Proximity
sensor LTR501 interrupt mode is interchanged (ALS/PS).
There is a register called INTERRUPT register (address 0x8F)
Bit 0 represents PS measurement trigger.
Bit 1 represents ALS measurement trigger.
This two bit fields are interchanged within the driver.
see datasheet page 24:
http://optoelectronics.liteon.com/upload/download/DS86-2012-0006/S_110_LTR-501ALS-01_PrelimDS_ver1%5B1%5D.pdf
Signed-off-by: Franziska Naepelt <franziska.naepelt@idt.com>
Fixes: 7ac702b3144b6 ("iio: ltr501: Add interrupt support")
Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/iio/light/ltr501.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index b30e0c1c6cc4..67838edd8b37 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -74,9 +74,9 @@ static const int int_time_mapping[] = {100000, 50000, 200000, 400000};
static const struct reg_field reg_field_it =
REG_FIELD(LTR501_ALS_MEAS_RATE, 3, 4);
static const struct reg_field reg_field_als_intr =
- REG_FIELD(LTR501_INTR, 0, 0);
-static const struct reg_field reg_field_ps_intr =
REG_FIELD(LTR501_INTR, 1, 1);
+static const struct reg_field reg_field_ps_intr =
+ REG_FIELD(LTR501_INTR, 0, 0);
static const struct reg_field reg_field_als_rate =
REG_FIELD(LTR501_ALS_MEAS_RATE, 0, 2);
static const struct reg_field reg_field_ps_rate =
--
2.13.0
^ permalink raw reply related
* Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Marek Vasut @ 2017-05-22 20:33 UTC (permalink / raw)
To: Fabio Estevam
Cc: Fabio Estevam, Stefan Agner, Sascha Hauer, DRI mailing list,
stable
In-Reply-To: <CAOMZO5AW=gmxn6GQr=wE00SdYHea0+6mboxhCo389-xCE0ZxFw@mail.gmail.com>
On 05/22/2017 08:52 PM, Fabio Estevam wrote:
> Hi Marek,
Hi!
> 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?
You could probably get it in via drm-misc ?
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: FAILED: patch "[PATCH] of: fdt: add missing allocation-failure check" failed to apply to 4.4-stable tree
From: Rob Herring @ 2017-05-22 20:46 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Johan Hovold, stable
In-Reply-To: <14954806628916@kroah.com>
On Mon, May 22, 2017 at 2:17 PM, <gregkh@linuxfoundation.org> wrote:
>
> 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,
The context looks the same, it's just the line number is 416 in v4.4.
>
> /* 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
* [PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam @ 2017-05-22 20:53 UTC (permalink / raw)
To: daniel; +Cc: marex, dri-devel, Fabio Estevam, #4 . 11 . x
From: Fabio Estevam <fabio.estevam@nxp.com>
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc: <stable@vger.kernel.org> #4.11.x
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Daniel,
Marek suggested that this goes via drm-misc.
Thanks
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 ++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..0abe776 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset */
+#define RESET_TIMEOUT 1000000
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ u32 reg;
+
+ writel(mask, addr + MXS_CLR_ADDR);
+ return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ /* Mandatory eLCDIF reset as per the Reference Manual */
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
^ permalink raw reply related
* + slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch added to -mm tree
From: akpm @ 2017-05-22 21:29 UTC (permalink / raw)
To: tglx, cl, hannes, hch, iamjoonsoo.kim, mhocko, penberg, peterz,
rientjes, rostedt, stable, mm-commits
The patch titled
Subject: slub/memcg: cure the brainless abuse of sysfs attributes
has been added to the -mm tree. Its filename is
slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Thomas Gleixner <tglx@linutronix.de>
Subject: slub/memcg: cure the brainless abuse of sysfs attributes
memcg_propagate_slab_attrs() abuses the sysfs attribute file functions to
propagate settings from the root kmem_cache to a newly created kmem_cache.
It does that with:
attr->show(root, buf);
attr->store(new, buf, strlen(bug);
Aside of being a lazy and absurd hackery this is broken because it does
not check the return value of the show() function.
Some of the show() functions return 0 w/o touching the buffer. That means
in such a case the store function is called with the stale content of the
previous show(). That causes nonsense like invoking kmem_cache_shrink()
on a newly created kmem_cache. In the worst case it would cause handing
in an uninitialized buffer.
This should be rewritten proper by adding a propagate() callback to those
slub_attributes which must be propagated and avoid that insane conversion
to and from ASCII, but that's too large for a hot fix.
Check at least the return value of the show() function, so calling store()
with stale content is prevented.
Steven said:
: It can cause a deadlock with get_online_cpus() that has been uncovered
: by recent cpu hotplug and lockdep changes that Thomas and Peter have
: been doing.
:
: [ 102.567308] Possible unsafe locking scenario:
: [ 102.567308]
: [ 102.574846] CPU0 CPU1
: [ 102.580148] ---- ----
: [ 102.585421] lock(cpu_hotplug.lock);
: [ 102.589808] lock(slab_mutex);
: [ 102.596166] lock(cpu_hotplug.lock);
: [ 102.603028] lock(slab_mutex);
: [ 102.606846]
: [ 102.606846] *** DEADLOCK ***
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1705201244540.2255@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/slub.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff -puN mm/slub.c~slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes mm/slub.c
--- a/mm/slub.c~slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes
+++ a/mm/slub.c
@@ -5512,6 +5512,7 @@ static void memcg_propagate_slab_attrs(s
char mbuf[64];
char *buf;
struct slab_attribute *attr = to_slab_attr(slab_attrs[i]);
+ ssize_t len;
if (!attr || !attr->store || !attr->show)
continue;
@@ -5536,8 +5537,9 @@ static void memcg_propagate_slab_attrs(s
buf = buffer;
}
- attr->show(root_cache, buf);
- attr->store(s, buf, strlen(buf));
+ len = attr->show(root_cache, buf);
+ if (len > 0)
+ attr->store(s, buf, len);
}
if (buffer)
_
Patches currently in -mm which might be from tglx@linutronix.de are
slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch
^ permalink raw reply
* + pcmcia-remove-left-over-%z-format.patch added to -mm tree
From: akpm @ 2017-05-22 21:30 UTC (permalink / raw)
To: nicolas.iooss_linux, adobriyan, laforge, stable, mm-commits
The patch titled
Subject: pcmcia: remove left-over %Z format
has been added to the -mm tree. Its filename is
pcmcia-remove-left-over-%z-format.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/pcmcia-remove-left-over-%25z-format.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/pcmcia-remove-left-over-%25z-format.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Subject: pcmcia: remove left-over %Z format
5b5e0928f742 ("lib/vsprintf.c: remove %Z support") removed some usages of
format %Z but forgot "%.2Zx". This makes clang 4.0 reports a
-Wformat-extra-args warning because it does not know about %Z.
Replace %Z with %z.
Link: http://lkml.kernel.org/r/20170520090946.22562-1-nicolas.iooss_linux@m4x.org
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: Harald Welte <laforge@gnumonks.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: <stable@vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/char/pcmcia/cm4040_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/char/pcmcia/cm4040_cs.c~pcmcia-remove-left-over-%z-format drivers/char/pcmcia/cm4040_cs.c
--- a/drivers/char/pcmcia/cm4040_cs.c~pcmcia-remove-left-over-%z-format
+++ a/drivers/char/pcmcia/cm4040_cs.c
@@ -374,7 +374,7 @@ static ssize_t cm4040_write(struct file
rc = write_sync_reg(SCR_HOST_TO_READER_START, dev);
if (rc <= 0) {
- DEBUGP(5, dev, "write_sync_reg c=%.2Zx\n", rc);
+ DEBUGP(5, dev, "write_sync_reg c=%.2zx\n", rc);
DEBUGP(2, dev, "<- cm4040_write (failed)\n");
if (rc == -ERESTARTSYS)
return rc;
@@ -387,7 +387,7 @@ static ssize_t cm4040_write(struct file
for (i = 0; i < bytes_to_write; i++) {
rc = wait_for_bulk_out_ready(dev);
if (rc <= 0) {
- DEBUGP(5, dev, "wait_for_bulk_out_ready rc=%.2Zx\n",
+ DEBUGP(5, dev, "wait_for_bulk_out_ready rc=%.2zx\n",
rc);
DEBUGP(2, dev, "<- cm4040_write (failed)\n");
if (rc == -ERESTARTSYS)
@@ -403,7 +403,7 @@ static ssize_t cm4040_write(struct file
rc = write_sync_reg(SCR_HOST_TO_READER_DONE, dev);
if (rc <= 0) {
- DEBUGP(5, dev, "write_sync_reg c=%.2Zx\n", rc);
+ DEBUGP(5, dev, "write_sync_reg c=%.2zx\n", rc);
DEBUGP(2, dev, "<- cm4040_write (failed)\n");
if (rc == -ERESTARTSYS)
return rc;
_
Patches currently in -mm which might be from nicolas.iooss_linux@m4x.org are
pcmcia-remove-left-over-%z-format.patch
^ permalink raw reply
* + mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once.patch added to -mm tree
From: akpm @ 2017-05-22 21:55 UTC (permalink / raw)
To: penguin-kernel, guro, hannes, mhocko, stable, vdavydov.dev,
mm-commits
The patch titled
Subject: mm/page_alloc.c: make sure OOM victim can try allocations with no watermarks once
has been added to the -mm tree. Its filename is
mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: mm/page_alloc.c: make sure OOM victim can try allocations with no watermarks once
Roman Gushchin has reported that the OOM killer can trivially selects next
OOM victim when a thread doing memory allocation from page fault path was
selected as first OOM victim.
----------
[ 25.721494] allocate invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
[ 25.725658] allocate cpuset=/ mems_allowed=0
[ 25.727033] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.729215] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.729598] Call Trace:
[ 25.729598] dump_stack+0x63/0x82
[ 25.729598] dump_header+0x97/0x21a
[ 25.729598] ? do_try_to_free_pages+0x2d7/0x360
[ 25.729598] ? security_capable_noaudit+0x45/0x60
[ 25.729598] oom_kill_process+0x219/0x3e0
[ 25.729598] out_of_memory+0x11d/0x480
[ 25.729598] __alloc_pages_slowpath+0xc84/0xd40
[ 25.729598] __alloc_pages_nodemask+0x245/0x260
[ 25.729598] alloc_pages_vma+0xa2/0x270
[ 25.729598] __handle_mm_fault+0xca9/0x10c0
[ 25.729598] handle_mm_fault+0xf3/0x210
[ 25.729598] __do_page_fault+0x240/0x4e0
[ 25.729598] trace_do_page_fault+0x37/0xe0
[ 25.729598] do_async_page_fault+0x19/0x70
[ 25.729598] async_page_fault+0x28/0x30
(...snipped...)
[ 25.781882] Out of memory: Kill process 492 (allocate) score 899 or sacrifice child
[ 25.783874] Killed process 492 (allocate) total-vm:2052368kB, anon-rss:1894576kB, file-rss:4kB, shmem-rss:0kB
[ 25.785680] allocate: page allocation failure: order:0, mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null)
[ 25.786797] allocate cpuset=/ mems_allowed=0
[ 25.787246] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.787935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.788867] Call Trace:
[ 25.789119] dump_stack+0x63/0x82
[ 25.789451] warn_alloc+0x114/0x1b0
[ 25.789451] __alloc_pages_slowpath+0xd32/0xd40
[ 25.789451] __alloc_pages_nodemask+0x245/0x260
[ 25.789451] alloc_pages_vma+0xa2/0x270
[ 25.789451] __handle_mm_fault+0xca9/0x10c0
[ 25.789451] handle_mm_fault+0xf3/0x210
[ 25.789451] __do_page_fault+0x240/0x4e0
[ 25.789451] trace_do_page_fault+0x37/0xe0
[ 25.789451] do_async_page_fault+0x19/0x70
[ 25.789451] async_page_fault+0x28/0x30
(...snipped...)
[ 25.810868] oom_reaper: reaped process 492 (allocate), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
(...snipped...)
[ 25.817589] allocate invoked oom-killer: gfp_mask=0x0(), nodemask=(null), order=0, oom_score_adj=0
[ 25.818821] allocate cpuset=/ mems_allowed=0
[ 25.819259] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.819847] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.820549] Call Trace:
[ 25.820733] dump_stack+0x63/0x82
[ 25.820961] dump_header+0x97/0x21a
[ 25.820961] ? security_capable_noaudit+0x45/0x60
[ 25.820961] oom_kill_process+0x219/0x3e0
[ 25.820961] out_of_memory+0x11d/0x480
[ 25.820961] pagefault_out_of_memory+0x68/0x80
[ 25.820961] mm_fault_error+0x8f/0x190
[ 25.820961] ? handle_mm_fault+0xf3/0x210
[ 25.820961] __do_page_fault+0x4b2/0x4e0
[ 25.820961] trace_do_page_fault+0x37/0xe0
[ 25.820961] do_async_page_fault+0x19/0x70
[ 25.820961] async_page_fault+0x28/0x30
(...snipped...)
[ 25.863078] Out of memory: Kill process 233 (firewalld) score 10 or sacrifice child
[ 25.863634] Killed process 233 (firewalld) total-vm:246076kB, anon-rss:20956kB, file-rss:0kB, shmem-rss:0kB
----------
There is a race window that the OOM reaper completes reclaiming the first
victim's memory while nothing but mutex_trylock() prevents the first
victim from calling out_of_memory() from pagefault_out_of_memory() after
memory allocation for page fault path failed due to being selected as an
OOM victim.
This is a side effect of commit 9a67f6488eca926f ("mm: consolidate
GFP_NOFAIL checks in the allocator slowpath") because that commit silently
changed the behavior from
/* Avoid allocations with no watermarks from looping endlessly */
to
/*
* Give up allocations without trying memory reserves if selected
* as an OOM victim
*/
in __alloc_pages_slowpath() by moving the location to check TIF_MEMDIE
flag. I have noticed this change but I didn't post a patch because I
thought it is an acceptable change other than noise by warn_alloc()
because !__GFP_NOFAIL allocations are allowed to fail. But we overlooked
that failing memory allocation from page fault path makes difference due
to the race window explained above.
While it might be possible to add a check to pagefault_out_of_memory()
that prevents the first victim from calling out_of_memory() or remove
out_of_memory() from pagefault_out_of_memory(), changing
pagefault_out_of_memory() does not suppress noise by warn_alloc() when
allocating thread was selected as an OOM victim. There is little point
with printing similar backtraces and memory information from both
out_of_memory() and warn_alloc().
Instead, if we guarantee that current thread can try allocations with no
watermarks once when current thread looping inside
__alloc_pages_slowpath() was selected as an OOM victim, we can follow "who
can use memory reserves" rules and suppress noise by warn_alloc() and
prevent memory allocations from page fault path from calling
pagefault_out_of_memory().
If we take the comment literally, this patch would do
: - if (test_thread_flag(TIF_MEMDIE))
: - goto nopage;
: + if (alloc_flags == ALLOC_NO_WATERMARKS || (gfp_mask & __GFP_NOMEMALLOC))
: + goto nopage;
because gfp_pfmemalloc_allowed() returns false if __GFP_NOMEMALLOC is
given. But if I recall correctly (I couldn't find the message), the
condition is meant to apply to only OOM victims despite the comment.
Therefore, this patch preserves TIF_MEMDIE check.
Fixes: 9a67f6488eca926f ("mm: consolidate GFP_NOFAIL checks in the allocator slowpath")
Link: http://lkml.kernel.org/r/201705192112.IAF69238.OQOHSJLFOFFMtV@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: Roman Gushchin <guro@fb.com>
Tested-by: Roman Gushchin <guro@fb.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: <stable@vger.kernel.org> [4.11]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/page_alloc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN mm/page_alloc.c~mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once mm/page_alloc.c
--- a/mm/page_alloc.c~mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once
+++ a/mm/page_alloc.c
@@ -3870,7 +3870,9 @@ retry:
goto got_pg;
/* Avoid allocations with no watermarks from looping endlessly */
- if (test_thread_flag(TIF_MEMDIE))
+ if (test_thread_flag(TIF_MEMDIE) &&
+ (alloc_flags == ALLOC_NO_WATERMARKS ||
+ (gfp_mask & __GFP_NOMEMALLOC)))
goto nopage;
/* Retry as long as the OOM killer is making progress */
_
Patches currently in -mm which might be from penguin-kernel@I-love.SAKURA.ne.jp are
mmpage_alloc-make-sure-oom-victim-can-try-allocations-with-no-watermarks-once.patch
^ permalink raw reply
* [PATCH v2 1/2] mm: avoid spurious 'bad pmd' warning messages
From: Ross Zwisler @ 2017-05-22 21:57 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
Cc: Ross Zwisler, Darrick J. Wong, Alexander Viro, Christoph Hellwig,
Dan Williams, Dave Hansen, Jan Kara, Matthew Wilcox,
linux-fsdevel, linux-mm, linux-nvdimm, Kirill A . Shutemov,
Pawel Lebioda, Dave Jiang, Xiong Zhou, Eryu Guan, stable
When the pmd_devmap() checks were added by:
commit 5c7fb56e5e3f ("mm, dax: dax-pmd vs thp-pmd vs hugetlbfs-pmd")
to add better support for DAX huge pages, they were all added to the end of
if() statements after existing pmd_trans_huge() checks. So, things like:
- if (pmd_trans_huge(*pmd))
+ if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
When further checks were added after pmd_trans_unstable() checks by:
commit 7267ec008b5c ("mm: postpone page table allocation until we have page
to map")
they were also added at the end of the conditional:
+ if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
This ordering is fine for pmd_trans_huge(), but doesn't work for
pmd_trans_unstable(). This is because DAX huge pages trip the bad_pmd()
check inside of pmd_none_or_trans_huge_or_clear_bad() (called by
pmd_trans_unstable()), which prints out a warning and returns 1. So, we do
end up doing the right thing, but only after spamming dmesg with suspicious
looking messages:
mm/pgtable-generic.c:39: bad pmd ffff8808daa49b88(84000001006000a5)
Reorder these checks in a helper so that pmd_devmap() is checked first,
avoiding the error messages, and add a comment explaining why the ordering
is important.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Fixes: commit 7267ec008b5c ("mm: postpone page table allocation until we have page to map")
Cc: stable@vger.kernel.org
---
Changes from v1:
- Break the checks out into the new pmd_devmap_trans_unstable() helper and
add a comment about the ordering (Dave). I ended up keeping this helper
in mm/memory.c because I didn't see an obvious header where it would
live happily. pmd_devmap() is either defined in
arch/x86/include/asm/pgtable.h or in include/linux/mm.h depending on
__HAVE_ARCH_PTE_DEVMAP and CONFIG_TRANSPARENT_HUGEPAGE, and
pmd_trans_unstable() is defined in include/asm-generic/pgtable.h.
- Add a comment explaining why pte_alloc_one_map() doesn't suffer from races.
This was the result of a conversation with Dave Hansen.
---
mm/memory.c | 40 ++++++++++++++++++++++++++++++----------
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 6ff5d72..2e65df1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3029,6 +3029,17 @@ static int __do_fault(struct vm_fault *vmf)
return ret;
}
+/*
+ * The ordering of these checks is important for pmds with _PAGE_DEVMAP set.
+ * If we check pmd_trans_unstable() first we will trip the bad_pmd() check
+ * inside of pmd_none_or_trans_huge_or_clear_bad(). This will end up correctly
+ * returning 1 but not before it spams dmesg with the pmd_clear_bad() output.
+ */
+static int pmd_devmap_trans_unstable(pmd_t *pmd)
+{
+ return pmd_devmap(*pmd) || pmd_trans_unstable(pmd);
+}
+
static int pte_alloc_one_map(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
@@ -3052,18 +3063,27 @@ static int pte_alloc_one_map(struct vm_fault *vmf)
map_pte:
/*
* If a huge pmd materialized under us just retry later. Use
- * pmd_trans_unstable() instead of pmd_trans_huge() to ensure the pmd
- * didn't become pmd_trans_huge under us and then back to pmd_none, as
- * a result of MADV_DONTNEED running immediately after a huge pmd fault
- * in a different thread of this mm, in turn leading to a misleading
- * pmd_trans_huge() retval. All we have to ensure is that it is a
- * regular pmd that we can walk with pte_offset_map() and we can do that
- * through an atomic read in C, which is what pmd_trans_unstable()
- * provides.
+ * pmd_trans_unstable() via pmd_devmap_trans_unstable() instead of
+ * pmd_trans_huge() to ensure the pmd didn't become pmd_trans_huge
+ * under us and then back to pmd_none, as a result of MADV_DONTNEED
+ * running immediately after a huge pmd fault in a different thread of
+ * this mm, in turn leading to a misleading pmd_trans_huge() retval.
+ * All we have to ensure is that it is a regular pmd that we can walk
+ * with pte_offset_map() and we can do that through an atomic read in
+ * C, which is what pmd_trans_unstable() provides.
*/
- if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf->pmd))
+ if (pmd_devmap_trans_unstable(vmf->pmd))
return VM_FAULT_NOPAGE;
+ /*
+ * At this point we know that our vmf->pmd points to a page of ptes
+ * and it cannot become pmd_none(), pmd_devmap() or pmd_trans_huge()
+ * for the duration of the fault. If a racing MADV_DONTNEED runs and
+ * we zap the ptes pointed to by our vmf->pmd, the vmf->ptl will still
+ * be valid and we will re-check to make sure the vmf->pte isn't
+ * pte_none() under vmf->ptl protection when we return to
+ * alloc_set_pte().
+ */
vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
&vmf->ptl);
return 0;
@@ -3690,7 +3710,7 @@ static int handle_pte_fault(struct vm_fault *vmf)
vmf->pte = NULL;
} else {
/* See comment in pte_alloc_one_map() */
- if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf->pmd))
+ if (pmd_devmap_trans_unstable(vmf->pmd))
return 0;
/*
* A regular pmd is established and it can't morph into a huge
--
2.9.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v2 2/2] dax: Fix race between colliding PMD & PTE entries
From: Ross Zwisler @ 2017-05-22 21:57 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
Cc: Ross Zwisler, Darrick J. Wong, Alexander Viro, Christoph Hellwig,
Dan Williams, Dave Hansen, Jan Kara, Matthew Wilcox,
linux-fsdevel, linux-mm, linux-nvdimm, Kirill A . Shutemov,
Pawel Lebioda, Dave Jiang, Xiong Zhou, Eryu Guan, stable
In-Reply-To: <20170522215749.23516-1-ross.zwisler@linux.intel.com>
We currently have two related PMD vs PTE races in the DAX code. These can
both be easily triggered by having two threads reading and writing
simultaneously to the same private mapping, with the key being that private
mapping reads can be handled with PMDs but private mapping writes are
always handled with PTEs so that we can COW.
Here is the first race:
CPU 0 CPU 1
(private mapping write)
__handle_mm_fault()
create_huge_pmd() - FALLBACK
handle_pte_fault()
passes check for pmd_devmap()
(private mapping read)
__handle_mm_fault()
create_huge_pmd()
dax_iomap_pmd_fault() inserts PMD
dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
installed in our page tables at this spot.
Here's the second race:
CPU 0 CPU 1
(private mapping read)
__handle_mm_fault()
passes check for pmd_none()
create_huge_pmd()
dax_iomap_pmd_fault() inserts PMD
(private mapping write)
__handle_mm_fault()
create_huge_pmd() - FALLBACK
(private mapping read)
__handle_mm_fault()
passes check for pmd_none()
create_huge_pmd()
handle_pte_fault()
dax_iomap_pte_fault() inserts PTE
dax_iomap_pmd_fault() inserts PMD,
but we already have a PTE at
this spot.
The core of the issue is that while there is isolation between faults to
the same range in the DAX fault handlers via our DAX entry locking, there
is no isolation between faults in the code in mm/memory.c. This means for
instance that this code in __handle_mm_fault() can run:
if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
ret = create_huge_pmd(&vmf);
But by the time we actually get to run the fault handler called by
create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
fault has installed a normal PMD here as a parent. This is the cause of
the 2nd race. The first race is similar - there is the following check in
handle_pte_fault():
} else {
/* See comment in pte_alloc_one_map() */
if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
return 0;
So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
will bail and retry the fault. This is correct, but there is nothing
preventing the PMD from being installed after this check but before we
actually get to the DAX PTE fault handlers.
In my testing these races result in the following types of errors:
BUG: Bad rss-counter state mm:ffff8800a817d280 idx:1 val:1
BUG: non-zero nr_ptes on freeing mm: 15
Fix this issue by having the DAX fault handlers verify that it is safe to
continue their fault after they have taken an entry lock to block other
racing faults.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Pawel Lebioda <pawel.lebioda@intel.com>
Cc: stable@vger.kernel.org
---
Changes from v1:
- Handle the failure case in dax_iomap_pte_fault() by retrying the fault
(Jan).
This series has survived my new xfstest (generic/437) and full xfstest
regression testing runs.
---
fs/dax.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/fs/dax.c b/fs/dax.c
index c22eaf1..fc62f36 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1155,6 +1155,17 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
}
/*
+ * It is possible, particularly with mixed reads & writes to private
+ * mappings, that we have raced with a PMD fault that overlaps with
+ * the PTE we need to set up. If so just return and the fault will be
+ * retried.
+ */
+ if (pmd_devmap(*vmf->pmd)) {
+ vmf_ret = VM_FAULT_NOPAGE;
+ goto unlock_entry;
+ }
+
+ /*
* Note that we don't bother to use iomap_apply here: DAX required
* the file system block size to be equal the page size, which means
* that we never have to deal with more than a single extent here.
@@ -1398,6 +1409,15 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
goto fallback;
/*
+ * It is possible, particularly with mixed reads & writes to private
+ * mappings, that we have raced with a PTE fault that overlaps with
+ * the PMD we need to set up. If so we just fall back to a PTE fault
+ * ourselves.
+ */
+ if (!pmd_none(*vmf->pmd))
+ goto unlock_entry;
+
+ /*
* Note that we don't use iomap_apply here. We aren't doing I/O, only
* setting up a mapping, so really we're using iomap_begin() as a way
* to look up our filesystem block.
--
2.9.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: Patch "drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one" has been added to the 4.9-stable tree
From: Ilia Mirkin @ 2017-05-22 22:57 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Ben Skeggs, # 3.9+, stable-commits
In-Reply-To: <1495472681204139@kroah.com>
Hi Greg,
This patch appears to have misapplied. I'm not sure why cherry-pick
got it wrong, but this is meant to go in the nv4a_chipset definition,
not nv44_chipset.
This comment also applies to the 4.4 and 4.11 cherry-picks you just did.
Thanks,
-ilia
On Mon, May 22, 2017 at 1:04 PM, <gregkh@linuxfoundation.org> wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 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:
> drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-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 ac799acaa4d8db4f7dcd968b15c9596c80a4677f Mon Sep 17 00:00:00 2001
> From: Ilia Mirkin <imirkin@alum.mit.edu>
> Date: Sat, 18 Mar 2017 16:23:10 -0400
> Subject: drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one
>
> From: Ilia Mirkin <imirkin@alum.mit.edu>
>
> commit ac799acaa4d8db4f7dcd968b15c9596c80a4677f upstream.
>
> The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
> and PCI varieties, rather than a core PCIE chip with a bridge for
> AGP/PCI as necessary. As a result, it appears that the MMU is also
> non-functional. For AGP cards, the vast majority of the NV4A lineup,
> this worked out since we force AGP cards to use the nv04 mmu. However
> for PCI variants, this did not work.
>
> Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
> the suggestion. This should be a no-op for NV4A AGP boards, as they were
> using it already.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -584,7 +584,7 @@ nv44_chipset = {
> .i2c = nv04_i2c_new,
> .imem = nv40_instmem_new,
> .mc = nv44_mc_new,
> - .mmu = nv44_mmu_new,
> + .mmu = nv04_mmu_new,
> .pci = nv40_pci_new,
> .therm = nv40_therm_new,
> .timer = nv41_timer_new,
>
>
> Patches currently in stable-queue which might be from imirkin@alum.mit.edu are
>
> queue-4.9/drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch
^ permalink raw reply
* [PATCH 1/2] ext4 crypto: don't let data integrity writebacks fail with ENOMEM
From: Eric Biggers @ 2017-05-22 23:37 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, Theodore Ts'o, Eric Biggers
From: Theodore Ts'o <tytso@mit.edu>
commit c9af28fdd44922a6c10c9f8315718408af98e315 upstream. [Please apply
to 4.4-stable. This fixes a bug which has caused problems on both
Android and Chrome OS, and this fix has already been included in a
number of ext4 encryption backports.]
We don't want the writeback triggered from the journal commit (in
data=writeback mode) to cause the journal to abort due to
generic_writepages() returning an ENOMEM error. In addition, if
fsync() fails with ENOMEM, most applications will probably not do the
right thing.
So if we are doing a data integrity sync, and ext4_encrypt() returns
ENOMEM, we will submit any queued I/O to date, and then retry the
allocation using GFP_NOFAIL.
Google-Bug-Id: 27641567
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
fs/ext4/crypto.c | 37 +++++++++++++++++++++----------------
fs/ext4/ext4.h | 6 ++++--
fs/ext4/page-io.c | 14 +++++++++++++-
fs/ext4/readpage.c | 2 +-
4 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c
index 9d6c2dcf1bd0..f240cef8b326 100644
--- a/fs/ext4/crypto.c
+++ b/fs/ext4/crypto.c
@@ -94,7 +94,8 @@ void ext4_release_crypto_ctx(struct ext4_crypto_ctx *ctx)
* Return: An allocated and initialized encryption context on success; error
* value or NULL otherwise.
*/
-struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode)
+struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode,
+ gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx = NULL;
int res = 0;
@@ -121,7 +122,7 @@ struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode)
list_del(&ctx->free_list);
spin_unlock_irqrestore(&ext4_crypto_ctx_lock, flags);
if (!ctx) {
- ctx = kmem_cache_zalloc(ext4_crypto_ctx_cachep, GFP_NOFS);
+ ctx = kmem_cache_zalloc(ext4_crypto_ctx_cachep, gfp_flags);
if (!ctx) {
res = -ENOMEM;
goto out;
@@ -258,7 +259,8 @@ static int ext4_page_crypto(struct inode *inode,
ext4_direction_t rw,
pgoff_t index,
struct page *src_page,
- struct page *dest_page)
+ struct page *dest_page,
+ gfp_t gfp_flags)
{
u8 xts_tweak[EXT4_XTS_TWEAK_SIZE];
@@ -269,7 +271,7 @@ static int ext4_page_crypto(struct inode *inode,
struct crypto_ablkcipher *tfm = ci->ci_ctfm;
int res = 0;
- req = ablkcipher_request_alloc(tfm, GFP_NOFS);
+ req = ablkcipher_request_alloc(tfm, gfp_flags);
if (!req) {
printk_ratelimited(KERN_ERR
"%s: crypto_request_alloc() failed\n",
@@ -310,9 +312,10 @@ static int ext4_page_crypto(struct inode *inode,
return 0;
}
-static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx)
+static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx,
+ gfp_t gfp_flags)
{
- ctx->w.bounce_page = mempool_alloc(ext4_bounce_page_pool, GFP_NOWAIT);
+ ctx->w.bounce_page = mempool_alloc(ext4_bounce_page_pool, gfp_flags);
if (ctx->w.bounce_page == NULL)
return ERR_PTR(-ENOMEM);
ctx->flags |= EXT4_WRITE_PATH_FL;
@@ -335,7 +338,8 @@ static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx)
* error value or NULL.
*/
struct page *ext4_encrypt(struct inode *inode,
- struct page *plaintext_page)
+ struct page *plaintext_page,
+ gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx;
struct page *ciphertext_page = NULL;
@@ -343,17 +347,17 @@ struct page *ext4_encrypt(struct inode *inode,
BUG_ON(!PageLocked(plaintext_page));
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, gfp_flags);
if (IS_ERR(ctx))
return (struct page *) ctx;
/* The encryption operation will require a bounce page. */
- ciphertext_page = alloc_bounce_page(ctx);
+ ciphertext_page = alloc_bounce_page(ctx, gfp_flags);
if (IS_ERR(ciphertext_page))
goto errout;
ctx->w.control_page = plaintext_page;
err = ext4_page_crypto(inode, EXT4_ENCRYPT, plaintext_page->index,
- plaintext_page, ciphertext_page);
+ plaintext_page, ciphertext_page, gfp_flags);
if (err) {
ciphertext_page = ERR_PTR(err);
errout:
@@ -381,8 +385,8 @@ int ext4_decrypt(struct page *page)
{
BUG_ON(!PageLocked(page));
- return ext4_page_crypto(page->mapping->host,
- EXT4_DECRYPT, page->index, page, page);
+ return ext4_page_crypto(page->mapping->host, EXT4_DECRYPT,
+ page->index, page, page, GFP_NOFS);
}
int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex)
@@ -403,11 +407,11 @@ int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex)
BUG_ON(inode->i_sb->s_blocksize != PAGE_CACHE_SIZE);
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, GFP_NOFS);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ciphertext_page = alloc_bounce_page(ctx);
+ ciphertext_page = alloc_bounce_page(ctx, GFP_NOWAIT);
if (IS_ERR(ciphertext_page)) {
err = PTR_ERR(ciphertext_page);
goto errout;
@@ -415,11 +419,12 @@ int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex)
while (len--) {
err = ext4_page_crypto(inode, EXT4_ENCRYPT, lblk,
- ZERO_PAGE(0), ciphertext_page);
+ ZERO_PAGE(0), ciphertext_page,
+ GFP_NOFS);
if (err)
goto errout;
- bio = bio_alloc(GFP_KERNEL, 1);
+ bio = bio_alloc(GFP_NOWAIT, 1);
if (!bio) {
err = -ENOMEM;
goto errout;
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 3de9bb357b4f..c8ad14c697c4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2261,11 +2261,13 @@ extern struct kmem_cache *ext4_crypt_info_cachep;
bool ext4_valid_contents_enc_mode(uint32_t mode);
uint32_t ext4_validate_encryption_key_size(uint32_t mode, uint32_t size);
extern struct workqueue_struct *ext4_read_workqueue;
-struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode);
+struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode,
+ gfp_t gfp_flags);
void ext4_release_crypto_ctx(struct ext4_crypto_ctx *ctx);
void ext4_restore_control_page(struct page *data_page);
struct page *ext4_encrypt(struct inode *inode,
- struct page *plaintext_page);
+ struct page *plaintext_page,
+ gfp_t gfp_flags);
int ext4_decrypt(struct page *page);
int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex);
extern const struct dentry_operations ext4_encrypted_d_ops;
diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index 17fbe3882b8e..5c72ae5d62a6 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/mm.h>
+#include <linux/backing-dev.h>
#include "ext4_jbd2.h"
#include "xattr.h"
@@ -485,9 +486,20 @@ int ext4_bio_write_page(struct ext4_io_submit *io,
if (ext4_encrypted_inode(inode) && S_ISREG(inode->i_mode) &&
nr_to_submit) {
- data_page = ext4_encrypt(inode, page);
+ gfp_t gfp_flags = GFP_NOFS;
+
+ retry_encrypt:
+ data_page = ext4_encrypt(inode, page, gfp_flags);
if (IS_ERR(data_page)) {
ret = PTR_ERR(data_page);
+ if (ret == ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
+ if (io->io_bio) {
+ ext4_io_submit(io);
+ congestion_wait(BLK_RW_ASYNC, HZ/50);
+ }
+ gfp_flags |= __GFP_NOFAIL;
+ goto retry_encrypt;
+ }
data_page = NULL;
goto out;
}
diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index 5dc5e95063de..bc7642f57dc8 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -279,7 +279,7 @@ int ext4_mpage_readpages(struct address_space *mapping,
if (ext4_encrypted_inode(inode) &&
S_ISREG(inode->i_mode)) {
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, GFP_NOFS);
if (IS_ERR(ctx))
goto set_error_page;
}
--
2.13.0.303.g4ebf302169-goog
^ permalink raw reply related
* [PATCH 2/2] ext4 crypto: fix some error handling
From: Eric Biggers @ 2017-05-22 23:37 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, Dan Carpenter, Theodore Ts'o,
Eric Biggers
In-Reply-To: <20170522233752.109220-1-ebiggers3@gmail.com>
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 4762cc3fbbd89e5fd316d6e4d3244a8984444f8d upstream. Please apply
to 4.4-stable.
We should be testing for -ENOMEM but the minus sign is missing.
Fixes: c9af28fdd449 ('ext4 crypto: don't let data integrity writebacks fail with ENOMEM')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
fs/ext4/page-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index 5c72ae5d62a6..6ca56f5f72b5 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -492,7 +492,7 @@ int ext4_bio_write_page(struct ext4_io_submit *io,
data_page = ext4_encrypt(inode, page, gfp_flags);
if (IS_ERR(data_page)) {
ret = PTR_ERR(data_page);
- if (ret == ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
+ if (ret == -ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
if (io->io_bio) {
ext4_io_submit(io);
congestion_wait(BLK_RW_ASYNC, HZ/50);
--
2.13.0.303.g4ebf302169-goog
^ permalink raw reply related
* Re: Patch "drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one" has been added to the 4.9-stable tree
From: Ilia Mirkin @ 2017-05-22 23:49 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Ben Skeggs, # 3.9+, stable-commits
In-Reply-To: <CAKb7UviDqxgCinqCRewvayHt1OubTBQiKAZj7xJno86uuCx0yQ@mail.gmail.com>
On Mon, May 22, 2017 at 6:57 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> Hi Greg,
>
> This patch appears to have misapplied. I'm not sure why cherry-pick
> got it wrong, but this is meant to go in the nv4a_chipset definition,
> not nv44_chipset.
>
> This comment also applies to the 4.4 and 4.11 cherry-picks you just did.
Aha, I see what happened. f94773b9f5ecd1df7c88c2e921924dd41d2020cc
made it into v4.11. However by then it appears to have also made it
into drm-next as ac799acaa4d8db4f7dcd968b15c9596c80a4677f and thus the
drm merge into v4.12. So now you have two versions of the same commit
and are trying to cherry-pick both.
I'm guessing it's also the reason why your cherrypick of my other
commit failed (ad01a91a820cd9f0d880c407bf556b67298dcc93).
And I might note that
"drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch" was
already there before, so didn't make it into your "4.9-stable patches"
commit on the stable-queue git tree.
-ilia
>
> Thanks,
>
> -ilia
>
> On Mon, May 22, 2017 at 1:04 PM, <gregkh@linuxfoundation.org> wrote:
>>
>> This is a note to let you know that I've just added the patch titled
>>
>> drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 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:
>> drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-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 ac799acaa4d8db4f7dcd968b15c9596c80a4677f Mon Sep 17 00:00:00 2001
>> From: Ilia Mirkin <imirkin@alum.mit.edu>
>> Date: Sat, 18 Mar 2017 16:23:10 -0400
>> Subject: drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one
>>
>> From: Ilia Mirkin <imirkin@alum.mit.edu>
>>
>> commit ac799acaa4d8db4f7dcd968b15c9596c80a4677f upstream.
>>
>> The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
>> and PCI varieties, rather than a core PCIE chip with a bridge for
>> AGP/PCI as necessary. As a result, it appears that the MMU is also
>> non-functional. For AGP cards, the vast majority of the NV4A lineup,
>> this worked out since we force AGP cards to use the nv04 mmu. However
>> for PCI variants, this did not work.
>>
>> Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
>> the suggestion. This should be a no-op for NV4A AGP boards, as they were
>> using it already.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
>> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
>> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> ---
>> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
>> @@ -584,7 +584,7 @@ nv44_chipset = {
>> .i2c = nv04_i2c_new,
>> .imem = nv40_instmem_new,
>> .mc = nv44_mc_new,
>> - .mmu = nv44_mmu_new,
>> + .mmu = nv04_mmu_new,
>> .pci = nv40_pci_new,
>> .therm = nv40_therm_new,
>> .timer = nv41_timer_new,
>>
>>
>> Patches currently in stable-queue which might be from imirkin@alum.mit.edu are
>>
>> queue-4.9/drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch
^ permalink raw reply
* Re: [PATCH v2 0/4] crypto: async crypto op fixes
From: Herbert Xu @ 2017-05-23 5:03 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: David S. Miller, Jonathan Corbet, David Howells, Ofir Drang,
stable, Eric Biggers, linux-crypto, linux-doc, linux-kernel,
keyrings
In-Reply-To: <1495114167-3073-1-git-send-email-gilad@benyossef.com>
On Thu, May 18, 2017 at 04:29:22PM +0300, Gilad Ben-Yossef wrote:
> This patch set fixes various usage and documentation errors
> in waiting for async crypto op to complete which can result
> in data corruption.
>
> Note: these were discovered in the process of working on a
> patch set that replaces these call sites and more with a
> generic implementation that will prevent these problems
> going forward. These are just the fix ups for current code.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> CC: stable@vger.kernel.org
> CC: Eric Biggers <ebiggers3@gmail.com>
Patches 1-3 applied. Please fix patch 4 and resubmit. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3
From: Ingo Molnar @ 2017-05-23 7:25 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Peter Zijlstra, Rik van Riel, James Hartsock,
Thomas Gleixner, stable, Tim Wright, Pavel Machek
In-Reply-To: <1495201910-12466-1-git-send-email-fweisbec@gmail.com>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> v2 had issues on -tip tree and triggered a warning. It seems to have
> disappeared. Perhaps it was due to another timer issue. Anyway this
> version brings more debugging informations, with a layout that is more
> bisection-friendly and it also handles ticks that fire outside IRQ
> context and thus carry NULL irq regs. This happen when
> hrtimer_interrupt() is called on hotplug cpu down for example.
>
> We'll see if the issue arises again.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> nohz/fixes
>
> HEAD: cd15f46b284f04dbedd065a9d99a4e0badae379a
>
> Thanks,
> Frederic
> ---
>
> Frederic Weisbecker (2):
> nohz: Add hrtimer sanity check
> nohz: Fix collision between tick and other hrtimers, again
>
>
> kernel/time/tick-sched.c | 48 +++++++++++++++++++++++++++++++++++++++++++-----
> kernel/time/tick-sched.h | 2 ++
> 2 files changed, 45 insertions(+), 5 deletions(-)
So I think the 3 commits queued up right now:
99fa871820cf: nohz: Reset next_tick cache even when the timer has no regs
411fe24e6b7c: nohz: Fix collision between tick and other hrtimers, again
ce6cf9a15d62: nohz: Add hrtimer sanity check
are OK and I'd not rebase them unless there's some breakage.
One thing I noticed: your second series does appear to have:
99fa871820cf: nohz: Reset next_tick cache even when the timer has no regs
is that intentional? That is pretty much the only commit I'd love to rebase with a
proper description added.
Thanks,
Ingo
^ permalink raw reply
* [PATCH rdma-next 2/2] IB/core: Don't resolve IP address to the loopback device
From: Leon Romanovsky @ 2017-05-23 7:48 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-rdma, Moni Shoua, stable
In-Reply-To: <20170523074845.10845-1-leon@kernel.org>
From: Moni Shoua <monis@mellanox.com>
When resolving an IP address that is on the host of the caller the
result from querying the routing table is the loopback device. This is
not a valid response, because it doesn't represent the RDMA device and
the port.
Therefore, callers need to check the resolved device and if it is a
loopback device find an alternative way to resolve it. To avoid this we
make sure that the response from rdma_resolve_ip() will not be the
loopback device.
While that, we fix an static checker warning about dereferencing an
unintitialized pointer using the same solution as in commit abeffce90c7f
("net/mlx5e: Fix a -Wmaybe-uninitialized warning") as a reference.
Signed-off-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
---
drivers/infiniband/core/addr.c | 40 +++++++++++++++++++++++++++++-----------
drivers/infiniband/core/cma.c | 32 +++-----------------------------
drivers/infiniband/core/verbs.c | 5 -----
3 files changed, 32 insertions(+), 45 deletions(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index d2afcb3dd81a..283ebe8f4783 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -269,6 +269,7 @@ int rdma_translate_ip(const struct sockaddr *addr,
return ret;
ret = rdma_copy_addr(dev_addr, dev, NULL);
+ dev_addr->bound_dev_if = dev->ifindex;
if (vlan_id)
*vlan_id = rdma_vlan_dev_vlan_id(dev);
dev_put(dev);
@@ -281,6 +282,7 @@ int rdma_translate_ip(const struct sockaddr *addr,
&((const struct sockaddr_in6 *)addr)->sin6_addr,
dev, 1)) {
ret = rdma_copy_addr(dev_addr, dev, NULL);
+ dev_addr->bound_dev_if = dev->ifindex;
if (vlan_id)
*vlan_id = rdma_vlan_dev_vlan_id(dev);
break;
@@ -406,10 +408,10 @@ static int addr4_resolve(struct sockaddr_in *src_in,
fl4.saddr = src_ip;
fl4.flowi4_oif = addr->bound_dev_if;
rt = ip_route_output_key(addr->net, &fl4);
- if (IS_ERR(rt)) {
- ret = PTR_ERR(rt);
- goto out;
- }
+ ret = PTR_ERR_OR_ZERO(rt);
+ if (ret)
+ return ret;
+
src_in->sin_family = AF_INET;
src_in->sin_addr.s_addr = fl4.saddr;
@@ -424,8 +426,6 @@ static int addr4_resolve(struct sockaddr_in *src_in,
*prt = rt;
return 0;
-out:
- return ret;
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -536,8 +536,12 @@ static int addr_resolve(struct sockaddr *src_in,
if (resolve_neigh)
ret = addr_resolve_neigh(&rt->dst, dst_in, addr, seq);
- ndev = rt->dst.dev;
- dev_hold(ndev);
+ if (addr->bound_dev_if) {
+ ndev = dev_get_by_index(addr->net, addr->bound_dev_if);
+ } else {
+ ndev = rt->dst.dev;
+ dev_hold(ndev);
+ }
ip_rt_put(rt);
} else {
@@ -553,13 +557,27 @@ static int addr_resolve(struct sockaddr *src_in,
if (resolve_neigh)
ret = addr_resolve_neigh(dst, dst_in, addr, seq);
- ndev = dst->dev;
- dev_hold(ndev);
+ if (addr->bound_dev_if) {
+ ndev = dev_get_by_index(addr->net, addr->bound_dev_if);
+ } else {
+ ndev = dst->dev;
+ dev_hold(ndev);
+ }
dst_release(dst);
}
- addr->bound_dev_if = ndev->ifindex;
+ if (ndev->flags & IFF_LOOPBACK) {
+ ret = rdma_translate_ip(dst_in, addr, NULL);
+ /*
+ * Put the loopback device and get the translated
+ * device instead.
+ */
+ dev_put(ndev);
+ ndev = dev_get_by_index(addr->net, addr->bound_dev_if);
+ } else {
+ addr->bound_dev_if = ndev->ifindex;
+ }
dev_put(ndev);
return ret;
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 91b7a2fe5a55..2a6dc10c5624 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -623,22 +623,11 @@ static inline int cma_validate_port(struct ib_device *device, u8 port,
if ((dev_type != ARPHRD_INFINIBAND) && rdma_protocol_ib(device, port))
return ret;
- if (dev_type == ARPHRD_ETHER && rdma_protocol_roce(device, port)) {
+ if (dev_type == ARPHRD_ETHER && rdma_protocol_roce(device, port))
ndev = dev_get_by_index(&init_net, bound_if_index);
- if (ndev && ndev->flags & IFF_LOOPBACK) {
- pr_info("detected loopback device\n");
- dev_put(ndev);
-
- if (!device->get_netdev)
- return -EOPNOTSUPP;
-
- ndev = device->get_netdev(device, port);
- if (!ndev)
- return -ENODEV;
- }
- } else {
+ else
gid_type = IB_GID_TYPE_IB;
- }
+
ret = ib_find_cached_gid_by_port(device, gid, gid_type, port,
ndev, NULL);
@@ -2570,21 +2559,6 @@ static int cma_resolve_iboe_route(struct rdma_id_private *id_priv)
goto err2;
}
- if (ndev->flags & IFF_LOOPBACK) {
- dev_put(ndev);
- if (!id_priv->id.device->get_netdev) {
- ret = -EOPNOTSUPP;
- goto err2;
- }
-
- ndev = id_priv->id.device->get_netdev(id_priv->id.device,
- id_priv->id.port_num);
- if (!ndev) {
- ret = -ENODEV;
- goto err2;
- }
- }
-
supported_gids = roce_gid_type_mask_support(id_priv->id.device,
id_priv->id.port_num);
gid_type = cma_route_gid_type(addr->dev_addr.network,
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index 4792f5209ac2..3d1389efa777 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -506,11 +506,6 @@ int ib_init_ah_from_wc(struct ib_device *device, u8 port_num,
}
resolved_dev = dev_get_by_index(&init_net, if_index);
- if (resolved_dev->flags & IFF_LOOPBACK) {
- dev_put(resolved_dev);
- resolved_dev = idev;
- dev_hold(resolved_dev);
- }
rcu_read_lock();
if (resolved_dev != idev && !rdma_is_upper_dev_rcu(idev,
resolved_dev))
--
2.12.2
^ permalink raw reply related
* [PATCH rdma-next 1/2] IB/core: Namespace is a mandatory input parameter for address resolution
From: Leon Romanovsky @ 2017-05-23 7:48 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-rdma, Moni Shoua, stable
From: Moni Shoua <monis@mellanox.com>
In function addr_resolve() the namespace is a required input parameter
and not an output. It is passed later for searching the routing table
and device addresses. Also, it shouldn't be copied back to the caller.
Fixes: 565edd1d5555 ('IB/addr: Pass network namespace as a parameter')
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
---
drivers/infiniband/core/addr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 02971e239a18..d2afcb3dd81a 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -518,6 +518,11 @@ static int addr_resolve(struct sockaddr *src_in,
struct dst_entry *dst;
int ret;
+ if (!addr->net) {
+ pr_warn_ratelimited("%s: missing namespace\n", __func__);
+ return -EINVAL;
+ }
+
if (src_in->sa_family == AF_INET) {
struct rtable *rt = NULL;
const struct sockaddr_in *dst_in4 =
@@ -555,7 +560,6 @@ static int addr_resolve(struct sockaddr *src_in,
}
addr->bound_dev_if = ndev->ifindex;
- addr->net = dev_net(ndev);
dev_put(ndev);
return ret;
--
2.12.2
^ permalink raw reply related
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