* [PATCH 4.4 01/16] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 23:59 ` Andrew Donnellan
2016-12-13 17:15 ` [PATCH 4.4 02/16] parisc: Purge TLB before setting PTE Greg Kroah-Hartman
` (15 subsequent siblings)
16 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pradipta Ghosh, Andrew Donnellan,
Russell Currey, Michael Ellerman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream.
In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after
after we call eeh_reset_pe() to reset the PCI controller. We then call
eeh_clear_pe_frozen_state(), which can return an error. In this case, we
bail out of eeh_reset_device() without calling pci_unlock_rescan_remove().
Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state()
error path so that we don't cause a deadlock later on.
Reported-by: Pradipta Ghosh <pradghos@in.ibm.com>
Fixes: 78954700631f ("powerpc/eeh: Avoid I/O access during PE reset")
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/eeh_driver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -612,8 +612,10 @@ static int eeh_reset_device(struct eeh_p
/* Clear frozen state */
rc = eeh_clear_pe_frozen_state(pe, false);
- if (rc)
+ if (rc) {
+ pci_unlock_rescan_remove();
return rc;
+ }
/* Give the system 5 seconds to finish running the user-space
* hotplug shutdown scripts, e.g. ifdown for ethernet. Yes,
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 4.4 01/16] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared
2016-12-13 17:15 ` [PATCH 4.4 01/16] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared Greg Kroah-Hartman
@ 2016-12-13 23:59 ` Andrew Donnellan
2016-12-14 1:01 ` Greg Kroah-Hartman
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Donnellan @ 2016-12-13 23:59 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Pradipta Ghosh, Russell Currey, Michael Ellerman
On 14/12/16 04:15, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>
> commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream.
>
> In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after
> after we call eeh_reset_pe() to reset the PCI controller. We then call
> eeh_clear_pe_frozen_state(), which can return an error. In this case, we
> bail out of eeh_reset_device() without calling pci_unlock_rescan_remove().
>
> Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state()
> error path so that we don't cause a deadlock later on.
>
> Reported-by: Pradipta Ghosh <pradghos@in.ibm.com>
> Fixes: 78954700631f ("powerpc/eeh: Avoid I/O access during PE reset")
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Russell Currey <ruscur@russell.cc>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It seems that something in your scripts munged the apostrophe in the
summary line when generating these emails. Though it looks fine in the
actual tree.
Andrew
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 4.4 01/16] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared
2016-12-13 23:59 ` Andrew Donnellan
@ 2016-12-14 1:01 ` Greg Kroah-Hartman
0 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-14 1:01 UTC (permalink / raw)
To: Andrew Donnellan
Cc: linux-kernel, stable, Pradipta Ghosh, Russell Currey, Michael Ellerman
On Wed, Dec 14, 2016 at 10:59:32AM +1100, Andrew Donnellan wrote:
> On 14/12/16 04:15, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> >
> > commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream.
> >
> > In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after
> > after we call eeh_reset_pe() to reset the PCI controller. We then call
> > eeh_clear_pe_frozen_state(), which can return an error. In this case, we
> > bail out of eeh_reset_device() without calling pci_unlock_rescan_remove().
> >
> > Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state()
> > error path so that we don't cause a deadlock later on.
> >
> > Reported-by: Pradipta Ghosh <pradghos@in.ibm.com>
> > Fixes: 78954700631f ("powerpc/eeh: Avoid I/O access during PE reset")
> > Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> > Acked-by: Russell Currey <ruscur@russell.cc>
> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> It seems that something in your scripts munged the apostrophe in the summary
> line when generating these emails. Though it looks fine in the actual tree.
Odd, the original patch has the subject right, so git will do it
correctly when it commits the patch. But, something dropped the '
character when the email was created. Given that it goes through quilt
a few different ways to get here to the mailing list, I'll blame it :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 4.4 02/16] parisc: Purge TLB before setting PTE
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 01/16] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 03/16] parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm Greg Kroah-Hartman
` (14 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John David Anglin, Helge Deller
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John David Anglin <dave.anglin@bell.net>
commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream.
The attached change interchanges the order of purging the TLB and
setting the corresponding page table entry. TLB purges are strongly
ordered. It occurred to me one night that setting the PTE first might
have subtle ordering issues on SMP machines and cause random memory
corruption.
A TLB lock guards the insertion of user TLB entries. So after the TLB
is purged, a new entry can't be inserted until the lock is released.
This ensures that the new PTE value is used when the lock is released.
Since making this change, no random segmentation faults have been
observed on the Debian hppa buildd servers.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/include/asm/pgtable.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -65,9 +65,9 @@ static inline void purge_tlb_entries(str
unsigned long flags; \
spin_lock_irqsave(&pa_tlb_lock, flags); \
old_pte = *ptep; \
- set_pte(ptep, pteval); \
if (pte_inserted(old_pte)) \
purge_tlb_entries(mm, addr); \
+ set_pte(ptep, pteval); \
spin_unlock_irqrestore(&pa_tlb_lock, flags); \
} while (0)
@@ -478,8 +478,8 @@ static inline int ptep_test_and_clear_yo
spin_unlock_irqrestore(&pa_tlb_lock, flags);
return 0;
}
- set_pte(ptep, pte_mkold(pte));
purge_tlb_entries(vma->vm_mm, addr);
+ set_pte(ptep, pte_mkold(pte));
spin_unlock_irqrestore(&pa_tlb_lock, flags);
return 1;
}
@@ -492,9 +492,9 @@ static inline pte_t ptep_get_and_clear(s
spin_lock_irqsave(&pa_tlb_lock, flags);
old_pte = *ptep;
- set_pte(ptep, __pte(0));
if (pte_inserted(old_pte))
purge_tlb_entries(mm, addr);
+ set_pte(ptep, __pte(0));
spin_unlock_irqrestore(&pa_tlb_lock, flags);
return old_pte;
@@ -504,8 +504,8 @@ static inline void ptep_set_wrprotect(st
{
unsigned long flags;
spin_lock_irqsave(&pa_tlb_lock, flags);
- set_pte(ptep, pte_wrprotect(*ptep));
purge_tlb_entries(mm, addr);
+ set_pte(ptep, pte_wrprotect(*ptep));
spin_unlock_irqrestore(&pa_tlb_lock, flags);
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 03/16] parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 01/16] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 02/16] parisc: Purge TLB before setting PTE Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 04/16] parisc: Fix TLB related boot crash on SMP machines Greg Kroah-Hartman
` (13 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John David Anglin, Helge Deller
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John David Anglin <dave.anglin@bell.net>
commit febe42964fe182281859b3d43d844bb25ca49367 upstream.
We have four routines in pacache.S that use temporary alias pages:
copy_user_page_asm(), clear_user_page_asm(), flush_dcache_page_asm() and
flush_icache_page_asm(). copy_user_page_asm() and clear_user_page_asm()
don't purge the TLB entry used for the operation.
flush_dcache_page_asm() and flush_icache_page_asm do purge the entry.
Presumably, this was thought to optimize TLB use. However, the
operation is quite heavy weight on PA 1.X processors as we need to take
the TLB lock and a TLB broadcast is sent to all processors.
This patch removes the purges from flush_dcache_page_asm() and
flush_icache_page_asm.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/pacache.S | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
--- a/arch/parisc/kernel/pacache.S
+++ b/arch/parisc/kernel/pacache.S
@@ -886,19 +886,10 @@ ENTRY(flush_dcache_page_asm)
fdc,m r31(%r28)
fdc,m r31(%r28)
fdc,m r31(%r28)
- cmpb,COND(<<) %r28, %r25,1b
+ cmpb,COND(<<) %r28, %r25,1b
fdc,m r31(%r28)
sync
-
-#ifdef CONFIG_PA20
- pdtlb,l %r0(%r25)
-#else
- tlb_lock %r20,%r21,%r22
- pdtlb %r0(%r25)
- tlb_unlock %r20,%r21,%r22
-#endif
-
bv %r0(%r2)
nop
.exit
@@ -973,17 +964,6 @@ ENTRY(flush_icache_page_asm)
fic,m %r31(%sr4,%r28)
sync
-
-#ifdef CONFIG_PA20
- pdtlb,l %r0(%r28)
- pitlb,l %r0(%sr4,%r25)
-#else
- tlb_lock %r20,%r21,%r22
- pdtlb %r0(%r28)
- pitlb %r0(%sr4,%r25)
- tlb_unlock %r20,%r21,%r22
-#endif
-
bv %r0(%r2)
nop
.exit
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 04/16] parisc: Fix TLB related boot crash on SMP machines
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 03/16] parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 05/16] zram: restrict add/remove attributes to root only Greg Kroah-Hartman
` (12 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helge Deller
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit 24d0492b7d5d321a9c5846c8c974eba9823ffaa0 upstream.
At bootup we run measurements to calculate the best threshold for when we
should be using full TLB flushes instead of just flushing a specific amount of
TLB entries. This performance test is run over the kernel text segment.
But running this TLB performance test on the kernel text segment turned out to
crash some SMP machines when the kernel text pages were mapped as huge pages.
To avoid those crashes this patch simply skips this test on some SMP machines
and calculates an optimal threshold based on the maximum number of available
TLB entries and number of online CPUs.
On a technical side, this seems to happen:
The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB
entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge
instruction seems to work without problems even if the pages were mapped as
huge pages. But on SMP systems the TLB purge instruction is broadcasted to
other CPUs. Those CPUs then crash the machine because the page size is not as
expected. C8000 machines with PA8800/PA8900 CPUs were not affected by this
problem, because the required cache coherency prohibits to use huge pages at
all. Sadly I didn't found any documentation about this behaviour, so this
finding is purely based on testing with phyiscal SMP machines (A500-44 and
J5000, both were 2-way boxes).
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/cache.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -375,6 +375,15 @@ void __init parisc_setup_cache_timing(vo
/* calculate TLB flush threshold */
+ /* On SMP machines, skip the TLB measure of kernel text which
+ * has been mapped as huge pages. */
+ if (num_online_cpus() > 1 && !parisc_requires_coherency()) {
+ threshold = max(cache_info.it_size, cache_info.dt_size);
+ threshold *= PAGE_SIZE;
+ threshold /= num_online_cpus();
+ goto set_tlb_threshold;
+ }
+
alltime = mfctl(16);
flush_tlb_all();
alltime = mfctl(16) - alltime;
@@ -393,6 +402,8 @@ void __init parisc_setup_cache_timing(vo
alltime, size, rangetime);
threshold = PAGE_ALIGN(num_online_cpus() * size * alltime / rangetime);
+
+set_tlb_threshold:
if (threshold)
parisc_tlb_flush_threshold = threshold;
printk(KERN_INFO "TLB flush threshold set to %lu KiB\n",
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 05/16] zram: restrict add/remove attributes to root only
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 04/16] parisc: Fix TLB related boot crash on SMP machines Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 06/16] locking/rtmutex: Prevent dequeue vs. unlock race Greg Kroah-Hartman
` (11 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sergey Senozhatsky, Steven Allen,
Minchan Kim, Andrew Morton, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
commit 5c7e9ccd91b90d87029261f8856294ee51934cab upstream.
zram hot_add sysfs attribute is a very 'special' attribute - reading
from it creates a new uninitialized zram device. This file, by a
mistake, can be read by a 'normal' user at the moment, while only root
must be able to create a new zram device, therefore hot_add attribute
must have S_IRUSR mode, not S_IRUGO.
[akpm@linux-foundation.org: s/sence/sense/, reflow comment to use 80 cols]
Fixes: 6566d1a32bf72 ("zram: add dynamic device add/remove functionality")
Link: http://lkml.kernel.org/r/20161205155845.20129-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Steven Allen <steven@stebalien.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/zram/zram_drv.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1378,8 +1378,14 @@ static ssize_t hot_remove_store(struct c
return ret ? ret : count;
}
+/*
+ * NOTE: hot_add attribute is not the usual read-only sysfs attribute. In a
+ * sense that reading from this file does alter the state of your system -- it
+ * creates a new un-initialized zram device and returns back this device's
+ * device_id (or an error code if it fails to create a new device).
+ */
static struct class_attribute zram_control_class_attrs[] = {
- __ATTR_RO(hot_add),
+ __ATTR(hot_add, 0400, hot_add_show, NULL),
__ATTR_WO(hot_remove),
__ATTR_NULL,
};
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 06/16] locking/rtmutex: Prevent dequeue vs. unlock race
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 05/16] zram: restrict add/remove attributes to root only Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 07/16] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner() Greg Kroah-Hartman
` (10 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Daney, David Daney,
Thomas Gleixner, Steven Rostedt, Peter Zijlstra (Intel),
Linus Torvalds, Mark Rutland, Sebastian Siewior, Will Deacon,
Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream.
David reported a futex/rtmutex state corruption. It's caused by the
following problem:
CPU0 CPU1 CPU2
l->owner=T1
rt_mutex_lock(l)
lock(l->wait_lock)
l->owner = T1 | HAS_WAITERS;
enqueue(T2)
boost()
unlock(l->wait_lock)
schedule()
rt_mutex_lock(l)
lock(l->wait_lock)
l->owner = T1 | HAS_WAITERS;
enqueue(T3)
boost()
unlock(l->wait_lock)
schedule()
signal(->T2) signal(->T3)
lock(l->wait_lock)
dequeue(T2)
deboost()
unlock(l->wait_lock)
lock(l->wait_lock)
dequeue(T3)
===> wait list is now empty
deboost()
unlock(l->wait_lock)
lock(l->wait_lock)
fixup_rt_mutex_waiters()
if (wait_list_empty(l)) {
owner = l->owner & ~HAS_WAITERS;
l->owner = owner
==> l->owner = T1
}
lock(l->wait_lock)
rt_mutex_unlock(l) fixup_rt_mutex_waiters()
if (wait_list_empty(l)) {
owner = l->owner & ~HAS_WAITERS;
cmpxchg(l->owner, T1, NULL)
===> Success (l->owner = NULL)
l->owner = owner
==> l->owner = T1
}
That means the problem is caused by fixup_rt_mutex_waiters() which does the
RMW to clear the waiters bit unconditionally when there are no waiters in
the rtmutexes rbtree.
This can be fatal: A concurrent unlock can release the rtmutex in the
fastpath because the waiters bit is not set. If the cmpxchg() gets in the
middle of the RMW operation then the previous owner, which just unlocked
the rtmutex is set as the owner again when the write takes place after the
successfull cmpxchg().
The solution is rather trivial: verify that the owner member of the rtmutex
has the waiters bit set before clearing it. This does not require a
cmpxchg() or other atomic operations because the waiters bit can only be
set and cleared with the rtmutex wait_lock held. It's also safe against the
fast path unlock attempt. The unlock attempt via cmpxchg() will either see
the bit set and take the slowpath or see the bit cleared and release it
atomically in the fastpath.
It's remarkable that the test program provided by David triggers on ARM64
and MIPS64 really quick, but it refuses to reproduce on x86-64, while the
problem exists there as well. That refusal might explain that this got not
discovered earlier despite the bug existing from day one of the rtmutex
implementation more than 10 years ago.
Thanks to David for meticulously instrumenting the code and providing the
information which allowed to decode this subtle problem.
Reported-by: David Daney <ddaney@caviumnetworks.com>
Tested-by: David Daney <david.daney@cavium.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core")
Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/locking/rtmutex.c | 68 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 66 insertions(+), 2 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -65,8 +65,72 @@ static inline void clear_rt_mutex_waiter
static void fixup_rt_mutex_waiters(struct rt_mutex *lock)
{
- if (!rt_mutex_has_waiters(lock))
- clear_rt_mutex_waiters(lock);
+ unsigned long owner, *p = (unsigned long *) &lock->owner;
+
+ if (rt_mutex_has_waiters(lock))
+ return;
+
+ /*
+ * The rbtree has no waiters enqueued, now make sure that the
+ * lock->owner still has the waiters bit set, otherwise the
+ * following can happen:
+ *
+ * CPU 0 CPU 1 CPU2
+ * l->owner=T1
+ * rt_mutex_lock(l)
+ * lock(l->lock)
+ * l->owner = T1 | HAS_WAITERS;
+ * enqueue(T2)
+ * boost()
+ * unlock(l->lock)
+ * block()
+ *
+ * rt_mutex_lock(l)
+ * lock(l->lock)
+ * l->owner = T1 | HAS_WAITERS;
+ * enqueue(T3)
+ * boost()
+ * unlock(l->lock)
+ * block()
+ * signal(->T2) signal(->T3)
+ * lock(l->lock)
+ * dequeue(T2)
+ * deboost()
+ * unlock(l->lock)
+ * lock(l->lock)
+ * dequeue(T3)
+ * ==> wait list is empty
+ * deboost()
+ * unlock(l->lock)
+ * lock(l->lock)
+ * fixup_rt_mutex_waiters()
+ * if (wait_list_empty(l) {
+ * l->owner = owner
+ * owner = l->owner & ~HAS_WAITERS;
+ * ==> l->owner = T1
+ * }
+ * lock(l->lock)
+ * rt_mutex_unlock(l) fixup_rt_mutex_waiters()
+ * if (wait_list_empty(l) {
+ * owner = l->owner & ~HAS_WAITERS;
+ * cmpxchg(l->owner, T1, NULL)
+ * ===> Success (l->owner = NULL)
+ *
+ * l->owner = owner
+ * ==> l->owner = T1
+ * }
+ *
+ * With the check for the waiter bit in place T3 on CPU2 will not
+ * overwrite. All tasks fiddling with the waiters bit are
+ * serialized by l->lock, so nothing else can modify the waiters
+ * bit. If the bit is set then nothing can change l->owner either
+ * so the simple RMW is safe. The cmpxchg() will simply fail if it
+ * happens in the middle of the RMW because the waiters bit is
+ * still set.
+ */
+ owner = READ_ONCE(*p);
+ if (owner & RT_MUTEX_HAS_WAITERS)
+ WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS);
}
/*
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 07/16] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 06/16] locking/rtmutex: Prevent dequeue vs. unlock race Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 08/16] perf/x86: Fix full width counter, counter overflow Greg Kroah-Hartman
` (9 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Thomas Gleixner,
Peter Zijlstra (Intel),
David Daney, Linus Torvalds, Mark Rutland, Sebastian Siewior,
Steven Rostedt, Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream.
While debugging the rtmutex unlock vs. dequeue race Will suggested to use
READ_ONCE() in rt_mutex_owner() as it might race against the
cmpxchg_release() in unlock_rt_mutex_safe().
Will: "It's a minor thing which will most likely not matter in practice"
Careful search did not unearth an actual problem in todays code, but it's
better to be safe than surprised.
Suggested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20161130210030.431379999@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/locking/rtmutex_common.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -75,8 +75,9 @@ task_top_pi_waiter(struct task_struct *p
static inline struct task_struct *rt_mutex_owner(struct rt_mutex *lock)
{
- return (struct task_struct *)
- ((unsigned long)lock->owner & ~RT_MUTEX_OWNER_MASKALL);
+ unsigned long owner = (unsigned long) READ_ONCE(lock->owner);
+
+ return (struct task_struct *) (owner & ~RT_MUTEX_OWNER_MASKALL);
}
/*
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 08/16] perf/x86: Fix full width counter, counter overflow
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 07/16] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner() Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 09/16] crypto: mcryptd - Check mcryptd algorithm compatibility Greg Kroah-Hartman
` (8 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lukasz Odzioba, Liang, Kan,
Peter Zijlstra (Intel),
Alexander Shishkin, Arnaldo Carvalho de Melo, Jiri Olsa,
Linus Torvalds, Stephane Eranian, Thomas Gleixner, Vince Weaver,
Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra (Intel) <peterz@infradead.org>
commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream.
Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM.
Both these parts have full_width_write set, and that does indeed have
a problem. In order to deal with counter wrap, we must sample the
counter at at least half the counter period (see also the sampling
theorem) such that we can unambiguously reconstruct the count.
However commit:
069e0c3c4058 ("perf/x86/intel: Support full width counting")
sets the sampling interval to the full period, not half.
Fixing that exposes another issue, in that we must not sign extend the
delta value when we shift it right; the counter cannot have
decremented after all.
With both these issues fixed, counter overflow functions correctly
again.
Reported-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
Tested-by: Liang, Kan <kan.liang@intel.com>
Tested-by: Odzioba, Lukasz <lukasz.odzioba@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: 069e0c3c4058 ("perf/x86/intel: Support full width counting")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/perf_event.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -67,7 +67,7 @@ u64 x86_perf_event_update(struct perf_ev
int shift = 64 - x86_pmu.cntval_bits;
u64 prev_raw_count, new_raw_count;
int idx = hwc->idx;
- s64 delta;
+ u64 delta;
if (idx == INTEL_PMC_IDX_FIXED_BTS)
return 0;
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -3636,7 +3636,7 @@ __init int intel_pmu_init(void)
/* Support full width counters using alternative MSR range */
if (x86_pmu.intel_cap.full_width_write) {
- x86_pmu.max_period = x86_pmu.cntval_mask;
+ x86_pmu.max_period = x86_pmu.cntval_mask >> 1;
x86_pmu.perfctr = MSR_IA32_PMC0;
pr_cont("full-width counters, ");
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 09/16] crypto: mcryptd - Check mcryptd algorithm compatibility
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 08/16] perf/x86: Fix full width counter, counter overflow Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 10/16] can: raw: raw_setsockopt: limit number of can_filter that can be set Greg Kroah-Hartman
` (7 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Tim Chen, Herbert Xu
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: tim <tim.c.chen@linux.intel.com>
commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream.
Algorithms not compatible with mcryptd could be spawned by mcryptd
with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name
construct. This causes mcryptd to crash the kernel if an arbitrary
"alg" is incompatible and not intended to be used with mcryptd. It is
an issue if AF_ALG tries to spawn mcryptd(alg) to expose it externally.
But such algorithms must be used internally and not be exposed.
We added a check to enforce that only internal algorithms are allowed
with mcryptd at the time mcryptd is spawning an algorithm.
Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/mcryptd.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -258,18 +258,22 @@ out_free_inst:
goto out;
}
-static inline void mcryptd_check_internal(struct rtattr **tb, u32 *type,
+static inline bool mcryptd_check_internal(struct rtattr **tb, u32 *type,
u32 *mask)
{
struct crypto_attr_type *algt;
algt = crypto_get_attr_type(tb);
if (IS_ERR(algt))
- return;
- if ((algt->type & CRYPTO_ALG_INTERNAL))
- *type |= CRYPTO_ALG_INTERNAL;
- if ((algt->mask & CRYPTO_ALG_INTERNAL))
- *mask |= CRYPTO_ALG_INTERNAL;
+ return false;
+
+ *type |= algt->type & CRYPTO_ALG_INTERNAL;
+ *mask |= algt->mask & CRYPTO_ALG_INTERNAL;
+
+ if (*type & *mask & CRYPTO_ALG_INTERNAL)
+ return true;
+ else
+ return false;
}
static int mcryptd_hash_init_tfm(struct crypto_tfm *tfm)
@@ -498,7 +502,8 @@ static int mcryptd_create_hash(struct cr
u32 mask = 0;
int err;
- mcryptd_check_internal(tb, &type, &mask);
+ if (!mcryptd_check_internal(tb, &type, &mask))
+ return -EINVAL;
salg = shash_attr_alg(tb[1], type, mask);
if (IS_ERR(salg))
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 10/16] can: raw: raw_setsockopt: limit number of can_filter that can be set
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 09/16] crypto: mcryptd - Check mcryptd algorithm compatibility Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 12/16] arm64: futex.h: Add missing PAN toggling Greg Kroah-Hartman
` (6 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrey Konovalov, Marc Kleine-Budde
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Kleine-Budde <mkl@pengutronix.de>
commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.
This patch adds a check to limit the number of can_filters that can be
set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER
are not prevented resulting in a warning.
Reference: https://lkml.org/lkml/2016/12/2/230
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/linux/can.h | 1 +
net/can/raw.c | 3 +++
2 files changed, 4 insertions(+)
--- a/include/uapi/linux/can.h
+++ b/include/uapi/linux/can.h
@@ -196,5 +196,6 @@ struct can_filter {
};
#define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */
+#define CAN_RAW_FILTER_MAX 512 /* maximum number of can_filter set via setsockopt() */
#endif /* !_UAPI_CAN_H */
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -499,6 +499,9 @@ static int raw_setsockopt(struct socket
if (optlen % sizeof(struct can_filter) != 0)
return -EINVAL;
+ if (optlen > CAN_RAW_FILTER_MAX * sizeof(struct can_filter))
+ return -EINVAL;
+
count = optlen / sizeof(struct can_filter);
if (count > 1) {
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 12/16] arm64: futex.h: Add missing PAN toggling
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 10/16] can: raw: raw_setsockopt: limit number of can_filter that can be set Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:15 ` [PATCH 4.4 13/16] m68k: Fix ndelay() macro Greg Kroah-Hartman
` (5 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, James Morse, Will Deacon, Mian Yousaf Kaukab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <james.morse@arm.com>
commit 811d61e384e24759372bb3f01772f3744b0a8327 upstream.
futex.h's futex_atomic_cmpxchg_inatomic() does not use the
__futex_atomic_op() macro and needs its own PAN toggling. This was missed
when the feature was implemented.
Fixes: 338d4f49d6f ("arm64: kernel: Add support for Privileged Access Never")
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/futex.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -121,6 +121,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
return -EFAULT;
asm volatile("// futex_atomic_cmpxchg_inatomic\n"
+ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
" prfm pstl1strm, %2\n"
"1: ldxr %w1, %2\n"
" sub %w3, %w1, %w4\n"
@@ -137,6 +138,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
" .align 3\n"
" .quad 1b, 4b, 2b, 4b\n"
" .popsection\n"
+ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
: "+r" (ret), "=&r" (val), "+Q" (*uaddr), "=&r" (tmp)
: "r" (oldval), "r" (newval), "Ir" (-EFAULT)
: "memory");
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 13/16] m68k: Fix ndelay() macro
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 12/16] arm64: futex.h: Add missing PAN toggling Greg Kroah-Hartman
@ 2016-12-13 17:15 ` Greg Kroah-Hartman
2016-12-13 17:16 ` [PATCH 4.4 14/16] batman-adv: Check for alloc errors when preparing TT local data Greg Kroah-Hartman
` (4 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Geert Uytterhoeven
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream.
The current ndelay() macro definition has an extra semi-colon at the
end of the line thus leading to a compilation error when ndelay is used
in a conditional block without curly braces like this one:
if (cond)
ndelay(t);
else
...
which, after the preprocessor pass gives:
if (cond)
m68k_ndelay(t);;
else
...
thus leading to the following gcc error:
error: 'else' without a previous 'if'
Remove this extra semi-colon.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/m68k/include/asm/delay.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/m68k/include/asm/delay.h
+++ b/arch/m68k/include/asm/delay.h
@@ -114,6 +114,6 @@ static inline void __udelay(unsigned lon
*/
#define HZSCALE (268435456 / (1000000 / HZ))
-#define ndelay(n) __delay(DIV_ROUND_UP((n) * ((((HZSCALE) >> 11) * (loops_per_jiffy >> 11)) >> 6), 1000));
+#define ndelay(n) __delay(DIV_ROUND_UP((n) * ((((HZSCALE) >> 11) * (loops_per_jiffy >> 11)) >> 6), 1000))
#endif /* defined(_M68K_DELAY_H) */
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 14/16] batman-adv: Check for alloc errors when preparing TT local data
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2016-12-13 17:15 ` [PATCH 4.4 13/16] m68k: Fix ndelay() macro Greg Kroah-Hartman
@ 2016-12-13 17:16 ` Greg Kroah-Hartman
2016-12-13 17:16 ` [PATCH 4.4 15/16] hotplug: Make register and unregister notifier API symmetric Greg Kroah-Hartman
` (3 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Sven Eckelmann,
Simon Wunderlich
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sven Eckelmann <sven@narfation.org>
commit c2d0f48a13e53b4747704c9e692f5e765e52041a upstream.
batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the
new TVLV block. The caller is informed about this problem with the returned
length of 0. Not checking this value results in an invalid memory access
when either tt_data or tt_change is accessed.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/batman-adv/translation-table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -2764,7 +2764,7 @@ static bool batadv_send_my_tt_response(s
&tvlv_tt_data,
&tt_change,
&tt_len);
- if (!tt_len)
+ if (!tt_len || !tvlv_len)
goto unlock;
/* Copy the last orig_node's OGM buffer */
@@ -2782,7 +2782,7 @@ static bool batadv_send_my_tt_response(s
&tvlv_tt_data,
&tt_change,
&tt_len);
- if (!tt_len)
+ if (!tt_len || !tvlv_len)
goto out;
/* fill the rest of the tvlv with the real TT entries */
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 15/16] hotplug: Make register and unregister notifier API symmetric
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2016-12-13 17:16 ` [PATCH 4.4 14/16] batman-adv: Check for alloc errors when preparing TT local data Greg Kroah-Hartman
@ 2016-12-13 17:16 ` Greg Kroah-Hartman
2016-12-13 17:16 ` [PATCH 4.4 16/16] crypto: rsa - Add Makefile dependencies to fix parallel builds Greg Kroah-Hartman
` (2 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Hocko, linux-mm,
Andrew Morton, Dan Streetman, Thomas Gleixner
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <mhocko@suse.com>
commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream.
Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its
notifiers when HOTPLUG_CPU=y while the registration might succeed even
when HOTPLUG_CPU=n if MODULE is enabled. This means that e.g. zswap
might keep a stale notifier on the list on the manual clean up during
the pool tear down and thus corrupt the list. Resulting in the following
[ 144.964346] BUG: unable to handle kernel paging request at ffff880658a2be78
[ 144.971337] IP: [<ffffffffa290b00b>] raw_notifier_chain_register+0x1b/0x40
<snipped>
[ 145.122628] Call Trace:
[ 145.125086] [<ffffffffa28e5cf8>] __register_cpu_notifier+0x18/0x20
[ 145.131350] [<ffffffffa2a5dd73>] zswap_pool_create+0x273/0x400
[ 145.137268] [<ffffffffa2a5e0fc>] __zswap_param_set+0x1fc/0x300
[ 145.143188] [<ffffffffa2944c1d>] ? trace_hardirqs_on+0xd/0x10
[ 145.149018] [<ffffffffa2908798>] ? kernel_param_lock+0x28/0x30
[ 145.154940] [<ffffffffa2a3e8cf>] ? __might_fault+0x4f/0xa0
[ 145.160511] [<ffffffffa2a5e237>] zswap_compressor_param_set+0x17/0x20
[ 145.167035] [<ffffffffa2908d3c>] param_attr_store+0x5c/0xb0
[ 145.172694] [<ffffffffa290848d>] module_attr_store+0x1d/0x30
[ 145.178443] [<ffffffffa2b2b41f>] sysfs_kf_write+0x4f/0x70
[ 145.183925] [<ffffffffa2b2a5b9>] kernfs_fop_write+0x149/0x180
[ 145.189761] [<ffffffffa2a99248>] __vfs_write+0x18/0x40
[ 145.194982] [<ffffffffa2a9a412>] vfs_write+0xb2/0x1a0
[ 145.200122] [<ffffffffa2a9a732>] SyS_write+0x52/0xa0
[ 145.205177] [<ffffffffa2ff4d97>] entry_SYSCALL_64_fastpath+0x12/0x17
This can be even triggered manually by changing
/sys/module/zswap/parameters/compressor multiple times.
Fix this issue by making unregister APIs symmetric to the register so
there are no surprises.
Fixes: 47e627bc8c9a ("[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU")
Reported-and-tested-by: Yu Zhao <yuzhao@google.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Streetman <ddstreet@ieee.org>
Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/cpu.h | 15 ++++-----------
kernel/cpu.c | 3 +--
2 files changed, 5 insertions(+), 13 deletions(-)
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -131,22 +131,16 @@ enum {
{ .notifier_call = fn, .priority = pri }; \
__register_cpu_notifier(&fn##_nb); \
}
-#else /* #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
-#define cpu_notifier(fn, pri) do { (void)(fn); } while (0)
-#define __cpu_notifier(fn, pri) do { (void)(fn); } while (0)
-#endif /* #else #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
-#ifdef CONFIG_HOTPLUG_CPU
extern int register_cpu_notifier(struct notifier_block *nb);
extern int __register_cpu_notifier(struct notifier_block *nb);
extern void unregister_cpu_notifier(struct notifier_block *nb);
extern void __unregister_cpu_notifier(struct notifier_block *nb);
-#else
-#ifndef MODULE
-extern int register_cpu_notifier(struct notifier_block *nb);
-extern int __register_cpu_notifier(struct notifier_block *nb);
-#else
+#else /* #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
+#define cpu_notifier(fn, pri) do { (void)(fn); } while (0)
+#define __cpu_notifier(fn, pri) do { (void)(fn); } while (0)
+
static inline int register_cpu_notifier(struct notifier_block *nb)
{
return 0;
@@ -156,7 +150,6 @@ static inline int __register_cpu_notifie
{
return 0;
}
-#endif
static inline void unregister_cpu_notifier(struct notifier_block *nb)
{
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -223,8 +223,6 @@ static int cpu_notify(unsigned long val,
return __cpu_notify(val, v, -1, NULL);
}
-#ifdef CONFIG_HOTPLUG_CPU
-
static void cpu_notify_nofail(unsigned long val, void *v)
{
BUG_ON(cpu_notify(val, v));
@@ -246,6 +244,7 @@ void __unregister_cpu_notifier(struct no
}
EXPORT_SYMBOL(__unregister_cpu_notifier);
+#ifdef CONFIG_HOTPLUG_CPU
/**
* clear_tasks_mm_cpumask - Safely clear tasks' mm_cpumask for a CPU
* @cpu: a CPU id
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 4.4 16/16] crypto: rsa - Add Makefile dependencies to fix parallel builds
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2016-12-13 17:16 ` [PATCH 4.4 15/16] hotplug: Make register and unregister notifier API symmetric Greg Kroah-Hartman
@ 2016-12-13 17:16 ` Greg Kroah-Hartman
2016-12-13 19:31 ` [PATCH 4.4 00/16] 4.4.39-stable review Shuah Khan
2016-12-14 4:11 ` Guenter Roeck
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-13 17:16 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Michael, Herbert Xu, Tuomas Tynkkynen
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Michael <david.michael@coreos.com>
commit 57891633eeef60e732e045731cf20e50ee80acb4 upstream.
Both asn1 headers are included by rsa_helper.c, so rsa_helper.o
should explicitly depend on them.
Signed-off-by: David Michael <david.michael@coreos.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Tuomas Tynkkynen <tuomas@tuxera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_CRYPTO_AKCIPHER2) += akciph
$(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
$(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
+$(obj)/rsa_helper.o: $(obj)/rsapubkey-asn1.h $(obj)/rsaprivkey-asn1.h
clean-files += rsapubkey-asn1.c rsapubkey-asn1.h
clean-files += rsaprivkey-asn1.c rsaprivkey-asn1.h
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 4.4 00/16] 4.4.39-stable review
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2016-12-13 17:16 ` [PATCH 4.4 16/16] crypto: rsa - Add Makefile dependencies to fix parallel builds Greg Kroah-Hartman
@ 2016-12-13 19:31 ` Shuah Khan
2016-12-14 4:11 ` Guenter Roeck
16 siblings, 0 replies; 20+ messages in thread
From: Shuah Khan @ 2016-12-13 19:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, Shuah Khan
On 12/13/2016 10:15 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.39 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Dec 15 17:15:06 UTC 2016.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.39-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 4.4 00/16] 4.4.39-stable review
2016-12-13 17:15 ` [PATCH 4.4 00/16] 4.4.39-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2016-12-13 19:31 ` [PATCH 4.4 00/16] 4.4.39-stable review Shuah Khan
@ 2016-12-14 4:11 ` Guenter Roeck
16 siblings, 0 replies; 20+ messages in thread
From: Guenter Roeck @ 2016-12-14 4:11 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuah.kh, patches, ben.hutchings, stable
On 12/13/2016 09:15 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.39 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Dec 15 17:15:06 UTC 2016.
> Anything received after that time might be too late.
>
Build results:
total: 149 pass: 149 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 20+ messages in thread