* [PATCH 4.4 001/168] arm64: debug: Dont propagate UNKNOWN FAR into si_code for debug signals
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 002/168] arm64: debug: Ensure debug handlers check triggering exception level Greg Kroah-Hartman
` (171 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Rutland, Will Deacon, Catalin Marinas
From: Will Deacon <will.deacon@arm.com>
commit b9a4b9d084d978f80eb9210727c81804588b42ff upstream.
FAR_EL1 is UNKNOWN for all debug exceptions other than those caused by
taking a hardware watchpoint. Unfortunately, if a debug handler returns
a non-zero value, then we will propagate the UNKNOWN FAR value to
userspace via the si_addr field of the SIGTRAP siginfo_t.
Instead, let's set si_addr to take on the PC of the faulting instruction,
which we have available in the current pt_regs.
Cc: <stable@vger.kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/fault.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -589,11 +589,12 @@ void __init hook_debug_fault_code(int nr
debug_fault_info[nr].name = name;
}
-asmlinkage int __exception do_debug_exception(unsigned long addr,
+asmlinkage int __exception do_debug_exception(unsigned long addr_if_watchpoint,
unsigned int esr,
struct pt_regs *regs)
{
const struct fault_info *inf = debug_fault_info + DBG_ESR_EVT(esr);
+ unsigned long pc = instruction_pointer(regs);
struct siginfo info;
int rv;
@@ -604,16 +605,16 @@ asmlinkage int __exception do_debug_exce
if (interrupts_enabled(regs))
trace_hardirqs_off();
- if (!inf->fn(addr, esr, regs)) {
+ if (!inf->fn(addr_if_watchpoint, esr, regs)) {
rv = 1;
} else {
pr_alert("Unhandled debug exception: %s (0x%08x) at 0x%016lx\n",
- inf->name, esr, addr);
+ inf->name, esr, pc);
info.si_signo = inf->sig;
info.si_errno = 0;
info.si_code = inf->code;
- info.si_addr = (void __user *)addr;
+ info.si_addr = (void __user *)pc;
arm64_notify_die("", regs, &info, 0);
rv = 0;
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 002/168] arm64: debug: Ensure debug handlers check triggering exception level
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 001/168] arm64: debug: Dont propagate UNKNOWN FAR into si_code for debug signals Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 003/168] ext4: cleanup bh release code in ext4_ind_remove_space() Greg Kroah-Hartman
` (170 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Rutland, Will Deacon, Catalin Marinas
From: Will Deacon <will.deacon@arm.com>
commit 6bd288569b50bc89fa5513031086746968f585cb upstream.
Debug exception handlers may be called for exceptions generated both by
user and kernel code. In many cases, this is checked explicitly, but
in other cases things either happen to work by happy accident or they
go slightly wrong. For example, executing 'brk #4' from userspace will
enter the kprobes code and be ignored, but the instruction will be
retried forever in userspace instead of delivering a SIGTRAP.
Fix this issue in the most stable-friendly fashion by simply adding
explicit checks of the triggering exception level to all of our debug
exception handlers.
Cc: <stable@vger.kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/kgdb.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -215,22 +215,31 @@ int kgdb_arch_handle_exception(int excep
static int kgdb_brk_fn(struct pt_regs *regs, unsigned int esr)
{
+ if (user_mode(regs))
+ return DBG_HOOK_ERROR;
+
kgdb_handle_exception(1, SIGTRAP, 0, regs);
- return 0;
+ return DBG_HOOK_HANDLED;
}
static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
{
+ if (user_mode(regs))
+ return DBG_HOOK_ERROR;
+
compiled_break = 1;
kgdb_handle_exception(1, SIGTRAP, 0, regs);
- return 0;
+ return DBG_HOOK_HANDLED;
}
static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr)
{
+ if (user_mode(regs))
+ return DBG_HOOK_ERROR;
+
kgdb_handle_exception(1, SIGTRAP, 0, regs);
- return 0;
+ return DBG_HOOK_HANDLED;
}
static struct break_hook kgdb_brkpt_hook = {
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 003/168] ext4: cleanup bh release code in ext4_ind_remove_space()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 001/168] arm64: debug: Dont propagate UNKNOWN FAR into si_code for debug signals Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 002/168] arm64: debug: Ensure debug handlers check triggering exception level Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 004/168] lib/int_sqrt: optimize initial value compute Greg Kroah-Hartman
` (169 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, zhangyi (F),
Theodore Tso, Jan Kara, Jari Ruusu
From: zhangyi (F) <yi.zhang@huawei.com>
commit 5e86bdda41534e17621d5a071b294943cae4376e upstream.
Currently, we are releasing the indirect buffer where we are done with
it in ext4_ind_remove_space(), so we can see the brelse() and
BUFFER_TRACE() everywhere. It seems fragile and hard to read, and we
may probably forget to release the buffer some day. This patch cleans
up the code by putting of the code which releases the buffers to the
end of the function.
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Jari Ruusu <jari.ruusu@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/indirect.c | 47 ++++++++++++++++++++++-------------------------
1 file changed, 22 insertions(+), 25 deletions(-)
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -1323,6 +1323,7 @@ int ext4_ind_remove_space(handle_t *hand
ext4_lblk_t offsets[4], offsets2[4];
Indirect chain[4], chain2[4];
Indirect *partial, *partial2;
+ Indirect *p = NULL, *p2 = NULL;
ext4_lblk_t max_block;
__le32 nr = 0, nr2 = 0;
int n = 0, n2 = 0;
@@ -1364,7 +1365,7 @@ int ext4_ind_remove_space(handle_t *hand
}
- partial = ext4_find_shared(inode, n, offsets, chain, &nr);
+ partial = p = ext4_find_shared(inode, n, offsets, chain, &nr);
if (nr) {
if (partial == chain) {
/* Shared branch grows from the inode */
@@ -1389,13 +1390,11 @@ int ext4_ind_remove_space(handle_t *hand
partial->p + 1,
(__le32 *)partial->bh->b_data+addr_per_block,
(chain+n-1) - partial);
- BUFFER_TRACE(partial->bh, "call brelse");
- brelse(partial->bh);
partial--;
}
end_range:
- partial2 = ext4_find_shared(inode, n2, offsets2, chain2, &nr2);
+ partial2 = p2 = ext4_find_shared(inode, n2, offsets2, chain2, &nr2);
if (nr2) {
if (partial2 == chain2) {
/*
@@ -1425,16 +1424,14 @@ end_range:
(__le32 *)partial2->bh->b_data,
partial2->p,
(chain2+n2-1) - partial2);
- BUFFER_TRACE(partial2->bh, "call brelse");
- brelse(partial2->bh);
partial2--;
}
goto do_indirects;
}
/* Punch happened within the same level (n == n2) */
- partial = ext4_find_shared(inode, n, offsets, chain, &nr);
- partial2 = ext4_find_shared(inode, n2, offsets2, chain2, &nr2);
+ partial = p = ext4_find_shared(inode, n, offsets, chain, &nr);
+ partial2 = p2 = ext4_find_shared(inode, n2, offsets2, chain2, &nr2);
/* Free top, but only if partial2 isn't its subtree. */
if (nr) {
@@ -1491,15 +1488,7 @@ end_range:
partial->p + 1,
partial2->p,
(chain+n-1) - partial);
- while (partial > chain) {
- BUFFER_TRACE(partial->bh, "call brelse");
- brelse(partial->bh);
- }
- while (partial2 > chain2) {
- BUFFER_TRACE(partial2->bh, "call brelse");
- brelse(partial2->bh);
- }
- return 0;
+ goto cleanup;
}
/*
@@ -1514,8 +1503,6 @@ end_range:
partial->p + 1,
(__le32 *)partial->bh->b_data+addr_per_block,
(chain+n-1) - partial);
- BUFFER_TRACE(partial->bh, "call brelse");
- brelse(partial->bh);
partial--;
}
if (partial2 > chain2 && depth2 <= depth) {
@@ -1523,11 +1510,21 @@ end_range:
(__le32 *)partial2->bh->b_data,
partial2->p,
(chain2+n2-1) - partial2);
- BUFFER_TRACE(partial2->bh, "call brelse");
- brelse(partial2->bh);
partial2--;
}
}
+
+cleanup:
+ while (p && p > chain) {
+ BUFFER_TRACE(p->bh, "call brelse");
+ brelse(p->bh);
+ p--;
+ }
+ while (p2 && p2 > chain2) {
+ BUFFER_TRACE(p2->bh, "call brelse");
+ brelse(p2->bh);
+ p2--;
+ }
return 0;
do_indirects:
@@ -1535,7 +1532,7 @@ do_indirects:
switch (offsets[0]) {
default:
if (++n >= n2)
- return 0;
+ break;
nr = i_data[EXT4_IND_BLOCK];
if (nr) {
ext4_free_branches(handle, inode, NULL, &nr, &nr+1, 1);
@@ -1543,7 +1540,7 @@ do_indirects:
}
case EXT4_IND_BLOCK:
if (++n >= n2)
- return 0;
+ break;
nr = i_data[EXT4_DIND_BLOCK];
if (nr) {
ext4_free_branches(handle, inode, NULL, &nr, &nr+1, 2);
@@ -1551,7 +1548,7 @@ do_indirects:
}
case EXT4_DIND_BLOCK:
if (++n >= n2)
- return 0;
+ break;
nr = i_data[EXT4_TIND_BLOCK];
if (nr) {
ext4_free_branches(handle, inode, NULL, &nr, &nr+1, 3);
@@ -1560,5 +1557,5 @@ do_indirects:
case EXT4_TIND_BLOCK:
;
}
- return 0;
+ goto cleanup;
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 004/168] lib/int_sqrt: optimize initial value compute
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 003/168] ext4: cleanup bh release code in ext4_ind_remove_space() Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 005/168] tty/serial: atmel: Add is_half_duplex helper Greg Kroah-Hartman
` (168 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Zijlstra (Intel),
Joe Perches, Will Deacon, Linus Torvalds, Anshul Garg,
Davidlohr Bueso, David Miller, Ingo Molnar, Kees Cook,
Matthew Wilcox, Michael Davidson, Thomas Gleixner, Andrew Morton
From: Peter Zijlstra <peterz@infradead.org>
commit f8ae107eef209bff29a5816bc1aad40d5cd69a80 upstream.
The initial value (@m) compute is:
m = 1UL << (BITS_PER_LONG - 2);
while (m > x)
m >>= 2;
Which is a linear search for the highest even bit smaller or equal to @x
We can implement this using a binary search using __fls() (or better when
its hardware implemented).
m = 1UL << (__fls(x) & ~1UL);
Especially for small values of @x; which are the more common arguments
when doing a CDF on idle times; the linear search is near to worst case,
while the binary search of __fls() is a constant 6 (or 5 on 32bit)
branches.
cycles: branches: branch-misses:
PRE:
hot: 43.633557 +- 0.034373 45.333132 +- 0.002277 0.023529 +- 0.000681
cold: 207.438411 +- 0.125840 45.333132 +- 0.002277 6.976486 +- 0.004219
SOFTWARE FLS:
hot: 29.576176 +- 0.028850 26.666730 +- 0.004511 0.019463 +- 0.000663
cold: 165.947136 +- 0.188406 26.666746 +- 0.004511 6.133897 +- 0.004386
HARDWARE FLS:
hot: 24.720922 +- 0.025161 20.666784 +- 0.004509 0.020836 +- 0.000677
cold: 132.777197 +- 0.127471 20.666776 +- 0.004509 5.080285 +- 0.003874
Averages computed over all values <128k using a LFSR to generate order.
Cold numbers have a LFSR based branch trace buffer 'confuser' ran between
each int_sqrt() invocation.
Link: http://lkml.kernel.org/r/20171020164644.936577234@infradead.org
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Suggested-by: Joe Perches <joe@perches.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Anshul Garg <aksgarg1989@gmail.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: David Miller <davem@davemloft.net>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Michael Davidson <md@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/int_sqrt.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/lib/int_sqrt.c
+++ b/lib/int_sqrt.c
@@ -7,6 +7,7 @@
#include <linux/kernel.h>
#include <linux/export.h>
+#include <linux/bitops.h>
/**
* int_sqrt - rough approximation to sqrt
@@ -21,10 +22,7 @@ unsigned long int_sqrt(unsigned long x)
if (x <= 1)
return x;
- m = 1UL << (BITS_PER_LONG - 2);
- while (m > x)
- m >>= 2;
-
+ m = 1UL << (__fls(x) & ~1UL);
while (m != 0) {
b = y + m;
y >>= 1;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 005/168] tty/serial: atmel: Add is_half_duplex helper
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 004/168] lib/int_sqrt: optimize initial value compute Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 006/168] mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified Greg Kroah-Hartman
` (167 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Razvan Stefanescu, Richard Genoud
From: Razvan Stefanescu <razvan.stefanescu@microchip.com>
commit f3040983132bf3477acd45d2452a906e67c2fec9 upstream.
Use a helper function to check that a port needs to use half duplex
communication, replacing several occurrences of multi-line bit checking.
Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -237,6 +237,12 @@ static inline void atmel_uart_write_char
#endif
+static inline int atmel_uart_is_half_duplex(struct uart_port *port)
+{
+ return (port->rs485.flags & SER_RS485_ENABLED) &&
+ !(port->rs485.flags & SER_RS485_RX_DURING_TX);
+}
+
#ifdef CONFIG_SERIAL_ATMEL_PDC
static bool atmel_use_pdc_rx(struct uart_port *port)
{
@@ -481,9 +487,9 @@ static void atmel_stop_tx(struct uart_po
/* Disable interrupts */
atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
- if ((port->rs485.flags & SER_RS485_ENABLED) &&
- !(port->rs485.flags & SER_RS485_RX_DURING_TX))
+ if (atmel_uart_is_half_duplex(port))
atmel_start_rx(port);
+
}
/*
@@ -500,8 +506,7 @@ static void atmel_start_tx(struct uart_p
return;
if (atmel_use_pdc_tx(port) || atmel_use_dma_tx(port))
- if ((port->rs485.flags & SER_RS485_ENABLED) &&
- !(port->rs485.flags & SER_RS485_RX_DURING_TX))
+ if (atmel_uart_is_half_duplex(port))
atmel_stop_rx(port);
if (atmel_use_pdc_tx(port))
@@ -810,8 +815,7 @@ static void atmel_complete_tx_dma(void *
*/
if (!uart_circ_empty(xmit))
tasklet_schedule(&atmel_port->tasklet);
- else if ((port->rs485.flags & SER_RS485_ENABLED) &&
- !(port->rs485.flags & SER_RS485_RX_DURING_TX)) {
+ else if (atmel_uart_is_half_duplex(port)) {
/* DMA done, stop TX, start RX for RS485 */
atmel_start_rx(port);
}
@@ -1388,8 +1392,7 @@ static void atmel_tx_pdc(struct uart_por
atmel_uart_writel(port, ATMEL_US_IER,
atmel_port->tx_done_mask);
} else {
- if ((port->rs485.flags & SER_RS485_ENABLED) &&
- !(port->rs485.flags & SER_RS485_RX_DURING_TX)) {
+ if (atmel_uart_is_half_duplex(port)) {
/* DMA done, stop TX, start RX for RS485 */
atmel_start_rx(port);
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 006/168] mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 005/168] tty/serial: atmel: Add is_half_duplex helper Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 007/168] i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA Greg Kroah-Hartman
` (166 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yang Shi, Oscar Salvador,
Cyril Hrubis, Kirill A. Shutemov, Rafael Aquini, David Rientjes,
Vlastimil Babka, Andrew Morton, Linus Torvalds
From: Yang Shi <yang.shi@linux.alibaba.com>
commit a7f40cfe3b7ada57af9b62fd28430eeb4a7cfcb7 upstream.
When MPOL_MF_STRICT was specified and an existing page was already on a
node that does not follow the policy, mbind() should return -EIO. But
commit 6f4576e3687b ("mempolicy: apply page table walker on
queue_pages_range()") broke the rule.
And commit c8633798497c ("mm: mempolicy: mbind and migrate_pages support
thp migration") didn't return the correct value for THP mbind() too.
If MPOL_MF_STRICT is set, ignore vma_migratable() to make sure it
reaches queue_pages_to_pte_range() or queue_pages_pmd() to check if an
existing page was already on a node that does not follow the policy.
And, non-migratable vma may be used, return -EIO too if MPOL_MF_MOVE or
MPOL_MF_MOVE_ALL was specified.
Tested with https://github.com/metan-ucw/ltp/blob/master/testcases/kernel/syscalls/mbind/mbind02.c
[akpm@linux-foundation.org: tweak code comment]
Link: http://lkml.kernel.org/r/1553020556-38583-1-git-send-email-yang.shi@linux.alibaba.com
Fixes: 6f4576e3687b ("mempolicy: apply page table walker on queue_pages_range()")
Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Reported-by: Cyril Hrubis <chrubis@suse.cz>
Suggested-by: Kirill A. Shutemov <kirill@shutemov.name>
Acked-by: Rafael Aquini <aquini@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.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>
---
mm/mempolicy.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -514,12 +514,16 @@ static int queue_pages_pte_range(pmd_t *
if (node_isset(nid, *qp->nmask) == !!(flags & MPOL_MF_INVERT))
continue;
- if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL))
+ if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) {
+ if (!vma_migratable(vma))
+ break;
migrate_page_add(page, qp->pagelist, flags);
+ } else
+ break;
}
pte_unmap_unlock(pte - 1, ptl);
cond_resched();
- return 0;
+ return addr != end ? -EIO : 0;
}
static int queue_pages_hugetlb(pte_t *pte, unsigned long hmask,
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 007/168] i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 006/168] mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 008/168] Bluetooth: Fix decrementing reference count twice in releasing socket Greg Kroah-Hartman
` (165 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jeremy Compostella, Wolfram Sang,
stable, Connor OBrien
From: Jeremy Compostella <jeremy.compostella@intel.com>
commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.
It is possible from a user application to run into that issue by
calling the I2C_SMBUS ioctl with data.block[0] greater than
I2C_SMBUS_BLOCK_MAX + 1.
This patch makes the code compliant with
Documentation/i2c/dev-interface by raising an error when the requested
size is larger than 32 bytes.
Call Trace:
[<ffffffff8139f695>] dump_stack+0x67/0x92
[<ffffffff811802a4>] panic+0xc5/0x1eb
[<ffffffff810ecb5f>] ? vprintk_default+0x1f/0x30
[<ffffffff817456d3>] ? i2cdev_ioctl_smbus+0x303/0x320
[<ffffffff8109a68b>] __stack_chk_fail+0x1b/0x20
[<ffffffff817456d3>] i2cdev_ioctl_smbus+0x303/0x320
[<ffffffff81745aed>] i2cdev_ioctl+0x4d/0x1e0
[<ffffffff811f761a>] do_vfs_ioctl+0x2ba/0x490
[<ffffffff81336e43>] ? security_file_ioctl+0x43/0x60
[<ffffffff811f7869>] SyS_ioctl+0x79/0x90
[<ffffffff81a22e97>] entry_SYSCALL_64_fastpath+0x12/0x6a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
[connoro@google.com: 4.9 backport: adjust filename]
Signed-off-by: Connor O'Brien <connoro@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/i2c-core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -2936,16 +2936,16 @@ static s32 i2c_smbus_xfer_emulated(struc
the underlying bus driver */
break;
case I2C_SMBUS_I2C_BLOCK_DATA:
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX) {
+ dev_err(&adapter->dev, "Invalid block %s size %d\n",
+ read_write == I2C_SMBUS_READ ? "read" : "write",
+ data->block[0]);
+ return -EINVAL;
+ }
if (read_write == I2C_SMBUS_READ) {
msg[1].len = data->block[0];
} else {
msg[0].len = data->block[0] + 1;
- if (msg[0].len > I2C_SMBUS_BLOCK_MAX + 1) {
- dev_err(&adapter->dev,
- "Invalid block write size %d\n",
- data->block[0]);
- return -EINVAL;
- }
for (i = 1; i <= data->block[0]; i++)
msgbuf0[i] = data->block[i];
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 008/168] Bluetooth: Fix decrementing reference count twice in releasing socket
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 007/168] i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 009/168] tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped Greg Kroah-Hartman
` (164 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+fdc00003f4efff43bc5b,
Myungho Jung, Marcel Holtmann, Zubin Mithra
From: Myungho Jung <mhjungk@gmail.com>
commit e20a2e9c42c9e4002d9e338d74e7819e88d77162 upstream.
When releasing socket, it is possible to enter hci_sock_release() and
hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
The reference count of hdev should be decremented only once from one of
them but if storing hdev to local variable in hci_sock_release() before
detached from socket and setting to NULL in hci_sock_dev_event(),
hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
referencing hdev from socket after bt_sock_unlink() in
hci_sock_release().
Reported-by: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bluetooth/hci_sock.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -558,13 +558,12 @@ static int hci_sock_release(struct socke
if (!sk)
return 0;
- hdev = hci_pi(sk)->hdev;
-
if (hci_pi(sk)->channel == HCI_CHANNEL_MONITOR)
atomic_dec(&monitor_promisc);
bt_sock_unlink(&hci_sk_list, sk);
+ hdev = hci_pi(sk)->hdev;
if (hdev) {
if (hci_pi(sk)->channel == HCI_CHANNEL_USER) {
/* When releasing an user channel exclusive access,
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 009/168] tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 008/168] Bluetooth: Fix decrementing reference count twice in releasing socket Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 010/168] CIFS: fix POSIX lock leak and invalid ptr deref Greg Kroah-Hartman
` (163 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Razvan Stefanescu, Richard Genoud
From: Razvan Stefanescu <razvan.stefanescu@microchip.com>
commit 69646d7a3689fbe1a65ae90397d22ac3f1b8d40f upstream.
In half-duplex operation, RX should be started after TX completes.
If DMA is used, there is a case when the DMA transfer completes but the
TX FIFO is not emptied, so the RX cannot be restarted just yet.
Use a boolean variable to store this state and rearm TX interrupt mask
to be signaled again that the transfer finished. In interrupt transmit
handler this variable is used to start RX. A warning message is generated
if RX is activated before TX fifo is cleared.
Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
RX after TX is done")
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -169,6 +169,8 @@ struct atmel_uart_port {
unsigned int pending_status;
spinlock_t lock_suspended;
+ bool hd_start_rx; /* can start RX during half-duplex operation */
+
int (*prepare_rx)(struct uart_port *port);
int (*prepare_tx)(struct uart_port *port);
void (*schedule_rx)(struct uart_port *port);
@@ -816,8 +818,13 @@ static void atmel_complete_tx_dma(void *
if (!uart_circ_empty(xmit))
tasklet_schedule(&atmel_port->tasklet);
else if (atmel_uart_is_half_duplex(port)) {
- /* DMA done, stop TX, start RX for RS485 */
- atmel_start_rx(port);
+ /*
+ * DMA done, re-enable TXEMPTY and signal that we can stop
+ * TX and start RX for RS485
+ */
+ atmel_port->hd_start_rx = true;
+ atmel_uart_writel(port, ATMEL_US_IER,
+ atmel_port->tx_done_mask);
}
spin_unlock_irqrestore(&port->lock, flags);
@@ -1257,9 +1264,20 @@ atmel_handle_transmit(struct uart_port *
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
if (pending & atmel_port->tx_done_mask) {
- /* Either PDC or interrupt transmission */
atmel_uart_writel(port, ATMEL_US_IDR,
atmel_port->tx_done_mask);
+
+ /* Start RX if flag was set and FIFO is empty */
+ if (atmel_port->hd_start_rx) {
+ if (!(atmel_uart_readl(port, ATMEL_US_CSR)
+ & ATMEL_US_TXEMPTY))
+ dev_warn(port->dev, "Should start RX, but TX fifo is not empty\n");
+
+ atmel_port->hd_start_rx = false;
+ atmel_start_rx(port);
+ return;
+ }
+
tasklet_schedule(&atmel_port->tasklet);
}
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 010/168] CIFS: fix POSIX lock leak and invalid ptr deref
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 009/168] tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 011/168] h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux- Greg Kroah-Hartman
` (162 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aurelien Aptel, NeilBrown,
Steve French, Pavel Shilovsky, Sasha Levin
[ Upstream commit bc31d0cdcfbadb6258b45db97e93b1c83822ba33 ]
We have a customer reporting crashes in lock_get_status() with many
"Leaked POSIX lock" messages preceeding the crash.
Leaked POSIX lock on dev=0x0:0x56 ...
Leaked POSIX lock on dev=0x0:0x56 ...
Leaked POSIX lock on dev=0x0:0x56 ...
Leaked POSIX lock on dev=0x0:0x53 ...
Leaked POSIX lock on dev=0x0:0x53 ...
Leaked POSIX lock on dev=0x0:0x53 ...
Leaked POSIX lock on dev=0x0:0x53 ...
POSIX: fl_owner=ffff8900e7b79380 fl_flags=0x1 fl_type=0x1 fl_pid=20709
Leaked POSIX lock on dev=0x0:0x4b ino...
Leaked locks on dev=0x0:0x4b ino=0xf911400000029:
POSIX: fl_owner=ffff89f41c870e00 fl_flags=0x1 fl_type=0x1 fl_pid=19592
stack segment: 0000 [#1] SMP
Modules linked in: binfmt_misc msr tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_gss_krb5 arc4 ecb auth_rpcgss nfsv4 md4 nfs nls_utf8 lockd grace cifs sunrpc ccm dns_resolver fscache af_packet iscsi_ibft iscsi_boot_sysfs vmw_vsock_vmci_transport vsock xfs libcrc32c sb_edac edac_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg ansi_cprng vmw_balloon aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev pcspkr vmxnet3 i2c_piix4 vmw_vmci shpchp fjes processor button ac btrfs xor raid6_pq sr_mod cdrom ata_generic sd_mod ata_piix vmwgfx crc32c_intel drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm serio_raw ahci libahci drm libata vmw_pvscsi sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
Supported: Yes
CPU: 6 PID: 28250 Comm: lsof Not tainted 4.4.156-94.64-default #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
task: ffff88a345f28740 ti: ffff88c74005c000 task.ti: ffff88c74005c000
RIP: 0010:[<ffffffff8125dcab>] [<ffffffff8125dcab>] lock_get_status+0x9b/0x3b0
RSP: 0018:ffff88c74005fd90 EFLAGS: 00010202
RAX: ffff89bde83e20ae RBX: ffff89e870003d18 RCX: 0000000049534f50
RDX: ffffffff81a3541f RSI: ffffffff81a3544e RDI: ffff89bde83e20ae
RBP: 0026252423222120 R08: 0000000020584953 R09: 000000000000ffff
R10: 0000000000000000 R11: ffff88c74005fc70 R12: ffff89e5ca7b1340
R13: 00000000000050e5 R14: ffff89e870003d30 R15: ffff89e5ca7b1340
FS: 00007fafd64be800(0000) GS:ffff89f41fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001c80018 CR3: 000000a522048000 CR4: 0000000000360670
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
0000000000000208 ffffffff81a3d6b6 ffff89e870003d30 ffff89e870003d18
ffff89e5ca7b1340 ffff89f41738d7c0 ffff89e870003d30 ffff89e5ca7b1340
ffffffff8125e08f 0000000000000000 ffff89bc22b67d00 ffff88c74005ff28
Call Trace:
[<ffffffff8125e08f>] locks_show+0x2f/0x70
[<ffffffff81230ad1>] seq_read+0x251/0x3a0
[<ffffffff81275bbc>] proc_reg_read+0x3c/0x70
[<ffffffff8120e456>] __vfs_read+0x26/0x140
[<ffffffff8120e9da>] vfs_read+0x7a/0x120
[<ffffffff8120faf2>] SyS_read+0x42/0xa0
[<ffffffff8161cbc3>] entry_SYSCALL_64_fastpath+0x1e/0xb7
When Linux closes a FD (close(), close-on-exec, dup2(), ...) it calls
filp_close() which also removes all posix locks.
The lock struct is initialized like so in filp_close() and passed
down to cifs
...
lock.fl_type = F_UNLCK;
lock.fl_flags = FL_POSIX | FL_CLOSE;
lock.fl_start = 0;
lock.fl_end = OFFSET_MAX;
...
Note the FL_CLOSE flag, which hints the VFS code that this unlocking
is done for closing the fd.
filp_close()
locks_remove_posix(filp, id);
vfs_lock_file(filp, F_SETLK, &lock, NULL);
return filp->f_op->lock(filp, cmd, fl) => cifs_lock()
rc = cifs_setlk(file, flock, type, wait_flag, posix_lck, lock, unlock, xid);
rc = server->ops->mand_unlock_range(cfile, flock, xid);
if (flock->fl_flags & FL_POSIX && !rc)
rc = locks_lock_file_wait(file, flock)
Notice how we don't call locks_lock_file_wait() which does the
generic VFS lock/unlock/wait work on the inode if rc != 0.
If we are closing the handle, the SMB server is supposed to remove any
locks associated with it. Similarly, cifs.ko frees and wakes up any
lock and lock waiter when closing the file:
cifs_close()
cifsFileInfo_put(file->private_data)
/*
* Delete any outstanding lock records. We'll lose them when the file
* is closed anyway.
*/
down_write(&cifsi->lock_sem);
list_for_each_entry_safe(li, tmp, &cifs_file->llist->locks, llist) {
list_del(&li->llist);
cifs_del_lock_waiters(li);
kfree(li);
}
list_del(&cifs_file->llist->llist);
kfree(cifs_file->llist);
up_write(&cifsi->lock_sem);
So we can safely ignore unlocking failures in cifs_lock() if they
happen with the FL_CLOSE flag hint set as both the server and the
client take care of it during the actual closing.
This is not a proper fix for the unlocking failure but it's safe and
it seems to prevent the lock leakages and crashes the customer
experiences.
Signed-off-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Steve French <stfrench@microsoft.com>
Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/file.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 0305e3866216..23a8374fa97f 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1574,8 +1574,20 @@ cifs_setlk(struct file *file, struct file_lock *flock, __u32 type,
rc = server->ops->mand_unlock_range(cfile, flock, xid);
out:
- if (flock->fl_flags & FL_POSIX && !rc)
+ if (flock->fl_flags & FL_POSIX) {
+ /*
+ * If this is a request to remove all locks because we
+ * are closing the file, it doesn't matter if the
+ * unlocking failed as both cifs.ko and the SMB server
+ * remove the lock on file close
+ */
+ if (rc) {
+ cifs_dbg(VFS, "%s failed rc=%d\n", __func__, rc);
+ if (!(flock->fl_flags & FL_CLOSE))
+ return rc;
+ }
rc = locks_lock_file_wait(file, flock);
+ }
return rc;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 011/168] h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux-
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 010/168] CIFS: fix POSIX lock leak and invalid ptr deref Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 012/168] tracing: kdb: Fix ftdump to not sleep Greg Kroah-Hartman
` (161 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Masahiro Yamada, Sasha Levin
[ Upstream commit fc2b47b55f17fd996f7a01975ce1c33c2f2513f6 ]
It believe it is a bad idea to hardcode a specific compiler prefix
that may or may not be installed on a user's system. It is annoying
when testing features that should not require compilers at all.
For example, mrproper, headers_install, etc. should work without
any compiler.
They look like follows on my machine.
$ make ARCH=h8300 mrproper
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
make: h8300-unknown-linux-gcc: Command not found
[ a bunch of the same error messages continue ]
$ make ARCH=h8300 headers_install
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
HOSTCC scripts/basic/fixdep
make: h8300-unknown-linux-gcc: Command not found
WRAP arch/h8300/include/generated/uapi/asm/kvm_para.h
[ snip ]
The solution is to delete this line, or to use cc-cross-prefix like
some architectures do. I chose the latter as a moderate fixup.
I added an alternative 'h8300-linux-' because it is available at:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/h8300/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile
index e1c02ca230cb..073bba6f9f60 100644
--- a/arch/h8300/Makefile
+++ b/arch/h8300/Makefile
@@ -23,7 +23,7 @@ KBUILD_AFLAGS += $(aflags-y)
LDFLAGS += $(ldflags-y)
ifeq ($(CROSS_COMPILE),)
-CROSS_COMPILE := h8300-unknown-linux-
+CROSS_COMPILE := $(call cc-cross-prefix, h8300-unknown-linux- h8300-linux-)
endif
core-y += arch/$(ARCH)/kernel/ arch/$(ARCH)/mm/
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 012/168] tracing: kdb: Fix ftdump to not sleep
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 011/168] h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux- Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 013/168] gpio: gpio-omap: fix level interrupt idling Greg Kroah-Hartman
` (160 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Brian Norris, Douglas Anderson,
Steven Rostedt (VMware),
Sasha Levin
[ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ]
As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
BUG for "sleeping function called from invalid context".
kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
atomic context. A very simple solution for this is to add allocation
flags to ring_buffer_read_prepare() so kdb can call it without
triggering the allocation error. This patch does that.
Note that in the original email thread about this, it was suggested
that perhaps the solution for kdb was to either preallocate the buffer
ahead of time or create our own iterator. I'm hoping that this
alternative of adding allocation flags to ring_buffer_read_prepare()
can be considered since it means I don't need to duplicate more of the
core trace code into "trace_kdb.c" (for either creating my own
iterator or re-preparing a ring allocator whose memory was already
allocated).
NOTE: another option for kdb is to actually figure out how to make it
reuse the existing ftrace_dump() function and totally eliminate the
duplication. This sounds very appealing and actually works (the "sr
z" command can be seen to properly dump the ftrace buffer). The
downside here is that ftrace_dump() fully consumes the trace buffer.
Unless that is changed I'd rather not use it because it means "ftdump
| grep xyz" won't be very useful to search the ftrace buffer since it
will throw away the whole trace on the first grep. A future patch to
dump only the last few lines of the buffer will also be hard to
implement.
[1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com
Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.org
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/ring_buffer.h | 2 +-
kernel/trace/ring_buffer.c | 5 +++--
kernel/trace/trace.c | 6 ++++--
kernel/trace/trace_kdb.c | 6 ++++--
4 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 19d0778ec382..121c8f99ecdd 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -125,7 +125,7 @@ ring_buffer_consume(struct ring_buffer *buffer, int cpu, u64 *ts,
unsigned long *lost_events);
struct ring_buffer_iter *
-ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu);
+ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu, gfp_t flags);
void ring_buffer_read_prepare_sync(void);
void ring_buffer_read_start(struct ring_buffer_iter *iter);
void ring_buffer_read_finish(struct ring_buffer_iter *iter);
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 74b20e3ab8c6..5e091614fe39 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4042,6 +4042,7 @@ EXPORT_SYMBOL_GPL(ring_buffer_consume);
* ring_buffer_read_prepare - Prepare for a non consuming read of the buffer
* @buffer: The ring buffer to read from
* @cpu: The cpu buffer to iterate over
+ * @flags: gfp flags to use for memory allocation
*
* This performs the initial preparations necessary to iterate
* through the buffer. Memory is allocated, buffer recording
@@ -4059,7 +4060,7 @@ EXPORT_SYMBOL_GPL(ring_buffer_consume);
* This overall must be paired with ring_buffer_read_finish.
*/
struct ring_buffer_iter *
-ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu)
+ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu, gfp_t flags)
{
struct ring_buffer_per_cpu *cpu_buffer;
struct ring_buffer_iter *iter;
@@ -4067,7 +4068,7 @@ ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu)
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return NULL;
- iter = kmalloc(sizeof(*iter), GFP_KERNEL);
+ iter = kmalloc(sizeof(*iter), flags);
if (!iter)
return NULL;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8c097de8a596..ae00e68ceae3 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3122,7 +3122,8 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot)
if (iter->cpu_file == RING_BUFFER_ALL_CPUS) {
for_each_tracing_cpu(cpu) {
iter->buffer_iter[cpu] =
- ring_buffer_read_prepare(iter->trace_buffer->buffer, cpu);
+ ring_buffer_read_prepare(iter->trace_buffer->buffer,
+ cpu, GFP_KERNEL);
}
ring_buffer_read_prepare_sync();
for_each_tracing_cpu(cpu) {
@@ -3132,7 +3133,8 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot)
} else {
cpu = iter->cpu_file;
iter->buffer_iter[cpu] =
- ring_buffer_read_prepare(iter->trace_buffer->buffer, cpu);
+ ring_buffer_read_prepare(iter->trace_buffer->buffer,
+ cpu, GFP_KERNEL);
ring_buffer_read_prepare_sync();
ring_buffer_read_start(iter->buffer_iter[cpu]);
tracing_iter_reset(iter, cpu);
diff --git a/kernel/trace/trace_kdb.c b/kernel/trace/trace_kdb.c
index 57149bce6aad..896458285fdd 100644
--- a/kernel/trace/trace_kdb.c
+++ b/kernel/trace/trace_kdb.c
@@ -50,14 +50,16 @@ static void ftrace_dump_buf(int skip_lines, long cpu_file)
if (cpu_file == RING_BUFFER_ALL_CPUS) {
for_each_tracing_cpu(cpu) {
iter.buffer_iter[cpu] =
- ring_buffer_read_prepare(iter.trace_buffer->buffer, cpu);
+ ring_buffer_read_prepare(iter.trace_buffer->buffer,
+ cpu, GFP_ATOMIC);
ring_buffer_read_start(iter.buffer_iter[cpu]);
tracing_iter_reset(&iter, cpu);
}
} else {
iter.cpu_file = cpu_file;
iter.buffer_iter[cpu_file] =
- ring_buffer_read_prepare(iter.trace_buffer->buffer, cpu_file);
+ ring_buffer_read_prepare(iter.trace_buffer->buffer,
+ cpu_file, GFP_ATOMIC);
ring_buffer_read_start(iter.buffer_iter[cpu_file]);
tracing_iter_reset(&iter, cpu_file);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 013/168] gpio: gpio-omap: fix level interrupt idling
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 012/168] tracing: kdb: Fix ftdump to not sleep Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 014/168] sysctl: handle overflow for file-max Greg Kroah-Hartman
` (159 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaro Koskinen, Keerthy,
Peter Ujfalusi, Russell King, Tony Lindgren, Grygorii Strashko,
Linus Walleij, Sasha Levin
[ Upstream commit d01849f7deba81f4959fd9e51bf20dbf46987d1c ]
Tony notes that the GPIO module does not idle when level interrupts are
in use, as the wakeup appears to get stuck.
After extensive investigation, it appears that the wakeup will only be
cleared if the interrupt status register is cleared while the interrupt
is enabled. However, we are currently clearing it with the interrupt
disabled for level-based interrupts.
It is acknowledged that this observed behaviour conflicts with a
statement in the TRM:
CAUTION
After servicing the interrupt, the status bit in the interrupt status
register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be
reset and the interrupt line released (by setting the corresponding
bit of the interrupt status register to 1) before enabling an
interrupt for the GPIO channel in the interrupt-enable register
(GPIOi.GPIO_IRQSTATUS_SET_0 or GPIOi.GPIO_IRQSTATUS_SET_1) to prevent
the occurrence of unexpected interrupts when enabling an interrupt
for the GPIO channel.
However, this does not appear to be a practical problem.
Further, as reported by Grygorii Strashko <grygorii.strashko@ti.com>,
the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP:
Fix the sequence to clear the IRQ status" saying:
if the status is cleared after disabling the IRQ then sWAKEUP will not
be cleared and gates the module transition
When we unmask the level interrupt after the interrupt has been handled,
enable the interrupt and only then clear the interrupt. If the interrupt
is still pending, the hardware will re-assert the interrupt status.
Should the caution note in the TRM prove to be a problem, we could
use a clear-enable-clear sequence instead.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[tony@atomide.com: updated comments based on an earlier TI patch]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpio/gpio-omap.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f7fbb46d5d79..9943273ec981 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -872,14 +872,16 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
if (trigger)
omap_set_gpio_triggering(bank, offset, trigger);
- /* For level-triggered GPIOs, the clearing must be done after
- * the HW source is cleared, thus after the handler has run */
- if (bank->level_mask & BIT(offset)) {
- omap_set_gpio_irqenable(bank, offset, 0);
+ omap_set_gpio_irqenable(bank, offset, 1);
+
+ /*
+ * For level-triggered GPIOs, clearing must be done after the source
+ * is cleared, thus after the handler has run. OMAP4 needs this done
+ * after enabing the interrupt to clear the wakeup status.
+ */
+ if (bank->level_mask & BIT(offset))
omap_clear_gpio_irqstatus(bank, offset);
- }
- omap_set_gpio_irqenable(bank, offset, 1);
raw_spin_unlock_irqrestore(&bank->lock, flags);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 014/168] sysctl: handle overflow for file-max
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 013/168] gpio: gpio-omap: fix level interrupt idling Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 21:50 ` Christian Brauner
2019-04-24 17:07 ` [PATCH 4.4 015/168] enic: fix build warning without CONFIG_CPUMASK_OFFSTACK Greg Kroah-Hartman
` (158 subsequent siblings)
172 siblings, 1 reply; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Brauner, Kees Cook,
Alexey Dobriyan, Al Viro, Dominik Brodowski, Eric W. Biederman,
Joe Lawrence, Luis Chamberlain, Waiman Long, Andrew Morton,
Linus Torvalds, Sasha Levin
[ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ]
Currently, when writing
echo 18446744073709551616 > /proc/sys/fs/file-max
/proc/sys/fs/file-max will overflow and be set to 0. That quickly
crashes the system.
This commit sets the max and min value for file-max. The max value is
set to long int. Any higher value cannot currently be used as the
percpu counters are long ints and not unsigned integers.
Note that the file-max value is ultimately parsed via
__do_proc_doulongvec_minmax(). This function does not report error when
min or max are exceeded. Which means if a value largen that long int is
written userspace will not receive an error instead the old value will be
kept. There is an argument to be made that this should be changed and
__do_proc_doulongvec_minmax() should return an error when a dedicated min
or max value are exceeded. However this has the potential to break
userspace so let's defer this to an RFC patch.
Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io
Signed-off-by: Christian Brauner <christian@brauner.io>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Waiman Long <longman@redhat.com>
[christian@brauner.io: v4]
Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/sysctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index beadcf83ceba..2f98b11477b8 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -126,6 +126,7 @@ static int __maybe_unused one = 1;
static int __maybe_unused two = 2;
static int __maybe_unused four = 4;
static unsigned long one_ul = 1;
+static unsigned long long_max = LONG_MAX;
static int one_hundred = 100;
#ifdef CONFIG_PRINTK
static int ten_thousand = 10000;
@@ -1603,6 +1604,8 @@ static struct ctl_table fs_table[] = {
.maxlen = sizeof(files_stat.max_files),
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &long_max,
},
{
.procname = "nr_open",
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 014/168] sysctl: handle overflow for file-max
2019-04-24 17:07 ` [PATCH 4.4 014/168] sysctl: handle overflow for file-max Greg Kroah-Hartman
@ 2019-04-24 21:50 ` Christian Brauner
2019-04-25 8:15 ` Greg Kroah-Hartman
0 siblings, 1 reply; 178+ messages in thread
From: Christian Brauner @ 2019-04-24 21:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Kees Cook, Alexey Dobriyan, Al Viro,
Dominik Brodowski, Eric W. Biederman, Joe Lawrence,
Luis Chamberlain, Waiman Long, Andrew Morton, Linus Torvalds,
Sasha Levin
On Wed, Apr 24, 2019 at 7:16 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> [ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ]
>
> Currently, when writing
>
> echo 18446744073709551616 > /proc/sys/fs/file-max
>
> /proc/sys/fs/file-max will overflow and be set to 0. That quickly
> crashes the system.
>
> This commit sets the max and min value for file-max. The max value is
> set to long int. Any higher value cannot currently be used as the
> percpu counters are long ints and not unsigned integers.
>
> Note that the file-max value is ultimately parsed via
> __do_proc_doulongvec_minmax(). This function does not report error when
> min or max are exceeded. Which means if a value largen that long int is
> written userspace will not receive an error instead the old value will be
> kept. There is an argument to be made that this should be changed and
> __do_proc_doulongvec_minmax() should return an error when a dedicated min
> or max value are exceeded. However this has the potential to break
> userspace so let's defer this to an RFC patch.
>
> Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io
> Signed-off-by: Christian Brauner <christian@brauner.io>
> Acked-by: Kees Cook <keescook@chromium.org>
> Cc: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Joe Lawrence <joe.lawrence@redhat.com>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Waiman Long <longman@redhat.com>
> [christian@brauner.io: v4]
> Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
Hey Greg,
Just an heads-up. This patch triggered a KASAN warning and Will has
sent a fix for that
which is already in master.
So if you backport this patch you likely also want to backport
9002b21465fa4d829edfc94a5a441005cffaa972
(See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9002b21465fa4d829edfc94a5a441005cffaa972
)
Seems we missed a Cc: for stable in there. Sorry about that.
Thanks!
Christian
> ---
> kernel/sysctl.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index beadcf83ceba..2f98b11477b8 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -126,6 +126,7 @@ static int __maybe_unused one = 1;
> static int __maybe_unused two = 2;
> static int __maybe_unused four = 4;
> static unsigned long one_ul = 1;
> +static unsigned long long_max = LONG_MAX;
> static int one_hundred = 100;
> #ifdef CONFIG_PRINTK
> static int ten_thousand = 10000;
> @@ -1603,6 +1604,8 @@ static struct ctl_table fs_table[] = {
> .maxlen = sizeof(files_stat.max_files),
> .mode = 0644,
> .proc_handler = proc_doulongvec_minmax,
> + .extra1 = &zero,
> + .extra2 = &long_max,
> },
> {
> .procname = "nr_open",
> --
> 2.19.1
>
>
>
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 014/168] sysctl: handle overflow for file-max
2019-04-24 21:50 ` Christian Brauner
@ 2019-04-25 8:15 ` Greg Kroah-Hartman
0 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-25 8:15 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-kernel, stable, Kees Cook, Alexey Dobriyan, Al Viro,
Dominik Brodowski, Eric W. Biederman, Joe Lawrence,
Luis Chamberlain, Waiman Long, Andrew Morton, Linus Torvalds,
Sasha Levin
On Wed, Apr 24, 2019 at 11:50:22PM +0200, Christian Brauner wrote:
> On Wed, Apr 24, 2019 at 7:16 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > [ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ]
> >
> > Currently, when writing
> >
> > echo 18446744073709551616 > /proc/sys/fs/file-max
> >
> > /proc/sys/fs/file-max will overflow and be set to 0. That quickly
> > crashes the system.
> >
> > This commit sets the max and min value for file-max. The max value is
> > set to long int. Any higher value cannot currently be used as the
> > percpu counters are long ints and not unsigned integers.
> >
> > Note that the file-max value is ultimately parsed via
> > __do_proc_doulongvec_minmax(). This function does not report error when
> > min or max are exceeded. Which means if a value largen that long int is
> > written userspace will not receive an error instead the old value will be
> > kept. There is an argument to be made that this should be changed and
> > __do_proc_doulongvec_minmax() should return an error when a dedicated min
> > or max value are exceeded. However this has the potential to break
> > userspace so let's defer this to an RFC patch.
> >
> > Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io
> > Signed-off-by: Christian Brauner <christian@brauner.io>
> > Acked-by: Kees Cook <keescook@chromium.org>
> > Cc: Alexey Dobriyan <adobriyan@gmail.com>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: Dominik Brodowski <linux@dominikbrodowski.net>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Cc: Joe Lawrence <joe.lawrence@redhat.com>
> > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > Cc: Waiman Long <longman@redhat.com>
> > [christian@brauner.io: v4]
> > Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> Hey Greg,
>
> Just an heads-up. This patch triggered a KASAN warning and Will has
> sent a fix for that
> which is already in master.
> So if you backport this patch you likely also want to backport
>
> 9002b21465fa4d829edfc94a5a441005cffaa972
>
> (See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9002b21465fa4d829edfc94a5a441005cffaa972
> )
>
> Seems we missed a Cc: for stable in there. Sorry about that.
No problem, thanks for letting me know, now queued up everywhere.
greg k-h
^ permalink raw reply [flat|nested] 178+ messages in thread
* [PATCH 4.4 015/168] enic: fix build warning without CONFIG_CPUMASK_OFFSTACK
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 014/168] sysctl: handle overflow for file-max Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 016/168] mm/cma.c: cma_declare_contiguous: correct err handling Greg Kroah-Hartman
` (157 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Nathan Chancellor,
David S. Miller, Sasha Levin
[ Upstream commit 43d281662fdb46750d49417559b71069f435298d ]
The enic driver relies on the CONFIG_CPUMASK_OFFSTACK feature to
dynamically allocate a struct member, but this is normally intended for
local variables.
Building with clang, I get a warning for a few locations that check the
address of the cpumask_var_t:
drivers/net/ethernet/cisco/enic/enic_main.c:122:22: error: address of array 'enic->msix[i].affinity_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
As far as I can tell, the code is still correct, as the truth value of
the pointer is what we need in this configuration. To get rid of
the warning, use cpumask_available() instead of checking the
pointer directly.
Fixes: 322cf7e3a4e8 ("enic: assign affinity hint to interrupts")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 9ef4caa4b84d..3c20d0dc9256 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -120,7 +120,7 @@ static void enic_init_affinity_hint(struct enic *enic)
for (i = 0; i < enic->intr_count; i++) {
if (enic_is_err_intr(enic, i) || enic_is_notify_intr(enic, i) ||
- (enic->msix[i].affinity_mask &&
+ (cpumask_available(enic->msix[i].affinity_mask) &&
!cpumask_empty(enic->msix[i].affinity_mask)))
continue;
if (zalloc_cpumask_var(&enic->msix[i].affinity_mask,
@@ -149,7 +149,7 @@ static void enic_set_affinity_hint(struct enic *enic)
for (i = 0; i < enic->intr_count; i++) {
if (enic_is_err_intr(enic, i) ||
enic_is_notify_intr(enic, i) ||
- !enic->msix[i].affinity_mask ||
+ !cpumask_available(enic->msix[i].affinity_mask) ||
cpumask_empty(enic->msix[i].affinity_mask))
continue;
err = irq_set_affinity_hint(enic->msix_entry[i].vector,
@@ -162,7 +162,7 @@ static void enic_set_affinity_hint(struct enic *enic)
for (i = 0; i < enic->wq_count; i++) {
int wq_intr = enic_msix_wq_intr(enic, i);
- if (enic->msix[wq_intr].affinity_mask &&
+ if (cpumask_available(enic->msix[wq_intr].affinity_mask) &&
!cpumask_empty(enic->msix[wq_intr].affinity_mask))
netif_set_xps_queue(enic->netdev,
enic->msix[wq_intr].affinity_mask,
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 016/168] mm/cma.c: cma_declare_contiguous: correct err handling
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 015/168] enic: fix build warning without CONFIG_CPUMASK_OFFSTACK Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 017/168] mm/page_ext.c: fix an imbalance with kmemleak Greg Kroah-Hartman
` (156 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peng Fan, Catalin Marinas,
Mike Rapoport, Laura Abbott, Joonsoo Kim, Michal Hocko,
Vlastimil Babka, Marek Szyprowski, Andrey Konovalov,
Andrew Morton, Linus Torvalds, Sasha Levin
[ Upstream commit 0d3bd18a5efd66097ef58622b898d3139790aa9d ]
In case cma_init_reserved_mem failed, need to free the memblock
allocated by memblock_reserve or memblock_alloc_range.
Quote Catalin's comments:
https://lkml.org/lkml/2019/2/26/482
Kmemleak is supposed to work with the memblock_{alloc,free} pair and it
ignores the memblock_reserve() as a memblock_alloc() implementation
detail. It is, however, tolerant to memblock_free() being called on
a sub-range or just a different range from a previous memblock_alloc().
So the original patch looks fine to me. FWIW:
Link: http://lkml.kernel.org/r/20190227144631.16708-1-peng.fan@nxp.com
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/cma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/cma.c b/mm/cma.c
index 43f4a122e969..f0d91aca5a4c 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -339,12 +339,14 @@ int __init cma_declare_contiguous(phys_addr_t base,
ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma);
if (ret)
- goto err;
+ goto free_mem;
pr_info("Reserved %ld MiB at %pa\n", (unsigned long)size / SZ_1M,
&base);
return 0;
+free_mem:
+ memblock_free(base, size);
err:
pr_err("Failed to reserve %ld MiB\n", (unsigned long)size / SZ_1M);
return ret;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 017/168] mm/page_ext.c: fix an imbalance with kmemleak
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 016/168] mm/cma.c: cma_declare_contiguous: correct err handling Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 018/168] mm/vmalloc.c: fix kernel BUG at mm/vmalloc.c:512! Greg Kroah-Hartman
` (155 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qian Cai, Catalin Marinas,
Andrew Morton, Linus Torvalds, Sasha Levin
[ Upstream commit 0c81585499601acd1d0e1cbf424cabfaee60628c ]
After offlining a memory block, kmemleak scan will trigger a crash, as
it encounters a page ext address that has already been freed during
memory offlining. At the beginning in alloc_page_ext(), it calls
kmemleak_alloc(), but it does not call kmemleak_free() in
free_page_ext().
BUG: unable to handle kernel paging request at ffff888453d00000
PGD 128a01067 P4D 128a01067 PUD 128a04067 PMD 47e09e067 PTE 800ffffbac2ff060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
CPU: 1 PID: 1594 Comm: bash Not tainted 5.0.0-rc8+ #15
Hardware name: HP ProLiant DL180 Gen9/ProLiant DL180 Gen9, BIOS U20 10/25/2017
RIP: 0010:scan_block+0xb5/0x290
Code: 85 6e 01 00 00 48 b8 00 00 30 f5 81 88 ff ff 48 39 c3 0f 84 5b 01 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 0f 85 87 01 00 00 <4c> 8b 3b e8 f3 0c fa ff 4c 39 3d 0c 6b 4c 01 0f 87 08 01 00 00 4c
RSP: 0018:ffff8881ec57f8e0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: ffff888453d00000 RCX: ffffffffa61e5a54
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888453d00000
RBP: ffff8881ec57f920 R08: fffffbfff4ed588d R09: fffffbfff4ed588c
R10: fffffbfff4ed588c R11: ffffffffa76ac463 R12: dffffc0000000000
R13: ffff888453d00ff9 R14: ffff8881f80cef48 R15: ffff8881f80cef48
FS: 00007f6c0e3f8740(0000) GS:ffff8881f7680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff888453d00000 CR3: 00000001c4244003 CR4: 00000000001606a0
Call Trace:
scan_gray_list+0x269/0x430
kmemleak_scan+0x5a8/0x10f0
kmemleak_write+0x541/0x6ca
full_proxy_write+0xf8/0x190
__vfs_write+0xeb/0x980
vfs_write+0x15a/0x4f0
ksys_write+0xd2/0x1b0
__x64_sys_write+0x73/0xb0
do_syscall_64+0xeb/0xaaa
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f6c0dad73b8
Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 63 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
RSP: 002b:00007ffd5b863cb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f6c0dad73b8
RDX: 0000000000000005 RSI: 000055a9216e1710 RDI: 0000000000000001
RBP: 000055a9216e1710 R08: 000000000000000a R09: 00007ffd5b863840
R10: 000000000000000a R11: 0000000000000246 R12: 00007f6c0dda9780
R13: 0000000000000005 R14: 00007f6c0dda4740 R15: 0000000000000005
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm irqbypass efivars ip_tables x_tables xfs sd_mod ahci libahci igb i2c_algo_bit libata i2c_core dm_mirror dm_region_hash dm_log dm_mod efivarfs
CR2: ffff888453d00000
---[ end trace ccf646c7456717c5 ]---
Kernel panic - not syncing: Fatal exception
Shutting down cpus with NMI
Kernel Offset: 0x24c00000 from 0xffffffff81000000 (relocation range:
0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---
Link: http://lkml.kernel.org/r/20190227173147.75650-1-cai@lca.pw
Signed-off-by: Qian Cai <cai@lca.pw>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/page_ext.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 4d1eac0d4fc5..de1f34c5a2f1 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -255,6 +255,7 @@ static void free_page_ext(void *addr)
table_size = sizeof(struct page_ext) * PAGES_PER_SECTION;
BUG_ON(PageReserved(page));
+ kmemleak_free(addr);
free_pages_exact(addr, table_size);
}
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 018/168] mm/vmalloc.c: fix kernel BUG at mm/vmalloc.c:512!
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 017/168] mm/page_ext.c: fix an imbalance with kmemleak Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 019/168] mm/slab.c: kmemleak no scan alien caches Greg Kroah-Hartman
` (154 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Uladzislau Rezki (Sony),
Andrew Morton, Ingo Molnar, Joel Fernandes, Matthew Wilcox,
Michal Hocko, Oleksiy Avramchenko, Steven Rostedt, Tejun Heo,
Thomas Garnier, Thomas Gleixner, Linus Torvalds, Sasha Levin
[ Upstream commit afd07389d3f4933c7f7817a92fb5e053d59a3182 ]
One of the vmalloc stress test case triggers the kernel BUG():
<snip>
[60.562151] ------------[ cut here ]------------
[60.562154] kernel BUG at mm/vmalloc.c:512!
[60.562206] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[60.562247] CPU: 0 PID: 430 Comm: vmalloc_test/0 Not tainted 4.20.0+ #161
[60.562293] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[60.562351] RIP: 0010:alloc_vmap_area+0x36f/0x390
<snip>
it can happen due to big align request resulting in overflowing of
calculated address, i.e. it becomes 0 after ALIGN()'s fixup.
Fix it by checking if calculated address is within vstart/vend range.
Link: http://lkml.kernel.org/r/20190124115648.9433-2-urezki@gmail.com
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/vmalloc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 400e580725da..7c556b59f0ec 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -446,7 +446,11 @@ nocache:
}
found:
- if (addr + size > vend)
+ /*
+ * Check also calculated address against the vstart,
+ * because it can be 0 because of big align request.
+ */
+ if (addr + size > vend || addr < vstart)
goto overflow;
va->va_start = addr;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 019/168] mm/slab.c: kmemleak no scan alien caches
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 018/168] mm/vmalloc.c: fix kernel BUG at mm/vmalloc.c:512! Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 020/168] ocfs2: fix a panic problem caused by o2cb_ctl Greg Kroah-Hartman
` (153 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qian Cai, Andrew Morton,
Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
Catalin Marinas, Linus Torvalds, Sasha Levin
[ Upstream commit 92d1d07daad65c300c7d0b68bbef8867e9895d54 ]
Kmemleak throws endless warnings during boot due to in
__alloc_alien_cache(),
alc = kmalloc_node(memsize, gfp, node);
init_arraycache(&alc->ac, entries, batch);
kmemleak_no_scan(ac);
Kmemleak does not track the array cache (alc->ac) but the alien cache
(alc) instead, so let it track the latter by lifting kmemleak_no_scan()
out of init_arraycache().
There is another place that calls init_arraycache(), but
alloc_kmem_cache_cpus() uses the percpu allocation where will never be
considered as a leak.
kmemleak: Found object by alias at 0xffff8007b9aa7e38
CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2
Call trace:
dump_backtrace+0x0/0x168
show_stack+0x24/0x30
dump_stack+0x88/0xb0
lookup_object+0x84/0xac
find_and_get_object+0x84/0xe4
kmemleak_no_scan+0x74/0xf4
setup_kmem_cache_node+0x2b4/0x35c
__do_tune_cpucache+0x250/0x2d4
do_tune_cpucache+0x4c/0xe4
enable_cpucache+0xc8/0x110
setup_cpu_cache+0x40/0x1b8
__kmem_cache_create+0x240/0x358
create_cache+0xc0/0x198
kmem_cache_create_usercopy+0x158/0x20c
kmem_cache_create+0x50/0x64
fsnotify_init+0x58/0x6c
do_one_initcall+0x194/0x388
kernel_init_freeable+0x668/0x688
kernel_init+0x18/0x124
ret_from_fork+0x10/0x18
kmemleak: Object 0xffff8007b9aa7e00 (size 256):
kmemleak: comm "swapper/0", pid 1, jiffies 4294697137
kmemleak: min_count = 1
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak: checksum = 0
kmemleak: backtrace:
kmemleak_alloc+0x84/0xb8
kmem_cache_alloc_node_trace+0x31c/0x3a0
__kmalloc_node+0x58/0x78
setup_kmem_cache_node+0x26c/0x35c
__do_tune_cpucache+0x250/0x2d4
do_tune_cpucache+0x4c/0xe4
enable_cpucache+0xc8/0x110
setup_cpu_cache+0x40/0x1b8
__kmem_cache_create+0x240/0x358
create_cache+0xc0/0x198
kmem_cache_create_usercopy+0x158/0x20c
kmem_cache_create+0x50/0x64
fsnotify_init+0x58/0x6c
do_one_initcall+0x194/0x388
kernel_init_freeable+0x668/0x688
kernel_init+0x18/0x124
kmemleak: Not scanning unknown object at 0xffff8007b9aa7e38
CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2
Call trace:
dump_backtrace+0x0/0x168
show_stack+0x24/0x30
dump_stack+0x88/0xb0
kmemleak_no_scan+0x90/0xf4
setup_kmem_cache_node+0x2b4/0x35c
__do_tune_cpucache+0x250/0x2d4
do_tune_cpucache+0x4c/0xe4
enable_cpucache+0xc8/0x110
setup_cpu_cache+0x40/0x1b8
__kmem_cache_create+0x240/0x358
create_cache+0xc0/0x198
kmem_cache_create_usercopy+0x158/0x20c
kmem_cache_create+0x50/0x64
fsnotify_init+0x58/0x6c
do_one_initcall+0x194/0x388
kernel_init_freeable+0x668/0x688
kernel_init+0x18/0x124
ret_from_fork+0x10/0x18
Link: http://lkml.kernel.org/r/20190129184518.39808-1-cai@lca.pw
Fixes: 1fe00d50a9e8 ("slab: factor out initialization of array cache")
Signed-off-by: Qian Cai <cai@lca.pw>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/slab.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 92df044f5e00..d043b8007f23 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -660,14 +660,6 @@ static void start_cpu_timer(int cpu)
static void init_arraycache(struct array_cache *ac, int limit, int batch)
{
- /*
- * The array_cache structures contain pointers to free object.
- * However, when such objects are allocated or transferred to another
- * cache the pointers are not cleared and they could be counted as
- * valid references during a kmemleak scan. Therefore, kmemleak must
- * not scan such objects.
- */
- kmemleak_no_scan(ac);
if (ac) {
ac->avail = 0;
ac->limit = limit;
@@ -683,6 +675,14 @@ static struct array_cache *alloc_arraycache(int node, int entries,
struct array_cache *ac = NULL;
ac = kmalloc_node(memsize, gfp, node);
+ /*
+ * The array_cache structures contain pointers to free object.
+ * However, when such objects are allocated or transferred to another
+ * cache the pointers are not cleared and they could be counted as
+ * valid references during a kmemleak scan. Therefore, kmemleak must
+ * not scan such objects.
+ */
+ kmemleak_no_scan(ac);
init_arraycache(ac, entries, batchcount);
return ac;
}
@@ -876,6 +876,7 @@ static struct alien_cache *__alloc_alien_cache(int node, int entries,
alc = kmalloc_node(memsize, gfp, node);
if (alc) {
+ kmemleak_no_scan(alc);
init_arraycache(&alc->ac, entries, batch);
spin_lock_init(&alc->lock);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 020/168] ocfs2: fix a panic problem caused by o2cb_ctl
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 019/168] mm/slab.c: kmemleak no scan alien caches Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 021/168] f2fs: do not use mutex lock in atomic context Greg Kroah-Hartman
` (152 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jia Guo, Joseph Qi, Jun Piao,
Mark Fasheh, Joel Becker, Junxiao Bi, Changwei Ge, Andrew Morton,
Linus Torvalds, Sasha Levin
[ Upstream commit cc725ef3cb202ef2019a3c67c8913efa05c3cce6 ]
In the process of creating a node, it will cause NULL pointer
dereference in kernel if o2cb_ctl failed in the interval (mkdir,
o2cb_set_node_attribute(node_num)] in function o2cb_add_node.
The node num is initialized to 0 in function o2nm_node_group_make_item,
o2nm_node_group_drop_item will mistake the node number 0 for a valid
node number when we delete the node before the node number is set
correctly. If the local node number of the current host happens to be
0, cluster->cl_local_node will be set to O2NM_INVALID_NODE_NUM while
o2hb_thread still running. The panic stack is generated as follows:
o2hb_thread
\-o2hb_do_disk_heartbeat
\-o2hb_check_own_slot
|-slot = ®->hr_slots[o2nm_this_node()];
//o2nm_this_node() return O2NM_INVALID_NODE_NUM
We need to check whether the node number is set when we delete the node.
Link: http://lkml.kernel.org/r/133d8045-72cc-863e-8eae-5013f9f6bc51@huawei.com
Signed-off-by: Jia Guo <guojia12@huawei.com>
Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
Acked-by: Jun Piao <piaojun@huawei.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <ge.changwei@h3c.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/ocfs2/cluster/nodemanager.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/ocfs2/cluster/nodemanager.c b/fs/ocfs2/cluster/nodemanager.c
index 3c45a9301a09..a87a08e1bfab 100644
--- a/fs/ocfs2/cluster/nodemanager.c
+++ b/fs/ocfs2/cluster/nodemanager.c
@@ -621,13 +621,15 @@ static void o2nm_node_group_drop_item(struct config_group *group,
struct o2nm_node *node = to_o2nm_node(item);
struct o2nm_cluster *cluster = to_o2nm_cluster(group->cg_item.ci_parent);
- o2net_disconnect_node(node);
+ if (cluster->cl_nodes[node->nd_num] == node) {
+ o2net_disconnect_node(node);
- if (cluster->cl_has_local &&
- (cluster->cl_local_node == node->nd_num)) {
- cluster->cl_has_local = 0;
- cluster->cl_local_node = O2NM_INVALID_NODE_NUM;
- o2net_stop_listening(node);
+ if (cluster->cl_has_local &&
+ (cluster->cl_local_node == node->nd_num)) {
+ cluster->cl_has_local = 0;
+ cluster->cl_local_node = O2NM_INVALID_NODE_NUM;
+ o2net_stop_listening(node);
+ }
}
/* XXX call into net to stop this node from trading messages */
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 021/168] f2fs: do not use mutex lock in atomic context
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 020/168] ocfs2: fix a panic problem caused by o2cb_ctl Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 022/168] fs/file.c: initialize init_files.resize_wait Greg Kroah-Hartman
` (151 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sahitya Tummala, Chao Yu,
Jaegeuk Kim, Sasha Levin
[ Upstream commit 9083977dabf3833298ddcd40dee28687f1e6b483 ]
Fix below warning coming because of using mutex lock in atomic context.
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:98
in_atomic(): 1, irqs_disabled(): 0, pid: 585, name: sh
Preemption disabled at: __radix_tree_preload+0x28/0x130
Call trace:
dump_backtrace+0x0/0x2b4
show_stack+0x20/0x28
dump_stack+0xa8/0xe0
___might_sleep+0x144/0x194
__might_sleep+0x58/0x8c
mutex_lock+0x2c/0x48
f2fs_trace_pid+0x88/0x14c
f2fs_set_node_page_dirty+0xd0/0x184
Do not use f2fs_radix_tree_insert() to avoid doing cond_resched() with
spin_lock() acquired.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/f2fs/trace.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/trace.c b/fs/f2fs/trace.c
index 145fb659ad44..8f327fa7ae47 100644
--- a/fs/f2fs/trace.c
+++ b/fs/f2fs/trace.c
@@ -60,6 +60,7 @@ void f2fs_trace_pid(struct page *page)
page->private = pid;
+retry:
if (radix_tree_preload(GFP_NOFS))
return;
@@ -70,7 +71,12 @@ void f2fs_trace_pid(struct page *page)
if (p)
radix_tree_delete(&pids, pid);
- f2fs_radix_tree_insert(&pids, pid, current);
+ if (radix_tree_insert(&pids, pid, current)) {
+ spin_unlock(&pids_lock);
+ radix_tree_preload_end();
+ cond_resched();
+ goto retry;
+ }
trace_printk("%3x:%3x %4x %-16s\n",
MAJOR(inode->i_sb->s_dev), MINOR(inode->i_sb->s_dev),
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 022/168] fs/file.c: initialize init_files.resize_wait
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 021/168] f2fs: do not use mutex lock in atomic context Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 023/168] cifs: use correct format characters Greg Kroah-Hartman
` (150 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Richard Zhang, Andrew Morton,
Al Viro, Linus Torvalds, Sasha Levin
[ Upstream commit 5704a06810682683355624923547b41540e2801a ]
(Taken from https://bugzilla.kernel.org/show_bug.cgi?id=200647)
'get_unused_fd_flags' in kthread cause kernel crash. It works fine on
4.1, but causes crash after get 64 fds. It also cause crash on
ubuntu1404/1604/1804, centos7.5, and the crash messages are almost the
same.
The crash message on centos7.5 shows below:
start fd 61
start fd 62
start fd 63
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: __wake_up_common+0x2e/0x90
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: test(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter devlink sunrpc kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd sg ppdev pcspkr virtio_balloon parport_pc parport i2c_piix4 joydev ip_tables xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi virtio_scsi virtio_console virtio_net cirrus drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul crct10dif_common crc32c_intel drm ata_piix serio_raw libata virtio_pci virtio_ring i2c_core
virtio floppy dm_mirror dm_region_hash dm_log dm_mod
CPU: 2 PID: 1820 Comm: test_fd Kdump: loaded Tainted: G OE ------------ 3.10.0-862.3.3.el7.x86_64 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
task: ffff8e92b9431fa0 ti: ffff8e94247a0000 task.ti: ffff8e94247a0000
RIP: 0010:__wake_up_common+0x2e/0x90
RSP: 0018:ffff8e94247a2d18 EFLAGS: 00010086
RAX: 0000000000000000 RBX: ffffffff9d09daa0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffff9d09daa0
RBP: ffff8e94247a2d50 R08: 0000000000000000 R09: ffff8e92b95dfda8
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9d09daa8
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8e9434e80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000017c686000 CR4: 00000000000207e0
Call Trace:
__wake_up+0x39/0x50
expand_files+0x131/0x250
__alloc_fd+0x47/0x170
get_unused_fd_flags+0x30/0x40
test_fd+0x12a/0x1c0 [test]
kthread+0xd1/0xe0
ret_from_fork_nospec_begin+0x21/0x21
Code: 66 90 55 48 89 e5 41 57 41 89 f7 41 56 41 89 ce 41 55 41 54 49 89 fc 49 83 c4 08 53 48 83 ec 10 48 8b 47 08 89 55 cc 4c 89 45 d0 <48> 8b 08 49 39 c4 48 8d 78 e8 4c 8d 69 e8 75 08 eb 3b 4c 89 ef
RIP __wake_up_common+0x2e/0x90
RSP <ffff8e94247a2d18>
CR2: 0000000000000000
This issue exists since CentOS 7.5 3.10.0-862 and CentOS 7.4
(3.10.0-693.21.1 ) is ok. Root cause: the item 'resize_wait' is not
initialized before being used.
Reported-by: Richard Zhang <zhang.zijian@h3c.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/file.c b/fs/file.c
index 39f8f15921da..7e9eb65a2912 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -474,6 +474,7 @@ struct files_struct init_files = {
.full_fds_bits = init_files.full_fds_bits_init,
},
.file_lock = __SPIN_LOCK_UNLOCKED(init_files.file_lock),
+ .resize_wait = __WAIT_QUEUE_HEAD_INITIALIZER(init_files.resize_wait),
};
static unsigned long find_next_fd(struct fdtable *fdt, unsigned long start)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 023/168] cifs: use correct format characters
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 022/168] fs/file.c: initialize init_files.resize_wait Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 024/168] dm thin: add sanity checks to thin-pool and external snapshot creation Greg Kroah-Hartman
` (149 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Louis Taylor, Steve French,
Nick Desaulniers, Sasha Levin
[ Upstream commit 259594bea574e515a148171b5cd84ce5cbdc028a ]
When compiling with -Wformat, clang emits the following warnings:
fs/cifs/smb1ops.c:312:20: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
tgt_total_cnt, total_in_tgt);
^~~~~~~~~~~~
fs/cifs/cifs_dfs_ref.c:289:4: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->flags, ref->server_type);
^~~~~~~~~~
fs/cifs/cifs_dfs_ref.c:289:16: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->flags, ref->server_type);
^~~~~~~~~~~~~~~~
fs/cifs/cifs_dfs_ref.c:291:4: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->ref_flag, ref->path_consumed);
^~~~~~~~~~~~~
fs/cifs/cifs_dfs_ref.c:291:19: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
ref->ref_flag, ref->path_consumed);
^~~~~~~~~~~~~~~~~~
The types of these arguments are unconditionally defined, so this patch
updates the format character to the correct ones for ints and unsigned
ints.
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Louis Taylor <louis@kragniz.eu>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/cifs_dfs_ref.c | 4 ++--
fs/cifs/smb1ops.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/cifs_dfs_ref.c b/fs/cifs/cifs_dfs_ref.c
index 7dc886c9a78f..1ea643faf04b 100644
--- a/fs/cifs/cifs_dfs_ref.c
+++ b/fs/cifs/cifs_dfs_ref.c
@@ -266,9 +266,9 @@ static void dump_referral(const struct dfs_info3_param *ref)
{
cifs_dbg(FYI, "DFS: ref path: %s\n", ref->path_name);
cifs_dbg(FYI, "DFS: node path: %s\n", ref->node_name);
- cifs_dbg(FYI, "DFS: fl: %hd, srv_type: %hd\n",
+ cifs_dbg(FYI, "DFS: fl: %d, srv_type: %d\n",
ref->flags, ref->server_type);
- cifs_dbg(FYI, "DFS: ref_flags: %hd, path_consumed: %hd\n",
+ cifs_dbg(FYI, "DFS: ref_flags: %d, path_consumed: %d\n",
ref->ref_flag, ref->path_consumed);
}
diff --git a/fs/cifs/smb1ops.c b/fs/cifs/smb1ops.c
index efd72e1fae74..f7a9adab0b84 100644
--- a/fs/cifs/smb1ops.c
+++ b/fs/cifs/smb1ops.c
@@ -305,7 +305,7 @@ coalesce_t2(char *second_buf, struct smb_hdr *target_hdr)
remaining = tgt_total_cnt - total_in_tgt;
if (remaining < 0) {
- cifs_dbg(FYI, "Server sent too much data. tgt_total_cnt=%hu total_in_tgt=%hu\n",
+ cifs_dbg(FYI, "Server sent too much data. tgt_total_cnt=%hu total_in_tgt=%u\n",
tgt_total_cnt, total_in_tgt);
return -EPROTO;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 024/168] dm thin: add sanity checks to thin-pool and external snapshot creation
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 023/168] cifs: use correct format characters Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 025/168] cifs: Fix NULL pointer dereference of devname Greg Kroah-Hartman
` (148 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Cai (Xiang Feng),
Mike Snitzer, Sasha Levin
[ Upstream commit 70de2cbda8a5d788284469e755f8b097d339c240 ]
Invoking dm_get_device() twice on the same device path with different
modes is dangerous. Because in that case, upgrade_mode() will alloc a
new 'dm_dev' and free the old one, which may be referenced by a previous
caller. Dereferencing the dangling pointer will trigger kernel NULL
pointer dereference.
The following two cases can reproduce this issue. Actually, they are
invalid setups that must be disallowed, e.g.:
1. Creating a thin-pool with read_only mode, and the same device as
both metadata and data.
dmsetup create thinp --table \
"0 41943040 thin-pool /dev/vdb /dev/vdb 128 0 1 read_only"
BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
...
Call Trace:
new_read+0xfb/0x110 [dm_bufio]
dm_bm_read_lock+0x43/0x190 [dm_persistent_data]
? kmem_cache_alloc_trace+0x15c/0x1e0
__create_persistent_data_objects+0x65/0x3e0 [dm_thin_pool]
dm_pool_metadata_open+0x8c/0xf0 [dm_thin_pool]
pool_ctr.cold.79+0x213/0x913 [dm_thin_pool]
? realloc_argv+0x50/0x70 [dm_mod]
dm_table_add_target+0x14e/0x330 [dm_mod]
table_load+0x122/0x2e0 [dm_mod]
? dev_status+0x40/0x40 [dm_mod]
ctl_ioctl+0x1aa/0x3e0 [dm_mod]
dm_ctl_ioctl+0xa/0x10 [dm_mod]
do_vfs_ioctl+0xa2/0x600
? handle_mm_fault+0xda/0x200
? __do_page_fault+0x26c/0x4f0
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x55/0x150
entry_SYSCALL_64_after_hwframe+0x44/0xa9
2. Creating a external snapshot using the same thin-pool device.
dmsetup create thinp --table \
"0 41943040 thin-pool /dev/vdc /dev/vdb 128 0 2 ignore_discard"
dmsetup message /dev/mapper/thinp 0 "create_thin 0"
dmsetup create snap --table \
"0 204800 thin /dev/mapper/thinp 0 /dev/mapper/thinp"
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
...
Call Trace:
? __alloc_pages_nodemask+0x13c/0x2e0
retrieve_status+0xa5/0x1f0 [dm_mod]
? dm_get_live_or_inactive_table.isra.7+0x20/0x20 [dm_mod]
table_status+0x61/0xa0 [dm_mod]
ctl_ioctl+0x1aa/0x3e0 [dm_mod]
dm_ctl_ioctl+0xa/0x10 [dm_mod]
do_vfs_ioctl+0xa2/0x600
ksys_ioctl+0x60/0x90
? ksys_write+0x4f/0xb0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x55/0x150
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Jason Cai (Xiang Feng) <jason.cai@linux.alibaba.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/dm-thin.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 07eaa9f90712..d52ea584e0bc 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -3210,6 +3210,13 @@ static int pool_ctr(struct dm_target *ti, unsigned argc, char **argv)
as.argc = argc;
as.argv = argv;
+ /* make sure metadata and data are different devices */
+ if (!strcmp(argv[0], argv[1])) {
+ ti->error = "Error setting metadata or data device";
+ r = -EINVAL;
+ goto out_unlock;
+ }
+
/*
* Set default pool features.
*/
@@ -4092,6 +4099,12 @@ static int thin_ctr(struct dm_target *ti, unsigned argc, char **argv)
tc->sort_bio_list = RB_ROOT;
if (argc == 3) {
+ if (!strcmp(argv[0], argv[2])) {
+ ti->error = "Error setting origin device";
+ r = -EINVAL;
+ goto bad_origin_dev;
+ }
+
r = dm_get_device(ti, argv[2], FMODE_READ, &origin_dev);
if (r) {
ti->error = "Error opening origin device";
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 025/168] cifs: Fix NULL pointer dereference of devname
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 024/168] dm thin: add sanity checks to thin-pool and external snapshot creation Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 026/168] fs: fix guard_bio_eod to check for real EOD errors Greg Kroah-Hartman
` (147 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yao Liu, Steve French, Sasha Levin
[ Upstream commit 68e2672f8fbd1e04982b8d2798dd318bf2515dd2 ]
There is a NULL pointer dereference of devname in strspn()
The oops looks something like:
CIFS: Attempting to mount (null)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
...
RIP: 0010:strspn+0x0/0x50
...
Call Trace:
? cifs_parse_mount_options+0x222/0x1710 [cifs]
? cifs_get_volume_info+0x2f/0x80 [cifs]
cifs_setup_volume_info+0x20/0x190 [cifs]
cifs_get_volume_info+0x50/0x80 [cifs]
cifs_smb3_do_mount+0x59/0x630 [cifs]
? ida_alloc_range+0x34b/0x3d0
cifs_do_mount+0x11/0x20 [cifs]
mount_fs+0x52/0x170
vfs_kern_mount+0x6b/0x170
do_mount+0x216/0xdc0
ksys_mount+0x83/0xd0
__x64_sys_mount+0x25/0x30
do_syscall_64+0x65/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fix this by adding a NULL check on devname in cifs_parse_devname()
Signed-off-by: Yao Liu <yotta.liu@ucloud.cn>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/connect.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index eacf57c24ca9..9cb72fd40eff 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1255,6 +1255,11 @@ cifs_parse_devname(const char *devname, struct smb_vol *vol)
const char *delims = "/\\";
size_t len;
+ if (unlikely(!devname || !*devname)) {
+ cifs_dbg(VFS, "Device name not specified.\n");
+ return -EINVAL;
+ }
+
/* make sure we have a valid UNC double delimiter prefix */
len = strspn(devname, delims);
if (len != 2)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 026/168] fs: fix guard_bio_eod to check for real EOD errors
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 025/168] cifs: Fix NULL pointer dereference of devname Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 027/168] tools lib traceevent: Fix buffer overflow in arg_eval Greg Kroah-Hartman
` (146 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ming Lei, Carlos Maiolino,
Jens Axboe, Sasha Levin
[ Upstream commit dce30ca9e3b676fb288c33c1f4725a0621361185 ]
guard_bio_eod() can truncate a segment in bio to allow it to do IO on
odd last sectors of a device.
It already checks if the IO starts past EOD, but it does not consider
the possibility of an IO request starting within device boundaries can
contain more than one segment past EOD.
In such cases, truncated_bytes can be bigger than PAGE_SIZE, and will
underflow bvec->bv_len.
Fix this by checking if truncated_bytes is lower than PAGE_SIZE.
This situation has been found on filesystems such as isofs and vfat,
which doesn't check the device size before mount, if the device is
smaller than the filesystem itself, a readahead on such filesystem,
which spans EOD, can trigger this situation, leading a call to
zero_user() with a wrong size possibly corrupting memory.
I didn't see any crash, or didn't let the system run long enough to
check if memory corruption will be hit somewhere, but adding
instrumentation to guard_bio_end() to check truncated_bytes size, was
enough to see the error.
The following script can trigger the error.
MNT=/mnt
IMG=./DISK.img
DEV=/dev/loop0
mkfs.vfat $IMG
mount $IMG $MNT
cp -R /etc $MNT &> /dev/null
umount $MNT
losetup -D
losetup --find --show --sizelimit 16247280 $IMG
mount $DEV $MNT
find $MNT -type f -exec cat {} + >/dev/null
Kudos to Eric Sandeen for coming up with the reproducer above
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/buffer.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/buffer.c b/fs/buffer.c
index 6f7d519a093b..f278e27bd8c0 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2985,6 +2985,13 @@ void guard_bio_eod(int rw, struct bio *bio)
/* Uhhuh. We've got a bio that straddles the device size! */
truncated_bytes = bio->bi_iter.bi_size - (maxsector << 9);
+ /*
+ * The bio contains more than one segment which spans EOD, just return
+ * and let IO layer turn it into an EIO
+ */
+ if (truncated_bytes > bvec->bv_len)
+ return;
+
/* Truncate the bio.. */
bio->bi_iter.bi_size -= truncated_bytes;
bvec->bv_len -= truncated_bytes;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 027/168] tools lib traceevent: Fix buffer overflow in arg_eval
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 026/168] fs: fix guard_bio_eod to check for real EOD errors Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 028/168] usb: chipidea: Grab the (legacy) USB PHY by phandle first Greg Kroah-Hartman
` (145 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Sartain, Mathias Krause,
Tony Jones, Steven Rostedt (VMware),
Frederic Weisbecker, Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ]
Fix buffer overflow observed when running perf test.
The overflow is when trying to evaluate "1ULL << (64 - 1)" which is
resulting in -9223372036854775808 which overflows the 20 character
buffer.
If is possible this bug has been reported before but I still don't see
any fix checked in:
See: https://www.spinics.net/lists/linux-perf-users/msg07714.html
Reported-by: Michael Sartain <mikesart@fastmail.com>
Reported-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Tony Jones <tonyj@suse.de>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a")
Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@suse.de
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/traceevent/event-parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index 6e4a10fe9dd0..743746a3c50d 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -2419,7 +2419,7 @@ static int arg_num_eval(struct print_arg *arg, long long *val)
static char *arg_eval (struct print_arg *arg)
{
long long val;
- static char buf[20];
+ static char buf[24];
switch (arg->type) {
case PRINT_ATOM:
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 028/168] usb: chipidea: Grab the (legacy) USB PHY by phandle first
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 027/168] tools lib traceevent: Fix buffer overflow in arg_eval Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 029/168] scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c Greg Kroah-Hartman
` (144 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Kocialkowski, Peter Chen, Sasha Levin
[ Upstream commit 68ef236274793066b9ba3154b16c0acc1c891e5c ]
According to the chipidea driver bindings, the USB PHY is specified via
the "phys" phandle node. However, this only takes effect for USB PHYs
that use the common PHY framework. For legacy USB PHYs, a simple lookup
based on the USB PHY type is done instead.
This does not play out well when more than one USB PHY is registered,
since the first registered PHY matching the type will always be
returned regardless of what the driver was bound to.
Fix this by looking up the PHY based on the "phys" phandle node.
Although generic PHYs are rather matched by their "phys-name" and not
the "phys" phandle directly, there is no helper for similar lookup on
legacy PHYs and it's probably not worth the effort to add it.
When no legacy USB PHY is found by phandle, fallback to grabbing any
registered USB2 PHY. This ensures backward compatibility if some users
were actually relying on this mechanism.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/chipidea/core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 57ee43512992..dee22d8effda 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -913,8 +913,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
} else if (ci->platdata->usb_phy) {
ci->usb_phy = ci->platdata->usb_phy;
} else {
+ ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys",
+ 0);
ci->phy = devm_phy_get(dev->parent, "usb-phy");
- ci->usb_phy = devm_usb_get_phy(dev->parent, USB_PHY_TYPE_USB2);
+
+ /* Fallback to grabbing any registered USB2 PHY */
+ if (IS_ERR(ci->usb_phy) &&
+ PTR_ERR(ci->usb_phy) != -EPROBE_DEFER)
+ ci->usb_phy = devm_usb_get_phy(dev->parent,
+ USB_PHY_TYPE_USB2);
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci->phy) == -ENOSYS &&
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 029/168] scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 028/168] usb: chipidea: Grab the (legacy) USB PHY by phandle first Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 030/168] coresight: etm4x: Add support to enable ETMv4.2 Greg Kroah-Hartman
` (143 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benjamin Block, Bart Van Assche,
Martin K. Petersen, Sasha Levin
[ Upstream commit 1749ef00f7312679f76d5e9104c5d1e22a829038 ]
We had a test-report where, under memory pressure, adding LUNs to the
systems would fail (the tests add LUNs strictly in sequence):
[ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5
[ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS
[ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43
[ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0
[ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection
[ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB)
[ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off
[ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08
[ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 5525.857838] sdk: sdk1
[ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk
[ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds
[ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
[ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
Looking at the code of scsi_alloc_sdev(), and all the calling contexts,
there seems to be no reason to use GFP_ATMOIC here. All the different
call-contexts use a mutex at some point, and nothing in between that
requires no sleeping, as far as I could see. Additionally, the code that
later allocates the block queue for the device (scsi_mq_alloc_queue())
already uses GFP_KERNEL.
There are similar allocations in two other functions:
scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with
GFP_KERNEL.
Here is the contexts for the three functions so far:
scsi_alloc_sdev()
scsi_probe_and_add_lun()
scsi_sequential_lun_scan()
__scsi_scan_target()
scsi_scan_target()
mutex_lock()
scsi_scan_channel()
scsi_scan_host_selected()
mutex_lock()
scsi_report_lun_scan()
__scsi_scan_target()
...
__scsi_add_device()
mutex_lock()
__scsi_scan_target()
...
scsi_report_lun_scan()
...
scsi_get_host_dev()
mutex_lock()
scsi_probe_and_add_lun()
...
scsi_add_lun()
scsi_probe_and_add_lun()
...
So replace all these, and give them a bit of a better chance to succeed,
with more chances of reclaim.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/scsi_scan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 850ddc5fac04..3e2288af56bc 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -217,7 +217,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
extern void scsi_requeue_run_queue(struct work_struct *work);
sdev = kzalloc(sizeof(*sdev) + shost->transportt->device_size,
- GFP_ATOMIC);
+ GFP_KERNEL);
if (!sdev)
goto out;
@@ -791,7 +791,7 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result,
*/
sdev->inquiry = kmemdup(inq_result,
max_t(size_t, sdev->inquiry_len, 36),
- GFP_ATOMIC);
+ GFP_KERNEL);
if (sdev->inquiry == NULL)
return SCSI_SCAN_NO_RESPONSE;
@@ -1085,7 +1085,7 @@ static int scsi_probe_and_add_lun(struct scsi_target *starget,
if (!sdev)
goto out;
- result = kmalloc(result_len, GFP_ATOMIC |
+ result = kmalloc(result_len, GFP_KERNEL |
((shost->unchecked_isa_dma) ? __GFP_DMA : 0));
if (!result)
goto out_free_sdev;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 030/168] coresight: etm4x: Add support to enable ETMv4.2
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 029/168] scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 031/168] ARM: 8840/1: use a raw_spinlock_t in unwind Greg Kroah-Hartman
` (142 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sai Prakash Ranjan, Suzuki K Poulose,
Mathieu Poirier, Sasha Levin
[ Upstream commit 5666dfd1d8a45a167f0d8b4ef47ea7f780b1f24a ]
SDM845 has ETMv4.2 and can use the existing etm4x driver.
But the current etm driver checks only for ETMv4.0 and
errors out for other etm4x versions. This patch adds this
missing support to enable SoC's with ETMv4x to use same
driver by checking only the ETM architecture major version
number.
Without this change, we get below error during etm probe:
/ # dmesg | grep etm
[ 6.660093] coresight-etm4x: probe of 7040000.etm failed with error -22
[ 6.666902] coresight-etm4x: probe of 7140000.etm failed with error -22
[ 6.673708] coresight-etm4x: probe of 7240000.etm failed with error -22
[ 6.680511] coresight-etm4x: probe of 7340000.etm failed with error -22
[ 6.687313] coresight-etm4x: probe of 7440000.etm failed with error -22
[ 6.694113] coresight-etm4x: probe of 7540000.etm failed with error -22
[ 6.700914] coresight-etm4x: probe of 7640000.etm failed with error -22
[ 6.707717] coresight-etm4x: probe of 7740000.etm failed with error -22
With this change, etm probe is successful:
/ # dmesg | grep etm
[ 6.659198] coresight-etm4x 7040000.etm: CPU0: ETM v4.2 initialized
[ 6.665848] coresight-etm4x 7140000.etm: CPU1: ETM v4.2 initialized
[ 6.672493] coresight-etm4x 7240000.etm: CPU2: ETM v4.2 initialized
[ 6.679129] coresight-etm4x 7340000.etm: CPU3: ETM v4.2 initialized
[ 6.685770] coresight-etm4x 7440000.etm: CPU4: ETM v4.2 initialized
[ 6.692403] coresight-etm4x 7540000.etm: CPU5: ETM v4.2 initialized
[ 6.699024] coresight-etm4x 7640000.etm: CPU6: ETM v4.2 initialized
[ 6.705646] coresight-etm4x 7740000.etm: CPU7: ETM v4.2 initialized
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 0edc10b44004..c80cc18747cb 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -54,7 +54,8 @@ static void etm4_os_unlock(void *info)
static bool etm4_arch_supported(u8 arch)
{
- switch (arch) {
+ /* Mask out the minor version number */
+ switch (arch & 0xf0) {
case ETM_ARCH_V4:
break;
default:
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 031/168] ARM: 8840/1: use a raw_spinlock_t in unwind
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 030/168] coresight: etm4x: Add support to enable ETMv4.2 Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 032/168] mmc: omap: fix the maximum timeout setting Greg Kroah-Hartman
` (141 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sebastian Andrzej Siewior,
Russell King, Sasha Levin
[ Upstream commit 74ffe79ae538283bbf7c155e62339f1e5c87b55a ]
Mostly unwind is done with irqs enabled however SLUB may call it with
irqs disabled while creating a new SLUB cache.
I had system freeze while loading a module which called
kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled
interrupts and then
->new_slab_objects()
->new_slab()
->setup_object()
->setup_object_debug()
->init_tracking()
->set_track()
->save_stack_trace()
->save_stack_trace_tsk()
->walk_stackframe()
->unwind_frame()
->unwind_find_idx()
=>spin_lock_irqsave(&unwind_lock);
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/kernel/unwind.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 0bee233fef9a..314cfb232a63 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -93,7 +93,7 @@ extern const struct unwind_idx __start_unwind_idx[];
static const struct unwind_idx *__origin_unwind_idx;
extern const struct unwind_idx __stop_unwind_idx[];
-static DEFINE_SPINLOCK(unwind_lock);
+static DEFINE_RAW_SPINLOCK(unwind_lock);
static LIST_HEAD(unwind_tables);
/* Convert a prel31 symbol to an absolute address */
@@ -201,7 +201,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned long addr)
/* module unwind tables */
struct unwind_table *table;
- spin_lock_irqsave(&unwind_lock, flags);
+ raw_spin_lock_irqsave(&unwind_lock, flags);
list_for_each_entry(table, &unwind_tables, list) {
if (addr >= table->begin_addr &&
addr < table->end_addr) {
@@ -213,7 +213,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned long addr)
break;
}
}
- spin_unlock_irqrestore(&unwind_lock, flags);
+ raw_spin_unlock_irqrestore(&unwind_lock, flags);
}
pr_debug("%s: idx = %p\n", __func__, idx);
@@ -529,9 +529,9 @@ struct unwind_table *unwind_table_add(unsigned long start, unsigned long size,
tab->begin_addr = text_addr;
tab->end_addr = text_addr + text_size;
- spin_lock_irqsave(&unwind_lock, flags);
+ raw_spin_lock_irqsave(&unwind_lock, flags);
list_add_tail(&tab->list, &unwind_tables);
- spin_unlock_irqrestore(&unwind_lock, flags);
+ raw_spin_unlock_irqrestore(&unwind_lock, flags);
return tab;
}
@@ -543,9 +543,9 @@ void unwind_table_del(struct unwind_table *tab)
if (!tab)
return;
- spin_lock_irqsave(&unwind_lock, flags);
+ raw_spin_lock_irqsave(&unwind_lock, flags);
list_del(&tab->list);
- spin_unlock_irqrestore(&unwind_lock, flags);
+ raw_spin_unlock_irqrestore(&unwind_lock, flags);
kfree(tab);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 032/168] mmc: omap: fix the maximum timeout setting
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 031/168] ARM: 8840/1: use a raw_spinlock_t in unwind Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 033/168] e1000e: Fix -Wformat-truncation warnings Greg Kroah-Hartman
` (140 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaro Koskinen, Ulf Hansson, Sasha Levin
[ Upstream commit a6327b5e57fdc679c842588c3be046c0b39cc127 ]
When running OMAP1 kernel on QEMU, MMC access is annoyingly noisy:
MMC: CTO of 0xff and 0xfe cannot be used!
MMC: CTO of 0xff and 0xfe cannot be used!
MMC: CTO of 0xff and 0xfe cannot be used!
[ad inf.]
Emulator warnings appear to be valid. The TI document SPRU680 [1]
("OMAP5910 Dual-Core Processor MultiMedia Card/Secure Data Memory Card
(MMC/SD) Reference Guide") page 36 states that the maximum timeout is 253
cycles and "0xff and 0xfe cannot be used".
Fix by using 0xfd as the maximum timeout.
Tested using QEMU 2.5 (Siemens SX1 machine, OMAP310), and also checked on
real hardware using Palm TE (OMAP310), Nokia 770 (OMAP1710) and Nokia N810
(OMAP2420) that MMC works as before.
[1] http://www.ti.com/lit/ug/spru680/spru680.pdf
Fixes: 730c9b7e6630f ("[MMC] Add OMAP MMC host driver")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mmc/host/omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5bcf4f45f8b4..20d422558fa3 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -921,7 +921,7 @@ static inline void set_cmd_timeout(struct mmc_omap_host *host, struct mmc_reques
reg &= ~(1 << 5);
OMAP_MMC_WRITE(host, SDIO, reg);
/* Set maximum timeout */
- OMAP_MMC_WRITE(host, CTO, 0xff);
+ OMAP_MMC_WRITE(host, CTO, 0xfd);
}
static inline void set_data_timeout(struct mmc_omap_host *host, struct mmc_request *req)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 033/168] e1000e: Fix -Wformat-truncation warnings
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 032/168] mmc: omap: fix the maximum timeout setting Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 034/168] IB/mlx4: Increase the timeout for CM cache Greg Kroah-Hartman
` (139 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Florian Fainelli, David S. Miller,
Sasha Levin
[ Upstream commit 135e7245479addc6b1f5d031e3d7e2ddb3d2b109 ]
Provide precision hints to snprintf() since we know the destination
buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the
following warnings:
drivers/net/ethernet/intel/e1000e/netdev.c: In function
'e1000_request_msix':
drivers/net/ethernet/intel/e1000e/netdev.c:2109:13: warning: 'snprintf'
output may be truncated before the last format character
[-Wformat-truncation=]
"%s-rx-0", netdev->name);
^
drivers/net/ethernet/intel/e1000e/netdev.c:2107:3: note: 'snprintf'
output between 6 and 21 bytes into a destination of size 20
snprintf(adapter->rx_ring->name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(adapter->rx_ring->name) - 1,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s-rx-0", netdev->name);
~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/e1000e/netdev.c:2125:13: warning: 'snprintf'
output may be truncated before the last format character
[-Wformat-truncation=]
"%s-tx-0", netdev->name);
^
drivers/net/ethernet/intel/e1000e/netdev.c:2123:3: note: 'snprintf'
output between 6 and 21 bytes into a destination of size 20
snprintf(adapter->tx_ring->name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(adapter->tx_ring->name) - 1,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s-tx-0", netdev->name);
~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 6369d88b81c1..6b1cacd86c6e 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -2131,7 +2131,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
if (strlen(netdev->name) < (IFNAMSIZ - 5))
snprintf(adapter->rx_ring->name,
sizeof(adapter->rx_ring->name) - 1,
- "%s-rx-0", netdev->name);
+ "%.14s-rx-0", netdev->name);
else
memcpy(adapter->rx_ring->name, netdev->name, IFNAMSIZ);
err = request_irq(adapter->msix_entries[vector].vector,
@@ -2147,7 +2147,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
if (strlen(netdev->name) < (IFNAMSIZ - 5))
snprintf(adapter->tx_ring->name,
sizeof(adapter->tx_ring->name) - 1,
- "%s-tx-0", netdev->name);
+ "%.14s-tx-0", netdev->name);
else
memcpy(adapter->tx_ring->name, netdev->name, IFNAMSIZ);
err = request_irq(adapter->msix_entries[vector].vector,
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 034/168] IB/mlx4: Increase the timeout for CM cache
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 033/168] e1000e: Fix -Wformat-truncation warnings Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:07 ` [PATCH 4.4 035/168] scsi: megaraid_sas: return error when create DMA pool failed Greg Kroah-Hartman
` (138 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Håkon Bugge, Jack Morgenstein,
Jason Gunthorpe, Sasha Levin
[ Upstream commit 2612d723aadcf8281f9bf8305657129bd9f3cd57 ]
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
Following the RDMA Connection Manager (CM) protocol, it is clear when
an entry has to evicted form the cache. But life is not perfect,
remote peers may die or be rebooted. Hence, it's a timeout to wipe out
a cache entry, when the PF driver assumes the remote peer has gone.
During workloads where a high number of QPs are destroyed concurrently,
excessive amount of CM DREQ retries has been observed
The problem can be demonstrated in a bare-metal environment, where two
nodes have instantiated 8 VFs each. This using dual ported HCAs, so we
have 16 vPorts per physical server.
64 processes are associated with each vPort and creates and destroys
one QP for each of the remote 64 processes. That is, 1024 QPs per
vPort, all in all 16K QPs. The QPs are created/destroyed using the
CM.
When tearing down these 16K QPs, excessive CM DREQ retries (and
duplicates) are observed. With some cat/paste/awk wizardry on the
infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the
nodes:
cm_rx_duplicates:
dreq 2102
cm_rx_msgs:
drep 1989
dreq 6195
rep 3968
req 4224
rtu 4224
cm_tx_msgs:
drep 4093
dreq 27568
rep 4224
req 3968
rtu 3968
cm_tx_retries:
dreq 23469
Note that the active/passive side is equally distributed between the
two nodes.
Enabling pr_debug in cm.c gives tons of:
[171778.814239] <mlx4_ib> mlx4_ib_multiplex_cm_handler: id{slave:
1,sl_cm_id: 0xd393089f} is NULL!
By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the
tear-down phase of the application is reduced from approximately 90 to
50 seconds. Retries/duplicates are also significantly reduced:
cm_rx_duplicates:
dreq 2460
[]
cm_tx_retries:
dreq 3010
req 47
Increasing the timeout further didn't help, as these duplicates and
retries stems from a too short CMA timeout, which was 20 (~4 seconds)
on the systems. By increasing the CMA timeout to 22 (~17 seconds), the
numbers fell down to about 10 for both of them.
Adjustment of the CMA timeout is not part of this commit.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Acked-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/mlx4/cm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/cm.c b/drivers/infiniband/hw/mlx4/cm.c
index 39a488889fc7..5dc920fe1326 100644
--- a/drivers/infiniband/hw/mlx4/cm.c
+++ b/drivers/infiniband/hw/mlx4/cm.c
@@ -39,7 +39,7 @@
#include "mlx4_ib.h"
-#define CM_CLEANUP_CACHE_TIMEOUT (5 * HZ)
+#define CM_CLEANUP_CACHE_TIMEOUT (30 * HZ)
struct id_map_entry {
struct rb_node node;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 035/168] scsi: megaraid_sas: return error when create DMA pool failed
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 034/168] IB/mlx4: Increase the timeout for CM cache Greg Kroah-Hartman
@ 2019-04-24 17:07 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 036/168] perf test: Fix failure of evsel-tp-sched test on s390 Greg Kroah-Hartman
` (137 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:07 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Yan, Sumit Saxena,
Martin K. Petersen, Sasha Levin
[ Upstream commit bcf3b67d16a4c8ffae0aa79de5853435e683945c ]
when create DMA pool for cmd frames failed, we should return -ENOMEM,
instead of 0.
In some case in:
megasas_init_adapter_fusion()
-->megasas_alloc_cmds()
-->megasas_create_frame_pool
create DMA pool failed,
--> megasas_free_cmds() [1]
-->megasas_alloc_cmds_fusion()
failed, then goto fail_alloc_cmds.
-->megasas_free_cmds() [2]
we will call megasas_free_cmds twice, [1] will kfree cmd_list,
[2] will use cmd_list.it will cause a problem:
Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffffffc000f70000
[00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003,
*pmd=0000001fbf894003, *pte=006000006d000707
Internal error: Oops: 96000005 [#1] SMP
Modules linked in:
CPU: 18 PID: 1 Comm: swapper/0 Not tainted
task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000
PC is at megasas_free_cmds+0x30/0x70
LR is at megasas_free_cmds+0x24/0x70
...
Call trace:
[<ffffffc0005b779c>] megasas_free_cmds+0x30/0x70
[<ffffffc0005bca74>] megasas_init_adapter_fusion+0x2f4/0x4d8
[<ffffffc0005b926c>] megasas_init_fw+0x2dc/0x760
[<ffffffc0005b9ab0>] megasas_probe_one+0x3c0/0xcd8
[<ffffffc0004a5abc>] local_pci_probe+0x4c/0xb4
[<ffffffc0004a5c40>] pci_device_probe+0x11c/0x14c
[<ffffffc00053a5e4>] driver_probe_device+0x1ec/0x430
[<ffffffc00053a92c>] __driver_attach+0xa8/0xb0
[<ffffffc000538178>] bus_for_each_dev+0x74/0xc8
[<ffffffc000539e88>] driver_attach+0x28/0x34
[<ffffffc000539a18>] bus_add_driver+0x16c/0x248
[<ffffffc00053b234>] driver_register+0x6c/0x138
[<ffffffc0004a5350>] __pci_register_driver+0x5c/0x6c
[<ffffffc000ce3868>] megasas_init+0xc0/0x1a8
[<ffffffc000082a58>] do_one_initcall+0xe8/0x1ec
[<ffffffc000ca7be8>] kernel_init_freeable+0x1c8/0x284
[<ffffffc0008d90b8>] kernel_init+0x1c/0xe4
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Acked-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index ac7acd257c99..2422094f1f15 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3847,6 +3847,7 @@ int megasas_alloc_cmds(struct megasas_instance *instance)
if (megasas_create_frame_pool(instance)) {
dev_printk(KERN_DEBUG, &instance->pdev->dev, "Error creating frame DMA pool\n");
megasas_free_cmds(instance);
+ return -ENOMEM;
}
return 0;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 036/168] perf test: Fix failure of evsel-tp-sched test on s390
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2019-04-24 17:07 ` [PATCH 4.4 035/168] scsi: megaraid_sas: return error when create DMA pool failed Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 037/168] SoC: imx-sgtl5000: add missing put_device() Greg Kroah-Hartman
` (136 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Richter, Heiko Carstens,
Hendrik Brueckner, Martin Schwidefsky, Arnaldo Carvalho de Melo,
Sasha Levin
[ Upstream commit 03d309711d687460d1345de8a0363f45b1c8cd11 ]
Commit 489338a717a0 ("perf tests evsel-tp-sched: Fix bitwise operator")
causes test case 14 "Parse sched tracepoints fields" to fail on s390.
This test succeeds on x86.
In fact this test now fails on all architectures with type char treated
as type unsigned char.
The root cause is the signed-ness of character arrays in the tracepoints
sched_switch for structure members prev_comm and next_comm.
On s390 the output of:
[root@m35lp76 perf]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
name: sched_switch
ID: 287
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
...
field:char prev_comm[16]; offset:8; size:16; signed:0;
...
field:char next_comm[16]; offset:40; size:16; signed:0;
reveals the character arrays prev_comm and next_comm are per
default unsigned char and have values in the range of 0..255.
On x86 both fields are signed as this output shows:
[root@f29]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
name: sched_switch
ID: 287
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
...
field:char prev_comm[16]; offset:8; size:16; signed:1;
...
field:char next_comm[16]; offset:40; size:16; signed:1;
and the character arrays prev_comm and next_comm are per default signed
char and have values in the range of -1..127. The implementation of
type char is architecture specific.
Since the character arrays in both tracepoints sched_switch and
sched_wakeup should contain ascii characters, simply omit the check for
signedness in the test case.
Output before:
[root@m35lp76 perf]# ./perf test -F 14
14: Parse sched tracepoints fields :
--- start ---
sched:sched_switch: "prev_comm" signedness(0) is wrong, should be 1
sched:sched_switch: "next_comm" signedness(0) is wrong, should be 1
sched:sched_wakeup: "comm" signedness(0) is wrong, should be 1
---- end ----
14: Parse sched tracepoints fields : FAILED!
[root@m35lp76 perf]#
Output after:
[root@m35lp76 perf]# ./perf test -Fv 14
14: Parse sched tracepoints fields :
--- start ---
---- end ----
Parse sched tracepoints fields: Ok
[root@m35lp76 perf]#
Fixes: 489338a717a0 ("perf tests evsel-tp-sched: Fix bitwise operator")
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Link: http://lkml.kernel.org/r/20190219153639.31267-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/tests/evsel-tp-sched.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/tests/evsel-tp-sched.c b/tools/perf/tests/evsel-tp-sched.c
index da474d743b6a..1b832e54c04b 100644
--- a/tools/perf/tests/evsel-tp-sched.c
+++ b/tools/perf/tests/evsel-tp-sched.c
@@ -42,7 +42,7 @@ int test__perf_evsel__tp_sched_test(void)
return -1;
}
- if (perf_evsel__test_field(evsel, "prev_comm", 16, true))
+ if (perf_evsel__test_field(evsel, "prev_comm", 16, false))
ret = -1;
if (perf_evsel__test_field(evsel, "prev_pid", 4, true))
@@ -54,7 +54,7 @@ int test__perf_evsel__tp_sched_test(void)
if (perf_evsel__test_field(evsel, "prev_state", sizeof(long), true))
ret = -1;
- if (perf_evsel__test_field(evsel, "next_comm", 16, true))
+ if (perf_evsel__test_field(evsel, "next_comm", 16, false))
ret = -1;
if (perf_evsel__test_field(evsel, "next_pid", 4, true))
@@ -72,7 +72,7 @@ int test__perf_evsel__tp_sched_test(void)
return -1;
}
- if (perf_evsel__test_field(evsel, "comm", 16, true))
+ if (perf_evsel__test_field(evsel, "comm", 16, false))
ret = -1;
if (perf_evsel__test_field(evsel, "pid", 4, true))
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 037/168] SoC: imx-sgtl5000: add missing put_device()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 036/168] perf test: Fix failure of evsel-tp-sched test on s390 Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 038/168] media: sh_veu: Correct return type for mem2mem buffer helpers Greg Kroah-Hartman
` (135 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wen Yang, Timur Tabi, Nicolin Chen,
Xiubo Li, Fabio Estevam, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, NXP Linux Team, alsa-devel,
linuxppc-dev, linux-arm-kernel, Sasha Levin
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/imx-sgtl5000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index b99e0b5e00e9..8e525f7ac08d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+ put_device(&ssi_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(&pdev->dev, "failed to find codec platform device\n");
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 038/168] media: sh_veu: Correct return type for mem2mem buffer helpers
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 037/168] SoC: imx-sgtl5000: add missing put_device() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 039/168] media: s5p-jpeg: " Greg Kroah-Hartman
` (134 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ezequiel Garcia, Hans Verkuil,
Mauro Carvalho Chehab, Sasha Levin
[ Upstream commit 43c145195c7fc3025ee7ecfc67112ac1c82af7c2 ]
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
Fixing this is necessary to fix the mem2mem buffer handling API,
changing the return to the correct struct vb2_v4l2_buffer instead
of a void pointer.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/sh_veu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c
index d6ab33e7060a..b9f4cdee555e 100644
--- a/drivers/media/platform/sh_veu.c
+++ b/drivers/media/platform/sh_veu.c
@@ -277,13 +277,13 @@ static void sh_veu_process(struct sh_veu_dev *veu,
static void sh_veu_device_run(void *priv)
{
struct sh_veu_dev *veu = priv;
- struct vb2_buffer *src_buf, *dst_buf;
+ struct vb2_v4l2_buffer *src_buf, *dst_buf;
src_buf = v4l2_m2m_next_src_buf(veu->m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(veu->m2m_ctx);
if (src_buf && dst_buf)
- sh_veu_process(veu, src_buf, dst_buf);
+ sh_veu_process(veu, &src_buf->vb2_buf, &dst_buf->vb2_buf);
}
/* ========== video ioctls ========== */
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 039/168] media: s5p-jpeg: Correct return type for mem2mem buffer helpers
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 038/168] media: sh_veu: Correct return type for mem2mem buffer helpers Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 040/168] media: s5p-g2d: " Greg Kroah-Hartman
` (133 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ezequiel Garcia, Hans Verkuil,
Mauro Carvalho Chehab, Sasha Levin
[ Upstream commit 4a88f89885c7cf65c62793f385261a6e3315178a ]
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
Fixing this is necessary to fix the mem2mem buffer handling API,
changing the return to the correct struct vb2_v4l2_buffer instead
of a void pointer.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 38 ++++++++++-----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 9c6fc09b88e0..80c83bba7af3 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -788,14 +788,14 @@ static void skip(struct s5p_jpeg_buffer *buf, long len);
static void exynos4_jpeg_parse_decode_h_tbl(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+ struct vb2_v4l2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
struct s5p_jpeg_buffer jpeg_buffer;
unsigned int word;
int c, x, components;
jpeg_buffer.size = 2; /* Ls */
jpeg_buffer.data =
- (unsigned long)vb2_plane_vaddr(vb, 0) + ctx->out_q.sos + 2;
+ (unsigned long)vb2_plane_vaddr(&vb->vb2_buf, 0) + ctx->out_q.sos + 2;
jpeg_buffer.curr = 0;
word = 0;
@@ -825,14 +825,14 @@ static void exynos4_jpeg_parse_decode_h_tbl(struct s5p_jpeg_ctx *ctx)
static void exynos4_jpeg_parse_huff_tbl(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+ struct vb2_v4l2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
struct s5p_jpeg_buffer jpeg_buffer;
unsigned int word;
int c, i, n, j;
for (j = 0; j < ctx->out_q.dht.n; ++j) {
jpeg_buffer.size = ctx->out_q.dht.len[j];
- jpeg_buffer.data = (unsigned long)vb2_plane_vaddr(vb, 0) +
+ jpeg_buffer.data = (unsigned long)vb2_plane_vaddr(&vb->vb2_buf, 0) +
ctx->out_q.dht.marker[j];
jpeg_buffer.curr = 0;
@@ -884,13 +884,13 @@ static void exynos4_jpeg_parse_huff_tbl(struct s5p_jpeg_ctx *ctx)
static void exynos4_jpeg_parse_decode_q_tbl(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+ struct vb2_v4l2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
struct s5p_jpeg_buffer jpeg_buffer;
int c, x, components;
jpeg_buffer.size = ctx->out_q.sof_len;
jpeg_buffer.data =
- (unsigned long)vb2_plane_vaddr(vb, 0) + ctx->out_q.sof;
+ (unsigned long)vb2_plane_vaddr(&vb->vb2_buf, 0) + ctx->out_q.sof;
jpeg_buffer.curr = 0;
skip(&jpeg_buffer, 5); /* P, Y, X */
@@ -915,14 +915,14 @@ static void exynos4_jpeg_parse_decode_q_tbl(struct s5p_jpeg_ctx *ctx)
static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+ struct vb2_v4l2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
struct s5p_jpeg_buffer jpeg_buffer;
unsigned int word;
int c, i, j;
for (j = 0; j < ctx->out_q.dqt.n; ++j) {
jpeg_buffer.size = ctx->out_q.dqt.len[j];
- jpeg_buffer.data = (unsigned long)vb2_plane_vaddr(vb, 0) +
+ jpeg_buffer.data = (unsigned long)vb2_plane_vaddr(&vb->vb2_buf, 0) +
ctx->out_q.dqt.marker[j];
jpeg_buffer.curr = 0;
@@ -2016,15 +2016,15 @@ static void s5p_jpeg_device_run(void *priv)
{
struct s5p_jpeg_ctx *ctx = priv;
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *src_buf, *dst_buf;
+ struct vb2_v4l2_buffer *src_buf, *dst_buf;
unsigned long src_addr, dst_addr, flags;
spin_lock_irqsave(&ctx->jpeg->slock, flags);
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
- src_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
- dst_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
+ src_addr = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+ dst_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
s5p_jpeg_reset(jpeg->regs);
s5p_jpeg_poweron(jpeg->regs);
@@ -2097,7 +2097,7 @@ static void exynos4_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
struct s5p_jpeg_fmt *fmt;
- struct vb2_buffer *vb;
+ struct vb2_v4l2_buffer *vb;
struct s5p_jpeg_addr jpeg_addr = {};
u32 pix_size, padding_bytes = 0;
@@ -2116,7 +2116,7 @@ static void exynos4_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
vb = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
}
- jpeg_addr.y = vb2_dma_contig_plane_dma_addr(vb, 0);
+ jpeg_addr.y = vb2_dma_contig_plane_dma_addr(&vb->vb2_buf, 0);
if (fmt->colplanes == 2) {
jpeg_addr.cb = jpeg_addr.y + pix_size - padding_bytes;
@@ -2134,7 +2134,7 @@ static void exynos4_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
static void exynos4_jpeg_set_jpeg_addr(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *vb;
+ struct vb2_v4l2_buffer *vb;
unsigned int jpeg_addr = 0;
if (ctx->mode == S5P_JPEG_ENCODE)
@@ -2142,7 +2142,7 @@ static void exynos4_jpeg_set_jpeg_addr(struct s5p_jpeg_ctx *ctx)
else
vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
- jpeg_addr = vb2_dma_contig_plane_dma_addr(vb, 0);
+ jpeg_addr = vb2_dma_contig_plane_dma_addr(&vb->vb2_buf, 0);
if (jpeg->variant->version == SJPEG_EXYNOS5433 &&
ctx->mode == S5P_JPEG_DECODE)
jpeg_addr += ctx->out_q.sos;
@@ -2257,7 +2257,7 @@ static void exynos3250_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
struct s5p_jpeg_fmt *fmt;
- struct vb2_buffer *vb;
+ struct vb2_v4l2_buffer *vb;
struct s5p_jpeg_addr jpeg_addr = {};
u32 pix_size;
@@ -2271,7 +2271,7 @@ static void exynos3250_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
fmt = ctx->cap_q.fmt;
}
- jpeg_addr.y = vb2_dma_contig_plane_dma_addr(vb, 0);
+ jpeg_addr.y = vb2_dma_contig_plane_dma_addr(&vb->vb2_buf, 0);
if (fmt->colplanes == 2) {
jpeg_addr.cb = jpeg_addr.y + pix_size;
@@ -2289,7 +2289,7 @@ static void exynos3250_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
static void exynos3250_jpeg_set_jpeg_addr(struct s5p_jpeg_ctx *ctx)
{
struct s5p_jpeg *jpeg = ctx->jpeg;
- struct vb2_buffer *vb;
+ struct vb2_v4l2_buffer *vb;
unsigned int jpeg_addr = 0;
if (ctx->mode == S5P_JPEG_ENCODE)
@@ -2297,7 +2297,7 @@ static void exynos3250_jpeg_set_jpeg_addr(struct s5p_jpeg_ctx *ctx)
else
vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
- jpeg_addr = vb2_dma_contig_plane_dma_addr(vb, 0);
+ jpeg_addr = vb2_dma_contig_plane_dma_addr(&vb->vb2_buf, 0);
exynos3250_jpeg_jpgadr(jpeg->regs, jpeg_addr);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 040/168] media: s5p-g2d: Correct return type for mem2mem buffer helpers
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 039/168] media: s5p-jpeg: " Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 041/168] media: mx2_emmaprp: " Greg Kroah-Hartman
` (132 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ezequiel Garcia, Hans Verkuil,
Mauro Carvalho Chehab, Sasha Levin
[ Upstream commit 30fa627b32230737bc3f678067e2adfecf956987 ]
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
Fixing this is necessary to fix the mem2mem buffer handling API,
changing the return to the correct struct vb2_v4l2_buffer instead
of a void pointer.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/s5p-g2d/g2d.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-g2d/g2d.c b/drivers/media/platform/s5p-g2d/g2d.c
index e1936d9d27da..2b939555cccb 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -497,7 +497,7 @@ static void device_run(void *prv)
{
struct g2d_ctx *ctx = prv;
struct g2d_dev *dev = ctx->dev;
- struct vb2_buffer *src, *dst;
+ struct vb2_v4l2_buffer *src, *dst;
unsigned long flags;
u32 cmd = 0;
@@ -512,10 +512,10 @@ static void device_run(void *prv)
spin_lock_irqsave(&dev->ctrl_lock, flags);
g2d_set_src_size(dev, &ctx->in);
- g2d_set_src_addr(dev, vb2_dma_contig_plane_dma_addr(src, 0));
+ g2d_set_src_addr(dev, vb2_dma_contig_plane_dma_addr(&src->vb2_buf, 0));
g2d_set_dst_size(dev, &ctx->out);
- g2d_set_dst_addr(dev, vb2_dma_contig_plane_dma_addr(dst, 0));
+ g2d_set_dst_addr(dev, vb2_dma_contig_plane_dma_addr(&dst->vb2_buf, 0));
g2d_set_rop4(dev, ctx->rop);
g2d_set_flip(dev, ctx->flip);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 041/168] media: mx2_emmaprp: Correct return type for mem2mem buffer helpers
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 040/168] media: s5p-g2d: " Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 042/168] leds: lp55xx: fix null deref on firmware load failure Greg Kroah-Hartman
` (131 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ezequiel Garcia, Hans Verkuil,
Mauro Carvalho Chehab, Sasha Levin
[ Upstream commit 8d20dcefe471763f23ad538369ec65b51993ffff ]
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
Fixing this is necessary to fix the mem2mem buffer handling API,
changing the return to the correct struct vb2_v4l2_buffer instead
of a void pointer.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/mx2_emmaprp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/mx2_emmaprp.c b/drivers/media/platform/mx2_emmaprp.c
index 03a1b606655d..009a4bb77d05 100644
--- a/drivers/media/platform/mx2_emmaprp.c
+++ b/drivers/media/platform/mx2_emmaprp.c
@@ -289,7 +289,7 @@ static void emmaprp_device_run(void *priv)
{
struct emmaprp_ctx *ctx = priv;
struct emmaprp_q_data *s_q_data, *d_q_data;
- struct vb2_buffer *src_buf, *dst_buf;
+ struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct emmaprp_dev *pcdev = ctx->dev;
unsigned int s_width, s_height;
unsigned int d_width, d_height;
@@ -309,8 +309,8 @@ static void emmaprp_device_run(void *priv)
d_height = d_q_data->height;
d_size = d_width * d_height;
- p_in = vb2_dma_contig_plane_dma_addr(src_buf, 0);
- p_out = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
+ p_in = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+ p_out = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
if (!p_in || !p_out) {
v4l2_err(&pcdev->v4l2_dev,
"Acquiring kernel pointers to buffers failed\n");
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 042/168] leds: lp55xx: fix null deref on firmware load failure
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 041/168] media: mx2_emmaprp: " Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 043/168] kprobes: Prohibit probing on bsearch() Greg Kroah-Hartman
` (130 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Kazior, Jacek Anaszewski, Sasha Levin
[ Upstream commit 5ddb0869bfc1bca6cfc592c74c64a026f936638c ]
I've stumbled upon a kernel crash and the logs
pointed me towards the lp5562 driver:
> <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2
> <4>[306013.894990] lp5562 0-0030: Falling back to user helper
> ...
> <3>[306073.924886] lp5562 0-0030: firmware request failed
> <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58
> <4>[306074.255539] LR is at release_firmware+0x6c/0x138
> ...
After taking a look I noticed firmware_release()
could be called with either NULL or a dangling
pointer.
Fixes: 10c06d178df11 ("leds-lp55xx: support firmware interface")
Signed-off-by: Michal Kazior <michal@plume.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/leds/leds-lp55xx-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index 59b76833f0d3..fd077c176a62 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -200,7 +200,7 @@ static void lp55xx_firmware_loaded(const struct firmware *fw, void *context)
if (!fw) {
dev_err(dev, "firmware request failed\n");
- goto out;
+ return;
}
/* handling firmware data is chip dependent */
@@ -213,9 +213,9 @@ static void lp55xx_firmware_loaded(const struct firmware *fw, void *context)
mutex_unlock(&chip->lock);
-out:
/* firmware should be released for other channel use */
release_firmware(chip->fw);
+ chip->fw = NULL;
}
static int lp55xx_request_firmware(struct lp55xx_chip *chip)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 043/168] kprobes: Prohibit probing on bsearch()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 042/168] leds: lp55xx: fix null deref on firmware load failure Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 044/168] ARM: 8833/1: Ensure that NEON code always compiles with Clang Greg Kroah-Hartman
` (129 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrea Righi, Masami Hiramatsu,
Alexander Shishkin, Arnaldo Carvalho de Melo, Jiri Olsa,
Linus Torvalds, Mathieu Desnoyers, Peter Zijlstra,
Steven Rostedt, Thomas Gleixner, Ingo Molnar, Sasha Levin
[ Upstream commit 02106f883cd745523f7766d90a739f983f19e650 ]
Since kprobe breakpoing handler is using bsearch(), probing on this
routine can cause recursive breakpoint problem.
int3
->do_int3()
->ftrace_int3_handler()
->ftrace_location()
->ftrace_location_range()
->bsearch() -> int3
Prohibit probing on bsearch().
Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.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: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/154998813406.31052.8791425358974650922.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
lib/bsearch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bsearch.c b/lib/bsearch.c
index e33c179089db..d50048446b77 100644
--- a/lib/bsearch.c
+++ b/lib/bsearch.c
@@ -11,6 +11,7 @@
#include <linux/export.h>
#include <linux/bsearch.h>
+#include <linux/kprobes.h>
/*
* bsearch - binary search an array of elements
@@ -51,3 +52,4 @@ void *bsearch(const void *key, const void *base, size_t num, size_t size,
return NULL;
}
EXPORT_SYMBOL(bsearch);
+NOKPROBE_SYMBOL(bsearch);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 044/168] ARM: 8833/1: Ensure that NEON code always compiles with Clang
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 043/168] kprobes: Prohibit probing on bsearch() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 045/168] ALSA: PCM: check if ops are defined before suspending PCM Greg Kroah-Hartman
` (128 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Nathan Chancellor,
Nicolas Pitre, Nick Desaulniers, Stefan Agner, Russell King,
Sasha Levin
[ Upstream commit de9c0d49d85dc563549972edc5589d195cd5e859 ]
While building arm32 allyesconfig, I ran into the following errors:
arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
'-mfloat-abi=softfp -mfpu=neon'
In file included from lib/raid6/neon1.c:27:
/home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
error: "NEON support not enabled"
Building V=1 showed NEON_FLAGS getting passed along to Clang but
__ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
which is the '-march' value for allyesconfig.
>From lib/Basic/Targets/ARM.cpp in the Clang source:
// This only gets set when Neon instructions are actually available, unlike
// the VFP define, hence the soft float and arch check. This is subtly
// different from gcc, we follow the intent which was that it should be set
// when Neon instructions are actually available.
if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
Builder.defineMacro("__ARM_NEON", "1");
Builder.defineMacro("__ARM_NEON__");
// current AArch32 NEON implementations do not support double-precision
// floating-point even when it is present in VFP.
Builder.defineMacro("__ARM_NEON_FP",
"0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
}
Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
definined by Clang. This doesn't functionally change anything because
that code will only run where NEON is supported, which is implicitly
armv7.
Link: https://github.com/ClangBuiltLinux/linux/issues/287
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/arm/kernel_mode_neon.txt | 4 ++--
arch/arm/lib/Makefile | 2 +-
arch/arm/lib/xor-neon.c | 2 +-
lib/raid6/Makefile | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt
index 525452726d31..b9e060c5b61e 100644
--- a/Documentation/arm/kernel_mode_neon.txt
+++ b/Documentation/arm/kernel_mode_neon.txt
@@ -6,7 +6,7 @@ TL;DR summary
* Use only NEON instructions, or VFP instructions that don't rely on support
code
* Isolate your NEON code in a separate compilation unit, and compile it with
- '-mfpu=neon -mfloat-abi=softfp'
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
NEON code
* Don't sleep in your NEON code, and be aware that it will be executed with
@@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:
* isolate the NEON code in a separate compilation unit and compile it with
- '-mfpu=neon -mfloat-abi=softfp';
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is *not*
built with the GCC flag '-mfpu=neon' set.
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index d8a780799506..06348a3d50c2 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -35,7 +35,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
$(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
- NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
+ NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
CFLAGS_xor-neon.o += $(NEON_FLAGS)
obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
endif
diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
index 2c40aeab3eaa..c691b901092f 100644
--- a/arch/arm/lib/xor-neon.c
+++ b/arch/arm/lib/xor-neon.c
@@ -14,7 +14,7 @@
MODULE_LICENSE("GPL");
#ifndef __ARM_NEON__
-#error You should compile this file with '-mfloat-abi=softfp -mfpu=neon'
+#error You should compile this file with '-march=armv7-a -mfloat-abi=softfp -mfpu=neon'
#endif
/*
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 3b10a48fa040..a84efd4aad37 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -23,7 +23,7 @@ endif
ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
NEON_FLAGS := -ffreestanding
ifeq ($(ARCH),arm)
-NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
+NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
endif
ifeq ($(ARCH),arm64)
CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 045/168] ALSA: PCM: check if ops are defined before suspending PCM
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 044/168] ARM: 8833/1: Ensure that NEON code always compiles with Clang Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 046/168] bcache: fix input overflow to cache set sysfs file io_error_halflife Greg Kroah-Hartman
` (127 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ranjani Sridharan,
Pierre-Louis Bossart, Takashi Iwai, Sasha Levin
[ Upstream commit d9c0b2afe820fa3b3f8258a659daee2cc71ca3ef ]
BE dai links only have internal PCM's and their substream ops may
not be set. Suspending these PCM's will result in their
ops->trigger() being invoked and cause a kernel oops.
So skip suspending PCM's if their ops are NULL.
[ NOTE: this change is required now for following the recent PCM core
change to get rid of snd_pcm_suspend() call. Since DPCM BE takes
the runtime carried from FE while keeping NULL ops, it can hit this
bug. See details at:
https://github.com/thesofproject/linux/pull/582
-- tiwai ]
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/core/pcm_native.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 4d6f0f56d54a..252392abd1b9 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -1342,6 +1342,14 @@ int snd_pcm_suspend_all(struct snd_pcm *pcm)
/* FIXME: the open/close code should lock this as well */
if (substream->runtime == NULL)
continue;
+
+ /*
+ * Skip BE dai link PCM's that are internal and may
+ * not have their substream ops set.
+ */
+ if (!substream->ops)
+ continue;
+
err = snd_pcm_suspend(substream);
if (err < 0 && err != -EBUSY)
return err;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 046/168] bcache: fix input overflow to cache set sysfs file io_error_halflife
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 045/168] ALSA: PCM: check if ops are defined before suspending PCM Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 047/168] bcache: fix input overflow to sequential_cutoff Greg Kroah-Hartman
` (126 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Coly Li, Jens Axboe, Sasha Levin
[ Upstream commit a91fbda49f746119828f7e8ad0f0aa2ab0578f65 ]
Cache set sysfs entry io_error_halflife is used to set c->error_decay.
c->error_decay is in type unsigned int, and it is converted by
strtoul_or_return(), therefore overflow to c->error_decay is possible
for a large input value.
This patch fixes the overflow by using strtoul_safe_clamp() to convert
input string to an unsigned long value in range [0, UINT_MAX], then
divides by 88 and set it to c->error_decay.
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/bcache/sysfs.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 5a5c1f1bd8a5..87daccbbc61b 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -645,8 +645,17 @@ STORE(__bch_cache_set)
c->error_limit = strtoul_or_return(buf) << IO_ERROR_SHIFT;
/* See count_io_errors() for why 88 */
- if (attr == &sysfs_io_error_halflife)
- c->error_decay = strtoul_or_return(buf) / 88;
+ if (attr == &sysfs_io_error_halflife) {
+ unsigned long v = 0;
+ ssize_t ret;
+
+ ret = strtoul_safe_clamp(buf, v, 0, UINT_MAX);
+ if (!ret) {
+ c->error_decay = v / 88;
+ return size;
+ }
+ return ret;
+ }
sysfs_strtoul(journal_delay_ms, c->journal_delay_ms);
sysfs_strtoul(verify, c->verify);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 047/168] bcache: fix input overflow to sequential_cutoff
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 046/168] bcache: fix input overflow to cache set sysfs file io_error_halflife Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 048/168] bcache: improve sysfs_strtoul_clamp() Greg Kroah-Hartman
` (125 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Coly Li, Jens Axboe, Sasha Levin
[ Upstream commit 8c27a3953e92eb0b22dbb03d599f543a05f9574e ]
People may set sequential_cutoff of a cached device via sysfs file,
but current code does not check input value overflow. E.g. if value
4294967295 (UINT_MAX) is written to file sequential_cutoff, its value
is 4GB, but if 4294967296 (UINT_MAX + 1) is written into, its value
will be 0. This is an unexpected behavior.
This patch replaces d_strtoi_h() by sysfs_strtoul_clamp() to convert
input string to unsigned integer value, and limit its range in
[0, UINT_MAX]. Then the input overflow can be fixed.
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/bcache/sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 87daccbbc61b..463ce6757338 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -215,7 +215,9 @@ STORE(__cached_dev)
d_strtoul(writeback_rate_d_term);
d_strtoul_nonzero(writeback_rate_p_term_inverse);
- d_strtoi_h(sequential_cutoff);
+ sysfs_strtoul_clamp(sequential_cutoff,
+ dc->sequential_cutoff,
+ 0, UINT_MAX);
d_strtoi_h(readahead);
if (attr == &sysfs_clear_stats)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 048/168] bcache: improve sysfs_strtoul_clamp()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 047/168] bcache: fix input overflow to sequential_cutoff Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 049/168] fbdev: fbmem: fix memory access if logo is bigger than the screen Greg Kroah-Hartman
` (124 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Coly Li, Jens Axboe, Sasha Levin
[ Upstream commit 596b5a5dd1bc2fa019fdaaae522ef331deef927f ]
Currently sysfs_strtoul_clamp() is defined as,
82 #define sysfs_strtoul_clamp(file, var, min, max) \
83 do { \
84 if (attr == &sysfs_ ## file) \
85 return strtoul_safe_clamp(buf, var, min, max) \
86 ?: (ssize_t) size; \
87 } while (0)
The problem is, if bit width of var is less then unsigned long, min and
max may not protect var from integer overflow, because overflow happens
in strtoul_safe_clamp() before checking min and max.
To fix such overflow in sysfs_strtoul_clamp(), to make min and max take
effect, this patch adds an unsigned long variable, and uses it to macro
strtoul_safe_clamp() to convert an unsigned long value in range defined
by [min, max]. Then assign this value to var. By this method, if bit
width of var is less than unsigned long, integer overflow won't happen
before min and max are checking.
Now sysfs_strtoul_clamp() can properly handle smaller data type like
unsigned int, of cause min and max should be defined in range of
unsigned int too.
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/bcache/sysfs.h | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/md/bcache/sysfs.h b/drivers/md/bcache/sysfs.h
index 0526fe92a683..e7a3c12aa66f 100644
--- a/drivers/md/bcache/sysfs.h
+++ b/drivers/md/bcache/sysfs.h
@@ -80,9 +80,16 @@ do { \
#define sysfs_strtoul_clamp(file, var, min, max) \
do { \
- if (attr == &sysfs_ ## file) \
- return strtoul_safe_clamp(buf, var, min, max) \
- ?: (ssize_t) size; \
+ if (attr == &sysfs_ ## file) { \
+ unsigned long v = 0; \
+ ssize_t ret; \
+ ret = strtoul_safe_clamp(buf, v, min, max); \
+ if (!ret) { \
+ var = v; \
+ return size; \
+ } \
+ return ret; \
+ } \
} while (0)
#define strtoul_or_return(cp) \
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 049/168] fbdev: fbmem: fix memory access if logo is bigger than the screen
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 048/168] bcache: improve sysfs_strtoul_clamp() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 050/168] cdrom: Fix race condition in cdrom_sysctl_register Greg Kroah-Hartman
` (123 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Manfred Schlaegl, Martin Kepplinger,
Daniel Vetter, Bartlomiej Zolnierkiewicz, Sasha Levin
[ Upstream commit a5399db139cb3ad9b8502d8b1bd02da9ce0b9df0 ]
There is no clipping on the x or y axis for logos larger that the framebuffer
size. Therefore: a logo bigger than screen size leads to invalid memory access:
[ 1.254664] Backtrace:
[ 1.254728] [<c02714e0>] (cfb_imageblit) from [<c026184c>] (fb_show_logo+0x620/0x684)
[ 1.254763] r10:00000003 r9:00027fd8 r8:c6a40000 r7:c6a36e50 r6:00000000 r5:c06b81e4
[ 1.254774] r4:c6a3e800
[ 1.254810] [<c026122c>] (fb_show_logo) from [<c026c1e4>] (fbcon_switch+0x3fc/0x46c)
[ 1.254842] r10:c6a3e824 r9:c6a3e800 r8:00000000 r7:c6a0c000 r6:c070b014 r5:c6a3e800
[ 1.254852] r4:c6808c00
[ 1.254889] [<c026bde8>] (fbcon_switch) from [<c029c8f8>] (redraw_screen+0xf0/0x1e8)
[ 1.254918] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c070d5a0 r5:00000080
[ 1.254928] r4:c6808c00
[ 1.254961] [<c029c808>] (redraw_screen) from [<c029d264>] (do_bind_con_driver+0x194/0x2e4)
[ 1.254991] r9:00000000 r8:00000000 r7:00000014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0
So prevent displaying a logo bigger than screen size and avoid invalid
memory access.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/core/fbmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index ea2bd6208a2f..9eae191728d2 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -425,6 +425,9 @@ static void fb_do_show_logo(struct fb_info *info, struct fb_image *image,
{
unsigned int x;
+ if (image->width > info->var.xres || image->height > info->var.yres)
+ return;
+
if (rotate == FB_ROTATE_UR) {
for (x = 0;
x < num && image->dx + image->width <= info->var.xres;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 050/168] cdrom: Fix race condition in cdrom_sysctl_register
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 049/168] fbdev: fbmem: fix memory access if logo is bigger than the screen Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 051/168] e1000e: fix cyclic resets at link up with active tx Greg Kroah-Hartman
` (122 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Guenter Roeck, Jens Axboe, Sasha Levin
[ Upstream commit f25191bb322dec8fa2979ecb8235643aa42470e1 ]
The following traceback is sometimes seen when booting an image in qemu:
[ 54.608293] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 54.611085] Fusion MPT base driver 3.04.20
[ 54.611877] Copyright (c) 1999-2008 LSI Corporation
[ 54.616234] Fusion MPT SAS Host driver 3.04.20
[ 54.635139] sysctl duplicate entry: /dev/cdrom//info
[ 54.639578] CPU: 0 PID: 266 Comm: kworker/u4:5 Not tainted 5.0.0-rc5 #1
[ 54.639578] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[ 54.641273] Workqueue: events_unbound async_run_entry_fn
[ 54.641273] Call Trace:
[ 54.641273] dump_stack+0x67/0x90
[ 54.641273] __register_sysctl_table+0x50b/0x570
[ 54.641273] ? rcu_read_lock_sched_held+0x6f/0x80
[ 54.641273] ? kmem_cache_alloc_trace+0x1c7/0x1f0
[ 54.646814] __register_sysctl_paths+0x1c8/0x1f0
[ 54.646814] cdrom_sysctl_register.part.7+0xc/0x5f
[ 54.646814] register_cdrom.cold.24+0x2a/0x33
[ 54.646814] sr_probe+0x4bd/0x580
[ 54.646814] ? __driver_attach+0xd0/0xd0
[ 54.646814] really_probe+0xd6/0x260
[ 54.646814] ? __driver_attach+0xd0/0xd0
[ 54.646814] driver_probe_device+0x4a/0xb0
[ 54.646814] ? __driver_attach+0xd0/0xd0
[ 54.646814] bus_for_each_drv+0x73/0xc0
[ 54.646814] __device_attach+0xd6/0x130
[ 54.646814] bus_probe_device+0x9a/0xb0
[ 54.646814] device_add+0x40c/0x670
[ 54.646814] ? __pm_runtime_resume+0x4f/0x80
[ 54.646814] scsi_sysfs_add_sdev+0x81/0x290
[ 54.646814] scsi_probe_and_add_lun+0x888/0xc00
[ 54.646814] ? scsi_autopm_get_host+0x21/0x40
[ 54.646814] __scsi_add_device+0x116/0x130
[ 54.646814] ata_scsi_scan_host+0x93/0x1c0
[ 54.646814] async_run_entry_fn+0x34/0x100
[ 54.646814] process_one_work+0x237/0x5e0
[ 54.646814] worker_thread+0x37/0x380
[ 54.646814] ? rescuer_thread+0x360/0x360
[ 54.646814] kthread+0x118/0x130
[ 54.646814] ? kthread_create_on_node+0x60/0x60
[ 54.646814] ret_from_fork+0x3a/0x50
The only sensible explanation is that cdrom_sysctl_register() is called
twice, once from the module init function and once from register_cdrom().
cdrom_sysctl_register() is not mutex protected and may happily execute
twice if the second call is made before the first call is complete.
Use a static atomic to ensure that the function is executed exactly once.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/cdrom/cdrom.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index d203940203b6..aee23092f50e 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -265,6 +265,7 @@
/* #define ERRLOGMASK (CD_WARNING|CD_OPEN|CD_COUNT_TRACKS|CD_CLOSE) */
/* #define ERRLOGMASK (CD_WARNING|CD_REG_UNREG|CD_DO_IOCTL|CD_OPEN|CD_CLOSE|CD_COUNT_TRACKS) */
+#include <linux/atomic.h>
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/major.h>
@@ -3677,9 +3678,9 @@ static struct ctl_table_header *cdrom_sysctl_header;
static void cdrom_sysctl_register(void)
{
- static int initialized;
+ static atomic_t initialized = ATOMIC_INIT(0);
- if (initialized == 1)
+ if (!atomic_add_unless(&initialized, 1, 1))
return;
cdrom_sysctl_header = register_sysctl_table(cdrom_root_table);
@@ -3690,8 +3691,6 @@ static void cdrom_sysctl_register(void)
cdrom_sysctl_settings.debug = debug;
cdrom_sysctl_settings.lock = lockdoor;
cdrom_sysctl_settings.check = check_media_type;
-
- initialized = 1;
}
static void cdrom_sysctl_unregister(void)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 051/168] e1000e: fix cyclic resets at link up with active tx
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 050/168] cdrom: Fix race condition in cdrom_sysctl_register Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:31 ` Konstantin Khlebnikov
2019-04-24 17:08 ` [PATCH 4.4 052/168] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe Greg Kroah-Hartman
` (121 subsequent siblings)
172 siblings, 1 reply; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khlebnikov, Aaron Brown,
Jeff Kirsher, Sasha Levin
[ Upstream commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61 ]
I'm seeing series of e1000e resets (sometimes endless) at system boot
if something generates tx traffic at this time. In my case this is
netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states
have been disabled in order to enable jumbo frames" from e1000e itself.
As result e1000_watchdog_task sees used tx buffer while carrier is off
and start this reset cycle again.
[ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000
[ 23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 27.174495] 8021q: 802.1Q VLAN Support v1.8
[ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1
[ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
[ 30.898564] netpoll: netconsole: local port 6666
[ 30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8
[ 30.898567] netpoll: netconsole: interface 'eth1'
[ 30.898568] netpoll: netconsole: remote port 6666
[ 30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790
[ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0
[ 30.917747] console [netcon0] enabled
[ 30.917749] netconsole: network logging started
[ 31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
This patch flushes tx buffers only once when carrier is off
rather than at each watchdog iteration.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 6b1cacd86c6e..44312962b64e 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5246,8 +5246,13 @@ static void e1000_watchdog_task(struct work_struct *work)
/* 8000ES2LAN requires a Rx packet buffer work-around
* on link down event; reset the controller to flush
* the Rx packet buffer.
+ *
+ * If the link is lost the controller stops DMA, but
+ * if there is queued Tx work it cannot be done. So
+ * reset the controller to flush the Tx packet buffers.
*/
- if (adapter->flags & FLAG_RX_NEEDS_RESTART)
+ if ((adapter->flags & FLAG_RX_NEEDS_RESTART) ||
+ e1000_desc_unused(tx_ring) + 1 < tx_ring->count)
adapter->flags |= FLAG_RESTART_NOW;
else
pm_schedule_suspend(netdev->dev.parent,
@@ -5270,14 +5275,6 @@ link_up:
adapter->gotc_old = adapter->stats.gotc;
spin_unlock(&adapter->stats64_lock);
- /* If the link is lost the controller stops DMA, but
- * if there is queued Tx work it cannot be done. So
- * reset the controller to flush the Tx packet buffers.
- */
- if (!netif_carrier_ok(netdev) &&
- (e1000_desc_unused(tx_ring) + 1 < tx_ring->count))
- adapter->flags |= FLAG_RESTART_NOW;
-
/* If reset is necessary, do it outside of interrupt context. */
if (adapter->flags & FLAG_RESTART_NOW) {
schedule_work(&adapter->reset_task);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 051/168] e1000e: fix cyclic resets at link up with active tx
2019-04-24 17:08 ` [PATCH 4.4 051/168] e1000e: fix cyclic resets at link up with active tx Greg Kroah-Hartman
@ 2019-04-24 17:31 ` Konstantin Khlebnikov
2019-04-25 8:12 ` Greg Kroah-Hartman
0 siblings, 1 reply; 178+ messages in thread
From: Konstantin Khlebnikov @ 2019-04-24 17:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Aaron Brown, Jeff Kirsher, Sasha Levin
Please skip this. It's going to be reverted upstream:
https://patchwork.ozlabs.org/patch/1086838/
while original problem fixed differently:
https://patchwork.ozlabs.org/patch/1086839/
same for 3.18 branch
On 24.04.2019 20:08, Greg Kroah-Hartman wrote:
> [ Upstream commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61 ]
>
> I'm seeing series of e1000e resets (sometimes endless) at system boot
> if something generates tx traffic at this time. In my case this is
> netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states
> have been disabled in order to enable jumbo frames" from e1000e itself.
> As result e1000_watchdog_task sees used tx buffer while carrier is off
> and start this reset cycle again.
>
> [ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
> [ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [ 22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000
> [ 23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
> [ 27.174495] 8021q: 802.1Q VLAN Support v1.8
> [ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1
> [ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
> [ 30.898564] netpoll: netconsole: local port 6666
> [ 30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8
> [ 30.898567] netpoll: netconsole: interface 'eth1'
> [ 30.898568] netpoll: netconsole: remote port 6666
> [ 30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790
> [ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0
> [ 30.917747] console [netcon0] enabled
> [ 30.917749] netconsole: network logging started
> [ 31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
> [ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
>
> This patch flushes tx buffers only once when carrier is off
> rather than at each watchdog iteration.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 6b1cacd86c6e..44312962b64e 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -5246,8 +5246,13 @@ static void e1000_watchdog_task(struct work_struct *work)
> /* 8000ES2LAN requires a Rx packet buffer work-around
> * on link down event; reset the controller to flush
> * the Rx packet buffer.
> + *
> + * If the link is lost the controller stops DMA, but
> + * if there is queued Tx work it cannot be done. So
> + * reset the controller to flush the Tx packet buffers.
> */
> - if (adapter->flags & FLAG_RX_NEEDS_RESTART)
> + if ((adapter->flags & FLAG_RX_NEEDS_RESTART) ||
> + e1000_desc_unused(tx_ring) + 1 < tx_ring->count)
> adapter->flags |= FLAG_RESTART_NOW;
> else
> pm_schedule_suspend(netdev->dev.parent,
> @@ -5270,14 +5275,6 @@ link_up:
> adapter->gotc_old = adapter->stats.gotc;
> spin_unlock(&adapter->stats64_lock);
>
> - /* If the link is lost the controller stops DMA, but
> - * if there is queued Tx work it cannot be done. So
> - * reset the controller to flush the Tx packet buffers.
> - */
> - if (!netif_carrier_ok(netdev) &&
> - (e1000_desc_unused(tx_ring) + 1 < tx_ring->count))
> - adapter->flags |= FLAG_RESTART_NOW;
> -
> /* If reset is necessary, do it outside of interrupt context. */
> if (adapter->flags & FLAG_RESTART_NOW) {
> schedule_work(&adapter->reset_task);
>
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 051/168] e1000e: fix cyclic resets at link up with active tx
2019-04-24 17:31 ` Konstantin Khlebnikov
@ 2019-04-25 8:12 ` Greg Kroah-Hartman
0 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-25 8:12 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-kernel, stable, Aaron Brown, Jeff Kirsher, Sasha Levin
On Wed, Apr 24, 2019 at 08:31:47PM +0300, Konstantin Khlebnikov wrote:
> Please skip this. It's going to be reverted upstream:
> https://patchwork.ozlabs.org/patch/1086838/
>
> while original problem fixed differently:
> https://patchwork.ozlabs.org/patch/1086839/
>
> same for 3.18 branch
Ok, I'll drop it from these two trees. But note that this commit is
already in 4.9.168, 4.14.111, 4.19.34, and 5.0.7, so someone should make
sure to send that revert and "real" fix to the stable tree so we can fix
the issue in those trees too, when it hits Linus's tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 178+ messages in thread
* [PATCH 4.4 052/168] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 051/168] e1000e: fix cyclic resets at link up with active tx Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 053/168] soc: qcom: gsbi: Fix error handling in gsbi_probe() Greg Kroah-Hartman
` (120 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wen Yang, Timur Tabi, Nicolin Chen,
Xiubo Li, Fabio Estevam, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, alsa-devel, linuxppc-dev,
Sasha Levin
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 1b05d1c5d9fd..a32fe14b4687 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -659,6 +659,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+ put_device(&cpu_pdev->dev);
fail:
of_node_put(cpu_np);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 053/168] soc: qcom: gsbi: Fix error handling in gsbi_probe()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 052/168] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 054/168] mt7601u: bump supported EEPROM version Greg Kroah-Hartman
` (119 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexey Khoroshilov, Bjorn Andersson,
Andy Gross, Sasha Levin
[ Upstream commit 8cd09a3dd3e176c62da67efcd477a44a8d87185e ]
If of_platform_populate() fails in gsbi_probe(),
gsbi->hclk is left undisabled.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/qcom/qcom_gsbi.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/qcom_gsbi.c b/drivers/soc/qcom/qcom_gsbi.c
index 09c669e70d63..038abc377fdb 100644
--- a/drivers/soc/qcom/qcom_gsbi.c
+++ b/drivers/soc/qcom/qcom_gsbi.c
@@ -138,7 +138,7 @@ static int gsbi_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
struct gsbi_info *gsbi;
- int i;
+ int i, ret;
u32 mask, gsbi_num;
const struct crci_config *config = NULL;
@@ -221,7 +221,10 @@ static int gsbi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, gsbi);
- return of_platform_populate(node, NULL, NULL, &pdev->dev);
+ ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
+ if (ret)
+ clk_disable_unprepare(gsbi->hclk);
+ return ret;
}
static int gsbi_remove(struct platform_device *pdev)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 054/168] mt7601u: bump supported EEPROM version
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 053/168] soc: qcom: gsbi: Fix error handling in gsbi_probe() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 055/168] ARM: avoid Cortex-A9 livelock on tight dmb loops Greg Kroah-Hartman
` (118 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stanislaw Gruszka, Jakub Kicinski,
Kalle Valo, Sasha Levin, Michael
[ Upstream commit 3bd1505fed71d834f45e87b32ff07157fdda47e0 ]
As reported by Michael eeprom 0d is supported and work with the driver.
Dump of /sys/kernel/debug/ieee80211/phy1/mt7601u/eeprom_param
with 0d EEPORM looks like this:
RSSI offset: 0 0
Reference temp: f9
LNA gain: 8
Reg channels: 1-14
Per rate power:
raw:05 bw20:05 bw40:05
raw:05 bw20:05 bw40:05
raw:03 bw20:03 bw40:03
raw:03 bw20:03 bw40:03
raw:04 bw20:04 bw40:04
raw:00 bw20:00 bw40:00
raw:00 bw20:00 bw40:00
raw:00 bw20:00 bw40:00
raw:02 bw20:02 bw40:02
raw:00 bw20:00 bw40:00
Per channel power:
tx_power ch1:09 ch2:09
tx_power ch3:0a ch4:0a
tx_power ch5:0a ch6:0a
tx_power ch7:0b ch8:0b
tx_power ch9:0b ch10:0b
tx_power ch11:0b ch12:0b
tx_power ch13:0b ch14:0b
Reported-and-tested-by: Michael <ZeroBeat@gmx.de>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt7601u/eeprom.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/eeprom.h b/drivers/net/wireless/mediatek/mt7601u/eeprom.h
index 662d12703b69..57b503ae63f1 100644
--- a/drivers/net/wireless/mediatek/mt7601u/eeprom.h
+++ b/drivers/net/wireless/mediatek/mt7601u/eeprom.h
@@ -17,7 +17,7 @@
struct mt7601u_dev;
-#define MT7601U_EE_MAX_VER 0x0c
+#define MT7601U_EE_MAX_VER 0x0d
#define MT7601U_EEPROM_SIZE 256
#define MT7601U_DEFAULT_TX_POWER 6
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 055/168] ARM: avoid Cortex-A9 livelock on tight dmb loops
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 054/168] mt7601u: bump supported EEPROM version Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 056/168] tty: increase the default flip buffer limit to 2*640K Greg Kroah-Hartman
` (117 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Russell King, Sasha Levin
[ Upstream commit 5388a5b82199facacd3d7ac0d05aca6e8f902fed ]
machine_crash_nonpanic_core() does this:
while (1)
cpu_relax();
because the kernel has crashed, and we have no known safe way to deal
with the CPU. So, we place the CPU into an infinite loop which we
expect it to never exit - at least not until the system as a whole is
reset by some method.
In the absence of erratum 754327, this code assembles to:
b .
In other words, an infinite loop. When erratum 754327 is enabled,
this becomes:
1: dmb
b 1b
It has been observed that on some systems (eg, OMAP4) where, if a
crash is triggered, the system tries to kexec into the panic kernel,
but fails after taking the secondary CPU down - placing it into one
of these loops. This causes the system to livelock, and the most
noticable effect is the system stops after issuing:
Loading crashdump kernel...
to the system console.
The tested as working solution I came up with was to add wfe() to
these infinite loops thusly:
while (1) {
cpu_relax();
wfe();
}
which, without 754327 builds to:
1: wfe
b 1b
or with 754327 is enabled:
1: dmb
wfe
b 1b
Adding "wfe" does two things depending on the environment we're running
under:
- where we're running on bare metal, and the processor implements
"wfe", it stops us spinning endlessly in a loop where we're never
going to do any useful work.
- if we're running in a VM, it allows the CPU to be given back to the
hypervisor and rescheduled for other purposes (maybe a different VM)
rather than wasting CPU cycles inside a crashed VM.
However, in light of erratum 794072, Will Deacon wanted to see 10 nops
as well - which is reasonable to cover the case where we have erratum
754327 enabled _and_ we have a processor that doesn't implement the
wfe hint.
So, we now end up with:
1: wfe
b 1b
when erratum 754327 is disabled, or:
1: dmb
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
wfe
b 1b
when erratum 754327 is enabled. We also get the dmb + 10 nop
sequence elsewhere in the kernel, in terminating loops.
This is reasonable - it means we get the workaround for erratum
794072 when erratum 754327 is enabled, but still relinquish the dead
processor - either by placing it in a lower power mode when wfe is
implemented as such or by returning it to the hypervisior, or in the
case where wfe is a no-op, we use the workaround specified in erratum
794072 to avoid the problem.
These as two entirely orthogonal problems - the 10 nops addresses
erratum 794072, and the wfe is an optimisation that makes the system
more efficient when crashed either in terms of power consumption or
by allowing the host/other VMs to make use of the CPU.
I don't see any reason not to use kexec() inside a VM - it has the
potential to provide automated recovery from a failure of the VMs
kernel with the opportunity for saving a crashdump of the failure.
A panic() with a reboot timeout won't do that, and reading the
libvirt documentation, setting on_reboot to "preserve" won't either
(the documentation states "The preserve action for an on_reboot event
is treated as a destroy".) Surely it has to be a good thing to
avoiding having CPUs spinning inside a VM that is doing no useful
work.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/barrier.h | 2 ++
arch/arm/include/asm/processor.h | 6 +++++-
arch/arm/kernel/machine_kexec.c | 5 ++++-
arch/arm/kernel/smp.c | 4 +++-
arch/arm/mach-omap2/prm_common.c | 4 +++-
5 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 3ff5642d9788..27c1d26b05b5 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -10,6 +10,8 @@
#define sev() __asm__ __volatile__ ("sev" : : : "memory")
#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+#else
+#define wfe() do { } while (0)
#endif
#if __LINUX_ARM_ARCH__ >= 7
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 8a1e8e995dae..08509183c7df 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -77,7 +77,11 @@ extern void release_thread(struct task_struct *);
unsigned long get_wchan(struct task_struct *p);
#if __LINUX_ARM_ARCH__ == 6 || defined(CONFIG_ARM_ERRATA_754327)
-#define cpu_relax() smp_mb()
+#define cpu_relax() \
+ do { \
+ smp_mb(); \
+ __asm__ __volatile__("nop; nop; nop; nop; nop; nop; nop; nop; nop; nop;"); \
+ } while (0)
#else
#define cpu_relax() barrier()
#endif
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 8bf3b7c09888..46519916a465 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -87,8 +87,11 @@ void machine_crash_nonpanic_core(void *unused)
set_cpu_online(smp_processor_id(), false);
atomic_dec(&waiting_for_crash_ipi);
- while (1)
+
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
static void machine_kexec_mask_interrupts(void)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 08ce9e36dc5a..0f1c11861147 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -563,8 +563,10 @@ static void ipi_cpu_stop(unsigned int cpu)
local_fiq_disable();
local_irq_disable();
- while (1)
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
static DEFINE_PER_CPU(struct completion *, cpu_completion);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 0ce4548ef7f0..4b9e9d1d8229 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -533,8 +533,10 @@ void omap_prm_reset_system(void)
prm_ll_data->reset_system();
- while (1)
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
/**
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 056/168] tty: increase the default flip buffer limit to 2*640K
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 055/168] ARM: avoid Cortex-A9 livelock on tight dmb loops Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 057/168] media: mt9m111: set initial frame size other than 0x0 Greg Kroah-Hartman
` (116 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Manfred Schlaegl, Martin Kepplinger,
Sasha Levin
[ Upstream commit 7ab57b76ebf632bf2231ccabe26bea33868118c6 ]
We increase the default limit for buffer memory allocation by a factor of
10 to 640K to prevent data loss when using fast serial interfaces.
For example when using RS485 without flow-control at speeds of 1Mbit/s
an upwards we've run into problems such as applications being too slow
to read out this buffer (on embedded devices based on imx53 or imx6).
If you want to write transmitted data to a slow SD card and thus have
realtime requirements, this limit can become a problem.
That shouldn't be the case and 640K buffers fix such problems for us.
This value is a maximum limit for allocation only. It has no effect
on systems that currently run fine. When transmission is slow enough
applications and hardware can keep up and increasing this limit
doesn't change anything.
It only _allows_ to allocate more than 2*64K in cases we currently fail to
allocate memory despite having some.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/tty_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 355e9cad680d..4706df20191b 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -25,7 +25,7 @@
* Byte threshold to limit memory consumption for flip buffers.
* The actual memory limit is > 2x this amount.
*/
-#define TTYB_DEFAULT_MEM_LIMIT 65536
+#define TTYB_DEFAULT_MEM_LIMIT (640 * 1024UL)
/*
* We default to dicing tty buffer allocations to this many characters
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 057/168] media: mt9m111: set initial frame size other than 0x0
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 056/168] tty: increase the default flip buffer limit to 2*640K Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 058/168] hwrng: virtio - Avoid repeated init of completion Greg Kroah-Hartman
` (115 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Enrico Scholz, Michael Grzeschik,
Marco Felsch, Akinobu Mita, Sakari Ailus, Mauro Carvalho Chehab,
Sasha Levin
[ Upstream commit 29856308137de1c21eda89411695f4fc6e9780ff ]
This driver sets initial frame width and height to 0x0, which is invalid.
So set it to selection rectangle bounds instead.
This is detected by v4l2-compliance detected.
Cc: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Cc: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/i2c/soc_camera/mt9m111.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c b/drivers/media/i2c/soc_camera/mt9m111.c
index 6dfaead6aaa8..1d1ca03c797f 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -988,6 +988,8 @@ static int mt9m111_probe(struct i2c_client *client,
mt9m111->rect.top = MT9M111_MIN_DARK_ROWS;
mt9m111->rect.width = MT9M111_MAX_WIDTH;
mt9m111->rect.height = MT9M111_MAX_HEIGHT;
+ mt9m111->width = mt9m111->rect.width;
+ mt9m111->height = mt9m111->rect.height;
mt9m111->fmt = &mt9m111_colour_fmts[0];
mt9m111->lastpage = -1;
mutex_init(&mt9m111->power_lock);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 058/168] hwrng: virtio - Avoid repeated init of completion
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 057/168] media: mt9m111: set initial frame size other than 0x0 Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 059/168] soc/tegra: fuse: Fix illegal free of IO base address Greg Kroah-Hartman
` (114 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Tolnay, Herbert Xu, Sasha Levin
[ Upstream commit aef027db48da56b6f25d0e54c07c8401ada6ce21 ]
The virtio-rng driver uses a completion called have_data to wait for a
virtio read to be fulfilled by the hypervisor. The completion is reset
before placing a buffer on the virtio queue and completed by the virtio
callback once data has been written into the buffer.
Prior to this commit, the driver called init_completion on this
completion both during probe as well as when registering virtio buffers
as part of a hwrng read operation. The second of these init_completion
calls should instead be reinit_completion because the have_data
completion has already been inited by probe. As described in
Documentation/scheduler/completion.txt, "Calling init_completion() twice
on the same completion object is most likely a bug".
This bug was present in the initial implementation of virtio-rng in
f7f510ec1957 ("virtio: An entropy device, as suggested by hpa"). Back
then the have_data completion was a single static completion rather than
a member of one of potentially multiple virtrng_info structs as
implemented later by 08e53fbdb85c ("virtio-rng: support multiple
virtio-rng devices"). The original driver incorrectly used
init_completion rather than INIT_COMPLETION to reset have_data during
read.
Tested by running `head -c48 /dev/random | hexdump` within crosvm, the
Chrome OS virtual machine monitor, and confirming that the virtio-rng
driver successfully produces random bytes from the host.
Signed-off-by: David Tolnay <dtolnay@gmail.com>
Tested-by: David Tolnay <dtolnay@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/hw_random/virtio-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c
index 3fa2f8a009b3..1c5c4314c6b5 100644
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -73,7 +73,7 @@ static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait)
if (!vi->busy) {
vi->busy = true;
- init_completion(&vi->have_data);
+ reinit_completion(&vi->have_data);
register_buffer(vi, buf, size);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 059/168] soc/tegra: fuse: Fix illegal free of IO base address
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 058/168] hwrng: virtio - Avoid repeated init of completion Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 060/168] hpet: Fix missing = character in the __setup() code of hpet_mmap_enable Greg Kroah-Hartman
` (113 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Timo Alho, Jon Hunter,
Thierry Reding, Sasha Levin
[ Upstream commit 51294bf6b9e897d595466dcda5a3f2751906a200 ]
On cases where device tree entries for fuse and clock provider are in
different order, fuse driver needs to defer probing. This leads to
freeing incorrect IO base address as the fuse->base variable gets
overwritten once during first probe invocation. This leads to the
following spew during boot:
[ 3.082285] Trying to vfree() nonexistent vm area (00000000cfe8fd94)
[ 3.082308] WARNING: CPU: 5 PID: 126 at /hdd/l4t/kernel/stable/mm/vmalloc.c:1511 __vunmap+0xcc/0xd8
[ 3.082318] Modules linked in:
[ 3.082330] CPU: 5 PID: 126 Comm: kworker/5:1 Tainted: G S 4.19.7-tegra-gce119d3 #1
[ 3.082340] Hardware name: quill (DT)
[ 3.082353] Workqueue: events deferred_probe_work_func
[ 3.082364] pstate: 40000005 (nZcv daif -PAN -UAO)
[ 3.082372] pc : __vunmap+0xcc/0xd8
[ 3.082379] lr : __vunmap+0xcc/0xd8
[ 3.082385] sp : ffff00000a1d3b60
[ 3.082391] x29: ffff00000a1d3b60 x28: 0000000000000000
[ 3.082402] x27: 0000000000000000 x26: ffff000008e8b610
[ 3.082413] x25: 0000000000000000 x24: 0000000000000009
[ 3.082423] x23: ffff000009221a90 x22: ffff000009f6d000
[ 3.082432] x21: 0000000000000000 x20: 0000000000000000
[ 3.082442] x19: ffff000009f6d000 x18: ffffffffffffffff
[ 3.082452] x17: 0000000000000000 x16: 0000000000000000
[ 3.082462] x15: ffff0000091396c8 x14: 0720072007200720
[ 3.082471] x13: 0720072007200720 x12: 0720072907340739
[ 3.082481] x11: 0764076607380765 x10: 0766076307300730
[ 3.082491] x9 : 0730073007300730 x8 : 0730073007280720
[ 3.082501] x7 : 0761076507720761 x6 : 0000000000000102
[ 3.082510] x5 : 0000000000000000 x4 : 0000000000000000
[ 3.082519] x3 : ffffffffffffffff x2 : ffff000009150ff8
[ 3.082528] x1 : 3d95b1429fff5200 x0 : 0000000000000000
[ 3.082538] Call trace:
[ 3.082545] __vunmap+0xcc/0xd8
[ 3.082552] vunmap+0x24/0x30
[ 3.082561] __iounmap+0x2c/0x38
[ 3.082569] tegra_fuse_probe+0xc8/0x118
[ 3.082577] platform_drv_probe+0x50/0xa0
[ 3.082585] really_probe+0x1b0/0x288
[ 3.082593] driver_probe_device+0x58/0x100
[ 3.082601] __device_attach_driver+0x98/0xf0
[ 3.082609] bus_for_each_drv+0x64/0xc8
[ 3.082616] __device_attach+0xd8/0x130
[ 3.082624] device_initial_probe+0x10/0x18
[ 3.082631] bus_probe_device+0x90/0x98
[ 3.082638] deferred_probe_work_func+0x74/0xb0
[ 3.082649] process_one_work+0x1e0/0x318
[ 3.082656] worker_thread+0x228/0x450
[ 3.082664] kthread+0x128/0x130
[ 3.082672] ret_from_fork+0x10/0x18
[ 3.082678] ---[ end trace 0810fe6ba772c1c7 ]---
Fix this by retaining the value of fuse->base until driver has
successfully probed.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/tegra/fuse/fuse-tegra.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c b/drivers/soc/tegra/fuse/fuse-tegra.c
index de2c1bfe28b5..c4f5e5bbb8dc 100644
--- a/drivers/soc/tegra/fuse/fuse-tegra.c
+++ b/drivers/soc/tegra/fuse/fuse-tegra.c
@@ -131,13 +131,17 @@ static int tegra_fuse_probe(struct platform_device *pdev)
/* take over the memory region from the early initialization */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
fuse->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(fuse->base))
- return PTR_ERR(fuse->base);
+ if (IS_ERR(fuse->base)) {
+ err = PTR_ERR(fuse->base);
+ fuse->base = base;
+ return err;
+ }
fuse->clk = devm_clk_get(&pdev->dev, "fuse");
if (IS_ERR(fuse->clk)) {
dev_err(&pdev->dev, "failed to get FUSE clock: %ld",
PTR_ERR(fuse->clk));
+ fuse->base = base;
return PTR_ERR(fuse->clk);
}
@@ -146,8 +150,10 @@ static int tegra_fuse_probe(struct platform_device *pdev)
if (fuse->soc->probe) {
err = fuse->soc->probe(fuse);
- if (err < 0)
+ if (err < 0) {
+ fuse->base = base;
return err;
+ }
}
if (tegra_fuse_create_sysfs(&pdev->dev, fuse->soc->info->size,
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 060/168] hpet: Fix missing = character in the __setup() code of hpet_mmap_enable
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 059/168] soc/tegra: fuse: Fix illegal free of IO base address Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 061/168] dmaengine: imx-dma: fix warning comparison of distinct pointer types Greg Kroah-Hartman
` (112 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Buland Singh, Sasha Levin
[ Upstream commit 24d48a61f2666630da130cc2ec2e526eacf229e3 ]
Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for
user processes")' introduced a new kernel command line parameter hpet_mmap,
that is required to expose the memory map of the HPET registers to
user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is
broken and never takes effect due to missing '=' character in the __setup()
code of hpet_mmap_enable.
Before this patch:
dmesg output with the kernel command line parameter hpet_mmap=1
[ 0.204152] HPET mmap disabled
dmesg output with the kernel command line parameter hpet_mmap=0
[ 0.204192] HPET mmap disabled
After this patch:
dmesg output with the kernel command line parameter hpet_mmap=1
[ 0.203945] HPET mmap enabled
dmesg output with the kernel command line parameter hpet_mmap=0
[ 0.204652] HPET mmap disabled
Fixes: 3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes")
Signed-off-by: Buland Singh <bsingh@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 240b6cf1d97c..72e073895ed9 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -376,7 +376,7 @@ static __init int hpet_mmap_enable(char *str)
pr_info("HPET mmap %s\n", hpet_mmap_enabled ? "enabled" : "disabled");
return 1;
}
-__setup("hpet_mmap", hpet_mmap_enable);
+__setup("hpet_mmap=", hpet_mmap_enable);
static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
{
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 061/168] dmaengine: imx-dma: fix warning comparison of distinct pointer types
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 060/168] hpet: Fix missing = character in the __setup() code of hpet_mmap_enable Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 062/168] netfilter: physdev: relax br_netfilter dependency Greg Kroah-Hartman
` (111 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Anders Roxell, Olof Johansson,
Fabio Estevam, Vinod Koul, Sasha Levin
[ Upstream commit 9227ab5643cb8350449502dd9e3168a873ab0e3b ]
The warning got introduced by commit 930507c18304 ("arm64: add basic
Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning
haven't been seen before since size_t was 'unsigned int' when built on
arm32.
../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’:
../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^~
../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’
(__typecheck(x, y) && __no_side_effects(x, y))
^~~~~~~~~~~
../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’
__builtin_choose_expr(__safe_cmp(x, y), \
^~~~~~~~~~
../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’
#define min(x, y) __careful_cmp(x, y, <)
^~~~~~~~~~~~~
../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’
now = min(d->len, sg_dma_len(sg));
^~~
Rework so that we use min_t and pass in the size_t that returns the
minimum of two values, using the specified type.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/dma/imx-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index dfa337ae06fc..529b315a6683 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -286,7 +286,7 @@ static inline int imxdma_sg_next(struct imxdma_desc *d)
struct scatterlist *sg = d->sg;
unsigned long now;
- now = min(d->len, sg_dma_len(sg));
+ now = min_t(size_t, d->len, sg_dma_len(sg));
if (d->len != IMX_DMA_LENGTH_LOOP)
d->len -= now;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 062/168] netfilter: physdev: relax br_netfilter dependency
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 061/168] dmaengine: imx-dma: fix warning comparison of distinct pointer types Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 063/168] media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration Greg Kroah-Hartman
` (110 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Florian Westphal, Pablo Neira Ayuso,
Sasha Levin
[ Upstream commit 8e2f311a68494a6677c1724bdcb10bada21af37c ]
Following command:
iptables -D FORWARD -m physdev ...
causes connectivity loss in some setups.
Reason is that iptables userspace will probe kernel for the module revision
of the physdev patch, and physdev has an artificial dependency on
br_netfilter (xt_physdev use makes no sense unless a br_netfilter module
is loaded).
This causes the "phydev" module to be loaded, which in turn enables the
"call-iptables" infrastructure.
bridged packets might then get dropped by the iptables ruleset.
The better fix would be to change the "call-iptables" defaults to 0 and
enforce explicit setting to 1, but that breaks backwards compatibility.
This does the next best thing: add a request_module call to checkentry.
This was a stray '-D ... -m physdev' won't activate br_netfilter
anymore.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/netfilter/br_netfilter.h | 1 -
net/bridge/br_netfilter_hooks.c | 5 -----
net/netfilter/xt_physdev.c | 9 +++++++--
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/net/netfilter/br_netfilter.h b/include/net/netfilter/br_netfilter.h
index e8d1448425a7..b1d0d46344e2 100644
--- a/include/net/netfilter/br_netfilter.h
+++ b/include/net/netfilter/br_netfilter.h
@@ -42,7 +42,6 @@ static inline struct rtable *bridge_parent_rtable(const struct net_device *dev)
}
struct net_device *setup_pre_routing(struct sk_buff *skb);
-void br_netfilter_enable(void);
#if IS_ENABLED(CONFIG_IPV6)
int br_validate_ipv6(struct net *net, struct sk_buff *skb);
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index 6def85d75b1d..93b5525bcccf 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -873,11 +873,6 @@ static const struct nf_br_ops br_ops = {
.br_dev_xmit_hook = br_nf_dev_xmit,
};
-void br_netfilter_enable(void)
-{
-}
-EXPORT_SYMBOL_GPL(br_netfilter_enable);
-
/* For br_nf_post_routing, we need (prio = NF_BR_PRI_LAST), because
* br_dev_queue_push_xmit is called afterwards */
static struct nf_hook_ops br_nf_ops[] __read_mostly = {
diff --git a/net/netfilter/xt_physdev.c b/net/netfilter/xt_physdev.c
index 1caaccbc306c..7e4063621960 100644
--- a/net/netfilter/xt_physdev.c
+++ b/net/netfilter/xt_physdev.c
@@ -96,8 +96,7 @@ match_outdev:
static int physdev_mt_check(const struct xt_mtchk_param *par)
{
const struct xt_physdev_info *info = par->matchinfo;
-
- br_netfilter_enable();
+ static bool brnf_probed __read_mostly;
if (!(info->bitmask & XT_PHYSDEV_OP_MASK) ||
info->bitmask & ~XT_PHYSDEV_OP_MASK)
@@ -113,6 +112,12 @@ static int physdev_mt_check(const struct xt_mtchk_param *par)
if (par->hook_mask & (1 << NF_INET_LOCAL_OUT))
return -EINVAL;
}
+
+ if (!brnf_probed) {
+ brnf_probed = true;
+ request_module("br_netfilter");
+ }
+
return 0;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 063/168] media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 062/168] netfilter: physdev: relax br_netfilter dependency Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 064/168] regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting Greg Kroah-Hartman
` (109 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pawe? Chmiel, Jacek Anaszewski,
Mauro Carvalho Chehab, Sasha Levin
[ Upstream commit 49710c32cd9d6626a77c9f5f978a5f58cb536b35 ]
Previously when doing format enumeration, it was returning all
formats supported by driver, even if they're not supported by hw.
Add missing check for fmt_ver_flag, so it'll be fixed and only those
supported by hw will be returned. Similar thing is already done
in s5p_jpeg_find_format.
It was found by using v4l2-compliance tool and checking result
of VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS test
and using v4l2-ctl to get list of all supported formats.
Tested on s5pv210-galaxys (Samsung i9000 phone).
Fixes: bb677f3ac434 ("[media] Exynos4 JPEG codec v4l2 driver")
Signed-off-by: Pawe? Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
[hverkuil-cisco@xs4all.nl: fix a few alignment issues]
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 80c83bba7af3..0d981bbf38bc 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1262,13 +1262,16 @@ static int s5p_jpeg_querycap(struct file *file, void *priv,
return 0;
}
-static int enum_fmt(struct s5p_jpeg_fmt *sjpeg_formats, int n,
+static int enum_fmt(struct s5p_jpeg_ctx *ctx,
+ struct s5p_jpeg_fmt *sjpeg_formats, int n,
struct v4l2_fmtdesc *f, u32 type)
{
int i, num = 0;
+ unsigned int fmt_ver_flag = ctx->jpeg->variant->fmt_ver_flag;
for (i = 0; i < n; ++i) {
- if (sjpeg_formats[i].flags & type) {
+ if (sjpeg_formats[i].flags & type &&
+ sjpeg_formats[i].flags & fmt_ver_flag) {
/* index-th format of type type found ? */
if (num == f->index)
break;
@@ -1294,11 +1297,11 @@ static int s5p_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv);
if (ctx->mode == S5P_JPEG_ENCODE)
- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f,
+ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f,
SJPEG_FMT_FLAG_ENC_CAPTURE);
- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f,
- SJPEG_FMT_FLAG_DEC_CAPTURE);
+ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f,
+ SJPEG_FMT_FLAG_DEC_CAPTURE);
}
static int s5p_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
@@ -1307,11 +1310,11 @@ static int s5p_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv);
if (ctx->mode == S5P_JPEG_ENCODE)
- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f,
+ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f,
SJPEG_FMT_FLAG_ENC_OUTPUT);
- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f,
- SJPEG_FMT_FLAG_DEC_OUTPUT);
+ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f,
+ SJPEG_FMT_FLAG_DEC_OUTPUT);
}
static struct s5p_jpeg_q_data *get_q_data(struct s5p_jpeg_ctx *ctx,
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 064/168] regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 063/168] media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 065/168] wlcore: Fix memory leak in case wl12xx_fetch_firmware failure Greg Kroah-Hartman
` (108 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Axel Lin, Mark Brown, Sasha Levin
[ Upstream commit f01a7beb6791f1c419424c1a6958b7d0a289c974 ]
The act8600_sudcdc_voltage_ranges setting does not match the datasheet.
The problems in below entry:
REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000),
1. The off-by-one min_sel causes wrong volatage calculation.
The min_sel should be 192.
2. According to the datasheet[1] Table 7. (on page 43):
The selector 248 (0b11111000) ~ 255 (0b11111111) are 41.400V.
Also fix off-by-one for ACT8600_SUDCDC_VOLTAGE_NUM.
[1] https://active-semi.com/wp-content/uploads/ACT8600_Datasheet.pdf
Fixes: df3a950e4e73 ("regulator: act8865: Add act8600 support")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/regulator/act8865-regulator.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c b/drivers/regulator/act8865-regulator.c
index f8d4cd3d1397..63a00d1d9360 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -131,7 +131,7 @@
* ACT8865 voltage number
*/
#define ACT8865_VOLTAGE_NUM 64
-#define ACT8600_SUDCDC_VOLTAGE_NUM 255
+#define ACT8600_SUDCDC_VOLTAGE_NUM 256
struct act8865 {
struct regmap *regmap;
@@ -154,7 +154,8 @@ static const struct regulator_linear_range act8600_sudcdc_voltage_ranges[] = {
REGULATOR_LINEAR_RANGE(3000000, 0, 63, 0),
REGULATOR_LINEAR_RANGE(3000000, 64, 159, 100000),
REGULATOR_LINEAR_RANGE(12600000, 160, 191, 200000),
- REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000),
+ REGULATOR_LINEAR_RANGE(19000000, 192, 247, 400000),
+ REGULATOR_LINEAR_RANGE(41400000, 248, 255, 0),
};
static struct regulator_ops act8865_ops = {
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 065/168] wlcore: Fix memory leak in case wl12xx_fetch_firmware failure
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 064/168] regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 066/168] x86/build: Mark per-CPU symbols as absolute explicitly for LLD Greg Kroah-Hartman
` (107 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zumeng Chen, Kalle Valo, Sasha Levin
[ Upstream commit ba2ffc96321c8433606ceeb85c9e722b8113e5a7 ]
Release fw_status, raw_fw_status, and tx_res_if when wl12xx_fetch_firmware
failed instead of meaningless goto out to avoid the following memory leak
reports(Only the last one listed):
unreferenced object 0xc28a9a00 (size 512):
comm "kworker/0:4", pid 31298, jiffies 2783204 (age 203.290s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<6624adab>] kmemleak_alloc+0x40/0x74
[<500ddb31>] kmem_cache_alloc_trace+0x1ac/0x270
[<db4d731d>] wl12xx_chip_wakeup+0xc4/0x1fc [wlcore]
[<76c5db53>] wl1271_op_add_interface+0x4a4/0x8f4 [wlcore]
[<cbf30777>] drv_add_interface+0xa4/0x1a0 [mac80211]
[<65bac325>] ieee80211_reconfig+0x9c0/0x1644 [mac80211]
[<2817c80e>] ieee80211_restart_work+0x90/0xc8 [mac80211]
[<7e1d425a>] process_one_work+0x284/0x42c
[<55f9432e>] worker_thread+0x2fc/0x48c
[<abb582c6>] kthread+0x148/0x160
[<63144b13>] ret_from_fork+0x14/0x2c
[< (null)>] (null)
[<1f6e7715>] 0xffffffff
Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ti/wlcore/main.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 7b27c7e23af2..cc10b72607c6 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -1123,8 +1123,11 @@ static int wl12xx_chip_wakeup(struct wl1271 *wl, bool plt)
goto out;
ret = wl12xx_fetch_firmware(wl, plt);
- if (ret < 0)
- goto out;
+ if (ret < 0) {
+ kfree(wl->fw_status);
+ kfree(wl->raw_fw_status);
+ kfree(wl->tx_res_if);
+ }
out:
return ret;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 066/168] x86/build: Mark per-CPU symbols as absolute explicitly for LLD
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 065/168] wlcore: Fix memory leak in case wl12xx_fetch_firmware failure Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 067/168] dmaengine: tegra: avoid overflow of byte tracking Greg Kroah-Hartman
` (106 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Golovin,
Rafael Ávila de Espíndola, Nick Desaulniers,
Borislav Petkov, H. Peter Anvin, Andy Lutomirski, Brijesh Singh,
Cao Jin, Ingo Molnar, Joerg Roedel, Masahiro Yamada,
Masami Hiramatsu, Thomas Gleixner, Tri Vo, morbo, x86-ml,
Sasha Levin
[ Upstream commit d071ae09a4a1414c1433d5ae9908959a7325b0ad ]
Accessing per-CPU variables is done by finding the offset of the
variable in the per-CPU block and adding it to the address of the
respective CPU's block.
Section 3.10.8 of ld.bfd's documentation states:
For expressions involving numbers, relative addresses and absolute
addresses, ld follows these rules to evaluate terms:
Other binary operations, that is, between two relative addresses
not in the same section, or between a relative address and an
absolute address, first convert any non-absolute term to an
absolute address before applying the operator."
Note that LLVM's linker does not adhere to the GNU ld's implementation
and as such requires implicitly-absolute terms to be explicitly marked
as absolute in the linker script. If not, it fails currently with:
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:153: at least one side of the expression must be absolute
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:154: at least one side of the expression must be absolute
Makefile:1040: recipe for target 'vmlinux' failed
This is not a functional change for ld.bfd which converts the term to an
absolute symbol anyways as specified above.
Based on a previous submission by Tri Vo <trong@android.com>.
Reported-by: Dmitry Golovin <dima@golovin.in>
Signed-off-by: Rafael Ávila de Espíndola <rafael@espindo.la>
[ Update commit message per Boris' and Michael's suggestions. ]
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
[ Massage commit message more, fix typos. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Dmitry Golovin <dima@golovin.in>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Cao Jin <caoj.fnst@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tri Vo <trong@android.com>
Cc: dima@golovin.in
Cc: morbo@google.com
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181219190145.252035-1-ndesaulniers@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index a703842b54de..17e1e60b6b40 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -365,7 +365,7 @@ SECTIONS
* Per-cpu symbols which need to be offset from __per_cpu_load
* for the boot processor.
*/
-#define INIT_PER_CPU(x) init_per_cpu__##x = x + __per_cpu_load
+#define INIT_PER_CPU(x) init_per_cpu__##x = ABSOLUTE(x) + __per_cpu_load
INIT_PER_CPU(gdt_page);
INIT_PER_CPU(irq_stack_union);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 067/168] dmaengine: tegra: avoid overflow of byte tracking
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 066/168] x86/build: Mark per-CPU symbols as absolute explicitly for LLD Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 068/168] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers Greg Kroah-Hartman
` (105 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Osipenko, Ben Dooks,
Jon Hunter, Vinod Koul, Sasha Levin
[ Upstream commit e486df39305864604b7e25f2a95d51039517ac57 ]
The dma_desc->bytes_transferred counter tracks the number of bytes
moved by the DMA channel. This is then used to calculate the information
passed back in the in the tegra_dma_tx_status callback, which is usually
fine.
When the DMA channel is configured as continous, then the bytes_transferred
counter will increase over time and eventually overflow to become negative
so the residue count will become invalid and the ALSA sound-dma code will
report invalid hardware pointer values to the application. This results in
some users becoming confused about the playout position and putting audio
data in the wrong place.
To fix this issue, always ensure the bytes_transferred field is modulo the
size of the request. We only do this for the case of the cyclic transfer
done ISR as anyone attempting to move 2GiB of DMA data in one transfer
is unlikely.
Note, we don't fix the issue that we should /never/ transfer a negative
number of bytes so we could make those fields unsigned.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/dma/tegra20-apb-dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index c8f79dcaaee8..67f201b8dcda 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -632,7 +632,10 @@ static void handle_cont_sngl_cycle_dma_done(struct tegra_dma_channel *tdc,
sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq), node);
dma_desc = sgreq->dma_desc;
- dma_desc->bytes_transferred += sgreq->req_len;
+ /* if we dma for long enough the transfer count will wrap */
+ dma_desc->bytes_transferred =
+ (dma_desc->bytes_transferred + sgreq->req_len) %
+ dma_desc->bytes_requested;
/* Callback need to be call */
if (!dma_desc->cb_count)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 068/168] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 067/168] dmaengine: tegra: avoid overflow of byte tracking Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 069/168] binfmt_elf: switch to new creds when switching to new mm Greg Kroah-Hartman
` (104 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Brian Vincent,
Ville Syrjälä,
Dhinakaran Pandiyan, Sasha Levin
[ Upstream commit c978ae9bde582e82a04c63a4071701691dd8b35c ]
We aren't supposed to force a stop+start between every i2c msg
when performing multi message transfers. This should eg. cause
the DDC segment address to be reset back to 0 between writing
the segment address and reading the actual EDID extension block.
To quote the E-DDC spec:
"... this standard requires that the segment pointer be
reset to 00h when a NO ACK or a STOP condition is received."
Since we're going to touch this might as well consult the
I2C_M_STOP flag to determine whether we want to force the stop
or not.
Cc: Brian Vincent <brainn@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5a1bafb5ecbb..ff12d926eb65 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3019,6 +3019,7 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs
msg.u.i2c_read.transactions[i].i2c_dev_id = msgs[i].addr;
msg.u.i2c_read.transactions[i].num_bytes = msgs[i].len;
msg.u.i2c_read.transactions[i].bytes = msgs[i].buf;
+ msg.u.i2c_read.transactions[i].no_stop_bit = !(msgs[i].flags & I2C_M_STOP);
}
msg.u.i2c_read.read_i2c_device_id = msgs[num - 1].addr;
msg.u.i2c_read.num_bytes_read = msgs[num - 1].len;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 069/168] binfmt_elf: switch to new creds when switching to new mm
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 068/168] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 070/168] kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD Greg Kroah-Hartman
` (103 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Robert Święcki,
Peter Zijlstra, David Howells, Oleg Nesterov, Andy Lutomirski,
Eric W. Biederman, Willy Tarreau, Kees Cook, Al Viro,
Linus Torvalds, Federico Manuel Bento
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46 upstream.
We used to delay switching to the new credentials until after we had
mapped the executable (and possible elf interpreter). That was kind of
odd to begin with, since the new executable will actually then _run_
with the new creds, but whatever.
The bigger problem was that we also want to make sure that we turn off
prof events and tracing before we start mapping the new executable
state. So while this is a cleanup, it's also a fix for a possible
information leak.
Reported-by: Robert Święcki <robert@swiecki.net>
Tested-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Federico Manuel Bento <up201407890@fc.up.pt>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/binfmt_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -850,6 +850,7 @@ static int load_elf_binary(struct linux_
current->flags |= PF_RANDOMIZE;
setup_new_exec(bprm);
+ install_exec_creds(bprm);
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
@@ -1084,7 +1085,6 @@ static int load_elf_binary(struct linux_
goto out;
#endif /* ARCH_HAS_SETUP_ADDITIONAL_PAGES */
- install_exec_creds(bprm);
retval = create_elf_tables(bprm, &loc->elf_ex,
load_addr, interp_load_addr);
if (retval < 0)
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 070/168] kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 069/168] binfmt_elf: switch to new creds when switching to new mm Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 071/168] x86/build: Specify elf_i386 linker emulation explicitly for i386 objects Greg Kroah-Hartman
` (102 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nathan Chancellor, Nick Desaulniers,
Masahiro Yamada, Sasha Levin
commit ad15006cc78459d059af56729c4d9bed7c7fd860 upstream.
This causes an issue when trying to build with `make LD=ld.lld` if
ld.lld and the rest of your cross tools aren't in the same directory
(ex. /usr/local/bin) (as is the case for Android's build system), as the
GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point
where LLVM tools are, not GCC/binutils tools are located.
Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by
binutils for which LLVM does not provide a substitute for, such as
elfedit.
Fixes: 785f11aa595b ("kbuild: Add better clang cross build support")
Link: https://github.com/ClangBuiltLinux/linux/issues/341
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 35be7983ef2d..7bf3fb717921 100644
--- a/Makefile
+++ b/Makefile
@@ -610,7 +610,7 @@ all: vmlinux
ifeq ($(cc-name),clang)
ifneq ($(CROSS_COMPILE),)
CLANG_TARGET := --target=$(notdir $(CROSS_COMPILE:%-=%))
-GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD)))
+GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
CLANG_PREFIX := --prefix=$(GCC_TOOLCHAIN_DIR)
GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
endif
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 071/168] x86/build: Specify elf_i386 linker emulation explicitly for i386 objects
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 070/168] kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 072/168] x86: vdso: Use $LD instead of $CC to link Greg Kroah-Hartman
` (101 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Golovin, George Rimar, Tri Vo,
Borislav Petkov, Nick Desaulniers, H. Peter Anvin, Ingo Molnar,
Michael Matz, Thomas Gleixner, morbo, ruiu, x86-ml,
Nathan Chancellor, Sasha Levin
commit 927185c124d62a9a4d35878d7f6d432a166b74e3 upstream.
The kernel uses the OUTPUT_FORMAT linker script command in it's linker
scripts. Most of the time, the -m option is passed to the linker with
correct architecture, but sometimes (at least for x86_64) the -m option
contradicts the OUTPUT_FORMAT directive.
Specifically, arch/x86/boot and arch/x86/realmode/rm produce i386 object
files, but are linked with the -m elf_x86_64 linker flag when building
for x86_64.
The GNU linker manpage doesn't explicitly state any tie-breakers between
-m and OUTPUT_FORMAT. But with BFD and Gold linkers, OUTPUT_FORMAT
overrides the emulation value specified with the -m option.
LLVM lld has a different behavior, however. When supplied with
contradicting -m and OUTPUT_FORMAT values it fails with the following
error message:
ld.lld: error: arch/x86/realmode/rm/header.o is incompatible with elf_x86_64
Therefore, just add the correct -m after the incorrect one (it overrides
it), so the linker invocation looks like this:
ld -m elf_x86_64 -z max-page-size=0x200000 -m elf_i386 --emit-relocs -T \
realmode.lds header.o trampoline_64.o stack.o reboot.o -o realmode.elf
This is not a functional change for GNU ld, because (although not
explicitly documented) OUTPUT_FORMAT overrides -m EMULATION.
Tested by building x86_64 kernel with GNU gcc/ld toolchain and booting
it in QEMU.
[ bp: massage and clarify text. ]
Suggested-by: Dmitry Golovin <dima@golovin.in>
Signed-off-by: George Rimar <grimar@accesssoftek.com>
Signed-off-by: Tri Vo <trong@android.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Tri Vo <trong@android.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Michael Matz <matz@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: morbo@google.com
Cc: ndesaulniers@google.com
Cc: ruiu@google.com
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20190111201012.71210-1-trong@android.com
[nc: Fix conflicts due to lack of commit 58ab5e0c2c40 ("Kbuild: arch:
look for generated headers in obtree") in this tree]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/boot/Makefile | 2 +-
arch/x86/realmode/rm/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 6da2cd0897f3..e94745321cac 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -100,7 +100,7 @@ $(obj)/zoffset.h: $(obj)/compressed/vmlinux FORCE
AFLAGS_header.o += -I$(obj)
$(obj)/header.o: $(obj)/voffset.h $(obj)/zoffset.h
-LDFLAGS_setup.elf := -T
+LDFLAGS_setup.elf := -m elf_i386 -T
$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
$(call if_changed,ld)
diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
index 2730d775ef9a..228cb16962ba 100644
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -43,7 +43,7 @@ $(obj)/pasyms.h: $(REALMODE_OBJS) FORCE
targets += realmode.lds
$(obj)/realmode.lds: $(obj)/pasyms.h
-LDFLAGS_realmode.elf := --emit-relocs -T
+LDFLAGS_realmode.elf := -m elf_i386 --emit-relocs -T
CPPFLAGS_realmode.lds += -P -C -I$(obj)
targets += realmode.elf
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 072/168] x86: vdso: Use $LD instead of $CC to link
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 071/168] x86/build: Specify elf_i386 linker emulation explicitly for i386 objects Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 073/168] x86/vdso: Drop implicit common-page-size linker flag Greg Kroah-Hartman
` (100 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alistair Strachan, Thomas Gleixner,
Andy Lutomirski, H. Peter Anvin, kernel-team, joel, Andi Kleen,
Nathan Chancellor, Sasha Levin
commit 379d98ddf41344273d9718556f761420f4dc80b3 upstream.
The vdso{32,64}.so can fail to link with CC=clang when clang tries to find
a suitable GCC toolchain to link these libraries with.
/usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o:
access beyond end of merged section (782)
This happens because the host environment leaked into the cross compiler
environment due to the way clang searches for suitable GCC toolchains.
Clang is a retargetable compiler, and each invocation of it must provide
--target=<something> --gcc-toolchain=<something> to allow it to find the
correct binutils for cross compilation. These flags had been added to
KBUILD_CFLAGS, but the vdso code uses CC and not KBUILD_CFLAGS (for various
reasons) which breaks clang's ability to find the correct linker when cross
compiling.
Most of the time this goes unnoticed because the host linker is new enough
to work anyway, or is incompatible and skipped, but this cannot be reliably
assumed.
This change alters the vdso makefile to just use LD directly, which
bypasses clang and thus the searching problem. The makefile will just use
${CROSS_COMPILE}ld instead, which is always what we want. This matches the
method used to link vmlinux.
This drops references to DISABLE_LTO; this option doesn't seem to be set
anywhere, and not knowing what its possible values are, it's not clear how
to convert it from CC to LD flag.
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: kernel-team@android.com
Cc: joel@joelfernandes.org
Cc: Andi Kleen <andi.kleen@intel.com>
Link: https://lkml.kernel.org/r/20180803173931.117515-1-astrachan@google.com
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/entry/vdso/Makefile | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 265c0ed68118..84c4a7105c2a 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -41,10 +41,8 @@ targets += $(vdso_img_sodbg)
export CPPFLAGS_vdso.lds += -P -C
-VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
- -Wl,--no-undefined \
- -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 \
- $(DISABLE_LTO)
+VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -soname linux-vdso.so.1 --no-undefined \
+ -z max-page-size=4096 -z common-page-size=4096
$(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
$(call if_changed,vdso)
@@ -90,10 +88,8 @@ CFLAGS_REMOVE_vvar.o = -pg
#
CPPFLAGS_vdsox32.lds = $(CPPFLAGS_vdso.lds)
-VDSO_LDFLAGS_vdsox32.lds = -Wl,-m,elf32_x86_64 \
- -Wl,-soname=linux-vdso.so.1 \
- -Wl,-z,max-page-size=4096 \
- -Wl,-z,common-page-size=4096
+VDSO_LDFLAGS_vdsox32.lds = -m elf32_x86_64 -soname linux-vdso.so.1 \
+ -z max-page-size=4096 -z common-page-size=4096
# 64-bit objects to re-brand as x32
vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
@@ -121,7 +117,7 @@ $(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) FORCE
$(call if_changed,vdso)
CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
-VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1
+VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -soname linux-gate.so.1
# This makes sure the $(obj) subdirectory exists even though vdso32/
# is not a kbuild sub-make subdirectory.
@@ -157,13 +153,13 @@ $(obj)/vdso32.so.dbg: FORCE \
# The DSO images are built using a special linker script.
#
quiet_cmd_vdso = VDSO $@
- cmd_vdso = $(CC) -nostdlib -o $@ \
+ cmd_vdso = $(LD) -nostdlib -o $@ \
$(VDSO_LDFLAGS) $(VDSO_LDFLAGS_$(filter %.lds,$(^F))) \
- -Wl,-T,$(filter %.lds,$^) $(filter %.o,$^) && \
+ -T $(filter %.lds,$^) $(filter %.o,$^) && \
sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
-VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=both) \
- $(call cc-ldoption, -Wl$(comma)--build-id) -Wl,-Bsymbolic $(LTO_CFLAGS)
+VDSO_LDFLAGS = -shared $(call ld-option, --hash-style=both) \
+ $(call ld-option, --build-id) -Bsymbolic
GCOV_PROFILE := n
#
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 073/168] x86/vdso: Drop implicit common-page-size linker flag
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 072/168] x86: vdso: Use $LD instead of $CC to link Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 074/168] lib/string.c: implement a basic bcmp Greg Kroah-Hartman
` (99 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Golovin, Bill Wendling,
Rui Ueyama, Nick Desaulniers, Borislav Petkov, Andy Lutomirski,
Andi Kleen, Fangrui Song, H. Peter Anvin, Ingo Molnar,
Thomas Gleixner, x86-ml, Nathan Chancellor, Sasha Levin
commit ac3e233d29f7f77f28243af0132057d378d3ea58 upstream.
GNU linker's -z common-page-size's default value is based on the target
architecture. arch/x86/entry/vdso/Makefile sets it to the architecture
default, which is implicit and redundant. Drop it.
Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
Reported-by: Dmitry Golovin <dima@golovin.in>
Reported-by: Bill Wendling <morbo@google.com>
Suggested-by: Dmitry Golovin <dima@golovin.in>
Suggested-by: Rui Ueyama <ruiu@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Fangrui Song <maskray@google.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
Link: https://bugs.llvm.org/show_bug.cgi?id=38774
Link: https://github.com/ClangBuiltLinux/linux/issues/31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/entry/vdso/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 84c4a7105c2a..297dda4d5947 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -42,7 +42,7 @@ targets += $(vdso_img_sodbg)
export CPPFLAGS_vdso.lds += -P -C
VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -soname linux-vdso.so.1 --no-undefined \
- -z max-page-size=4096 -z common-page-size=4096
+ -z max-page-size=4096
$(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
$(call if_changed,vdso)
@@ -89,7 +89,7 @@ CFLAGS_REMOVE_vvar.o = -pg
CPPFLAGS_vdsox32.lds = $(CPPFLAGS_vdso.lds)
VDSO_LDFLAGS_vdsox32.lds = -m elf32_x86_64 -soname linux-vdso.so.1 \
- -z max-page-size=4096 -z common-page-size=4096
+ -z max-page-size=4096
# 64-bit objects to re-brand as x32
vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 074/168] lib/string.c: implement a basic bcmp
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 073/168] x86/vdso: Drop implicit common-page-size linker flag Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 075/168] tty: mark Siemens R3964 line discipline as BROKEN Greg Kroah-Hartman
` (98 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nick Desaulniers, Nathan Chancellor,
Adhemerval Zanella, Arnd Bergmann, James Y Knight,
Masahiro Yamada, Rasmus Villemoes, Steven Rostedt (VMware),
Andy Shevchenko, David Laight, Namhyung Kim, Alexander Shishkin,
Dan Williams, Andrew Morton, Linus Torvalds, Sasha Levin
[ Upstream commit 5f074f3e192f10c9fade898b9b3b8812e3d83342 ]
A recent optimization in Clang (r355672) lowers comparisons of the
return value of memcmp against zero to comparisons of the return value
of bcmp against zero. This helps some platforms that implement bcmp
more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
an optimized implementation is in the works.
This results in linkage failures for all targets with Clang due to the
undefined symbol. For now, just implement bcmp as a tailcail to memcmp
to unbreak the build. This routine can be further optimized in the
future.
Other ideas discussed:
* A weak alias was discussed, but breaks for architectures that define
their own implementations of memcmp since aliases to declarations are
not permitted (only definitions). Arch-specific memcmp
implementations typically declare memcmp in C headers, but implement
them in assembly.
* -ffreestanding also is used sporadically throughout the kernel.
* -fno-builtin-bcmp doesn't work when doing LTO.
Link: https://bugs.llvm.org/show_bug.cgi?id=41035
Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
Link: https://github.com/ClangBuiltLinux/linux/issues/416
Link: http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: James Y Knight <jyknight@google.com>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/string.h | 3 +++
lib/string.c | 20 ++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index c026b7a19e26..870268d42ae7 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -110,6 +110,9 @@ extern void * memscan(void *,int,__kernel_size_t);
#ifndef __HAVE_ARCH_MEMCMP
extern int memcmp(const void *,const void *,__kernel_size_t);
#endif
+#ifndef __HAVE_ARCH_BCMP
+extern int bcmp(const void *,const void *,__kernel_size_t);
+#endif
#ifndef __HAVE_ARCH_MEMCHR
extern void * memchr(const void *,int,__kernel_size_t);
#endif
diff --git a/lib/string.c b/lib/string.c
index 1a90db9bc6e1..c7cf65ac42ad 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -746,6 +746,26 @@ __visible int memcmp(const void *cs, const void *ct, size_t count)
EXPORT_SYMBOL(memcmp);
#endif
+#ifndef __HAVE_ARCH_BCMP
+/**
+ * bcmp - returns 0 if and only if the buffers have identical contents.
+ * @a: pointer to first buffer.
+ * @b: pointer to second buffer.
+ * @len: size of buffers.
+ *
+ * The sign or magnitude of a non-zero return value has no particular
+ * meaning, and architectures may implement their own more efficient bcmp(). So
+ * while this particular implementation is a simple (tail) call to memcmp, do
+ * not rely on anything but whether the return value is zero or non-zero.
+ */
+#undef bcmp
+int bcmp(const void *a, const void *b, size_t len)
+{
+ return memcmp(a, b, len);
+}
+EXPORT_SYMBOL(bcmp);
+#endif
+
#ifndef __HAVE_ARCH_MEMSCAN
/**
* memscan - Find a character in an area of memory.
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 075/168] tty: mark Siemens R3964 line discipline as BROKEN
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 074/168] lib/string.c: implement a basic bcmp Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 076/168] tty: ldisc: add sysctl to prevent autoloading of ldiscs Greg Kroah-Hartman
` (97 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jann Horn, Linus Torvalds
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7084edc3f6d67750f50d4183134c4fb5712a5c8 upstream.
The n_r3964 line discipline driver was written in a different time, when
SMP machines were rare, and users were trusted to do the right thing.
Since then, the world has moved on but not this code, it has stayed
rooted in the past with its lovely hand-crafted list structures and
loads of "interesting" race conditions all over the place.
After attempting to clean up most of the issues, I just gave up and am
now marking the driver as BROKEN so that hopefully someone who has this
hardware will show up out of the woodwork (I know you are out there!)
and will help with debugging a raft of changes that I had laying around
for the code, but was too afraid to commit as odds are they would break
things.
Many thanks to Jann and Linus for pointing out the initial problems in
this codebase, as well as many reviews of my attempts to fix the issues.
It was a case of whack-a-mole, and as you can see, the mole won.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
drivers/char/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -389,7 +389,7 @@ config XILINX_HWICAP
config R3964
tristate "Siemens R3964 line discipline"
- depends on TTY
+ depends on TTY && BROKEN
---help---
This driver allows synchronous communication with devices using the
Siemens R3964 packet protocol. Unless you are dealing with special
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 076/168] tty: ldisc: add sysctl to prevent autoloading of ldiscs
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 075/168] tty: mark Siemens R3964 line discipline as BROKEN Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 077/168] ipv6: Fix dangling pointer when ipv6 fragment Greg Kroah-Hartman
` (96 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c0cca7c847e6e019d67b7d793efbbe3b947d004 upstream.
By default, the kernel will automatically load the module of any line
dicipline that is asked for. As this sometimes isn't the safest thing
to do, provide a sysctl to disable this feature.
By default, we set this to 'y' as that is the historical way that Linux
has worked, and we do not want to break working systems. But in the
future, perhaps this can default to 'n' to prevent this functionality.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/Kconfig | 23 +++++++++++++++++++++++
drivers/tty/tty_io.c | 3 +++
drivers/tty/tty_ldisc.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+)
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -466,4 +466,27 @@ config MIPS_EJTAG_FDC_KGDB_CHAN
help
FDC channel number to use for KGDB.
+config LDISC_AUTOLOAD
+ bool "Automatically load TTY Line Disciplines"
+ default y
+ help
+ Historically the kernel has always automatically loaded any
+ line discipline that is in a kernel module when a user asks
+ for it to be loaded with the TIOCSETD ioctl, or through other
+ means. This is not always the best thing to do on systems
+ where you know you will not be using some of the more
+ "ancient" line disciplines, so prevent the kernel from doing
+ this unless the request is coming from a process with the
+ CAP_SYS_MODULE permissions.
+
+ Say 'Y' here if you trust your userspace users to do the right
+ thing, or if you have only provided the line disciplines that
+ you know you will be using, or if you wish to continue to use
+ the traditional method of on-demand loading of these modules
+ by any user.
+
+ This functionality can be changed at runtime with the
+ dev.tty.ldisc_autoload sysctl, this configuration option will
+ only set the default value of this functionality.
+
endif # TTY
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -513,6 +513,8 @@ void proc_clear_tty(struct task_struct *
tty_kref_put(tty);
}
+extern void tty_sysctl_init(void);
+
/**
* proc_set_tty - set the controlling terminal
*
@@ -3689,6 +3691,7 @@ void console_sysfs_notify(void)
*/
int __init tty_init(void)
{
+ tty_sysctl_init();
cdev_init(&tty_cdev, &tty_fops);
if (cdev_add(&tty_cdev, MKDEV(TTYAUX_MAJOR, 0), 1) ||
register_chrdev_region(MKDEV(TTYAUX_MAJOR, 0), 1, "/dev/tty") < 0)
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -148,6 +148,13 @@ static void put_ldops(struct tty_ldisc_o
* takes tty_ldiscs_lock to guard against ldisc races
*/
+#if defined(CONFIG_LDISC_AUTOLOAD)
+ #define INITIAL_AUTOLOAD_STATE 1
+#else
+ #define INITIAL_AUTOLOAD_STATE 0
+#endif
+static int tty_ldisc_autoload = INITIAL_AUTOLOAD_STATE;
+
static struct tty_ldisc *tty_ldisc_get(struct tty_struct *tty, int disc)
{
struct tty_ldisc *ld;
@@ -162,6 +169,8 @@ static struct tty_ldisc *tty_ldisc_get(s
*/
ldops = get_ldops(disc);
if (IS_ERR(ldops)) {
+ if (!capable(CAP_SYS_MODULE) && !tty_ldisc_autoload)
+ return ERR_PTR(-EPERM);
request_module("tty-ldisc-%d", disc);
ldops = get_ldops(disc);
if (IS_ERR(ldops))
@@ -830,3 +839,41 @@ void tty_ldisc_begin(void)
/* Setup the default TTY line discipline. */
(void) tty_register_ldisc(N_TTY, &tty_ldisc_N_TTY);
}
+
+static int zero;
+static int one = 1;
+static struct ctl_table tty_table[] = {
+ {
+ .procname = "ldisc_autoload",
+ .data = &tty_ldisc_autoload,
+ .maxlen = sizeof(tty_ldisc_autoload),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
+ { }
+};
+
+static struct ctl_table tty_dir_table[] = {
+ {
+ .procname = "tty",
+ .mode = 0555,
+ .child = tty_table,
+ },
+ { }
+};
+
+static struct ctl_table tty_root_table[] = {
+ {
+ .procname = "dev",
+ .mode = 0555,
+ .child = tty_dir_table,
+ },
+ { }
+};
+
+void tty_sysctl_init(void)
+{
+ register_sysctl_table(tty_root_table);
+}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 077/168] ipv6: Fix dangling pointer when ipv6 fragment
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 076/168] tty: ldisc: add sysctl to prevent autoloading of ldiscs Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 078/168] ipv6: sit: reset ip header pointer in ipip6_rcv Greg Kroah-Hartman
` (95 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Junwei Hu, Wenhao Zhang,
syzbot+e8ce541d095e486074fc, Zhiqiang Liu, Martin KaFai Lau,
David S. Miller
From: Junwei Hu <hujunwei4@huawei.com>
[ Upstream commit ef0efcd3bd3fd0589732b67fb586ffd3c8705806 ]
At the beginning of ip6_fragment func, the prevhdr pointer is
obtained in the ip6_find_1stfragopt func.
However, all the pointers pointing into skb header may change
when calling skb_checksum_help func with
skb->ip_summed = CHECKSUM_PARTIAL condition.
The prevhdr pointe will be dangling if it is not reloaded after
calling __skb_linearize func in skb_checksum_help func.
Here, I add a variable, nexthdr_offset, to evaluate the offset,
which does not changes even after calling __skb_linearize func.
Fixes: 405c92f7a541 ("ipv6: add defensive check for CHECKSUM_PARTIAL skbs in ip_fragment")
Signed-off-by: Junwei Hu <hujunwei4@huawei.com>
Reported-by: Wenhao Zhang <zhangwenhao8@huawei.com>
Reported-by: syzbot+e8ce541d095e486074fc@syzkaller.appspotmail.com
Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -575,7 +575,7 @@ int ip6_fragment(struct net *net, struct
inet6_sk(skb->sk) : NULL;
struct ipv6hdr *tmp_hdr;
struct frag_hdr *fh;
- unsigned int mtu, hlen, left, len;
+ unsigned int mtu, hlen, left, len, nexthdr_offset;
int hroom, troom;
__be32 frag_id;
int ptr, offset = 0, err = 0;
@@ -586,6 +586,7 @@ int ip6_fragment(struct net *net, struct
goto fail;
hlen = err;
nexthdr = *prevhdr;
+ nexthdr_offset = prevhdr - skb_network_header(skb);
mtu = ip6_skb_dst_mtu(skb);
@@ -620,6 +621,7 @@ int ip6_fragment(struct net *net, struct
(err = skb_checksum_help(skb)))
goto fail;
+ prevhdr = skb_network_header(skb) + nexthdr_offset;
hroom = LL_RESERVED_SPACE(rt->dst.dev);
if (skb_has_frag_list(skb)) {
int first_len = skb_pagelen(skb);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 078/168] ipv6: sit: reset ip header pointer in ipip6_rcv
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (76 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 077/168] ipv6: Fix dangling pointer when ipv6 fragment Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 079/168] net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock() Greg Kroah-Hartman
` (94 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jianlin Shi, Lorenzo Bianconi,
David S. Miller
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit bb9bd814ebf04f579be466ba61fc922625508807 ]
ipip6 tunnels run iptunnel_pull_header on received skbs. This can
determine the following use-after-free accessing iph pointer since
the packet will be 'uncloned' running pskb_expand_head if it is a
cloned gso skb (e.g if the packet has been sent though a veth device)
[ 706.369655] BUG: KASAN: use-after-free in ipip6_rcv+0x1678/0x16e0 [sit]
[ 706.449056] Read of size 1 at addr ffffe01b6bd855f5 by task ksoftirqd/1/=
[ 706.669494] Hardware name: HPE ProLiant m400 Server/ProLiant m400 Server, BIOS U02 08/19/2016
[ 706.771839] Call trace:
[ 706.801159] dump_backtrace+0x0/0x2f8
[ 706.845079] show_stack+0x24/0x30
[ 706.884833] dump_stack+0xe0/0x11c
[ 706.925629] print_address_description+0x68/0x260
[ 706.982070] kasan_report+0x178/0x340
[ 707.025995] __asan_report_load1_noabort+0x30/0x40
[ 707.083481] ipip6_rcv+0x1678/0x16e0 [sit]
[ 707.132623] tunnel64_rcv+0xd4/0x200 [tunnel4]
[ 707.185940] ip_local_deliver_finish+0x3b8/0x988
[ 707.241338] ip_local_deliver+0x144/0x470
[ 707.289436] ip_rcv_finish+0x43c/0x14b0
[ 707.335447] ip_rcv+0x628/0x1138
[ 707.374151] __netif_receive_skb_core+0x1670/0x2600
[ 707.432680] __netif_receive_skb+0x28/0x190
[ 707.482859] process_backlog+0x1d0/0x610
[ 707.529913] net_rx_action+0x37c/0xf68
[ 707.574882] __do_softirq+0x288/0x1018
[ 707.619852] run_ksoftirqd+0x70/0xa8
[ 707.662734] smpboot_thread_fn+0x3a4/0x9e8
[ 707.711875] kthread+0x2c8/0x350
[ 707.750583] ret_from_fork+0x10/0x18
[ 707.811302] Allocated by task 16982:
[ 707.854182] kasan_kmalloc.part.1+0x40/0x108
[ 707.905405] kasan_kmalloc+0xb4/0xc8
[ 707.948291] kasan_slab_alloc+0x14/0x20
[ 707.994309] __kmalloc_node_track_caller+0x158/0x5e0
[ 708.053902] __kmalloc_reserve.isra.8+0x54/0xe0
[ 708.108280] __alloc_skb+0xd8/0x400
[ 708.150139] sk_stream_alloc_skb+0xa4/0x638
[ 708.200346] tcp_sendmsg_locked+0x818/0x2b90
[ 708.251581] tcp_sendmsg+0x40/0x60
[ 708.292376] inet_sendmsg+0xf0/0x520
[ 708.335259] sock_sendmsg+0xac/0xf8
[ 708.377096] sock_write_iter+0x1c0/0x2c0
[ 708.424154] new_sync_write+0x358/0x4a8
[ 708.470162] __vfs_write+0xc4/0xf8
[ 708.510950] vfs_write+0x12c/0x3d0
[ 708.551739] ksys_write+0xcc/0x178
[ 708.592533] __arm64_sys_write+0x70/0xa0
[ 708.639593] el0_svc_handler+0x13c/0x298
[ 708.686646] el0_svc+0x8/0xc
[ 708.739019] Freed by task 17:
[ 708.774597] __kasan_slab_free+0x114/0x228
[ 708.823736] kasan_slab_free+0x10/0x18
[ 708.868703] kfree+0x100/0x3d8
[ 708.905320] skb_free_head+0x7c/0x98
[ 708.948204] skb_release_data+0x320/0x490
[ 708.996301] pskb_expand_head+0x60c/0x970
[ 709.044399] __iptunnel_pull_header+0x3b8/0x5d0
[ 709.098770] ipip6_rcv+0x41c/0x16e0 [sit]
[ 709.146873] tunnel64_rcv+0xd4/0x200 [tunnel4]
[ 709.200195] ip_local_deliver_finish+0x3b8/0x988
[ 709.255596] ip_local_deliver+0x144/0x470
[ 709.303692] ip_rcv_finish+0x43c/0x14b0
[ 709.349705] ip_rcv+0x628/0x1138
[ 709.388413] __netif_receive_skb_core+0x1670/0x2600
[ 709.446943] __netif_receive_skb+0x28/0x190
[ 709.497120] process_backlog+0x1d0/0x610
[ 709.544169] net_rx_action+0x37c/0xf68
[ 709.589131] __do_softirq+0x288/0x1018
[ 709.651938] The buggy address belongs to the object at ffffe01b6bd85580
which belongs to the cache kmalloc-1024 of size 1024
[ 709.804356] The buggy address is located 117 bytes inside of
1024-byte region [ffffe01b6bd85580, ffffe01b6bd85980)
[ 709.946340] The buggy address belongs to the page:
[ 710.003824] page:ffff7ff806daf600 count:1 mapcount:0 mapping:ffffe01c4001f600 index:0x0
[ 710.099914] flags: 0xfffff8000000100(slab)
[ 710.149059] raw: 0fffff8000000100 dead000000000100 dead000000000200 ffffe01c4001f600
[ 710.242011] raw: 0000000000000000 0000000000380038 00000001ffffffff 0000000000000000
[ 710.334966] page dumped because: kasan: bad access detected
Fix it resetting iph pointer after iptunnel_pull_header
Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap")
Tested-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/sit.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -693,6 +693,10 @@ static int ipip6_rcv(struct sk_buff *skb
if (iptunnel_pull_header(skb, 0, htons(ETH_P_IPV6)))
goto out;
+ /* skb can be uncloned in iptunnel_pull_header, so
+ * old iph is no longer valid
+ */
+ iph = (const struct iphdr *)skb_mac_header(skb);
err = IP_ECN_decapsulate(iph, skb);
if (unlikely(err)) {
if (log_ecn_error)
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 079/168] net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock().
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (77 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 078/168] ipv6: sit: reset ip header pointer in ipip6_rcv Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 080/168] openvswitch: fix flow actions reallocation Greg Kroah-Hartman
` (93 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Santosh Shilimkar, Hulk Robot,
Mao Wenan, David S. Miller
From: Mao Wenan <maowenan@huawei.com>
[ Upstream commit cb66ddd156203daefb8d71158036b27b0e2caf63 ]
When it is to cleanup net namespace, rds_tcp_exit_net() will call
rds_tcp_kill_sock(), if t_sock is NULL, it will not call
rds_conn_destroy(), rds_conn_path_destroy() and rds_tcp_conn_free() to free
connection, and the worker cp_conn_w is not stopped, afterwards the net is freed in
net_drop_ns(); While cp_conn_w rds_connect_worker() will call rds_tcp_conn_path_connect()
and reference 'net' which has already been freed.
In rds_tcp_conn_path_connect(), rds_tcp_set_callbacks() will set t_sock = sock before
sock->ops->connect, but if connect() is failed, it will call
rds_tcp_restore_callbacks() and set t_sock = NULL, if connect is always
failed, rds_connect_worker() will try to reconnect all the time, so
rds_tcp_kill_sock() will never to cancel worker cp_conn_w and free the
connections.
Therefore, the condition !tc->t_sock is not needed if it is going to do
cleanup_net->rds_tcp_exit_net->rds_tcp_kill_sock, because tc->t_sock is always
NULL, and there is on other path to cancel cp_conn_w and free
connection. So this patch is to fix this.
rds_tcp_kill_sock():
...
if (net != c_net || !tc->t_sock)
...
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
==================================================================
BUG: KASAN: use-after-free in inet_create+0xbcc/0xd28
net/ipv4/af_inet.c:340
Read of size 4 at addr ffff8003496a4684 by task kworker/u8:4/3721
CPU: 3 PID: 3721 Comm: kworker/u8:4 Not tainted 5.1.0 #11
Hardware name: linux,dummy-virt (DT)
Workqueue: krdsd rds_connect_worker
Call trace:
dump_backtrace+0x0/0x3c0 arch/arm64/kernel/time.c:53
show_stack+0x28/0x38 arch/arm64/kernel/traps.c:152
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x120/0x188 lib/dump_stack.c:113
print_address_description+0x68/0x278 mm/kasan/report.c:253
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x21c/0x348 mm/kasan/report.c:409
__asan_report_load4_noabort+0x30/0x40 mm/kasan/report.c:429
inet_create+0xbcc/0xd28 net/ipv4/af_inet.c:340
__sock_create+0x4f8/0x770 net/socket.c:1276
sock_create_kern+0x50/0x68 net/socket.c:1322
rds_tcp_conn_path_connect+0x2b4/0x690 net/rds/tcp_connect.c:114
rds_connect_worker+0x108/0x1d0 net/rds/threads.c:175
process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153
worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296
kthread+0x2f0/0x378 kernel/kthread.c:255
ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117
Allocated by task 687:
save_stack mm/kasan/kasan.c:448 [inline]
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:553
kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:490
slab_post_alloc_hook mm/slab.h:444 [inline]
slab_alloc_node mm/slub.c:2705 [inline]
slab_alloc mm/slub.c:2713 [inline]
kmem_cache_alloc+0x14c/0x388 mm/slub.c:2718
kmem_cache_zalloc include/linux/slab.h:697 [inline]
net_alloc net/core/net_namespace.c:384 [inline]
copy_net_ns+0xc4/0x2d0 net/core/net_namespace.c:424
create_new_namespaces+0x300/0x658 kernel/nsproxy.c:107
unshare_nsproxy_namespaces+0xa0/0x198 kernel/nsproxy.c:206
ksys_unshare+0x340/0x628 kernel/fork.c:2577
__do_sys_unshare kernel/fork.c:2645 [inline]
__se_sys_unshare kernel/fork.c:2643 [inline]
__arm64_sys_unshare+0x38/0x58 kernel/fork.c:2643
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:47 [inline]
el0_svc_common+0x168/0x390 arch/arm64/kernel/syscall.c:83
el0_svc_handler+0x60/0xd0 arch/arm64/kernel/syscall.c:129
el0_svc+0x8/0xc arch/arm64/kernel/entry.S:960
Freed by task 264:
save_stack mm/kasan/kasan.c:448 [inline]
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x114/0x220 mm/kasan/kasan.c:521
kasan_slab_free+0x10/0x18 mm/kasan/kasan.c:528
slab_free_hook mm/slub.c:1370 [inline]
slab_free_freelist_hook mm/slub.c:1397 [inline]
slab_free mm/slub.c:2952 [inline]
kmem_cache_free+0xb8/0x3a8 mm/slub.c:2968
net_free net/core/net_namespace.c:400 [inline]
net_drop_ns.part.6+0x78/0x90 net/core/net_namespace.c:407
net_drop_ns net/core/net_namespace.c:406 [inline]
cleanup_net+0x53c/0x6d8 net/core/net_namespace.c:569
process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153
worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296
kthread+0x2f0/0x378 kernel/kthread.c:255
ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117
The buggy address belongs to the object at ffff8003496a3f80
which belongs to the cache net_namespace of size 7872
The buggy address is located 1796 bytes inside of
7872-byte region [ffff8003496a3f80, ffff8003496a5e40)
The buggy address belongs to the page:
page:ffff7e000d25a800 count:1 mapcount:0 mapping:ffff80036ce4b000
index:0x0 compound_mapcount: 0
flags: 0xffffe0000008100(slab|head)
raw: 0ffffe0000008100 dead000000000100 dead000000000200 ffff80036ce4b000
raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8003496a4580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8003496a4600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8003496a4680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8003496a4700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8003496a4780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Fixes: 467fa15356ac("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -346,7 +346,7 @@ static void rds_tcp_kill_sock(struct net
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
struct net *c_net = read_pnet(&tc->conn->c_net);
- if (net != c_net || !tc->t_sock)
+ if (net != c_net)
continue;
list_move_tail(&tc->t_tcp_node, &tmp_list);
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 080/168] openvswitch: fix flow actions reallocation
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (78 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 079/168] net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 081/168] qmi_wwan: add Olicard 600 Greg Kroah-Hartman
` (92 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrea Righi, Pravin B Shelar,
David S. Miller
From: Andrea Righi <andrea.righi@canonical.com>
[ Upstream commit f28cd2af22a0c134e4aa1c64a70f70d815d473fb ]
The flow action buffer can be resized if it's not big enough to contain
all the requested flow actions. However, this resize doesn't take into
account the new requested size, the buffer is only increased by a factor
of 2x. This might be not enough to contain the new data, causing a
buffer overflow, for example:
[ 42.044472] =============================================================================
[ 42.045608] BUG kmalloc-96 (Not tainted): Redzone overwritten
[ 42.046415] -----------------------------------------------------------------------------
[ 42.047715] Disabling lock debugging due to kernel taint
[ 42.047716] INFO: 0x8bf2c4a5-0x720c0928. First byte 0x0 instead of 0xcc
[ 42.048677] INFO: Slab 0xbc6d2040 objects=29 used=18 fp=0xdc07dec4 flags=0x2808101
[ 42.049743] INFO: Object 0xd53a3464 @offset=2528 fp=0xccdcdebb
[ 42.050747] Redzone 76f1b237: cc cc cc cc cc cc cc cc ........
[ 42.051839] Object d53a3464: 6b 6b 6b 6b 6b 6b 6b 6b 0c 00 00 00 6c 00 00 00 kkkkkkkk....l...
[ 42.053015] Object f49a30cc: 6c 00 0c 00 00 00 00 00 00 00 00 03 78 a3 15 f6 l...........x...
[ 42.054203] Object acfe4220: 20 00 02 00 ff ff ff ff 00 00 00 00 00 00 00 00 ...............
[ 42.055370] Object 21024e91: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 42.056541] Object 070e04c3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 42.057797] Object 948a777a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 42.059061] Redzone 8bf2c4a5: 00 00 00 00 ....
[ 42.060189] Padding a681b46e: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Fix by making sure the new buffer is properly resized to contain all the
requested data.
BugLink: https://bugs.launchpad.net/bugs/1813244
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/openvswitch/flow_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1736,14 +1736,14 @@ static struct nlattr *reserve_sfa_size(s
struct sw_flow_actions *acts;
int new_acts_size;
- int req_size = NLA_ALIGN(attr_len);
+ size_t req_size = NLA_ALIGN(attr_len);
int next_offset = offsetof(struct sw_flow_actions, actions) +
(*sfa)->actions_len;
if (req_size <= (ksize(*sfa) - next_offset))
goto out;
- new_acts_size = ksize(*sfa) * 2;
+ new_acts_size = max(next_offset + req_size, ksize(*sfa) * 2);
if (new_acts_size > MAX_ACTIONS_BUFSIZE) {
if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) {
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 081/168] qmi_wwan: add Olicard 600
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (79 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 080/168] openvswitch: fix flow actions reallocation Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 082/168] sctp: initialize _pad of sockaddr_in before copying to user memory Greg Kroah-Hartman
` (91 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bjørn Mork, David S. Miller
From: Bjørn Mork <bjorn@mork.no>
[ Upstream commit 6289d0facd9ebce4cc83e5da39e15643ee998dc5 ]
This is a Qualcomm based device with a QMI function on interface 4.
It is mode switched from 2020:2030 using a standard eject message.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=2020 ProdID=2031 Rev= 2.32
S: Manufacturer=Mobile Connect
S: Product=Mobile Connect
S: SerialNumber=0123456789ABCDEF
C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -717,6 +717,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */
{QMI_FIXED_INTF(0x2001, 0x7e19, 4)}, /* D-Link DWM-221 B1 */
{QMI_FIXED_INTF(0x2001, 0x7e35, 4)}, /* D-Link DWM-222 */
+ {QMI_FIXED_INTF(0x2020, 0x2031, 4)}, /* Olicard 600 */
{QMI_FIXED_INTF(0x2020, 0x2033, 4)}, /* BroadMobi BM806U */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 082/168] sctp: initialize _pad of sockaddr_in before copying to user memory
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (80 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 081/168] qmi_wwan: add Olicard 600 Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 083/168] tcp: Ensure DCTCP reacts to losses Greg Kroah-Hartman
` (90 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+86b5c7c236a22616a72f,
Xin Long, Alexander Potapenko, Neil Horman, David S. Miller
From: Xin Long <lucien.xin@gmail.com>
[ Upstream commit 09279e615c81ce55e04835970601ae286e3facbe ]
Syzbot report a kernel-infoleak:
BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
Call Trace:
_copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
copy_to_user include/linux/uaccess.h:174 [inline]
sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
...
Uninit was stored to memory at:
sctp_transport_init net/sctp/transport.c:61 [inline]
sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
...
Bytes 8-15 of 16 are uninitialized
It was caused by that th _pad field (the 8-15 bytes) of a v4 addr (saved in
struct sockaddr_in) wasn't initialized, but directly copied to user memory
in sctp_getsockopt_peer_addrs().
So fix it by calling memset(addr->v4.sin_zero, 0, 8) to initialize _pad of
sockaddr_in before copying it to user memory in sctp_v4_addr_to_user(), as
sctp_v6_addr_to_user() does.
Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Tested-by: Alexander Potapenko <glider@google.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/protocol.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -598,6 +598,7 @@ out:
static int sctp_v4_addr_to_user(struct sctp_sock *sp, union sctp_addr *addr)
{
/* No address mapping for V4 sockets */
+ memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero));
return sizeof(struct sockaddr_in);
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 083/168] tcp: Ensure DCTCP reacts to losses
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (81 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 082/168] sctp: initialize _pad of sockaddr_in before copying to user memory Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 084/168] netns: provide pure entropy for net_hash_mix() Greg Kroah-Hartman
` (89 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Koen De Schepper, Olivier Tilmans,
Bob Briscoe, Lawrence Brakmo, Florian Westphal, Daniel Borkmann,
Yuchung Cheng, Neal Cardwell, Eric Dumazet, Andrew Shewmaker,
Glenn Judd, Daniel Borkmann, David S. Miller
From: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
[ Upstream commit aecfde23108b8e637d9f5c5e523b24fb97035dc3 ]
RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to
loss episodes in the same way as conventional TCP".
Currently, Linux DCTCP performs no cwnd reduction when losses
are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
alpha to its maximal value if a RTO happens. This behavior
is sub-optimal for at least two reasons: i) it ignores losses
triggering fast retransmissions; and ii) it causes unnecessary large
cwnd reduction in the future if the loss was isolated as it resets
the historical term of DCTCP's alpha EWMA to its maximal value (i.e.,
denoting a total congestion). The second reason has an especially
noticeable effect when using DCTCP in high BDP environments, where
alpha normally stays at low values.
This patch replace the clamping of alpha by setting ssthresh to
half of cwnd for both fast retransmissions and RTOs, at most once
per RTT. Consequently, the dctcp_clamp_alpha_on_loss module parameter
has been removed.
The table below shows experimental results where we measured the
drop probability of a PIE AQM (not applying ECN marks) at a
bottleneck in the presence of a single TCP flow with either the
alpha-clamping option enabled or the cwnd halving proposed by this
patch. Results using reno or cubic are given for comparison.
| Link | RTT | Drop
TCP CC | speed | base+AQM | probability
==================|=========|==========|============
CUBIC | 40Mbps | 7+20ms | 0.21%
RENO | | | 0.19%
DCTCP-CLAMP-ALPHA | | | 25.80%
DCTCP-HALVE-CWND | | | 0.22%
------------------|---------|----------|------------
CUBIC | 100Mbps | 7+20ms | 0.03%
RENO | | | 0.02%
DCTCP-CLAMP-ALPHA | | | 23.30%
DCTCP-HALVE-CWND | | | 0.04%
------------------|---------|----------|------------
CUBIC | 800Mbps | 1+1ms | 0.04%
RENO | | | 0.05%
DCTCP-CLAMP-ALPHA | | | 18.70%
DCTCP-HALVE-CWND | | | 0.06%
We see that, without halving its cwnd for all source of losses,
DCTCP drives the AQM to large drop probabilities in order to keep
the queue length under control (i.e., it repeatedly faces RTOs).
Instead, if DCTCP reacts to all source of losses, it can then be
controlled by the AQM using similar drop levels than cubic or reno.
Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
Cc: Bob Briscoe <research@bobbriscoe.net>
Cc: Lawrence Brakmo <brakmo@fb.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Daniel Borkmann <borkmann@iogearbox.net>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Glenn Judd <glenn.judd@morganstanley.com>
Acked-by: Florian Westphal <fw@strlen.de>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/tcp_dctcp.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
--- a/net/ipv4/tcp_dctcp.c
+++ b/net/ipv4/tcp_dctcp.c
@@ -66,11 +66,6 @@ static unsigned int dctcp_alpha_on_init
module_param(dctcp_alpha_on_init, uint, 0644);
MODULE_PARM_DESC(dctcp_alpha_on_init, "parameter for initial alpha value");
-static unsigned int dctcp_clamp_alpha_on_loss __read_mostly;
-module_param(dctcp_clamp_alpha_on_loss, uint, 0644);
-MODULE_PARM_DESC(dctcp_clamp_alpha_on_loss,
- "parameter for clamping alpha on loss");
-
static struct tcp_congestion_ops dctcp_reno;
static void dctcp_reset(const struct tcp_sock *tp, struct dctcp *ca)
@@ -211,21 +206,23 @@ static void dctcp_update_alpha(struct so
}
}
-static void dctcp_state(struct sock *sk, u8 new_state)
+static void dctcp_react_to_loss(struct sock *sk)
{
- if (dctcp_clamp_alpha_on_loss && new_state == TCP_CA_Loss) {
- struct dctcp *ca = inet_csk_ca(sk);
+ struct dctcp *ca = inet_csk_ca(sk);
+ struct tcp_sock *tp = tcp_sk(sk);
- /* If this extension is enabled, we clamp dctcp_alpha to
- * max on packet loss; the motivation is that dctcp_alpha
- * is an indicator to the extend of congestion and packet
- * loss is an indicator of extreme congestion; setting
- * this in practice turned out to be beneficial, and
- * effectively assumes total congestion which reduces the
- * window by half.
- */
- ca->dctcp_alpha = DCTCP_MAX_ALPHA;
- }
+ ca->loss_cwnd = tp->snd_cwnd;
+ tp->snd_ssthresh = max(tp->snd_cwnd >> 1U, 2U);
+}
+
+static void dctcp_state(struct sock *sk, u8 new_state)
+{
+ if (new_state == TCP_CA_Recovery &&
+ new_state != inet_csk(sk)->icsk_ca_state)
+ dctcp_react_to_loss(sk);
+ /* We handle RTO in dctcp_cwnd_event to ensure that we perform only
+ * one loss-adjustment per RTT.
+ */
}
static void dctcp_cwnd_event(struct sock *sk, enum tcp_ca_event ev)
@@ -237,6 +234,9 @@ static void dctcp_cwnd_event(struct sock
case CA_EVENT_ECN_NO_CE:
dctcp_ce_state_1_to_0(sk);
break;
+ case CA_EVENT_LOSS:
+ dctcp_react_to_loss(sk);
+ break;
default:
/* Don't care for the rest. */
break;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 084/168] netns: provide pure entropy for net_hash_mix()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (82 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 083/168] tcp: Ensure DCTCP reacts to losses Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 085/168] net: ethtool: not call vzalloc for zero sized memory request Greg Kroah-Hartman
` (88 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, Amit Klein,
Benny Pinkas, Pavel Emelyanov, David S. Miller
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 355b98553789b646ed97ad801a619ff898471b92 ]
net_hash_mix() currently uses kernel address of a struct net,
and is used in many places that could be used to reveal this
address to a patient attacker, thus defeating KASLR, for
the typical case (initial net namespace, &init_net is
not dynamically allocated)
I believe the original implementation tried to avoid spending
too many cycles in this function, but security comes first.
Also provide entropy regardless of CONFIG_NET_NS.
Fixes: 0b4419162aa6 ("netns: introduce the net_hash_mix "salt" for hashes")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Benny Pinkas <benny@pinkas.net>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/net_namespace.h | 1 +
include/net/netns/hash.h | 15 ++-------------
net/core/net_namespace.c | 1 +
3 files changed, 4 insertions(+), 13 deletions(-)
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -53,6 +53,7 @@ struct net {
*/
spinlock_t rules_mod_lock;
+ u32 hash_mix;
atomic64_t cookie_gen;
struct list_head list; /* list of network namespaces */
--- a/include/net/netns/hash.h
+++ b/include/net/netns/hash.h
@@ -1,21 +1,10 @@
#ifndef __NET_NS_HASH_H__
#define __NET_NS_HASH_H__
-#include <asm/cache.h>
-
-struct net;
+#include <net/net_namespace.h>
static inline u32 net_hash_mix(const struct net *net)
{
-#ifdef CONFIG_NET_NS
- /*
- * shift this right to eliminate bits, that are
- * always zeroed
- */
-
- return (u32)(((unsigned long)net) >> L1_CACHE_SHIFT);
-#else
- return 0;
-#endif
+ return net->hash_mix;
}
#endif
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -280,6 +280,7 @@ static __net_init int setup_net(struct n
atomic_set(&net->count, 1);
atomic_set(&net->passive, 1);
+ get_random_bytes(&net->hash_mix, sizeof(u32));
net->dev_base_seq = 1;
net->user_ns = user_ns;
idr_init(&net->netns_ids);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 085/168] net: ethtool: not call vzalloc for zero sized memory request
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (83 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 084/168] netns: provide pure entropy for net_hash_mix() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 086/168] ip6_tunnel: Match to ARPHRD_TUNNEL6 for dev type Greg Kroah-Hartman
` (87 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Li RongQing, Wang Li, Michal Kubecek,
David S. Miller
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 3d8830266ffc28c16032b859e38a0252e014b631 ]
NULL or ZERO_SIZE_PTR will be returned for zero sized memory
request, and derefencing them will lead to a segfault
so it is unnecessory to call vzalloc for zero sized memory
request and not call functions which maybe derefence the
NULL allocated memory
this also fixes a possible memory leak if phy_ethtool_get_stats
returns error, memory should be freed before exit
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Wang Li <wangli39@baidu.com>
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/ethtool.c | 29 +++++++++++++++++++----------
1 file changed, 19 insertions(+), 10 deletions(-)
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1287,17 +1287,22 @@ static int ethtool_get_strings(struct ne
gstrings.len = ret;
- data = kcalloc(gstrings.len, ETH_GSTRING_LEN, GFP_USER);
- if (!data)
- return -ENOMEM;
+ if (gstrings.len) {
+ data = kcalloc(gstrings.len, ETH_GSTRING_LEN, GFP_USER);
+ if (!data)
+ return -ENOMEM;
- __ethtool_get_strings(dev, gstrings.string_set, data);
+ __ethtool_get_strings(dev, gstrings.string_set, data);
+ } else {
+ data = NULL;
+ }
ret = -EFAULT;
if (copy_to_user(useraddr, &gstrings, sizeof(gstrings)))
goto out;
useraddr += sizeof(gstrings);
- if (copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
+ if (gstrings.len &&
+ copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
goto out;
ret = 0;
@@ -1385,17 +1390,21 @@ static int ethtool_get_stats(struct net_
return -EFAULT;
stats.n_stats = n_stats;
- data = kmalloc(n_stats * sizeof(u64), GFP_USER);
- if (!data)
- return -ENOMEM;
+ if (n_stats) {
+ data = kmalloc(n_stats * sizeof(u64), GFP_USER);
+ if (!data)
+ return -ENOMEM;
- ops->get_ethtool_stats(dev, &stats, data);
+ ops->get_ethtool_stats(dev, &stats, data);
+ } else {
+ data = NULL;
+ }
ret = -EFAULT;
if (copy_to_user(useraddr, &stats, sizeof(stats)))
goto out;
useraddr += sizeof(stats);
- if (copy_to_user(useraddr, data, stats.n_stats * sizeof(u64)))
+ if (n_stats && copy_to_user(useraddr, data, n_stats * sizeof(u64)))
goto out;
ret = 0;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 086/168] ip6_tunnel: Match to ARPHRD_TUNNEL6 for dev type
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (84 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 085/168] net: ethtool: not call vzalloc for zero sized memory request Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 087/168] ALSA: seq: Fix OOB-reads from strlcpy Greg Kroah-Hartman
` (86 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sheena Mira-ato, David S. Miller
From: Sheena Mira-ato <sheena.mira-ato@alliedtelesis.co.nz>
[ Upstream commit b2e54b09a3d29c4db883b920274ca8dca4d9f04d ]
The device type for ip6 tunnels is set to
ARPHRD_TUNNEL6. However, the ip4ip6_err function
is expecting the device type of the tunnel to be
ARPHRD_TUNNEL. Since the device types do not
match, the function exits and the ICMP error
packet is not sent to the originating host. Note
that the device type for IPv4 tunnels is set to
ARPHRD_TUNNEL.
Fix is to expect a tunnel device type of
ARPHRD_TUNNEL6 instead. Now the tunnel device
type matches and the ICMP error packet is sent
to the originating host.
Signed-off-by: Sheena Mira-ato <sheena.mira-ato@alliedtelesis.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -622,7 +622,7 @@ ip4ip6_err(struct sk_buff *skb, struct i
IPPROTO_IPIP,
RT_TOS(eiph->tos), 0);
if (IS_ERR(rt) ||
- rt->dst.dev->type != ARPHRD_TUNNEL) {
+ rt->dst.dev->type != ARPHRD_TUNNEL6) {
if (!IS_ERR(rt))
ip_rt_put(rt);
goto out;
@@ -632,7 +632,7 @@ ip4ip6_err(struct sk_buff *skb, struct i
ip_rt_put(rt);
if (ip_route_input(skb2, eiph->daddr, eiph->saddr, eiph->tos,
skb2->dev) ||
- skb_dst(skb2)->dev->type != ARPHRD_TUNNEL)
+ skb_dst(skb2)->dev->type != ARPHRD_TUNNEL6)
goto out;
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 087/168] ALSA: seq: Fix OOB-reads from strlcpy
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (85 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 086/168] ip6_tunnel: Match to ARPHRD_TUNNEL6 for dev type Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 088/168] include/linux/bitrev.h: fix constant bitrev Greg Kroah-Hartman
` (85 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zubin Mithra, Guenter Roeck, Takashi Iwai
From: Zubin Mithra <zsm@chromium.org>
commit 212ac181c158c09038c474ba68068be49caecebb upstream.
When ioctl calls are made with non-null-terminated userspace strings,
strlcpy causes an OOB-read from within strlen. Fix by changing to use
strscpy instead.
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/seq_clientmgr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1249,7 +1249,7 @@ static int snd_seq_ioctl_set_client_info
/* fill the info fields */
if (client_info.name[0])
- strlcpy(client->name, client_info.name, sizeof(client->name));
+ strscpy(client->name, client_info.name, sizeof(client->name));
client->filter = client_info.filter;
client->event_lost = client_info.event_lost;
@@ -1558,7 +1558,7 @@ static int snd_seq_ioctl_create_queue(st
/* set queue name */
if (! info.name[0])
snprintf(info.name, sizeof(info.name), "Queue-%d", q->queue);
- strlcpy(q->name, info.name, sizeof(q->name));
+ strscpy(q->name, info.name, sizeof(q->name));
snd_use_lock_free(&q->use_lock);
if (copy_to_user(arg, &info, sizeof(info)))
@@ -1636,7 +1636,7 @@ static int snd_seq_ioctl_set_queue_info(
queuefree(q);
return -EPERM;
}
- strlcpy(q->name, info.name, sizeof(q->name));
+ strscpy(q->name, info.name, sizeof(q->name));
queuefree(q);
return 0;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 088/168] include/linux/bitrev.h: fix constant bitrev
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (86 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 087/168] ALSA: seq: Fix OOB-reads from strlcpy Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 089/168] ASoC: fsl_esai: fix channel swap issue when stream starts Greg Kroah-Hartman
` (84 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Nick Desaulniers,
Zhao Qiang, Yalin Wang, Andrew Morton, Linus Torvalds
From: Arnd Bergmann <arnd@arndb.de>
commit 6147e136ff5071609b54f18982dea87706288e21 upstream.
clang points out with hundreds of warnings that the bitrev macros have a
problem with constant input:
drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization
[-Werror,-Wuninitialized]
u8 crc = bitrev8(data->val_status & 0x0F);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8'
__constant_bitrev8(__x) : \
~~~~~~~~~~~~~~~~~~~^~~~
include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8'
u8 __x = x; \
~~~ ^
Both the bitrev and the __constant_bitrev macros use an internal
variable named __x, which goes horribly wrong when passing one to the
other.
The obvious fix is to rename one of the variables, so this adds an extra
'_'.
It seems we got away with this because
- there are only a few drivers using bitrev macros
- usually there are no constant arguments to those
- when they are constant, they tend to be either 0 or (unsigned)-1
(drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and
give the correct result by pure chance.
In fact, the only driver that I could find that gets different results
with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver
for fairly rare hardware (adding the maintainer to Cc for testing).
Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de
Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Zhao Qiang <qiang.zhao@nxp.com>
Cc: Yalin Wang <yalin.wang@sonymobile.com>
Cc: <stable@vger.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>
---
include/linux/bitrev.h | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
--- a/include/linux/bitrev.h
+++ b/include/linux/bitrev.h
@@ -31,32 +31,32 @@ static inline u32 __bitrev32(u32 x)
#define __constant_bitrev32(x) \
({ \
- u32 __x = x; \
- __x = (__x >> 16) | (__x << 16); \
- __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \
- __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
- __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
- __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
- __x; \
+ u32 ___x = x; \
+ ___x = (___x >> 16) | (___x << 16); \
+ ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \
+ ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \
+ ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \
+ ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \
+ ___x; \
})
#define __constant_bitrev16(x) \
({ \
- u16 __x = x; \
- __x = (__x >> 8) | (__x << 8); \
- __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \
- __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \
- __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \
- __x; \
+ u16 ___x = x; \
+ ___x = (___x >> 8) | (___x << 8); \
+ ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \
+ ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \
+ ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \
+ ___x; \
})
#define __constant_bitrev8(x) \
({ \
- u8 __x = x; \
- __x = (__x >> 4) | (__x << 4); \
- __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \
- __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \
- __x; \
+ u8 ___x = x; \
+ ___x = (___x >> 4) | (___x << 4); \
+ ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \
+ ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \
+ ___x; \
})
#define bitrev32(x) \
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 089/168] ASoC: fsl_esai: fix channel swap issue when stream starts
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (87 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 088/168] include/linux/bitrev.h: fix constant bitrev Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 090/168] block: do not leak memory in bio_copy_user_iov() Greg Kroah-Hartman
` (83 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Fabio Estevam, Nicolin Chen,
Shengjiu Wang, Mark Brown
From: S.j. Wang <shengjiu.wang@nxp.com>
commit 0ff4e8c61b794a4bf6c854ab071a1abaaa80f358 upstream.
There is very low possibility ( < 0.1% ) that channel swap happened
in beginning when multi output/input pin is enabled. The issue is
that hardware can't send data to correct pin in the beginning with
the normal enable flow.
This is hardware issue, but there is no errata, the workaround flow
is that: Each time playback/recording, firstly clear the xSMA/xSMB,
then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
before xSMA). Which is to use the xSMA as the trigger start register,
previously the xCR_TE or xCR_RE is the bit for starting.
Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/fsl/fsl_esai.c | 47 +++++++++++++++++++++++++++++++++++++----------
1 file changed, 37 insertions(+), 10 deletions(-)
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -57,6 +57,8 @@ struct fsl_esai {
u32 fifo_depth;
u32 slot_width;
u32 slots;
+ u32 tx_mask;
+ u32 rx_mask;
u32 hck_rate[2];
u32 sck_rate[2];
bool hck_dir[2];
@@ -357,21 +359,13 @@ static int fsl_esai_set_dai_tdm_slot(str
regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR,
ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMA,
- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(tx_mask));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMB,
- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(tx_mask));
-
regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR,
ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMA,
- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(rx_mask));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMB,
- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
-
esai_priv->slot_width = slot_width;
esai_priv->slots = slots;
+ esai_priv->tx_mask = tx_mask;
+ esai_priv->rx_mask = rx_mask;
return 0;
}
@@ -582,6 +576,7 @@ static int fsl_esai_trigger(struct snd_p
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
u8 i, channels = substream->runtime->channels;
u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
+ u32 mask;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -594,15 +589,38 @@ static int fsl_esai_trigger(struct snd_p
for (i = 0; tx && i < channels; i++)
regmap_write(esai_priv->regmap, REG_ESAI_ETDR, 0x0);
+ /*
+ * When set the TE/RE in the end of enablement flow, there
+ * will be channel swap issue for multi data line case.
+ * In order to workaround this issue, we switch the bit
+ * enablement sequence to below sequence
+ * 1) clear the xSMB & xSMA: which is done in probe and
+ * stop state.
+ * 2) set TE/RE
+ * 3) set xSMB
+ * 4) set xSMA: xSMA is the last one in this flow, which
+ * will trigger esai to start.
+ */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
+ mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+ ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
+
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ ESAI_xSMA_xS_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+ ESAI_xSMB_xS_MASK, 0);
/* Disable and reset FIFO */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
@@ -887,6 +905,15 @@ static int fsl_esai_probe(struct platfor
return ret;
}
+ esai_priv->tx_mask = 0xFFFFFFFF;
+ esai_priv->rx_mask = 0xFFFFFFFF;
+
+ /* Clear the TSMA, TSMB, RSMA, RSMB */
+ regmap_write(esai_priv->regmap, REG_ESAI_TSMA, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_TSMB, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_RSMA, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_RSMB, 0);
+
ret = devm_snd_soc_register_component(&pdev->dev, &fsl_esai_component,
&fsl_esai_dai, 1);
if (ret) {
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 090/168] block: do not leak memory in bio_copy_user_iov()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (88 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 089/168] ASoC: fsl_esai: fix channel swap issue when stream starts Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 091/168] genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() Greg Kroah-Hartman
` (82 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, linux-block, Linus Torvalds,
Chaitanya Kulkarni, Jérôme Glisse, Jens Axboe
From: Jérôme Glisse <jglisse@redhat.com>
commit a3761c3c91209b58b6f33bf69dd8bb8ec0c9d925 upstream.
When bio_add_pc_page() fails in bio_copy_user_iov() we should free
the page we just allocated otherwise we are leaking it.
Cc: linux-block@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/bio.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/block/bio.c
+++ b/block/bio.c
@@ -1216,8 +1216,11 @@ struct bio *bio_copy_user_iov(struct req
}
}
- if (bio_add_pc_page(q, bio, page, bytes, offset) < bytes)
+ if (bio_add_pc_page(q, bio, page, bytes, offset) < bytes) {
+ if (!map_data)
+ __free_page(page);
break;
+ }
len -= bytes;
offset = 0;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 091/168] genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (89 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 090/168] block: do not leak memory in bio_copy_user_iov() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 092/168] ARM: dts: at91: Fix typo in ISC_D0 on PC9 Greg Kroah-Hartman
` (81 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephen Boyd, Thomas Gleixner,
Marc Zyngier, linux-arm-kernel, linux-gpio, Lina Iyer
From: Stephen Boyd <swboyd@chromium.org>
commit 325aa19598e410672175ed50982f902d4e3f31c5 upstream.
If a child irqchip calls irq_chip_set_wake_parent() but its parent irqchip
has the IRQCHIP_SKIP_SET_WAKE flag set an error is returned.
This is inconsistent behaviour vs. set_irq_wake_real() which returns 0 when
the irqchip has the IRQCHIP_SKIP_SET_WAKE flag set. It doesn't attempt to
walk the chain of parents and set irq wake on any chips that don't have the
flag set either. If the intent is to call the .irq_set_wake() callback of
the parent irqchip, then we expect irqchip implementations to omit the
IRQCHIP_SKIP_SET_WAKE flag and implement an .irq_set_wake() function that
calls irq_chip_set_wake_parent().
The problem has been observed on a Qualcomm sdm845 device where set wake
fails on any GPIO interrupts after applying work in progress wakeup irq
patches to the GPIO driver. The chain of chips looks like this:
QCOM GPIO -> QCOM PDC (SKIP) -> ARM GIC (SKIP)
The GPIO controllers parent is the QCOM PDC irqchip which in turn has ARM
GIC as parent. The QCOM PDC irqchip has the IRQCHIP_SKIP_SET_WAKE flag
set, and so does the grandparent ARM GIC.
The GPIO driver doesn't know if the parent needs to set wake or not, so it
unconditionally calls irq_chip_set_wake_parent() causing this function to
return a failure because the parent irqchip (PDC) doesn't have the
.irq_set_wake() callback set. Returning 0 instead makes everything work and
irqs from the GPIO controller can be configured for wakeup.
Make it consistent by returning 0 (success) from irq_chip_set_wake_parent()
when a parent chip has IRQCHIP_SKIP_SET_WAKE set.
[ tglx: Massaged changelog ]
Fixes: 08b55e2a9208e ("genirq: Add irqchip_set_wake_parent")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-gpio@vger.kernel.org
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190325181026.247796-1-swboyd@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/irq/chip.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1056,6 +1056,10 @@ int irq_chip_set_vcpu_affinity_parent(st
int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
{
data = data->parent_data;
+
+ if (data->chip->flags & IRQCHIP_SKIP_SET_WAKE)
+ return 0;
+
if (data->chip->irq_set_wake)
return data->chip->irq_set_wake(data, on);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 092/168] ARM: dts: at91: Fix typo in ISC_D0 on PC9
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (90 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 091/168] genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 093/168] arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value Greg Kroah-Hartman
` (80 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Engraf, Nicolas Ferre,
Ludovic Desroches
From: David Engraf <david.engraf@sysgo.com>
commit e7dfb6d04e4715be1f3eb2c60d97b753fd2e4516 upstream.
The function argument for the ISC_D0 on PC9 was incorrect. According to
the documentation it should be 'C' aka 3.
Signed-off-by: David Engraf <david.engraf@sysgo.com>
Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/sama5d2-pinfunc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/sama5d2-pinfunc.h
+++ b/arch/arm/boot/dts/sama5d2-pinfunc.h
@@ -517,7 +517,7 @@
#define PIN_PC9__GPIO PINMUX_PIN(PIN_PC9, 0, 0)
#define PIN_PC9__FIQ PINMUX_PIN(PIN_PC9, 1, 3)
#define PIN_PC9__GTSUCOMP PINMUX_PIN(PIN_PC9, 2, 1)
-#define PIN_PC9__ISC_D0 PINMUX_PIN(PIN_PC9, 2, 1)
+#define PIN_PC9__ISC_D0 PINMUX_PIN(PIN_PC9, 3, 1)
#define PIN_PC9__TIOA4 PINMUX_PIN(PIN_PC9, 4, 2)
#define PIN_PC10 74
#define PIN_PC10__GPIO PINMUX_PIN(PIN_PC10, 0, 0)
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 093/168] arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (91 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 092/168] ARM: dts: at91: Fix typo in ISC_D0 on PC9 Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 094/168] xen: Prevent buffer overflow in privcmd ioctl Greg Kroah-Hartman
` (79 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, stable, Will Deacon
From: Will Deacon <will.deacon@arm.com>
commit 045afc24124d80c6998d9c770844c67912083506 upstream.
Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't
explicitly set the return value on the non-faulting path and instead
leaves it holding the result of the underlying atomic operation. This
means that any FUTEX_WAKE_OP atomic operation which computes a non-zero
value will be reported as having failed. Regrettably, I wrote the buggy
code back in 2011 and it was upstreamed as part of the initial arm64
support in 2012.
The reasons we appear to get away with this are:
1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get
exercised by futex() test applications
2. If the result of the atomic operation is zero, the system call
behaves correctly
3. Prior to version 2.25, the only operation used by GLIBC set the
futex to zero, and therefore worked as expected. From 2.25 onwards,
FUTEX_WAKE_OP is not used by GLIBC at all.
Fix the implementation by ensuring that the return value is either 0
to indicate that the atomic operation completed successfully, or -EFAULT
if we encountered a fault when accessing the user mapping.
Cc: <stable@kernel.org>
Fixes: 6170a97460db ("arm64: Atomic operations")
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/futex.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -33,8 +33,8 @@
" prfm pstl1strm, %2\n" \
"1: ldxr %w1, %2\n" \
insn "\n" \
-"2: stlxr %w3, %w0, %2\n" \
-" cbnz %w3, 1b\n" \
+"2: stlxr %w0, %w3, %2\n" \
+" cbnz %w0, 1b\n" \
" dmb ish\n" \
"3:\n" \
" .pushsection .fixup,\"ax\"\n" \
@@ -55,29 +55,29 @@
static inline int
arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
{
- int oldval = 0, ret, tmp;
+ int oldval, ret, tmp;
pagefault_disable();
switch (op) {
case FUTEX_OP_SET:
- __futex_atomic_op("mov %w0, %w4",
+ __futex_atomic_op("mov %w3, %w4",
ret, oldval, uaddr, tmp, oparg);
break;
case FUTEX_OP_ADD:
- __futex_atomic_op("add %w0, %w1, %w4",
+ __futex_atomic_op("add %w3, %w1, %w4",
ret, oldval, uaddr, tmp, oparg);
break;
case FUTEX_OP_OR:
- __futex_atomic_op("orr %w0, %w1, %w4",
+ __futex_atomic_op("orr %w3, %w1, %w4",
ret, oldval, uaddr, tmp, oparg);
break;
case FUTEX_OP_ANDN:
- __futex_atomic_op("and %w0, %w1, %w4",
+ __futex_atomic_op("and %w3, %w1, %w4",
ret, oldval, uaddr, tmp, ~oparg);
break;
case FUTEX_OP_XOR:
- __futex_atomic_op("eor %w0, %w1, %w4",
+ __futex_atomic_op("eor %w3, %w1, %w4",
ret, oldval, uaddr, tmp, oparg);
break;
default:
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 094/168] xen: Prevent buffer overflow in privcmd ioctl
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (92 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 093/168] arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:08 ` [PATCH 4.4 095/168] sched/fair: Do not re-read ->h_load_next during hierarchical load calculation Greg Kroah-Hartman
` (78 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Boris Ostrovsky,
Juergen Gross
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 42d8644bd77dd2d747e004e367cb0c895a606f39 upstream.
The "call" variable comes from the user in privcmd_ioctl_hypercall().
It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32)
elements. We need to put an upper bound on it to prevent an out of
bounds access.
Cc: stable@vger.kernel.org
Fixes: 1246ae0bb992 ("xen: add variable hypercall caller")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/xen/hypercall.h | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -215,6 +215,9 @@ privcmd_call(unsigned call,
__HYPERCALL_DECLS;
__HYPERCALL_5ARG(a1, a2, a3, a4, a5);
+ if (call >= PAGE_SIZE / sizeof(hypercall_page[0]))
+ return -EINVAL;
+
stac();
asm volatile(CALL_NOSPEC
: __HYPERCALL_5PARAM
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 095/168] sched/fair: Do not re-read ->h_load_next during hierarchical load calculation
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (93 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 094/168] xen: Prevent buffer overflow in privcmd ioctl Greg Kroah-Hartman
@ 2019-04-24 17:08 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 096/168] xtensa: fix return_address Greg Kroah-Hartman
` (77 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mel Gorman, Peter Zijlstra (Intel),
Valentin Schneider, Linus Torvalds, Mike Galbraith,
Thomas Gleixner, Ingo Molnar
From: Mel Gorman <mgorman@techsingularity.net>
commit 0e9f02450da07fc7b1346c8c32c771555173e397 upstream.
A NULL pointer dereference bug was reported on a distribution kernel but
the same issue should be present on mainline kernel. It occured on s390
but should not be arch-specific. A partial oops looks like:
Unable to handle kernel pointer dereference in virtual kernel address space
...
Call Trace:
...
try_to_wake_up+0xfc/0x450
vhost_poll_wakeup+0x3a/0x50 [vhost]
__wake_up_common+0xbc/0x178
__wake_up_common_lock+0x9e/0x160
__wake_up_sync_key+0x4e/0x60
sock_def_readable+0x5e/0x98
The bug hits any time between 1 hour to 3 days. The dereference occurs
in update_cfs_rq_h_load when accumulating h_load. The problem is that
cfq_rq->h_load_next is not protected by any locking and can be updated
by parallel calls to task_h_load. Depending on the compiler, code may be
generated that re-reads cfq_rq->h_load_next after the check for NULL and
then oops when reading se->avg.load_avg. The dissassembly showed that it
was possible to reread h_load_next after the check for NULL.
While this does not appear to be an issue for later compilers, it's still
an accident if the correct code is generated. Full locking in this path
would have high overhead so this patch uses READ_ONCE to read h_load_next
only once and check for NULL before dereferencing. It was confirmed that
there were no further oops after 10 days of testing.
As Peter pointed out, it is also necessary to use WRITE_ONCE() to avoid any
potential problems with store tearing.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Fixes: 685207963be9 ("sched: Move h_load calculation to task_h_load()")
Link: https://lkml.kernel.org/r/20190319123610.nsivgf3mjbjjesxb@techsingularity.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/fair.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6022,10 +6022,10 @@ static void update_cfs_rq_h_load(struct
if (cfs_rq->last_h_load_update == now)
return;
- cfs_rq->h_load_next = NULL;
+ WRITE_ONCE(cfs_rq->h_load_next, NULL);
for_each_sched_entity(se) {
cfs_rq = cfs_rq_of(se);
- cfs_rq->h_load_next = se;
+ WRITE_ONCE(cfs_rq->h_load_next, se);
if (cfs_rq->last_h_load_update == now)
break;
}
@@ -6035,7 +6035,7 @@ static void update_cfs_rq_h_load(struct
cfs_rq->last_h_load_update = now;
}
- while ((se = cfs_rq->h_load_next) != NULL) {
+ while ((se = READ_ONCE(cfs_rq->h_load_next)) != NULL) {
load = cfs_rq->h_load;
load = div64_ul(load * se->avg.load_avg,
cfs_rq_load_avg(cfs_rq) + 1);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 096/168] xtensa: fix return_address
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (94 preceding siblings ...)
2019-04-24 17:08 ` [PATCH 4.4 095/168] sched/fair: Do not re-read ->h_load_next during hierarchical load calculation Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 097/168] PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller Greg Kroah-Hartman
` (76 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Max Filippov
From: Max Filippov <jcmvbkbc@gmail.com>
commit ada770b1e74a77fff2d5f539bf6c42c25f4784db upstream.
return_address returns the address that is one level higher in the call
stack than requested in its argument, because level 0 corresponds to its
caller's return address. Use requested level as the number of stack
frames to skip.
This fixes the address reported by might_sleep and friends.
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/xtensa/kernel/stacktrace.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/arch/xtensa/kernel/stacktrace.c
+++ b/arch/xtensa/kernel/stacktrace.c
@@ -272,10 +272,14 @@ static int return_address_cb(struct stac
return 1;
}
+/*
+ * level == 0 is for the return address from the caller of this function,
+ * not from this function itself.
+ */
unsigned long return_address(unsigned level)
{
struct return_addr_data r = {
- .skip = level + 1,
+ .skip = level,
};
walk_stackframe(stack_pointer(NULL), return_address_cb, &r);
return r.addr;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 097/168] PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (95 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 096/168] xtensa: fix return_address Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 098/168] perf/core: Restore mmap record type correctly Greg Kroah-Hartman
` (75 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andre Przywara, Bjorn Helgaas
From: Andre Przywara <andre.przywara@arm.com>
commit 9cde402a59770a0669d895399c13407f63d7d209 upstream.
There is a Marvell 88SE9170 PCIe SATA controller I found on a board here.
Some quick testing with the ARM SMMU enabled reveals that it suffers from
the same requester ID mixup problems as the other Marvell chips listed
already.
Add the PCI vendor/device ID to the list of chips which need the
workaround.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3623,6 +3623,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130,
quirk_dma_func1_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9170,
+ quirk_dma_func1_alias);
/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c47 + c57 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9172,
quirk_dma_func1_alias);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 098/168] perf/core: Restore mmap record type correctly
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (96 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 097/168] PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 099/168] ext4: add missing brelse() in add_new_gdb_meta_bg() Greg Kroah-Hartman
` (74 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephane Eranian,
Peter Zijlstra (Intel),
Andi Kleen, Jiri Olsa, Kan Liang, Arnaldo Carvalho de Melo,
Sasha Levin
[ Upstream commit d9c1bb2f6a2157b38e8eb63af437cb22701d31ee ]
On mmap(), perf_events generates a RECORD_MMAP record and then checks
which events are interested in this record. There are currently 2
versions of mmap records: RECORD_MMAP and RECORD_MMAP2. MMAP2 is larger.
The event configuration controls which version the user level tool
accepts.
If the event->attr.mmap2=1 field then MMAP2 record is returned. The
perf_event_mmap_output() takes care of this. It checks attr->mmap2 and
corrects the record fields before putting it in the sampling buffer of
the event. At the end the function restores the modified MMAP record
fields.
The problem is that the function restores the size but not the type.
Thus, if a subsequent event only accepts MMAP type, then it would
instead receive an MMAP2 record with a size of MMAP record.
This patch fixes the problem by restoring the record type on exit.
Signed-off-by: Stephane Eranian <eranian@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Fixes: 13d7a2410fa6 ("perf: Add attr->mmap2 attribute to an event")
Link: http://lkml.kernel.org/r/20190307185233.225521-1-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/events/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index e53dfb5b826e..17230ca00bd4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5998,6 +5998,7 @@ static void perf_event_mmap_output(struct perf_event *event,
struct perf_output_handle handle;
struct perf_sample_data sample;
int size = mmap_event->event_id.header.size;
+ u32 type = mmap_event->event_id.header.type;
int ret;
if (!perf_event_mmap_match(event, data))
@@ -6041,6 +6042,7 @@ static void perf_event_mmap_output(struct perf_event *event,
perf_output_end(&handle);
out:
mmap_event->event_id.header.size = size;
+ mmap_event->event_id.header.type = type;
}
static void perf_event_mmap_event(struct perf_mmap_event *mmap_event)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 099/168] ext4: add missing brelse() in add_new_gdb_meta_bg()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (97 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 098/168] perf/core: Restore mmap record type correctly Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 100/168] ext4: report real fs size after failed resize Greg Kroah-Hartman
` (73 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lukas Czerner, Theodore Tso, Sasha Levin
[ Upstream commit d64264d6218e6892edd832dc3a5a5857c2856c53 ]
Currently in add_new_gdb_meta_bg() there is a missing brelse of gdb_bh
in case ext4_journal_get_write_access() fails.
Additionally kvfree() is missing in the same error path. Fix it by
moving the ext4_journal_get_write_access() before the ext4 sb update as
Ted suggested and release n_group_desc and gdb_bh in case it fails.
Fixes: 61a9c11e5e7a ("ext4: add missing brelse() add_new_gdb_meta_bg()'s error path")
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/ext4/resize.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 4bd12247a9be..22c90eb9a4e0 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -907,11 +907,18 @@ static int add_new_gdb_meta_bg(struct super_block *sb,
memcpy(n_group_desc, o_group_desc,
EXT4_SB(sb)->s_gdb_count * sizeof(struct buffer_head *));
n_group_desc[gdb_num] = gdb_bh;
+
+ BUFFER_TRACE(gdb_bh, "get_write_access");
+ err = ext4_journal_get_write_access(handle, gdb_bh);
+ if (err) {
+ kvfree(n_group_desc);
+ brelse(gdb_bh);
+ return err;
+ }
+
EXT4_SB(sb)->s_group_desc = n_group_desc;
EXT4_SB(sb)->s_gdb_count++;
kvfree(o_group_desc);
- BUFFER_TRACE(gdb_bh, "get_write_access");
- err = ext4_journal_get_write_access(handle, gdb_bh);
return err;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 100/168] ext4: report real fs size after failed resize
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (98 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 099/168] ext4: add missing brelse() in add_new_gdb_meta_bg() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 101/168] ALSA: echoaudio: add a check for ioremap_nocache Greg Kroah-Hartman
` (72 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lukas Czerner, Theodore Tso, Sasha Levin
[ Upstream commit 6c7328400e0488f7d49e19e02290ba343b6811b2 ]
Currently when the file system resize using ext4_resize_fs() fails it
will report into log that "resized filesystem to <requested block
count>". However this may not be true in the case of failure. Use the
current block count as returned by ext4_blocks_count() to report the
block count.
Additionally, report a warning that "error occurred during file system
resize"
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/ext4/resize.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 22c90eb9a4e0..5223eb25bf59 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -2047,6 +2047,10 @@ int ext4_resize_fs(struct super_block *sb, ext4_fsblk_t n_blocks_count)
free_flex_gd(flex_gd);
if (resize_inode != NULL)
iput(resize_inode);
- ext4_msg(sb, KERN_INFO, "resized filesystem to %llu", n_blocks_count);
+ if (err)
+ ext4_warning(sb, "error (%d) occurred during "
+ "file system resize", err);
+ ext4_msg(sb, KERN_INFO, "resized filesystem to %llu",
+ ext4_blocks_count(es));
return err;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 101/168] ALSA: echoaudio: add a check for ioremap_nocache
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (99 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 100/168] ext4: report real fs size after failed resize Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 102/168] ALSA: sb8: add a check for request_region Greg Kroah-Hartman
` (71 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kangjie Lu, Takashi Iwai, Sasha Levin
[ Upstream commit 6ade657d6125ec3ec07f95fa51e28138aef6208f ]
In case ioremap_nocache fails, the fix releases chip and returns
an error code upstream to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/pci/echoaudio/echoaudio.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sound/pci/echoaudio/echoaudio.c b/sound/pci/echoaudio/echoaudio.c
index 286f5e3686a3..d73ee11a32bd 100644
--- a/sound/pci/echoaudio/echoaudio.c
+++ b/sound/pci/echoaudio/echoaudio.c
@@ -1953,6 +1953,11 @@ static int snd_echo_create(struct snd_card *card,
}
chip->dsp_registers = (volatile u32 __iomem *)
ioremap_nocache(chip->dsp_registers_phys, sz);
+ if (!chip->dsp_registers) {
+ dev_err(chip->card->dev, "ioremap failed\n");
+ snd_echo_free(chip);
+ return -ENOMEM;
+ }
if (request_irq(pci->irq, snd_echo_interrupt, IRQF_SHARED,
KBUILD_MODNAME, chip)) {
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 102/168] ALSA: sb8: add a check for request_region
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (100 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 101/168] ALSA: echoaudio: add a check for ioremap_nocache Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 103/168] IB/mlx4: Fix race condition between catas error reset and aliasguid flows Greg Kroah-Hartman
` (70 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kangjie Lu, Takashi Iwai, Sasha Levin
[ Upstream commit dcd0feac9bab901d5739de51b3f69840851f8919 ]
In case request_region fails, the fix returns an error code to
avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/isa/sb/sb8.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/isa/sb/sb8.c b/sound/isa/sb/sb8.c
index b8e2391c33ff..0c7fe1418447 100644
--- a/sound/isa/sb/sb8.c
+++ b/sound/isa/sb/sb8.c
@@ -111,6 +111,10 @@ static int snd_sb8_probe(struct device *pdev, unsigned int dev)
/* block the 0x388 port to avoid PnP conflicts */
acard->fm_res = request_region(0x388, 4, "SoundBlaster FM");
+ if (!acard->fm_res) {
+ err = -EBUSY;
+ goto _err;
+ }
if (port[dev] != SNDRV_AUTO_PORT) {
if ((err = snd_sbdsp_create(card, port[dev], irq[dev],
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 103/168] IB/mlx4: Fix race condition between catas error reset and aliasguid flows
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (101 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 102/168] ALSA: sb8: add a check for request_region Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 104/168] mmc: davinci: remove extraneous __init annotation Greg Kroah-Hartman
` (69 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jack Morgenstein, Leon Romanovsky,
Jason Gunthorpe, Sasha Levin
[ Upstream commit 587443e7773e150ae29e643ee8f41a1eed226565 ]
Code review revealed a race condition which could allow the catas error
flow to interrupt the alias guid query post mechanism at random points.
Thiis is fixed by doing cancel_delayed_work_sync() instead of
cancel_delayed_work() during the alias guid mechanism destroy flow.
Fixes: a0c64a17aba8 ("mlx4: Add alias_guid mechanism")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/mlx4/alias_GUID.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/alias_GUID.c b/drivers/infiniband/hw/mlx4/alias_GUID.c
index 21cb41a60fe8..3a70b418d913 100644
--- a/drivers/infiniband/hw/mlx4/alias_GUID.c
+++ b/drivers/infiniband/hw/mlx4/alias_GUID.c
@@ -805,8 +805,8 @@ void mlx4_ib_destroy_alias_guid_service(struct mlx4_ib_dev *dev)
unsigned long flags;
for (i = 0 ; i < dev->num_ports; i++) {
- cancel_delayed_work(&dev->sriov.alias_guid.ports_guid[i].alias_guid_work);
det = &sriov->alias_guid.ports_guid[i];
+ cancel_delayed_work_sync(&det->alias_guid_work);
spin_lock_irqsave(&sriov->alias_guid.ag_work_lock, flags);
while (!list_empty(&det->cb_list)) {
cb_ctx = list_entry(det->cb_list.next,
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 104/168] mmc: davinci: remove extraneous __init annotation
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (102 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 103/168] IB/mlx4: Fix race condition between catas error reset and aliasguid flows Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 105/168] ALSA: opl3: fix mismatch between snd_opl3_drum_switch definition and declaration Greg Kroah-Hartman
` (68 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Wolfram Sang,
Nathan Chancellor, Ulf Hansson, Sasha Levin
[ Upstream commit 9ce58dd7d9da3ca0d7cb8c9568f1c6f4746da65a ]
Building with clang finds a mistaken __init tag:
WARNING: vmlinux.o(.text+0x5e4250): Section mismatch in reference from the function davinci_mmcsd_probe() to the function .init.text:init_mmcsd_host()
The function davinci_mmcsd_probe() references
the function __init init_mmcsd_host().
This is often because davinci_mmcsd_probe lacks a __init
annotation or the annotation of init_mmcsd_host is wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mmc/host/davinci_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index ea2a2ebc6b91..dba7565571a5 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -1147,7 +1147,7 @@ static inline void mmc_davinci_cpufreq_deregister(struct mmc_davinci_host *host)
{
}
#endif
-static void __init init_mmcsd_host(struct mmc_davinci_host *host)
+static void init_mmcsd_host(struct mmc_davinci_host *host)
{
mmc_davinci_reset_ctrl(host, 1);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 105/168] ALSA: opl3: fix mismatch between snd_opl3_drum_switch definition and declaration
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (103 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 104/168] mmc: davinci: remove extraneous __init annotation Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 106/168] thermal/int340x_thermal: Add additional UUIDs Greg Kroah-Hartman
` (67 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Colin Ian King, Takashi Iwai, Sasha Levin
[ Upstream commit b4748e7ab731e436cf5db4786358ada5dd2db6dd ]
The function snd_opl3_drum_switch declaration in the header file
has the order of the two arguments on_off and vel swapped when
compared to the definition arguments of vel and on_off. Fix this
by swapping them around to match the definition.
This error predates the git history, so no idea when this error
was introduced.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/drivers/opl3/opl3_voice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/drivers/opl3/opl3_voice.h b/sound/drivers/opl3/opl3_voice.h
index a371c075ac87..e26702559f61 100644
--- a/sound/drivers/opl3/opl3_voice.h
+++ b/sound/drivers/opl3/opl3_voice.h
@@ -41,7 +41,7 @@ void snd_opl3_timer_func(unsigned long data);
/* Prototypes for opl3_drums.c */
void snd_opl3_load_drums(struct snd_opl3 *opl3);
-void snd_opl3_drum_switch(struct snd_opl3 *opl3, int note, int on_off, int vel, struct snd_midi_channel *chan);
+void snd_opl3_drum_switch(struct snd_opl3 *opl3, int note, int vel, int on_off, struct snd_midi_channel *chan);
/* Prototypes for opl3_oss.c */
#ifdef CONFIG_SND_SEQUENCER_OSS
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 106/168] thermal/int340x_thermal: Add additional UUIDs
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (104 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 105/168] ALSA: opl3: fix mismatch between snd_opl3_drum_switch definition and declaration Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 107/168] thermal/int340x_thermal: fix mode setting Greg Kroah-Hartman
` (66 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthew Garrett, Nisha Aram,
Zhang Rui, Sasha Levin
[ Upstream commit 16fc8eca1975358111dbd7ce65e4ce42d1a848fb ]
Add more supported DPTF policies than the driver currently exposes.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Cc: Nisha Aram <nisha.aram@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/thermal/int340x_thermal/int3400_thermal.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c b/drivers/thermal/int340x_thermal/int3400_thermal.c
index 5836e5554433..0beed2899163 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -20,6 +20,13 @@ enum int3400_thermal_uuid {
INT3400_THERMAL_PASSIVE_1,
INT3400_THERMAL_ACTIVE,
INT3400_THERMAL_CRITICAL,
+ INT3400_THERMAL_ADAPTIVE_PERFORMANCE,
+ INT3400_THERMAL_EMERGENCY_CALL_MODE,
+ INT3400_THERMAL_PASSIVE_2,
+ INT3400_THERMAL_POWER_BOSS,
+ INT3400_THERMAL_VIRTUAL_SENSOR,
+ INT3400_THERMAL_COOLING_MODE,
+ INT3400_THERMAL_HARDWARE_DUTY_CYCLING,
INT3400_THERMAL_MAXIMUM_UUID,
};
@@ -27,6 +34,13 @@ static u8 *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
"42A441D6-AE6A-462b-A84B-4A8CE79027D3",
"3A95C389-E4B8-4629-A526-C52C88626BAE",
"97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
+ "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D",
+ "5349962F-71E6-431D-9AE8-0A635B710AEE",
+ "9E04115A-AE87-4D1C-9500-0F3E340BFE75",
+ "F5A35014-C209-46A4-993A-EB56DE7530A1",
+ "6ED722A7-9240-48A5-B479-31EEF723D7CF",
+ "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531",
+ "BE84BABF-C4D4-403D-B495-3128FD44dAC1",
};
struct int3400_thermal_priv {
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 107/168] thermal/int340x_thermal: fix mode setting
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (105 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 106/168] thermal/int340x_thermal: Add additional UUIDs Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 108/168] tools/power turbostat: return the exit status of a command Greg Kroah-Hartman
` (65 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthew Garrett, Zhang Rui, Sasha Levin
[ Upstream commit 396ee4d0cd52c13b3f6421b8d324d65da5e7e409 ]
int3400 only pushes the UUID into the firmware when the mode is flipped
to "enable". The current code only exposes the mode flag if the firmware
supports the PASSIVE_1 UUID, which not all machines do. Remove the
restriction.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/thermal/int340x_thermal/int3400_thermal.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c b/drivers/thermal/int340x_thermal/int3400_thermal.c
index 0beed2899163..d4c374cc4f74 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -285,10 +285,9 @@ static int int3400_thermal_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
- if (priv->uuid_bitmap & 1 << INT3400_THERMAL_PASSIVE_1) {
- int3400_thermal_ops.get_mode = int3400_thermal_get_mode;
- int3400_thermal_ops.set_mode = int3400_thermal_set_mode;
- }
+ int3400_thermal_ops.get_mode = int3400_thermal_get_mode;
+ int3400_thermal_ops.set_mode = int3400_thermal_set_mode;
+
priv->thermal = thermal_zone_device_register("INT3400 Thermal", 0, 0,
priv, &int3400_thermal_ops,
&int3400_thermal_params, 0, 0);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 108/168] tools/power turbostat: return the exit status of a command
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (106 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 107/168] thermal/int340x_thermal: fix mode setting Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 109/168] perf top: Fix error handling in cmd_top() Greg Kroah-Hartman
` (64 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Arcari, Len Brown,
Rafael J. Wysocki, Sasha Levin
[ Upstream commit 2a95496634a017c19641f26f00907af75b962f01 ]
turbostat failed to return a non-zero exit status even though the
supplied command (turbostat <command>) failed. Currently when turbostat
forks a command it returns zero instead of the actual exit status of the
command. Modify the code to return the exit status.
Signed-off-by: David Arcari <darcari@redhat.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/power/x86/turbostat/turbostat.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c
index 33c79e415075..532e7bf06868 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -3089,6 +3089,9 @@ int fork_it(char **argv)
signal(SIGQUIT, SIG_IGN);
if (waitpid(child_pid, &status, 0) == -1)
err(status, "waitpid");
+
+ if (WIFEXITED(status))
+ status = WEXITSTATUS(status);
}
/*
* n.b. fork_it() does not check for errors from for_all_cpus()
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 109/168] perf top: Fix error handling in cmd_top()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (107 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 108/168] tools/power turbostat: return the exit status of a command Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 110/168] perf evsel: Free evsel->counts in perf_evsel__exit() Greg Kroah-Hartman
` (63 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Changbin Du, Jiri Olsa,
Alexei Starovoitov, Daniel Borkmann, Namhyung Kim,
Peter Zijlstra, Steven Rostedt (VMware),
Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit 70c819e4bf1c5f492768b399d898d458ccdad2b6 ]
We should go to the cleanup path, to avoid leaks, detected using gcc's
ASan.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20190316080556.3075-9-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/builtin-top.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 47719bde34c6..4e64ba8163bb 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1320,8 +1320,9 @@ int cmd_top(int argc, const char **argv, const char *prefix __maybe_unused)
symbol_conf.priv_size = sizeof(struct annotation);
symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
- if (symbol__init(NULL) < 0)
- return -1;
+ status = symbol__init(NULL);
+ if (status < 0)
+ goto out_delete_evlist;
sort__setup_elide(stdout);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 110/168] perf evsel: Free evsel->counts in perf_evsel__exit()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (108 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 109/168] perf top: Fix error handling in cmd_top() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 111/168] perf tests: Fix a memory leak of cpu_map object in the openat_syscall_event_on_all_cpus test Greg Kroah-Hartman
` (62 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Changbin Du, Alexei Starovoitov,
Daniel Borkmann, Jiri Olsa, Namhyung Kim, Peter Zijlstra,
Steven Rostedt (VMware),
Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit 42dfa451d825a2ad15793c476f73e7bbc0f9d312 ]
Using gcc's ASan, Changbin reports:
=================================================================
==7494==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5625e5330a5e in zalloc util/util.h:23
#2 0x5625e5330a9b in perf_counts__new util/counts.c:10
#3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
#4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
#5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
#6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
#7 0x5625e51528e6 in run_test tests/builtin-test.c:358
#8 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#10 0x5625e515572f in cmd_test tests/builtin-test.c:722
#11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#15 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5625e532560d in zalloc util/util.h:23
#2 0x5625e532566b in xyarray__new util/xyarray.c:10
#3 0x5625e5330aba in perf_counts__new util/counts.c:15
#4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
#5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
#6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
#7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
#8 0x5625e51528e6 in run_test tests/builtin-test.c:358
#9 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#11 0x5625e515572f in cmd_test tests/builtin-test.c:722
#12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#16 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
His patch took care of evsel->prev_raw_counts, but the above backtraces
are about evsel->counts, so fix that instead.
Reported-by: Changbin Du <changbin.du@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lkml.kernel.org/n/tip-hd1x13g59f0nuhe4anxhsmfp@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/util/evsel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index f0bd4825f95a..97fde9275f42 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1051,6 +1051,7 @@ void perf_evsel__exit(struct perf_evsel *evsel)
{
assert(list_empty(&evsel->node));
assert(evsel->evlist == NULL);
+ perf_evsel__free_counts(evsel);
perf_evsel__free_fd(evsel);
perf_evsel__free_id(evsel);
perf_evsel__free_config_terms(evsel);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 111/168] perf tests: Fix a memory leak of cpu_map object in the openat_syscall_event_on_all_cpus test
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (109 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 110/168] perf evsel: Free evsel->counts in perf_evsel__exit() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 112/168] perf tests: Fix a memory leak in test__perf_evsel__tp_sched_test() Greg Kroah-Hartman
` (61 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Changbin Du, Jiri Olsa,
Alexei Starovoitov, Daniel Borkmann, Namhyung Kim,
Peter Zijlstra, Steven Rostedt (VMware),
Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit 93faa52e8371f0291ee1ff4994edae2b336b6233 ]
=================================================================
==7497==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a88f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x5625e5326213 in cpu_map__trim_new util/cpumap.c:45
#2 0x5625e5326703 in cpu_map__read util/cpumap.c:103
#3 0x5625e53267ef in cpu_map__read_all_cpu_map util/cpumap.c:120
#4 0x5625e5326915 in cpu_map__new util/cpumap.c:135
#5 0x5625e517b355 in test__openat_syscall_event_on_all_cpus tests/openat-syscall-all-cpus.c:36
#6 0x5625e51528e6 in run_test tests/builtin-test.c:358
#7 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#8 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#9 0x5625e515572f in cmd_test tests/builtin-test.c:722
#10 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#11 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#12 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#13 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#14 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes: f30a79b012e5 ("perf tools: Add reference counting for cpu_map object")
Link: http://lkml.kernel.org/r/20190316080556.3075-15-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/tests/openat-syscall-all-cpus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/openat-syscall-all-cpus.c b/tools/perf/tests/openat-syscall-all-cpus.c
index 2006485a2859..3848d5ab378d 100644
--- a/tools/perf/tests/openat-syscall-all-cpus.c
+++ b/tools/perf/tests/openat-syscall-all-cpus.c
@@ -35,7 +35,7 @@ int test__openat_syscall_event_on_all_cpus(void)
if (IS_ERR(evsel)) {
tracing_path__strerror_open_tp(errno, errbuf, sizeof(errbuf), "syscalls", "sys_enter_openat");
pr_debug("%s\n", errbuf);
- goto out_thread_map_delete;
+ goto out_cpu_map_delete;
}
if (perf_evsel__open(evsel, cpus, threads) < 0) {
@@ -109,6 +109,8 @@ int test__openat_syscall_event_on_all_cpus(void)
perf_evsel__close_fd(evsel, 1, threads->nr);
out_evsel_delete:
perf_evsel__delete(evsel);
+out_cpu_map_delete:
+ cpu_map__put(cpus);
out_thread_map_delete:
thread_map__put(threads);
return err;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 112/168] perf tests: Fix a memory leak in test__perf_evsel__tp_sched_test()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (110 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 111/168] perf tests: Fix a memory leak of cpu_map object in the openat_syscall_event_on_all_cpus test Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 113/168] x86/hpet: Prevent potential NULL pointer dereference Greg Kroah-Hartman
` (60 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Changbin Du, Jiri Olsa,
Alexei Starovoitov, Daniel Borkmann, Namhyung Kim,
Peter Zijlstra, Steven Rostedt (VMware),
Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit d982b33133284fa7efa0e52ae06b88f9be3ea764 ]
=================================================================
==20875==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1160 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc84138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x55bd50005599 in zalloc util/util.h:23
#2 0x55bd500068f5 in perf_evsel__newtp_idx util/evsel.c:327
#3 0x55bd4ff810fc in perf_evsel__newtp /home/work/linux/tools/perf/util/evsel.h:216
#4 0x55bd4ff81608 in test__perf_evsel__tp_sched_test tests/evsel-tp-sched.c:69
#5 0x55bd4ff528e6 in run_test tests/builtin-test.c:358
#6 0x55bd4ff52baf in test_and_print tests/builtin-test.c:388
#7 0x55bd4ff543fe in __cmd_test tests/builtin-test.c:583
#8 0x55bd4ff5572f in cmd_test tests/builtin-test.c:722
#9 0x55bd4ffc4087 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#10 0x55bd4ffc45c6 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#11 0x55bd4ffc49ca in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#12 0x55bd4ffc5138 in main /home/changbin/work/linux/tools/perf/perf.c:520
#13 0x7f1b6e34809a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 19 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc83f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x7f1b6e3ac30f in vasprintf (/lib/x86_64-linux-gnu/libc.so.6+0x8830f)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes: 6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields")
Link: http://lkml.kernel.org/r/20190316080556.3075-17-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/tests/evsel-tp-sched.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/tests/evsel-tp-sched.c b/tools/perf/tests/evsel-tp-sched.c
index da474d743b6a..37529f73833d 100644
--- a/tools/perf/tests/evsel-tp-sched.c
+++ b/tools/perf/tests/evsel-tp-sched.c
@@ -84,5 +84,6 @@ int test__perf_evsel__tp_sched_test(void)
if (perf_evsel__test_field(evsel, "target_cpu", 4, true))
ret = -1;
+ perf_evsel__delete(evsel);
return ret;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 113/168] x86/hpet: Prevent potential NULL pointer dereference
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (111 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 112/168] perf tests: Fix a memory leak in test__perf_evsel__tp_sched_test() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 114/168] x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors Greg Kroah-Hartman
` (59 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aditya Pakki, Thomas Gleixner, kjlu,
Borislav Petkov, H. Peter Anvin, Kees Cook, Joe Perches,
Nicolai Stange, Roland Dreier, Sasha Levin
[ Upstream commit 2e84f116afca3719c9d0a1a78b47b48f75fd5724 ]
hpet_virt_address may be NULL when ioremap_nocache fail, but the code lacks
a check.
Add a check to prevent NULL pointer dereference.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: kjlu@umn.edu
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: Nicolai Stange <nstange@suse.de>
Cc: Roland Dreier <roland@purestorage.com>
Link: https://lkml.kernel.org/r/20190319021958.17275-1-pakki001@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/hpet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 3fdc1e53aaac..9cce5504a5c7 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -825,6 +825,8 @@ int __init hpet_enable(void)
return 0;
hpet_set_mapping();
+ if (!hpet_virt_address)
+ return 0;
/*
* Read the period and check for a sane value:
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 114/168] x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (112 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 113/168] x86/hpet: Prevent potential NULL pointer dereference Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 115/168] iommu/vt-d: Check capability before disabling protected memory Greg Kroah-Hartman
` (58 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthew Whitehead, Thomas Gleixner,
luto, Sasha Levin
[ Upstream commit 18fb053f9b827bd98cfc64f2a35df8ab19745a1d ]
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:
setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:
outb(CX86_CCR2, 0x22);
inb(0x23);
>From the comments:
* When using the old macros a line like
* setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
* gets expanded to:
* do {
* outb((CX86_CCR2), 0x22);
* outb((({
* outb((CX86_CCR2), 0x22);
* inb(0x23);
* }) | 0x88), 0x23);
* } while (0);
The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.
Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: luto@kernel.org
Link: https://lkml.kernel.org/r/1552596361-8967-2-git-send-email-tedheadster@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/cpu/cyrix.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 15e47c1cd412..6e4e4191abb5 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -121,7 +121,7 @@ static void set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* Load/Store Serialize to mem access disable (=reorder it) */
- setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
+ setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -132,11 +132,11 @@ static void set_cx86_memwb(void)
printk(KERN_INFO "Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
/* CCR2 bit 2: unlock NW bit */
- setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
- setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
}
/*
@@ -150,14 +150,14 @@ static void geode_configure(void)
local_irq_save(flags);
/* Suspend on halt power saving and enable #SUSP pin */
- setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* FPU fast, DTE cache, Mem bypass */
- setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
+ setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
set_cx86_memwb();
@@ -292,7 +292,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
- setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
+ setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
/*
* GXm : 0x30 ... 0x5f GXm datasheet 51
@@ -315,7 +315,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++; /* M II */
/* Enable MMX extensions (App note 108) */
- setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
+ setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
} else {
/* A 6x86MX - it has the bug. */
set_cpu_bug(c, X86_BUG_COMA);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 115/168] iommu/vt-d: Check capability before disabling protected memory
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (113 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 114/168] x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 116/168] x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error Greg Kroah-Hartman
` (57 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jacob Pan, mark gross, Ashok Raj,
Lu Baolu, Joerg Roedel, Sasha Levin
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability register).
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: mark gross <mgross@intel.com>
Suggested-by: Ashok Raj <ashok.raj@intel.com>
Fixes: f8bab73515ca5 ("intel-iommu: PMEN support")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/intel-iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 8b4a4d95669a..3e97c4b2ebed 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1598,6 +1598,9 @@ static void iommu_disable_protect_mem_regions(struct intel_iommu *iommu)
u32 pmen;
unsigned long flags;
+ if (!cap_plmr(iommu->cap) && !cap_phmr(iommu->cap))
+ return;
+
raw_spin_lock_irqsave(&iommu->register_lock, flags);
pmen = readl(iommu->reg + DMAR_PMEN_REG);
pmen &= ~DMA_PMEN_EPM;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 116/168] x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (114 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 115/168] iommu/vt-d: Check capability before disabling protected memory Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 117/168] fix incorrect error code mapping for OBJECTID_NOT_FOUND Greg Kroah-Hartman
` (56 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nick Desaulniers, Nathan Chancellor,
Thomas Gleixner, Borislav Petkov, H. Peter Anvin,
clang-built-linux, Sasha Levin
[ Upstream commit e898e69d6b9475bf123f99b3c5d1a67bb7cb2361 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/x86/kernel/hw_breakpoint.c:355:2: warning: variable 'align' is used
uninitialized whenever switch default is taken
[-Wsometimes-uninitialized]
The default cannot be reached because arch_build_bp_info() initializes
hw->len to one of the specified cases. Nevertheless the warning is valid
and returning -EINVAL makes sure that this cannot be broken by future
modifications.
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: clang-built-linux@googlegroups.com
Link: https://github.com/ClangBuiltLinux/linux/issues/392
Link: https://lkml.kernel.org/r/20190307212756.4648-1-natechancellor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/hw_breakpoint.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 2bcfb5f2bc44..433f17d154e2 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -351,6 +351,7 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
#endif
default:
WARN_ON_ONCE(1);
+ return -EINVAL;
}
/*
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 117/168] fix incorrect error code mapping for OBJECTID_NOT_FOUND
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (115 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 116/168] x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 118/168] ext4: prohibit fstrim in norecovery mode Greg Kroah-Hartman
` (55 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Steve French, Amir Goldstein, Sasha Levin
[ Upstream commit 85f9987b236cf46e06ffdb5c225cf1f3c0acb789 ]
It was mapped to EIO which can be confusing when user space
queries for an object GUID for an object for which the server
file system doesn't support (or hasn't saved one).
As Amir Goldstein suggested this is similar to ENOATTR
(equivalently ENODATA in Linux errno definitions) so
changing NT STATUS code mapping for OBJECTID_NOT_FOUND
to ENODATA.
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/smb2maperror.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/smb2maperror.c b/fs/cifs/smb2maperror.c
index 98c25b969ab8..7e93d5706bf6 100644
--- a/fs/cifs/smb2maperror.c
+++ b/fs/cifs/smb2maperror.c
@@ -1034,7 +1034,8 @@ static const struct status_to_posix_error smb2_error_map_table[] = {
{STATUS_UNFINISHED_CONTEXT_DELETED, -EIO,
"STATUS_UNFINISHED_CONTEXT_DELETED"},
{STATUS_NO_TGT_REPLY, -EIO, "STATUS_NO_TGT_REPLY"},
- {STATUS_OBJECTID_NOT_FOUND, -EIO, "STATUS_OBJECTID_NOT_FOUND"},
+ /* Note that ENOATTTR and ENODATA are the same errno */
+ {STATUS_OBJECTID_NOT_FOUND, -ENODATA, "STATUS_OBJECTID_NOT_FOUND"},
{STATUS_NO_IP_ADDRESSES, -EIO, "STATUS_NO_IP_ADDRESSES"},
{STATUS_WRONG_CREDENTIAL_HANDLE, -EIO,
"STATUS_WRONG_CREDENTIAL_HANDLE"},
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 118/168] ext4: prohibit fstrim in norecovery mode
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (116 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 117/168] fix incorrect error code mapping for OBJECTID_NOT_FOUND Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 119/168] rsi: improve kernel thread handling to fix kernel panic Greg Kroah-Hartman
` (54 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Darrick J. Wong, Theodore Tso, Sasha Levin
[ Upstream commit 18915b5873f07e5030e6fb108a050fa7c71c59fb ]
The ext4 fstrim implementation uses the block bitmaps to find free space
that can be discarded. If we haven't replayed the journal, the bitmaps
will be stale and we absolutely *cannot* use stale metadata to zap the
underlying storage.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/ext4/ioctl.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index bcd7c4788903..e44e3cd738b6 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -599,6 +599,13 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
if (!blk_queue_discard(q))
return -EOPNOTSUPP;
+ /*
+ * We haven't replayed the journal, so we cannot use our
+ * block-bitmap-guided storage zapping commands.
+ */
+ if (test_opt(sb, NOLOAD) && ext4_has_feature_journal(sb))
+ return -EROFS;
+
if (copy_from_user(&range, (struct fstrim_range __user *)arg,
sizeof(range)))
return -EFAULT;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 119/168] rsi: improve kernel thread handling to fix kernel panic
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (117 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 118/168] ext4: prohibit fstrim in norecovery mode Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 120/168] 9p: do not trust pdu content for stat item size Greg Kroah-Hartman
` (53 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Siva Rebbagondla, Kalle Valo, Sasha Levin
[ Upstream commit 4c62764d0fc21a34ffc44eec1210038c3a2e4473 ]
While running regressions, observed below kernel panic when sdio disconnect
called. This is because of, kthread_stop() is taking care of
wait_for_completion() by default. When wait_for_completion triggered
in kthread_stop and as it was done already, giving kernel panic.
Hence, removing redundant wait_for_completion() from rsi_kill_thread().
... skipping ...
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50
PGD 0
Oops: 0002 [#1] SMP
CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic #154-Ubuntu
Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017
Stack:
ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000
ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000
ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15
Call Trace:
[<ffffffff8108160a>] __put_task_struct+0x5a/0x140
[<ffffffff810a484b>] kthread_stop+0x10b/0x110
[<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio]
[<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80
[<ffffffff816f0918>] sdio_bus_remove+0x38/0x100
[<ffffffff8156cc64>] __device_release_driver+0xa4/0x150
[<ffffffff8156d7a5>] driver_detach+0xb5/0xc0
[<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0
[<ffffffff8156dfbc>] driver_unregister+0x2c/0x50
[<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20
[<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio]
[<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210
[<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb
Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/rsi/rsi_common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_common.h b/drivers/net/wireless/rsi/rsi_common.h
index d3fbe33d2324..a13f08fd8690 100644
--- a/drivers/net/wireless/rsi/rsi_common.h
+++ b/drivers/net/wireless/rsi/rsi_common.h
@@ -75,7 +75,6 @@ static inline int rsi_kill_thread(struct rsi_thread *handle)
atomic_inc(&handle->thread_done);
rsi_set_event(&handle->event);
- wait_for_completion(&handle->completion);
return kthread_stop(handle->task);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 120/168] 9p: do not trust pdu content for stat item size
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (118 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 119/168] rsi: improve kernel thread handling to fix kernel panic Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 121/168] 9p locks: add mount option for lock retry interval Greg Kroah-Hartman
` (52 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gertjan Halkes, Dominique Martinet,
Sasha Levin
[ Upstream commit 2803cf4379ed252894f046cb8812a48db35294e3 ]
v9fs_dir_readdir() could deadloop if a struct was sent with a size set
to -2
Link: http://lkml.kernel.org/r/1536134432-11997-1-git-send-email-asmadeus@codewreck.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88021
Signed-off-by: Gertjan Halkes <gertjan@google.com>
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/9p/vfs_dir.c | 8 +++-----
net/9p/protocol.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
index 7d889f56b8e7..05769219d2c2 100644
--- a/fs/9p/vfs_dir.c
+++ b/fs/9p/vfs_dir.c
@@ -105,7 +105,6 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
int err = 0;
struct p9_fid *fid;
int buflen;
- int reclen = 0;
struct p9_rdir *rdir;
struct kvec kvec;
@@ -138,11 +137,10 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
while (rdir->head < rdir->tail) {
err = p9stat_read(fid->clnt, rdir->buf + rdir->head,
rdir->tail - rdir->head, &st);
- if (err) {
+ if (err <= 0) {
p9_debug(P9_DEBUG_VFS, "returned %d\n", err);
return -EIO;
}
- reclen = st.size+2;
over = !dir_emit(ctx, st.name, strlen(st.name),
v9fs_qid2ino(&st.qid), dt_type(&st));
@@ -150,8 +148,8 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
if (over)
return 0;
- rdir->head += reclen;
- ctx->pos += reclen;
+ rdir->head += err;
+ ctx->pos += err;
}
}
}
diff --git a/net/9p/protocol.c b/net/9p/protocol.c
index 145f80518064..7f1b45c082c9 100644
--- a/net/9p/protocol.c
+++ b/net/9p/protocol.c
@@ -570,9 +570,10 @@ int p9stat_read(struct p9_client *clnt, char *buf, int len, struct p9_wstat *st)
if (ret) {
p9_debug(P9_DEBUG_9P, "<<< p9stat_read failed: %d\n", ret);
trace_9p_protocol_dump(clnt, &fake_pdu);
+ return ret;
}
- return ret;
+ return fake_pdu.offset;
}
EXPORT_SYMBOL(p9stat_read);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 121/168] 9p locks: add mount option for lock retry interval
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (119 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 120/168] 9p: do not trust pdu content for stat item size Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 122/168] f2fs: fix to do sanity check with current segment number Greg Kroah-Hartman
` (51 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dinu-Razvan Chis-Serban,
Dominique Martinet, Sasha Levin
[ Upstream commit 5e172f75e51e3de1b4274146d9b990f803cb5c2a ]
The default P9_LOCK_TIMEOUT can be too long for some users exporting
a local file system to a guest VM (30s), make this configurable at
mount time.
Link: http://lkml.kernel.org/r/1536295827-3181-1-git-send-email-asmadeus@codewreck.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195727
Signed-off-by: Dinu-Razvan Chis-Serban <justcsdr@gmail.com>
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/9p/v9fs.c | 21 +++++++++++++++++++++
fs/9p/v9fs.h | 1 +
fs/9p/vfs_file.c | 6 +++++-
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 6caca025019d..1e9bb8db7b48 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -59,6 +59,8 @@ enum {
Opt_cache_loose, Opt_fscache, Opt_mmap,
/* Access options */
Opt_access, Opt_posixacl,
+ /* Lock timeout option */
+ Opt_locktimeout,
/* Error token */
Opt_err
};
@@ -78,6 +80,7 @@ static const match_table_t tokens = {
{Opt_cachetag, "cachetag=%s"},
{Opt_access, "access=%s"},
{Opt_posixacl, "posixacl"},
+ {Opt_locktimeout, "locktimeout=%u"},
{Opt_err, NULL}
};
@@ -126,6 +129,7 @@ static int v9fs_parse_options(struct v9fs_session_info *v9ses, char *opts)
#ifdef CONFIG_9P_FSCACHE
v9ses->cachetag = NULL;
#endif
+ v9ses->session_lock_timeout = P9_LOCK_TIMEOUT;
if (!opts)
return 0;
@@ -298,6 +302,23 @@ static int v9fs_parse_options(struct v9fs_session_info *v9ses, char *opts)
#endif
break;
+ case Opt_locktimeout:
+ r = match_int(&args[0], &option);
+ if (r < 0) {
+ p9_debug(P9_DEBUG_ERROR,
+ "integer field, but no integer?\n");
+ ret = r;
+ continue;
+ }
+ if (option < 1) {
+ p9_debug(P9_DEBUG_ERROR,
+ "locktimeout must be a greater than zero integer.\n");
+ ret = -EINVAL;
+ continue;
+ }
+ v9ses->session_lock_timeout = (long)option * HZ;
+ break;
+
default:
continue;
}
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index 6877050384a1..3775f275ede3 100644
--- a/fs/9p/v9fs.h
+++ b/fs/9p/v9fs.h
@@ -116,6 +116,7 @@ struct v9fs_session_info {
struct list_head slist; /* list of sessions registered with v9fs */
struct backing_dev_info bdi;
struct rw_semaphore rename_sem;
+ long session_lock_timeout; /* retry interval for blocking locks */
};
/* cache_validity flags */
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 62ce8b4a7e5f..373cc50544e9 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -154,6 +154,7 @@ static int v9fs_file_do_lock(struct file *filp, int cmd, struct file_lock *fl)
uint8_t status = P9_LOCK_ERROR;
int res = 0;
unsigned char fl_type;
+ struct v9fs_session_info *v9ses;
fid = filp->private_data;
BUG_ON(fid == NULL);
@@ -189,6 +190,8 @@ static int v9fs_file_do_lock(struct file *filp, int cmd, struct file_lock *fl)
if (IS_SETLKW(cmd))
flock.flags = P9_LOCK_FLAGS_BLOCK;
+ v9ses = v9fs_inode2v9ses(file_inode(filp));
+
/*
* if its a blocked request and we get P9_LOCK_BLOCKED as the status
* for lock request, keep on trying
@@ -202,7 +205,8 @@ static int v9fs_file_do_lock(struct file *filp, int cmd, struct file_lock *fl)
break;
if (status == P9_LOCK_BLOCKED && !IS_SETLKW(cmd))
break;
- if (schedule_timeout_interruptible(P9_LOCK_TIMEOUT) != 0)
+ if (schedule_timeout_interruptible(v9ses->session_lock_timeout)
+ != 0)
break;
/*
* p9_client_lock_dotl overwrites flock.client_id with the
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 122/168] f2fs: fix to do sanity check with current segment number
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (120 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 121/168] 9p locks: add mount option for lock retry interval Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 123/168] serial: uartps: console_setup() cant be placed to init section Greg Kroah-Hartman
` (50 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chao Yu, Jaegeuk Kim, Sasha Levin
[ Upstream commit 042be0f849e5fc24116d0afecfaf926eed5cac63 ]
https://bugzilla.kernel.org/show_bug.cgi?id=200219
Reproduction way:
- mount image
- run poc code
- umount image
F2FS-fs (loop1): Bitmap was wrongly set, blk:15364
------------[ cut here ]------------
kernel BUG at /home/yuchao/git/devf2fs/segment.c:2061!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 17686 Comm: umount Tainted: G W O 4.18.0-rc2+ #39
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
EIP: update_sit_entry+0x459/0x4e0 [f2fs]
Code: e8 1c b5 fd ff 0f 0b 0f 0b 8b 45 e4 c7 44 24 08 9c 7a 6c f8 c7 44 24 04 bc 4a 6c f8 89 44 24 0c 8b 06 89 04 24 e8 f7 b4 fd ff <0f> 0b 8b 45 e4 0f b6 d2 89 54 24 10 c7 44 24 08 60 7a 6c f8 c7 44
EAX: 00000032 EBX: 000000f8 ECX: 00000002 EDX: 00000001
ESI: d7177000 EDI: f520fe68 EBP: d6477c6c ESP: d6477c34
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282
CR0: 80050033 CR2: b7fbe000 CR3: 2a99b3c0 CR4: 000406f0
Call Trace:
f2fs_allocate_data_block+0x124/0x580 [f2fs]
do_write_page+0x78/0x150 [f2fs]
f2fs_do_write_node_page+0x25/0xa0 [f2fs]
__write_node_page+0x2bf/0x550 [f2fs]
f2fs_sync_node_pages+0x60e/0x6d0 [f2fs]
? sync_inode_metadata+0x2f/0x40
? f2fs_write_checkpoint+0x28f/0x7d0 [f2fs]
? up_write+0x1e/0x80
f2fs_write_checkpoint+0x2a9/0x7d0 [f2fs]
? mark_held_locks+0x5d/0x80
? _raw_spin_unlock_irq+0x27/0x50
kill_f2fs_super+0x68/0x90 [f2fs]
deactivate_locked_super+0x3d/0x70
deactivate_super+0x40/0x60
cleanup_mnt+0x39/0x70
__cleanup_mnt+0x10/0x20
task_work_run+0x81/0xa0
exit_to_usermode_loop+0x59/0xa7
do_fast_syscall_32+0x1f5/0x22c
entry_SYSENTER_32+0x53/0x86
EIP: 0xb7f95c51
Code: c1 1e f7 ff ff 89 e5 8b 55 08 85 d2 8b 81 64 cd ff ff 74 02 89 02 5d c3 8b 0c 24 c3 8b 1c 24 c3 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
EAX: 00000000 EBX: 0871ab90 ECX: bfb2cd00 EDX: 00000000
ESI: 00000000 EDI: 0871ab90 EBP: 0871ab90 ESP: bfb2cd7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
Modules linked in: f2fs(O) crc32_generic bnep rfcomm bluetooth ecdh_generic snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq pcbc joydev aesni_intel snd_seq_device aes_i586 snd_timer crypto_simd snd cryptd soundcore mac_hid serio_raw video i2c_piix4 parport_pc ppdev lp parport hid_generic psmouse usbhid hid e1000 [last unloaded: f2fs]
---[ end trace d423f83982cfcdc5 ]---
The reason is, different log headers using the same segment, once
one log's next block address is used by another log, it will cause
panic as above.
Main area: 24 segs, 24 secs 24 zones
- COLD data: 0, 0, 0
- WARM data: 1, 1, 1
- HOT data: 20, 20, 20
- Dir dnode: 22, 22, 22
- File dnode: 22, 22, 22
- Indir nodes: 21, 21, 21
So this patch adds sanity check to detect such condition to avoid
this issue.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/f2fs/super.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index dbd7adff8b5a..bd0dfaecfac3 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1143,7 +1143,7 @@ int sanity_check_ckpt(struct f2fs_sb_info *sbi)
unsigned int segment_count_main;
unsigned int cp_pack_start_sum, cp_payload;
block_t user_block_count;
- int i;
+ int i, j;
total = le32_to_cpu(raw_super->segment_count);
fsmeta = le32_to_cpu(raw_super->segment_count_ckpt);
@@ -1184,11 +1184,43 @@ int sanity_check_ckpt(struct f2fs_sb_info *sbi)
if (le32_to_cpu(ckpt->cur_node_segno[i]) >= main_segs ||
le16_to_cpu(ckpt->cur_node_blkoff[i]) >= blocks_per_seg)
return 1;
+ for (j = i + 1; j < NR_CURSEG_NODE_TYPE; j++) {
+ if (le32_to_cpu(ckpt->cur_node_segno[i]) ==
+ le32_to_cpu(ckpt->cur_node_segno[j])) {
+ f2fs_msg(sbi->sb, KERN_ERR,
+ "Node segment (%u, %u) has the same "
+ "segno: %u", i, j,
+ le32_to_cpu(ckpt->cur_node_segno[i]));
+ return 1;
+ }
+ }
}
for (i = 0; i < NR_CURSEG_DATA_TYPE; i++) {
if (le32_to_cpu(ckpt->cur_data_segno[i]) >= main_segs ||
le16_to_cpu(ckpt->cur_data_blkoff[i]) >= blocks_per_seg)
return 1;
+ for (j = i + 1; j < NR_CURSEG_DATA_TYPE; j++) {
+ if (le32_to_cpu(ckpt->cur_data_segno[i]) ==
+ le32_to_cpu(ckpt->cur_data_segno[j])) {
+ f2fs_msg(sbi->sb, KERN_ERR,
+ "Data segment (%u, %u) has the same "
+ "segno: %u", i, j,
+ le32_to_cpu(ckpt->cur_data_segno[i]));
+ return 1;
+ }
+ }
+ }
+ for (i = 0; i < NR_CURSEG_NODE_TYPE; i++) {
+ for (j = i; j < NR_CURSEG_DATA_TYPE; j++) {
+ if (le32_to_cpu(ckpt->cur_node_segno[i]) ==
+ le32_to_cpu(ckpt->cur_data_segno[j])) {
+ f2fs_msg(sbi->sb, KERN_ERR,
+ "Data segment (%u) and Data segment (%u)"
+ " has the same segno: %u", i, j,
+ le32_to_cpu(ckpt->cur_node_segno[i]));
+ return 1;
+ }
+ }
}
sit_bitmap_size = le32_to_cpu(ckpt->sit_ver_bitmap_bytesize);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 123/168] serial: uartps: console_setup() cant be placed to init section
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (121 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 122/168] f2fs: fix to do sanity check with current segment number Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 124/168] ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms Greg Kroah-Hartman
` (49 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michal Simek, Sasha Levin
[ Upstream commit 4bb1ce2350a598502b23088b169e16b43d4bc639 ]
When console device is rebinded, console_setup() is called again.
But marking it as __init means that function will be clear after boot is
complete. If console device is binded again console_setup() is not found
and error "Unable to handle kernel paging request at virtual address"
is reported.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/xilinx_uartps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 4f2f4aca8d2e..06efcef1b495 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1145,7 +1145,7 @@ static void cdns_uart_console_write(struct console *co, const char *s,
*
* Return: 0 on success, negative errno otherwise.
*/
-static int __init cdns_uart_console_setup(struct console *co, char *options)
+static int cdns_uart_console_setup(struct console *co, char *options)
{
struct uart_port *port = &cdns_uart_port[co->index];
int baud = 9600;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 124/168] ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (122 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 123/168] serial: uartps: console_setup() cant be placed to init section Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 125/168] ACPI / SBS: Fix GPE storm on recent MacBookPros Greg Kroah-Hartman
` (48 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bartlomiej Zolnierkiewicz,
Krzysztof Kozlowski, Sasha Levin
[ Upstream commit 6862fdf2201ab67cd962dbf0643d37db909f4860 ]
"S3C2410 PM Suspend Memory CRC" feature (controlled by
SAMSUNG_PM_CHECK config option) is incompatible with highmem
(uses phys_to_virt() instead of proper mapping) which is used by
the majority of Exynos boards. The issue manifests itself in OOPS
on affected boards, i.e. on Odroid-U3 I got the following one:
Unable to handle kernel paging request at virtual address f0000000
pgd = 1c0f9bb4
[f0000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[<c0458034>] (crc32_le) from [<c0121f8c>] (s3c_pm_makecheck+0x34/0x54)
[<c0121f8c>] (s3c_pm_makecheck) from [<c0121efc>] (s3c_pm_run_res+0x74/0x8c)
[<c0121efc>] (s3c_pm_run_res) from [<c0121ecc>] (s3c_pm_run_res+0x44/0x8c)
[<c0121ecc>] (s3c_pm_run_res) from [<c01210b8>] (exynos_suspend_enter+0x64/0x148)
[<c01210b8>] (exynos_suspend_enter) from [<c018893c>] (suspend_devices_and_enter+0x9ec/0xe74)
[<c018893c>] (suspend_devices_and_enter) from [<c0189534>] (pm_suspend+0x770/0xc04)
[<c0189534>] (pm_suspend) from [<c0186ce8>] (state_store+0x6c/0xcc)
[<c0186ce8>] (state_store) from [<c09db434>] (kobj_attr_store+0x14/0x20)
[<c09db434>] (kobj_attr_store) from [<c02fa63c>] (sysfs_kf_write+0x4c/0x50)
[<c02fa63c>] (sysfs_kf_write) from [<c02f97a4>] (kernfs_fop_write+0xfc/0x1e4)
[<c02f97a4>] (kernfs_fop_write) from [<c027b198>] (__vfs_write+0x2c/0x140)
[<c027b198>] (__vfs_write) from [<c027b418>] (vfs_write+0xa4/0x160)
[<c027b418>] (vfs_write) from [<c027b5d8>] (ksys_write+0x40/0x8c)
[<c027b5d8>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_CHECK config option to hide it on Exynos platforms.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/plat-samsung/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 57729b915003..b9396dcf836d 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -255,7 +255,7 @@ config S3C_PM_DEBUG_LED_SMDK
config SAMSUNG_PM_CHECK
bool "S3C2410 PM Suspend Memory CRC"
- depends on PM
+ depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210)
select CRC32
help
Enable the PM code's memory area checksum over sleep. This option
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 125/168] ACPI / SBS: Fix GPE storm on recent MacBookPros
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (123 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 124/168] ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 126/168] cifs: fallback to older infolevels on findfirst queryinfo retry Greg Kroah-Hartman
` (47 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ronald Tschalär,
Rafael J. Wysocki, Sasha Levin
[ Upstream commit ca1721c5bee77105829cbd7baab8ee0eab85b06d ]
On Apple machines, plugging-in or unplugging the power triggers a GPE
for the EC. Since these machines expose an SBS device, this GPE ends
up triggering the acpi_sbs_callback(). This in turn tries to get the
status of the SBS charger. However, on MBP13,* and MBP14,* machines,
performing the smbus-read operation to get the charger's status triggers
the EC's GPE again. The result is an endless re-triggering and handling
of that GPE, consuming significant CPU resources (> 50% in irq).
In the end this is quite similar to commit 3031cddea633 (ACPI / SBS:
Don't assume the existence of an SBS charger), except that on the above
machines a status of all 1's is returned. And like there, we just want
ignore the charger here.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=198169
Signed-off-by: Ronald Tschalär <ronald@innovation.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/acpi/sbs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
index cb3dedb1beae..b133dac8a7f2 100644
--- a/drivers/acpi/sbs.c
+++ b/drivers/acpi/sbs.c
@@ -443,9 +443,13 @@ static int acpi_ac_get_present(struct acpi_sbs *sbs)
/*
* The spec requires that bit 4 always be 1. If it's not set, assume
- * that the implementation doesn't support an SBS charger
+ * that the implementation doesn't support an SBS charger.
+ *
+ * And on some MacBooks a status of 0xffff is always returned, no
+ * matter whether the charger is plugged in or not, which is also
+ * wrong, so ignore the SBS charger for those too.
*/
- if (!((status >> 4) & 0x1))
+ if (!((status >> 4) & 0x1) || status == 0xffff)
return -ENODEV;
sbs->charger_present = (status >> 15) & 0x1;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 126/168] cifs: fallback to older infolevels on findfirst queryinfo retry
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (124 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 125/168] ACPI / SBS: Fix GPE storm on recent MacBookPros Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 127/168] crypto: sha256/arm - fix crash bug in Thumb2 build Greg Kroah-Hartman
` (46 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Steve French, Sasha Levin
[ Upstream commit 3b7960caceafdfc2cdfe2850487f8d091eb41144 ]
In cases where queryinfo fails, we have cases in cifs (vers=1.0)
where with backupuid mounts we retry the query info with findfirst.
This doesn't work to some NetApp servers which don't support
WindowsXP (and later) infolevel 261 (SMB_FIND_FILE_ID_FULL_DIR_INFO)
so in this case use other info levels (in this case it will usually
be level 257, SMB_FIND_FILE_DIRECTORY_INFO).
(Also fixes some indentation)
See kernel bugzilla 201435
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/inode.c | 69 +++++++++++++++++++++++++++----------------------
1 file changed, 38 insertions(+), 31 deletions(-)
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 5c3187df9ab9..d8bd8dd36211 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -759,43 +759,50 @@ cifs_get_inode_info(struct inode **inode, const char *full_path,
} else if ((rc == -EACCES) && backup_cred(cifs_sb) &&
(strcmp(server->vals->version_string, SMB1_VERSION_STRING)
== 0)) {
- /*
- * For SMB2 and later the backup intent flag is already
- * sent if needed on open and there is no path based
- * FindFirst operation to use to retry with
- */
-
- srchinf = kzalloc(sizeof(struct cifs_search_info),
- GFP_KERNEL);
- if (srchinf == NULL) {
- rc = -ENOMEM;
- goto cgii_exit;
- }
+ /*
+ * For SMB2 and later the backup intent flag is already
+ * sent if needed on open and there is no path based
+ * FindFirst operation to use to retry with
+ */
+
+ srchinf = kzalloc(sizeof(struct cifs_search_info),
+ GFP_KERNEL);
+ if (srchinf == NULL) {
+ rc = -ENOMEM;
+ goto cgii_exit;
+ }
- srchinf->endOfSearch = false;
+ srchinf->endOfSearch = false;
+ if (tcon->unix_ext)
+ srchinf->info_level = SMB_FIND_FILE_UNIX;
+ else if ((tcon->ses->capabilities &
+ tcon->ses->server->vals->cap_nt_find) == 0)
+ srchinf->info_level = SMB_FIND_FILE_INFO_STANDARD;
+ else if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)
srchinf->info_level = SMB_FIND_FILE_ID_FULL_DIR_INFO;
+ else /* no srvino useful for fallback to some netapp */
+ srchinf->info_level = SMB_FIND_FILE_DIRECTORY_INFO;
- srchflgs = CIFS_SEARCH_CLOSE_ALWAYS |
- CIFS_SEARCH_CLOSE_AT_END |
- CIFS_SEARCH_BACKUP_SEARCH;
+ srchflgs = CIFS_SEARCH_CLOSE_ALWAYS |
+ CIFS_SEARCH_CLOSE_AT_END |
+ CIFS_SEARCH_BACKUP_SEARCH;
- rc = CIFSFindFirst(xid, tcon, full_path,
- cifs_sb, NULL, srchflgs, srchinf, false);
- if (!rc) {
- data =
- (FILE_ALL_INFO *)srchinf->srch_entries_start;
+ rc = CIFSFindFirst(xid, tcon, full_path,
+ cifs_sb, NULL, srchflgs, srchinf, false);
+ if (!rc) {
+ data = (FILE_ALL_INFO *)srchinf->srch_entries_start;
- cifs_dir_info_to_fattr(&fattr,
- (FILE_DIRECTORY_INFO *)data, cifs_sb);
- fattr.cf_uniqueid = le64_to_cpu(
- ((SEARCH_ID_FULL_DIR_INFO *)data)->UniqueId);
- validinum = true;
+ cifs_dir_info_to_fattr(&fattr,
+ (FILE_DIRECTORY_INFO *)data, cifs_sb);
+ fattr.cf_uniqueid = le64_to_cpu(
+ ((SEARCH_ID_FULL_DIR_INFO *)data)->UniqueId);
+ validinum = true;
- cifs_buf_release(srchinf->ntwrk_buf_start);
- }
- kfree(srchinf);
- if (rc)
- goto cgii_exit;
+ cifs_buf_release(srchinf->ntwrk_buf_start);
+ }
+ kfree(srchinf);
+ if (rc)
+ goto cgii_exit;
} else
goto cgii_exit;
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 127/168] crypto: sha256/arm - fix crash bug in Thumb2 build
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (125 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 126/168] cifs: fallback to older infolevels on findfirst queryinfo retry Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 128/168] crypto: sha512/arm " Greg Kroah-Hartman
` (45 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Herbert Xu, Sasha Levin
[ Upstream commit 69216a545cf81b2b32d01948f7039315abaf75a0 ]
The SHA256 code we adopted from the OpenSSL project uses a rather
peculiar way to take the address of the round constant table: it
takes the address of the sha256_block_data_order() routine, and
substracts a constant known quantity to arrive at the base of the
table, which is emitted by the same assembler code right before
the routine's entry point.
However, recent versions of binutils have helpfully changed the
behavior of references emitted via an ADR instruction when running
in Thumb2 mode: it now takes the Thumb execution mode bit into
account, which is bit 0 af the address. This means the produced
table address also has bit 0 set, and so we end up with an address
value pointing 1 byte past the start of the table, which results
in crashes such as
Unable to handle kernel paging request at virtual address bf825000
pgd = 42f44b11
[bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
pc : [<bf820bca>] lr : [<bf824ffd>] psr: 800b0033
sp : ebc8bbe8 ip : faaabe1c fp : 2fdd3433
r10: 4c5f1692 r9 : e43037df r8 : b04b0a5a
r7 : c369d722 r6 : 39c3693e r5 : 7a013189 r4 : 1580d26b
r3 : 8762a9b0 r2 : eea9c2cd r1 : 3e9ab536 r0 : 1dea4ae7
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
Control: 70c5383d Table: 6b8467c0 DAC: dbadc0de
Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
Stack: (0xebc8bbe8 to 0xebc8c000)
...
unwind: Unknown symbol address bf820bca
unwind: Index not found bf820bca
Code: 441a ea80 40f9 440a (f85e) 3b04
---[ end trace e560cce92700ef8a ]---
Given that this affects older kernels as well, in case they are built
with a recent toolchain, apply a minimal backportable fix, which is
to emit another non-code label at the start of the routine, and
reference that instead. (This is similar to the current upstream state
of this file in OpenSSL)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/crypto/sha256-armv4.pl | 3 ++-
arch/arm/crypto/sha256-core.S_shipped | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/crypto/sha256-armv4.pl b/arch/arm/crypto/sha256-armv4.pl
index fac0533ea633..f64e8413ab9a 100644
--- a/arch/arm/crypto/sha256-armv4.pl
+++ b/arch/arm/crypto/sha256-armv4.pl
@@ -205,10 +205,11 @@ K256:
.global sha256_block_data_order
.type sha256_block_data_order,%function
sha256_block_data_order:
+.Lsha256_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8 @ sha256_block_data_order
#else
- adr r3,sha256_block_data_order
+ adr r3,.Lsha256_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
diff --git a/arch/arm/crypto/sha256-core.S_shipped b/arch/arm/crypto/sha256-core.S_shipped
index 555a1a8eec90..72c248081d27 100644
--- a/arch/arm/crypto/sha256-core.S_shipped
+++ b/arch/arm/crypto/sha256-core.S_shipped
@@ -86,10 +86,11 @@ K256:
.global sha256_block_data_order
.type sha256_block_data_order,%function
sha256_block_data_order:
+.Lsha256_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8 @ sha256_block_data_order
#else
- adr r3,sha256_block_data_order
+ adr r3,.Lsha256_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 128/168] crypto: sha512/arm - fix crash bug in Thumb2 build
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (126 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 127/168] crypto: sha256/arm - fix crash bug in Thumb2 build Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 129/168] iommu/dmar: Fix buffer overflow during PCI bus notification Greg Kroah-Hartman
` (44 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Herbert Xu, Sasha Levin
[ Upstream commit c64316502008064c158fa40cc250665e461b0f2a ]
The SHA512 code we adopted from the OpenSSL project uses a rather
peculiar way to take the address of the round constant table: it
takes the address of the sha256_block_data_order() routine, and
substracts a constant known quantity to arrive at the base of the
table, which is emitted by the same assembler code right before
the routine's entry point.
However, recent versions of binutils have helpfully changed the
behavior of references emitted via an ADR instruction when running
in Thumb2 mode: it now takes the Thumb execution mode bit into
account, which is bit 0 af the address. This means the produced
table address also has bit 0 set, and so we end up with an address
value pointing 1 byte past the start of the table, which results
in crashes such as
Unable to handle kernel paging request at virtual address bf825000
pgd = 42f44b11
[bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
pc : [<bf820bca>] lr : [<bf824ffd>] psr: 800b0033
sp : ebc8bbe8 ip : faaabe1c fp : 2fdd3433
r10: 4c5f1692 r9 : e43037df r8 : b04b0a5a
r7 : c369d722 r6 : 39c3693e r5 : 7a013189 r4 : 1580d26b
r3 : 8762a9b0 r2 : eea9c2cd r1 : 3e9ab536 r0 : 1dea4ae7
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
Control: 70c5383d Table: 6b8467c0 DAC: dbadc0de
Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
Stack: (0xebc8bbe8 to 0xebc8c000)
...
unwind: Unknown symbol address bf820bca
unwind: Index not found bf820bca
Code: 441a ea80 40f9 440a (f85e) 3b04
---[ end trace e560cce92700ef8a ]---
Given that this affects older kernels as well, in case they are built
with a recent toolchain, apply a minimal backportable fix, which is
to emit another non-code label at the start of the routine, and
reference that instead. (This is similar to the current upstream state
of this file in OpenSSL)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/crypto/sha512-armv4.pl | 3 ++-
arch/arm/crypto/sha512-core.S_shipped | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/crypto/sha512-armv4.pl b/arch/arm/crypto/sha512-armv4.pl
index a2b11a844357..5fe336420bcf 100644
--- a/arch/arm/crypto/sha512-armv4.pl
+++ b/arch/arm/crypto/sha512-armv4.pl
@@ -267,10 +267,11 @@ WORD64(0x5fcb6fab,0x3ad6faec, 0x6c44198c,0x4a475817)
.global sha512_block_data_order
.type sha512_block_data_order,%function
sha512_block_data_order:
+.Lsha512_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8 @ sha512_block_data_order
#else
- adr r3,sha512_block_data_order
+ adr r3,.Lsha512_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
diff --git a/arch/arm/crypto/sha512-core.S_shipped b/arch/arm/crypto/sha512-core.S_shipped
index 3694c4d4ca2b..de9bd7f55242 100644
--- a/arch/arm/crypto/sha512-core.S_shipped
+++ b/arch/arm/crypto/sha512-core.S_shipped
@@ -134,10 +134,11 @@ WORD64(0x5fcb6fab,0x3ad6faec, 0x6c44198c,0x4a475817)
.global sha512_block_data_order
.type sha512_block_data_order,%function
sha512_block_data_order:
+.Lsha512_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8 @ sha512_block_data_order
#else
- adr r3,sha512_block_data_order
+ adr r3,.Lsha512_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 129/168] iommu/dmar: Fix buffer overflow during PCI bus notification
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (127 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 128/168] crypto: sha512/arm " Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 130/168] ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t Greg Kroah-Hartman
` (43 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Julia Cartwright, Joerg Roedel, Sasha Levin
[ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
correct type and prevent a buffer overflow.
This bug manifests in systems with deep PCI hierarchies, and can lead to
an overflow of the static allocated buffer (dmar_pci_notify_info_buf),
or can lead to overflow of slab-allocated data.
BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0
Write of size 1 at addr ffffffff90445d80 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.14.87-rt49-02406-gd0a0e96 #1
Call Trace:
? dump_stack+0x46/0x59
? print_address_description+0x1df/0x290
? dmar_alloc_pci_notify_info+0x1d5/0x2e0
? kasan_report+0x256/0x340
? dmar_alloc_pci_notify_info+0x1d5/0x2e0
? e820__memblock_setup+0xb0/0xb0
? dmar_dev_scope_init+0x424/0x48f
? __down_write_common+0x1ec/0x230
? dmar_dev_scope_init+0x48f/0x48f
? dmar_free_unused_resources+0x109/0x109
? cpumask_next+0x16/0x20
? __kmem_cache_create+0x392/0x430
? kmem_cache_create+0x135/0x2f0
? e820__memblock_setup+0xb0/0xb0
? intel_iommu_init+0x170/0x1848
? _raw_spin_unlock_irqrestore+0x32/0x60
? migrate_enable+0x27a/0x5b0
? sched_setattr+0x20/0x20
? migrate_disable+0x1fc/0x380
? task_rq_lock+0x170/0x170
? try_to_run_init_process+0x40/0x40
? locks_remove_file+0x85/0x2f0
? dev_prepare_static_identity_mapping+0x78/0x78
? rt_spin_unlock+0x39/0x50
? lockref_put_or_lock+0x2a/0x40
? dput+0x128/0x2f0
? __rcu_read_unlock+0x66/0x80
? __fput+0x250/0x300
? __rcu_read_lock+0x1b/0x30
? mntput_no_expire+0x38/0x290
? e820__memblock_setup+0xb0/0xb0
? pci_iommu_init+0x25/0x63
? pci_iommu_init+0x25/0x63
? do_one_initcall+0x7e/0x1c0
? initcall_blacklisted+0x120/0x120
? kernel_init_freeable+0x27b/0x307
? rest_init+0xd0/0xd0
? kernel_init+0xf/0x120
? rest_init+0xd0/0xd0
? ret_from_fork+0x1f/0x40
The buggy address belongs to the variable:
dmar_pci_notify_info_buf+0x40/0x60
Fixes: 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI device path")
Signed-off-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 5a63e32a4a6b..cbad1926cec1 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -143,7 +143,7 @@ dmar_alloc_pci_notify_info(struct pci_dev *dev, unsigned long event)
for (tmp = dev; tmp; tmp = tmp->bus->self)
level++;
- size = sizeof(*info) + level * sizeof(struct acpi_dmar_pci_path);
+ size = sizeof(*info) + level * sizeof(info->path[0]);
if (size <= sizeof(dmar_pci_notify_info_buf)) {
info = (struct dmar_pci_notify_info *)dmar_pci_notify_info_buf;
} else {
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 130/168] ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (128 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 129/168] iommu/dmar: Fix buffer overflow during PCI bus notification Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 131/168] appletalk: Fix use-after-free in atalk_proc_exit Greg Kroah-Hartman
` (42 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yang Shi, Sebastian Andrzej Siewior,
Arnd Bergmann, Russell King, Sasha Levin
[ Upstream commit 143c2a89e0e5fda6c6fd08d7bc1126438c19ae90 ]
When running kprobe on -rt kernel, the below bug is caught:
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
|Preemption disabled at:[<802f2b98>] cpu_stopper_thread+0xc0/0x140
|CPU: 0 PID: 14 Comm: migration/0 Tainted: G O 4.8.3-rt2 #1
|Hardware name: Freescale LS1021A
|[<8025a43c>] (___might_sleep)
|[<80b5b324>] (rt_spin_lock)
|[<80b5c31c>] (__patch_text_real)
|[<80b5c3ac>] (patch_text_stop_machine)
|[<802f2920>] (multi_cpu_stop)
Since patch_text_stop_machine() is called in stop_machine() which
disables IRQ, sleepable lock should be not used in this atomic context,
so replace patch_lock to raw lock.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/kernel/patch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index 69bda1a5707e..1f665acaa6a9 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c
@@ -15,7 +15,7 @@ struct patch {
unsigned int insn;
};
-static DEFINE_SPINLOCK(patch_lock);
+static DEFINE_RAW_SPINLOCK(patch_lock);
static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
__acquires(&patch_lock)
@@ -32,7 +32,7 @@ static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
return addr;
if (flags)
- spin_lock_irqsave(&patch_lock, *flags);
+ raw_spin_lock_irqsave(&patch_lock, *flags);
else
__acquire(&patch_lock);
@@ -47,7 +47,7 @@ static void __kprobes patch_unmap(int fixmap, unsigned long *flags)
clear_fixmap(fixmap);
if (flags)
- spin_unlock_irqrestore(&patch_lock, *flags);
+ raw_spin_unlock_irqrestore(&patch_lock, *flags);
else
__release(&patch_lock);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 131/168] appletalk: Fix use-after-free in atalk_proc_exit
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (129 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 130/168] ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 132/168] lib/div64.c: off by one in shift Greg Kroah-Hartman
` (41 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hulk Robot, YueHaibing,
David S. Miller, Sasha Levin
[ Upstream commit 6377f787aeb945cae7abbb6474798de129e1f3ac ]
KASAN report this:
BUG: KASAN: use-after-free in pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
Read of size 8 at addr ffff8881f41fe5b0 by task syz-executor.0/2806
CPU: 0 PID: 2806 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xfa/0x1ce lib/dump_stack.c:113
print_address_description+0x65/0x270 mm/kasan/report.c:187
kasan_report+0x149/0x18d mm/kasan/report.c:317
pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
remove_proc_entry+0xe8/0x420 fs/proc/generic.c:667
atalk_proc_exit+0x18/0x820 [appletalk]
atalk_exit+0xf/0x5a [appletalk]
__do_sys_delete_module kernel/module.c:1018 [inline]
__se_sys_delete_module kernel/module.c:961 [inline]
__x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb2de6b9c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200001c0
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb2de6ba6bc
R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
Allocated by task 2806:
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
slab_post_alloc_hook mm/slab.h:444 [inline]
slab_alloc_node mm/slub.c:2739 [inline]
slab_alloc mm/slub.c:2747 [inline]
kmem_cache_alloc+0xcf/0x250 mm/slub.c:2752
kmem_cache_zalloc include/linux/slab.h:730 [inline]
__proc_create+0x30f/0xa20 fs/proc/generic.c:408
proc_mkdir_data+0x47/0x190 fs/proc/generic.c:469
0xffffffffc10c01bb
0xffffffffc10c0166
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 2806:
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
slab_free_hook mm/slub.c:1409 [inline]
slab_free_freelist_hook mm/slub.c:1436 [inline]
slab_free mm/slub.c:2986 [inline]
kmem_cache_free+0xa6/0x2a0 mm/slub.c:3002
pde_put+0x6e/0x80 fs/proc/generic.c:647
remove_proc_entry+0x1d3/0x420 fs/proc/generic.c:684
0xffffffffc10c031c
0xffffffffc10c0166
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881f41fe500
which belongs to the cache proc_dir_entry of size 256
The buggy address is located 176 bytes inside of
256-byte region [ffff8881f41fe500, ffff8881f41fe600)
The buggy address belongs to the page:
page:ffffea0007d07f80 count:1 mapcount:0 mapping:ffff8881f6e69a00 index:0x0
flags: 0x2fffc0000000200(slab)
raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6e69a00
raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881f41fe480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8881f41fe500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8881f41fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881f41fe600: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8881f41fe680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
It should check the return value of atalk_proc_init fails,
otherwise atalk_exit will trgger use-after-free in pde_subdir_find
while unload the module.This patch fix error cleanup path of atalk_init
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/atalk.h | 2 +-
net/appletalk/atalk_proc.c | 2 +-
net/appletalk/ddp.c | 37 ++++++++++++++++++++++++++------
net/appletalk/sysctl_net_atalk.c | 5 ++++-
4 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/include/linux/atalk.h b/include/linux/atalk.h
index 73fd8b7e9534..716d53799d1f 100644
--- a/include/linux/atalk.h
+++ b/include/linux/atalk.h
@@ -150,7 +150,7 @@ extern int sysctl_aarp_retransmit_limit;
extern int sysctl_aarp_resolve_time;
#ifdef CONFIG_SYSCTL
-extern void atalk_register_sysctl(void);
+extern int atalk_register_sysctl(void);
extern void atalk_unregister_sysctl(void);
#else
#define atalk_register_sysctl() do { } while(0)
diff --git a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c
index af46bc49e1e9..b5f84f428aa6 100644
--- a/net/appletalk/atalk_proc.c
+++ b/net/appletalk/atalk_proc.c
@@ -293,7 +293,7 @@ int __init atalk_proc_init(void)
goto out;
}
-void __exit atalk_proc_exit(void)
+void atalk_proc_exit(void)
{
remove_proc_entry("interface", atalk_proc_dir);
remove_proc_entry("route", atalk_proc_dir);
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index d5871ac493eb..4246df3b7ae8 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1912,12 +1912,16 @@ static const char atalk_err_snap[] __initconst =
/* Called by proto.c on kernel start up */
static int __init atalk_init(void)
{
- int rc = proto_register(&ddp_proto, 0);
+ int rc;
- if (rc != 0)
+ rc = proto_register(&ddp_proto, 0);
+ if (rc)
goto out;
- (void)sock_register(&atalk_family_ops);
+ rc = sock_register(&atalk_family_ops);
+ if (rc)
+ goto out_proto;
+
ddp_dl = register_snap_client(ddp_snap_id, atalk_rcv);
if (!ddp_dl)
printk(atalk_err_snap);
@@ -1925,12 +1929,33 @@ static int __init atalk_init(void)
dev_add_pack(<alk_packet_type);
dev_add_pack(&ppptalk_packet_type);
- register_netdevice_notifier(&ddp_notifier);
+ rc = register_netdevice_notifier(&ddp_notifier);
+ if (rc)
+ goto out_sock;
+
aarp_proto_init();
- atalk_proc_init();
- atalk_register_sysctl();
+ rc = atalk_proc_init();
+ if (rc)
+ goto out_aarp;
+
+ rc = atalk_register_sysctl();
+ if (rc)
+ goto out_proc;
out:
return rc;
+out_proc:
+ atalk_proc_exit();
+out_aarp:
+ aarp_cleanup_module();
+ unregister_netdevice_notifier(&ddp_notifier);
+out_sock:
+ dev_remove_pack(&ppptalk_packet_type);
+ dev_remove_pack(<alk_packet_type);
+ unregister_snap_client(ddp_dl);
+ sock_unregister(PF_APPLETALK);
+out_proto:
+ proto_unregister(&ddp_proto);
+ goto out;
}
module_init(atalk_init);
diff --git a/net/appletalk/sysctl_net_atalk.c b/net/appletalk/sysctl_net_atalk.c
index ebb864361f7a..4e6042e0fcac 100644
--- a/net/appletalk/sysctl_net_atalk.c
+++ b/net/appletalk/sysctl_net_atalk.c
@@ -44,9 +44,12 @@ static struct ctl_table atalk_table[] = {
static struct ctl_table_header *atalk_table_header;
-void atalk_register_sysctl(void)
+int __init atalk_register_sysctl(void)
{
atalk_table_header = register_net_sysctl(&init_net, "net/appletalk", atalk_table);
+ if (!atalk_table_header)
+ return -ENOMEM;
+ return 0;
}
void atalk_unregister_sysctl(void)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 132/168] lib/div64.c: off by one in shift
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (130 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 131/168] appletalk: Fix use-after-free in atalk_proc_exit Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 133/168] include/linux/swap.h: use offsetof() instead of custom __swapoffset macro Greg Kroah-Hartman
` (40 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stanislaw Gruszka, Siarhei Volkau,
Oleg Nesterov, Andrew Morton, Linus Torvalds, Sasha Levin
[ Upstream commit cdc94a37493135e355dfc0b0e086d84e3eadb50d ]
fls counts bits starting from 1 to 32 (returns 0 for zero argument). If
we add 1 we shift right one bit more and loose precision from divisor,
what cause function incorect results with some numbers.
Corrected code was tested in user-space, see bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202391
Link: http://lkml.kernel.org/r/1548686944-11891-1-git-send-email-sgruszka@redhat.com
Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reported-by: Siarhei Volkau <lis8215@gmail.com>
Tested-by: Siarhei Volkau <lis8215@gmail.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
lib/div64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/div64.c b/lib/div64.c
index 62a698a432bc..75b8521c2146 100644
--- a/lib/div64.c
+++ b/lib/div64.c
@@ -100,7 +100,7 @@ u64 div64_u64_rem(u64 dividend, u64 divisor, u64 *remainder)
quot = div_u64_rem(dividend, divisor, &rem32);
*remainder = rem32;
} else {
- int n = 1 + fls(high);
+ int n = fls(high);
quot = div_u64(dividend >> n, divisor >> n);
if (quot != 0)
@@ -138,7 +138,7 @@ u64 div64_u64(u64 dividend, u64 divisor)
if (high == 0) {
quot = div_u64(dividend, divisor);
} else {
- int n = 1 + fls(high);
+ int n = fls(high);
quot = div_u64(dividend >> n, divisor >> n);
if (quot != 0)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 133/168] include/linux/swap.h: use offsetof() instead of custom __swapoffset macro
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (131 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 132/168] lib/div64.c: off by one in shift Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 134/168] tpm/tpm_crb: Avoid unaligned reads in crb_recv() Greg Kroah-Hartman
` (39 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pi-Hsun Shih, Michal Hocko,
Andrew Morton, Linus Torvalds, Sasha Levin
[ Upstream commit a4046c06be50a4f01d435aa7fe57514818e6cc82 ]
Use offsetof() to calculate offset of a field to take advantage of
compiler built-in version when possible, and avoid UBSAN warning when
compiling with Clang:
UBSAN: Undefined behaviour in mm/swapfile.c:3010:38
member access within null pointer of type 'union swap_header'
CPU: 6 PID: 1833 Comm: swapon Tainted: G S 4.19.23 #43
Call trace:
dump_backtrace+0x0/0x194
show_stack+0x20/0x2c
__dump_stack+0x20/0x28
dump_stack+0x70/0x94
ubsan_epilogue+0x14/0x44
ubsan_type_mismatch_common+0xf4/0xfc
__ubsan_handle_type_mismatch_v1+0x34/0x54
__se_sys_swapon+0x654/0x1084
__arm64_sys_swapon+0x1c/0x24
el0_svc_common+0xa8/0x150
el0_svc_compat_handler+0x2c/0x38
el0_svc_compat+0x8/0x18
Link: http://lkml.kernel.org/r/20190312081902.223764-1-pihsun@chromium.org
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/swap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -135,9 +135,9 @@ struct swap_extent {
/*
* Max bad pages in the new format..
*/
-#define __swapoffset(x) ((unsigned long)&((union swap_header *)0)->x)
#define MAX_SWAP_BADPAGES \
- ((__swapoffset(magic.magic) - __swapoffset(info.badpages)) / sizeof(int))
+ ((offsetof(union swap_header, magic.magic) - \
+ offsetof(union swap_header, info.badpages)) / sizeof(int))
enum {
SWP_USED = (1 << 0), /* is slot in swap_info[] used? */
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 134/168] tpm/tpm_crb: Avoid unaligned reads in crb_recv()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (132 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 133/168] include/linux/swap.h: use offsetof() instead of custom __swapoffset macro Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 135/168] ovl: fix uid/gid when creating over whiteout Greg Kroah-Hartman
` (38 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, James Morris, Tomas Winkler,
Jerry Snitselaar, Jarkko Sakkinen, Sasha Levin (Microsoft)
commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream
The current approach to read first 6 bytes from the response and then tail
of the response, can cause the 2nd memcpy_fromio() to do an unaligned read
(e.g. read 32-bit word from address aligned to a 16-bits), depending on how
memcpy_fromio() is implemented. If this happens, the read will fail and the
memory controller will fill the read with 1's.
This was triggered by 170d13ca3a2f, which should be probably refined to
check and react to the address alignment. Before that commit, on x86
memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
thing (from tpm_crb's perspective) for us so far, but we should not rely on
that. Thus, it makes sense to fix this also in tpm_crb, not least because
the fix can be then backported to stable kernels and make them more robust
when compiled in differing environments.
Cc: stable@vger.kernel.org
Cc: James Morris <jmorris@namei.org>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>
Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>
---
drivers/char/tpm/tpm_crb.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 35308dfff754..8226e3b6dc1f 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -109,19 +109,29 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
struct crb_priv *priv = chip->vendor.priv;
unsigned int expected;
- /* sanity check */
- if (count < 6)
+ /* A sanity check that the upper layer wants to get at least the header
+ * as that is the minimum size for any TPM response.
+ */
+ if (count < TPM_HEADER_SIZE)
return -EIO;
+ /* If this bit is set, according to the spec, the TPM is in
+ * unrecoverable condition.
+ */
if (le32_to_cpu(ioread32(&priv->cca->sts)) & CRB_CA_STS_ERROR)
return -EIO;
- memcpy_fromio(buf, priv->rsp, 6);
- expected = be32_to_cpup((__be32 *) &buf[2]);
- if (expected > count || expected < 6)
+ /* Read the first 8 bytes in order to get the length of the response.
+ * We read exactly a quad word in order to make sure that the remaining
+ * reads will be aligned.
+ */
+ memcpy_fromio(buf, priv->rsp, 8);
+
+ expected = be32_to_cpup((__be32 *)&buf[2]);
+ if (expected > count || expected < TPM_HEADER_SIZE)
return -EIO;
- memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
+ memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
return expected;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 135/168] ovl: fix uid/gid when creating over whiteout
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (133 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 134/168] tpm/tpm_crb: Avoid unaligned reads in crb_recv() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 136/168] appletalk: Fix compile regression Greg Kroah-Hartman
` (37 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephen Smalley, Miklos Szeredi,
Sasha Levin (Microsoft)
[ Upstream commit d0e13f5bbe4be7c8f27736fc40503dcec04b7de0 ]
Fix a regression when creating a file over a whiteout. The new
file/directory needs to use the current fsuid/fsgid, not the ones from the
mounter's credentials.
The refcounting is a bit tricky: prepare_creds() sets an original refcount,
override_creds() gets one more, which revert_cred() drops. So
1) we need to expicitly put the mounter's credentials when overriding
with the updated one
2) we need to put the original ref to the updated creds (and this can
safely be done before revert_creds(), since we'll still have the ref
from override_creds()).
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Fixes: 3fe6e52f0626 ("ovl: override creds with the ones from the superblock mounter")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>
---
fs/overlayfs/dir.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index f8aa54272121..eedacae889b9 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -408,12 +408,21 @@ static int ovl_create_or_link(struct dentry *dentry, int mode, dev_t rdev,
err = ovl_create_upper(dentry, inode, &stat, link, hardlink);
} else {
const struct cred *old_cred;
+ struct cred *override_cred;
old_cred = ovl_override_creds(dentry->d_sb);
- err = ovl_create_over_whiteout(dentry, inode, &stat, link,
- hardlink);
+ err = -ENOMEM;
+ override_cred = prepare_creds();
+ if (override_cred) {
+ override_cred->fsuid = old_cred->fsuid;
+ override_cred->fsgid = old_cred->fsgid;
+ put_cred(override_creds(override_cred));
+ put_cred(override_cred);
+ err = ovl_create_over_whiteout(dentry, inode, &stat,
+ link, hardlink);
+ }
revert_creds(old_cred);
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 136/168] appletalk: Fix compile regression
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (134 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 135/168] ovl: fix uid/gid when creating over whiteout Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 137/168] bonding: fix event handling for stacked bonds Greg Kroah-Hartman
` (36 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, David S. Miller, Sasha Levin
[ Upstream commit 27da0d2ef998e222a876c0cec72aa7829a626266 ]
A bugfix just broke compilation of appletalk when CONFIG_SYSCTL
is disabled:
In file included from net/appletalk/ddp.c:65:
net/appletalk/ddp.c: In function 'atalk_init':
include/linux/atalk.h:164:34: error: expected expression before 'do'
#define atalk_register_sysctl() do { } while(0)
^~
net/appletalk/ddp.c:1934:7: note: in expansion of macro 'atalk_register_sysctl'
rc = atalk_register_sysctl();
This is easier to avoid by using conventional inline functions
as stubs rather than macros. The header already has inline
functions for other purposes, so I'm changing over all the
macros for consistency.
Fixes: 6377f787aeb9 ("appletalk: Fix use-after-free in atalk_proc_exit")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/atalk.h | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux/atalk.h b/include/linux/atalk.h
index 716d53799d1f..af43ed404ff4 100644
--- a/include/linux/atalk.h
+++ b/include/linux/atalk.h
@@ -153,16 +153,26 @@ extern int sysctl_aarp_resolve_time;
extern int atalk_register_sysctl(void);
extern void atalk_unregister_sysctl(void);
#else
-#define atalk_register_sysctl() do { } while(0)
-#define atalk_unregister_sysctl() do { } while(0)
+static inline int atalk_register_sysctl(void)
+{
+ return 0;
+}
+static inline void atalk_unregister_sysctl(void)
+{
+}
#endif
#ifdef CONFIG_PROC_FS
extern int atalk_proc_init(void);
extern void atalk_proc_exit(void);
#else
-#define atalk_proc_init() ({ 0; })
-#define atalk_proc_exit() do { } while(0)
+static inline int atalk_proc_init(void)
+{
+ return 0;
+}
+static inline void atalk_proc_exit(void)
+{
+}
#endif /* CONFIG_PROC_FS */
#endif /* __LINUX_ATALK_H__ */
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 137/168] bonding: fix event handling for stacked bonds
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (135 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 136/168] appletalk: Fix compile regression Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 138/168] net: atm: Fix potential Spectre v1 vulnerabilities Greg Kroah-Hartman
` (35 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sabrina Dubroca, David S. Miller
From: Sabrina Dubroca <sd@queasysnail.net>
[ Upstream commit 92480b3977fd3884649d404cbbaf839b70035699 ]
When a bond is enslaved to another bond, bond_netdev_event() only
handles the event as if the bond is a master, and skips treating the
bond as a slave.
This leads to a refcount leak on the slave, since we don't remove the
adjacency to its master and the master holds a reference on the slave.
Reproducer:
ip link add bondL type bond
ip link add bondU type bond
ip link set bondL master bondU
ip link del bondL
No "Fixes:" tag, this code is older than git history.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3067,8 +3067,12 @@ static int bond_netdev_event(struct noti
return NOTIFY_DONE;
if (event_dev->flags & IFF_MASTER) {
+ int ret;
+
netdev_dbg(event_dev, "IFF_MASTER\n");
- return bond_master_netdev_event(event, event_dev);
+ ret = bond_master_netdev_event(event, event_dev);
+ if (ret != NOTIFY_DONE)
+ return ret;
}
if (event_dev->flags & IFF_SLAVE) {
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 138/168] net: atm: Fix potential Spectre v1 vulnerabilities
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (136 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 137/168] bonding: fix event handling for stacked bonds Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 139/168] net: bridge: multicast: use rcu to access port list from br_multicast_start_querier Greg Kroah-Hartman
` (34 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, David S. Miller
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
[ Upstream commit 899537b73557aafbdd11050b501cf54b4f5c45af ]
arg is controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
net/atm/lec.c:715 lec_mcast_attach() warn: potential spectre issue 'dev_lec' [r] (local cap)
Fix this by sanitizing arg before using it to index dev_lec.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/atm/lec.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -721,7 +721,10 @@ static int lec_vcc_attach(struct atm_vcc
static int lec_mcast_attach(struct atm_vcc *vcc, int arg)
{
- if (arg < 0 || arg >= MAX_LEC_ITF || !dev_lec[arg])
+ if (arg < 0 || arg >= MAX_LEC_ITF)
+ return -EINVAL;
+ arg = array_index_nospec(arg, MAX_LEC_ITF);
+ if (!dev_lec[arg])
return -EINVAL;
vcc->proto_data = dev_lec[arg];
return lec_mcast_make(netdev_priv(dev_lec[arg]), vcc);
@@ -739,6 +742,7 @@ static int lecd_attach(struct atm_vcc *v
i = arg;
if (arg >= MAX_LEC_ITF)
return -EINVAL;
+ i = array_index_nospec(arg, MAX_LEC_ITF);
if (!dev_lec[i]) {
int size;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 139/168] net: bridge: multicast: use rcu to access port list from br_multicast_start_querier
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (137 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 138/168] net: atm: Fix potential Spectre v1 vulnerabilities Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 140/168] net: fou: do not use guehdr after iptunnel_pull_offloads in gue_udp_recv Greg Kroah-Hartman
` (33 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Aleksandrov, David S. Miller
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
[ Upstream commit c5b493ce192bd7a4e7bd073b5685aad121eeef82 ]
br_multicast_start_querier() walks over the port list but it can be
called from a timer with only multicast_lock held which doesn't protect
the port list, so use RCU to walk over it.
Fixes: c83b8fab06fc ("bridge: Restart queries when last querier expires")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bridge/br_multicast.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1894,7 +1894,8 @@ static void br_multicast_start_querier(s
__br_multicast_open(br, query);
- list_for_each_entry(port, &br->port_list, list) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(port, &br->port_list, list) {
if (port->state == BR_STATE_DISABLED ||
port->state == BR_STATE_BLOCKING)
continue;
@@ -1906,6 +1907,7 @@ static void br_multicast_start_querier(s
br_multicast_enable(&port->ip6_own_query);
#endif
}
+ rcu_read_unlock();
}
int br_multicast_toggle(struct net_bridge *br, unsigned long val)
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 140/168] net: fou: do not use guehdr after iptunnel_pull_offloads in gue_udp_recv
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (138 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 139/168] net: bridge: multicast: use rcu to access port list from br_multicast_start_querier Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 141/168] tcp: tcp_grow_window() needs to respect tcp_space() Greg Kroah-Hartman
` (32 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lorenzo Bianconi, David S. Miller
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit 988dc4a9a3b66be75b30405a5494faf0dc7cffb6 ]
gue tunnels run iptunnel_pull_offloads on received skbs. This can
determine a possible use-after-free accessing guehdr pointer since
the packet will be 'uncloned' running pskb_expand_head if it is a
cloned gso skb (e.g if the packet has been sent though a veth device)
Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/fou.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -116,6 +116,7 @@ static int gue_udp_recv(struct sock *sk,
struct guehdr *guehdr;
void *data;
u16 doffset = 0;
+ u8 proto_ctype;
if (!fou)
return 1;
@@ -173,13 +174,14 @@ static int gue_udp_recv(struct sock *sk,
if (unlikely(guehdr->control))
return gue_control_message(skb, guehdr);
+ proto_ctype = guehdr->proto_ctype;
__skb_pull(skb, sizeof(struct udphdr) + hdrlen);
skb_reset_transport_header(skb);
if (iptunnel_pull_offloads(skb))
goto drop;
- return -guehdr->proto_ctype;
+ return -proto_ctype;
drop:
kfree_skb(skb);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 141/168] tcp: tcp_grow_window() needs to respect tcp_space()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (139 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 140/168] net: fou: do not use guehdr after iptunnel_pull_offloads in gue_udp_recv Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 142/168] ipv4: recompile ip options in ipv4_link_failure Greg Kroah-Hartman
` (31 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, Soheil Hassas Yeganeh,
Neal Cardwell, Wei Wang, David S. Miller
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 50ce163a72d817a99e8974222dcf2886d5deb1ae ]
For some reason, tcp_grow_window() correctly tests if enough room
is present before attempting to increase tp->rcv_ssthresh,
but does not prevent it to grow past tcp_space()
This is causing hard to debug issues, like failing
the (__tcp_select_window(sk) >= tp->rcv_wnd) test
in __tcp_ack_snd_check(), causing ACK delays and possibly
slow flows.
Depending on tcp_rmem[2], MTU, skb->len/skb->truesize ratio,
we can see the problem happening on "netperf -t TCP_RR -- -r 2000,2000"
after about 60 round trips, when the active side no longer sends
immediate acks.
This bug predates git history.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Wei Wang <weiwan@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/tcp_input.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -365,11 +365,12 @@ static int __tcp_grow_window(const struc
static void tcp_grow_window(struct sock *sk, const struct sk_buff *skb)
{
struct tcp_sock *tp = tcp_sk(sk);
+ int room;
+
+ room = min_t(int, tp->window_clamp, tcp_space(sk)) - tp->rcv_ssthresh;
/* Check #1 */
- if (tp->rcv_ssthresh < tp->window_clamp &&
- (int)tp->rcv_ssthresh < tcp_space(sk) &&
- !tcp_under_memory_pressure(sk)) {
+ if (room > 0 && !tcp_under_memory_pressure(sk)) {
int incr;
/* Check #2. Increase window, if skb with such overhead
@@ -382,8 +383,7 @@ static void tcp_grow_window(struct sock
if (incr) {
incr = max_t(int, incr, 2 * skb->len);
- tp->rcv_ssthresh = min(tp->rcv_ssthresh + incr,
- tp->window_clamp);
+ tp->rcv_ssthresh += min(room, incr);
inet_csk(sk)->icsk_ack.quick |= 1;
}
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 142/168] ipv4: recompile ip options in ipv4_link_failure
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (140 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 141/168] tcp: tcp_grow_window() needs to respect tcp_space() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 143/168] ipv4: ensure rcu_read_lock() in ipv4_link_failure() Greg Kroah-Hartman
` (30 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephen Suryaputra, David S. Miller
From: Stephen Suryaputra <ssuryaextr@gmail.com>
[ Upstream commit ed0de45a1008991fdaa27a0152befcb74d126a8b ]
Recompile IP options since IPCB may not be valid anymore when
ipv4_link_failure is called from arp_error_report.
Refer to the commit 3da1ed7ac398 ("net: avoid use IPCB in cipso_v4_error")
and the commit before that (9ef6b42ad6fd) for a similar issue.
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/route.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1165,8 +1165,16 @@ static struct dst_entry *ipv4_dst_check(
static void ipv4_link_failure(struct sk_buff *skb)
{
struct rtable *rt;
+ struct ip_options opt;
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_UNREACH, 0);
+ /* Recompile ip options since IPCB may not be valid anymore.
+ */
+ memset(&opt, 0, sizeof(opt));
+ opt.optlen = ip_hdr(skb)->ihl*4 - sizeof(struct iphdr);
+ if (__ip_options_compile(dev_net(skb->dev), &opt, skb, NULL))
+ return;
+
+ __icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_UNREACH, 0, &opt);
rt = skb_rtable(skb);
if (rt)
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 143/168] ipv4: ensure rcu_read_lock() in ipv4_link_failure()
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (141 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 142/168] ipv4: recompile ip options in ipv4_link_failure Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 144/168] crypto: crypto4xx - properly set IV after de- and encrypt Greg Kroah-Hartman
` (29 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, syzbot,
Stephen Suryaputra, David S. Miller
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit c543cb4a5f07e09237ec0fc2c60c9f131b2c79ad ]
fib_compute_spec_dst() needs to be called under rcu protection.
syzbot reported :
WARNING: suspicious RCU usage
5.1.0-rc4+ #165 Not tainted
include/linux/inetdevice.h:220 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by swapper/0/0:
#0: 0000000051b67925 ((&n->timer)){+.-.}, at: lockdep_copy_map include/linux/lockdep.h:170 [inline]
#0: 0000000051b67925 ((&n->timer)){+.-.}, at: call_timer_fn+0xda/0x720 kernel/time/timer.c:1315
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-rc4+ #165
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5162
__in_dev_get_rcu include/linux/inetdevice.h:220 [inline]
fib_compute_spec_dst+0xbbd/0x1030 net/ipv4/fib_frontend.c:294
spec_dst_fill net/ipv4/ip_options.c:245 [inline]
__ip_options_compile+0x15a7/0x1a10 net/ipv4/ip_options.c:343
ipv4_link_failure+0x172/0x400 net/ipv4/route.c:1195
dst_link_failure include/net/dst.h:427 [inline]
arp_error_report+0xd1/0x1c0 net/ipv4/arp.c:297
neigh_invalidate+0x24b/0x570 net/core/neighbour.c:995
neigh_timer_handler+0xc35/0xf30 net/core/neighbour.c:1081
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
__do_softirq+0x266/0x95a kernel/softirq.c:293
invoke_softirq kernel/softirq.c:374 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:414
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/route.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1164,14 +1164,20 @@ static struct dst_entry *ipv4_dst_check(
static void ipv4_link_failure(struct sk_buff *skb)
{
- struct rtable *rt;
struct ip_options opt;
+ struct rtable *rt;
+ int res;
/* Recompile ip options since IPCB may not be valid anymore.
*/
memset(&opt, 0, sizeof(opt));
opt.optlen = ip_hdr(skb)->ihl*4 - sizeof(struct iphdr);
- if (__ip_options_compile(dev_net(skb->dev), &opt, skb, NULL))
+
+ rcu_read_lock();
+ res = __ip_options_compile(dev_net(skb->dev), &opt, skb, NULL);
+ rcu_read_unlock();
+
+ if (res)
return;
__icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_UNREACH, 0, &opt);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 144/168] crypto: crypto4xx - properly set IV after de- and encrypt
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (142 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 143/168] ipv4: ensure rcu_read_lock() in ipv4_link_failure() Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 145/168] modpost: file2alias: go back to simple devtable lookup Greg Kroah-Hartman
` (28 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Lamparter, Herbert Xu, Sasha Levin
[ Upstream commit fc340115ffb8235c1bbd200c28855e6373d0dd1a ]
This patch fixes cts(cbc(aes)) test when cbc-aes-ppc4xx is used.
alg: skcipher: Test 1 failed (invalid result) on encryption for cts(cbc-aes-ppc4xx)
00000000: 4b 10 75 fc 2f 14 1b 6a 27 35 37 33 d1 b7 70 05
00000010: 97
alg: skcipher: Failed to load transform for cts(cbc(aes)): -2
The CTS cipher mode expect the IV (req->iv) of skcipher_request
to contain the last ciphertext block after the {en,de}crypt
operation is complete.
Fix this issue for the AMCC Crypto4xx hardware engine.
The tcrypt test case for cts(cbc(aes)) is now correctly passed.
name : cts(cbc(aes))
driver : cts(cbc-aes-ppc4xx)
module : cts
priority : 300
refcnt : 1
selftest : passed
internal : no
type : skcipher
async : yes
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
chunksize : 16
walksize : 16
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/amcc/crypto4xx_alg.c | 3 ++-
drivers/crypto/amcc/crypto4xx_core.c | 9 +++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/amcc/crypto4xx_alg.c b/drivers/crypto/amcc/crypto4xx_alg.c
index 4afca3968773..e3b8bebfdd30 100644
--- a/drivers/crypto/amcc/crypto4xx_alg.c
+++ b/drivers/crypto/amcc/crypto4xx_alg.c
@@ -138,7 +138,8 @@ static int crypto4xx_setkey_aes(struct crypto_ablkcipher *cipher,
sa = (struct dynamic_sa_ctl *) ctx->sa_in;
ctx->hash_final = 0;
- set_dynamic_sa_command_0(sa, SA_NOT_SAVE_HASH, SA_NOT_SAVE_IV,
+ set_dynamic_sa_command_0(sa, SA_NOT_SAVE_HASH, (cm == CRYPTO_MODE_CBC ?
+ SA_SAVE_IV : SA_NOT_SAVE_IV),
SA_LOAD_HASH_FROM_SA, SA_LOAD_IV_FROM_STATE,
SA_NO_HEADER_PROC, SA_HASH_ALG_NULL,
SA_CIPHER_ALG_AES, SA_PAD_TYPE_ZERO,
diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c
index 78d0722feacb..1e810f5f03fa 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -645,6 +645,15 @@ static u32 crypto4xx_ablkcipher_done(struct crypto4xx_device *dev,
addr = dma_map_page(dev->core_dev->device, sg_page(dst),
dst->offset, dst->length, DMA_FROM_DEVICE);
}
+
+ if (pd_uinfo->sa_va->sa_command_0.bf.save_iv == SA_SAVE_IV) {
+ struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
+
+ crypto4xx_memcpy_from_le32((u32 *)req->iv,
+ pd_uinfo->sr_va->save_iv,
+ crypto_skcipher_ivsize(skcipher));
+ }
+
crypto4xx_ret_sg_desc(dev, pd_uinfo);
if (ablk_req->base.complete != NULL)
ablk_req->base.complete(&ablk_req->base, 0);
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 145/168] modpost: file2alias: go back to simple devtable lookup
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (143 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 144/168] crypto: crypto4xx - properly set IV after de- and encrypt Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 146/168] modpost: file2alias: check prototype of handler Greg Kroah-Hartman
` (27 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Masahiro Yamada, Mathieu Malaterre,
Nathan Chancellor, Sasha Levin
commit ec91e78d378cc5d4b43805a1227d8e04e5dfa17d upstream.
Commit e49ce14150c6 ("modpost: use linker section to generate table.")
was not so cool as we had expected first; it ended up with ugly section
hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile
on darwin again") came in.
Given a certain degree of unknowledge about the link stage of host
programs, I really want to see simple, stupid table lookup so that
this works in the same way regardless of the underlying executable
format.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Mathieu Malaterre <malat@debian.org>
[nc: Omit rpmsg, sdw, fslmc, tbsvc, and typec as they don't exist here
Add of to avoid backporting two larger patches]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
scripts/mod/file2alias.c | 136 +++++++++++++--------------------------
1 file changed, 45 insertions(+), 91 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 9f5cdd49ff0b..d0b164084225 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -50,46 +50,6 @@ struct devtable {
void *function;
};
-#define ___cat(a,b) a ## b
-#define __cat(a,b) ___cat(a,b)
-
-/* we need some special handling for this host tool running eventually on
- * Darwin. The Mach-O section handling is a bit different than ELF section
- * handling. The differnces in detail are:
- * a) we have segments which have sections
- * b) we need a API call to get the respective section symbols */
-#if defined(__MACH__)
-#include <mach-o/getsect.h>
-
-#define INIT_SECTION(name) do { \
- unsigned long name ## _len; \
- char *__cat(pstart_,name) = getsectdata("__TEXT", \
- #name, &__cat(name,_len)); \
- char *__cat(pstop_,name) = __cat(pstart_,name) + \
- __cat(name, _len); \
- __cat(__start_,name) = (void *)__cat(pstart_,name); \
- __cat(__stop_,name) = (void *)__cat(pstop_,name); \
- } while (0)
-#define SECTION(name) __attribute__((section("__TEXT, " #name)))
-
-struct devtable **__start___devtable, **__stop___devtable;
-#else
-#define INIT_SECTION(name) /* no-op for ELF */
-#define SECTION(name) __attribute__((section(#name)))
-
-/* We construct a table of pointers in an ELF section (pointers generally
- * go unpadded by gcc). ld creates boundary syms for us. */
-extern struct devtable *__start___devtable[], *__stop___devtable[];
-#endif /* __MACH__ */
-
-#if !defined(__used)
-# if __GNUC__ == 3 && __GNUC_MINOR__ < 3
-# define __used __attribute__((__unused__))
-# else
-# define __used __attribute__((__used__))
-# endif
-#endif
-
/* Define a variable f that holds the value of field f of struct devid
* based at address m.
*/
@@ -102,16 +62,6 @@ extern struct devtable *__start___devtable[], *__stop___devtable[];
#define DEF_FIELD_ADDR(m, devid, f) \
typeof(((struct devid *)0)->f) *f = ((m) + OFF_##devid##_##f)
-/* Add a table entry. We test function type matches while we're here. */
-#define ADD_TO_DEVTABLE(device_id, type, function) \
- static struct devtable __cat(devtable,__LINE__) = { \
- device_id + 0*sizeof((function)((const char *)NULL, \
- (void *)NULL, \
- (char *)NULL)), \
- SIZE_##type, (function) }; \
- static struct devtable *SECTION(__devtable) __used \
- __cat(devtable_ptr,__LINE__) = &__cat(devtable,__LINE__)
-
#define ADD(str, sep, cond, field) \
do { \
strcat(str, sep); \
@@ -388,7 +338,6 @@ static int do_hid_entry(const char *filename,
return 1;
}
-ADD_TO_DEVTABLE("hid", hid_device_id, do_hid_entry);
/* Looks like: ieee1394:venNmoNspNverN */
static int do_ieee1394_entry(const char *filename,
@@ -413,7 +362,6 @@ static int do_ieee1394_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("ieee1394", ieee1394_device_id, do_ieee1394_entry);
/* Looks like: pci:vNdNsvNsdNbcNscNiN. */
static int do_pci_entry(const char *filename,
@@ -457,7 +405,6 @@ static int do_pci_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("pci", pci_device_id, do_pci_entry);
/* looks like: "ccw:tNmNdtNdmN" */
static int do_ccw_entry(const char *filename,
@@ -481,7 +428,6 @@ static int do_ccw_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("ccw", ccw_device_id, do_ccw_entry);
/* looks like: "ap:tN" */
static int do_ap_entry(const char *filename,
@@ -492,7 +438,6 @@ static int do_ap_entry(const char *filename,
sprintf(alias, "ap:t%02X*", dev_type);
return 1;
}
-ADD_TO_DEVTABLE("ap", ap_device_id, do_ap_entry);
/* looks like: "css:tN" */
static int do_css_entry(const char *filename,
@@ -503,7 +448,6 @@ static int do_css_entry(const char *filename,
sprintf(alias, "css:t%01X", type);
return 1;
}
-ADD_TO_DEVTABLE("css", css_device_id, do_css_entry);
/* Looks like: "serio:tyNprNidNexN" */
static int do_serio_entry(const char *filename,
@@ -523,7 +467,6 @@ static int do_serio_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("serio", serio_device_id, do_serio_entry);
/* looks like: "acpi:ACPI0003" or "acpi:PNP0C0B" or "acpi:LNXVIDEO" or
* "acpi:bbsspp" (bb=base-class, ss=sub-class, pp=prog-if)
@@ -561,7 +504,6 @@ static int do_acpi_entry(const char *filename,
}
return 1;
}
-ADD_TO_DEVTABLE("acpi", acpi_device_id, do_acpi_entry);
/* looks like: "pnp:dD" */
static void do_pnp_device_entry(void *symval, unsigned long size,
@@ -682,7 +624,6 @@ static int do_pcmcia_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("pcmcia", pcmcia_device_id, do_pcmcia_entry);
static int do_of_entry (const char *filename, void *symval, char *alias)
{
@@ -707,7 +648,6 @@ static int do_of_entry (const char *filename, void *symval, char *alias)
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("of", of_device_id, do_of_entry);
static int do_vio_entry(const char *filename, void *symval,
char *alias)
@@ -727,7 +667,6 @@ static int do_vio_entry(const char *filename, void *symval,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("vio", vio_device_id, do_vio_entry);
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
@@ -800,7 +739,6 @@ static int do_input_entry(const char *filename, void *symval,
do_input(alias, *swbit, 0, INPUT_DEVICE_ID_SW_MAX);
return 1;
}
-ADD_TO_DEVTABLE("input", input_device_id, do_input_entry);
static int do_eisa_entry(const char *filename, void *symval,
char *alias)
@@ -812,7 +750,6 @@ static int do_eisa_entry(const char *filename, void *symval,
strcat(alias, "*");
return 1;
}
-ADD_TO_DEVTABLE("eisa", eisa_device_id, do_eisa_entry);
/* Looks like: parisc:tNhvNrevNsvN */
static int do_parisc_entry(const char *filename, void *symval,
@@ -832,7 +769,6 @@ static int do_parisc_entry(const char *filename, void *symval,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("parisc", parisc_device_id, do_parisc_entry);
/* Looks like: sdio:cNvNdN. */
static int do_sdio_entry(const char *filename,
@@ -849,7 +785,6 @@ static int do_sdio_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("sdio", sdio_device_id, do_sdio_entry);
/* Looks like: ssb:vNidNrevN. */
static int do_ssb_entry(const char *filename,
@@ -866,7 +801,6 @@ static int do_ssb_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("ssb", ssb_device_id, do_ssb_entry);
/* Looks like: bcma:mNidNrevNclN. */
static int do_bcma_entry(const char *filename,
@@ -885,7 +819,6 @@ static int do_bcma_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("bcma", bcma_device_id, do_bcma_entry);
/* Looks like: virtio:dNvN */
static int do_virtio_entry(const char *filename, void *symval,
@@ -901,7 +834,6 @@ static int do_virtio_entry(const char *filename, void *symval,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("virtio", virtio_device_id, do_virtio_entry);
/*
* Looks like: vmbus:guid
@@ -924,7 +856,6 @@ static int do_vmbus_entry(const char *filename, void *symval,
return 1;
}
-ADD_TO_DEVTABLE("vmbus", hv_vmbus_device_id, do_vmbus_entry);
/* Looks like: i2c:S */
static int do_i2c_entry(const char *filename, void *symval,
@@ -935,7 +866,6 @@ static int do_i2c_entry(const char *filename, void *symval,
return 1;
}
-ADD_TO_DEVTABLE("i2c", i2c_device_id, do_i2c_entry);
/* Looks like: spi:S */
static int do_spi_entry(const char *filename, void *symval,
@@ -946,7 +876,6 @@ static int do_spi_entry(const char *filename, void *symval,
return 1;
}
-ADD_TO_DEVTABLE("spi", spi_device_id, do_spi_entry);
static const struct dmifield {
const char *prefix;
@@ -1001,7 +930,6 @@ static int do_dmi_entry(const char *filename, void *symval,
strcat(alias, ":");
return 1;
}
-ADD_TO_DEVTABLE("dmi", dmi_system_id, do_dmi_entry);
static int do_platform_entry(const char *filename,
void *symval, char *alias)
@@ -1010,7 +938,6 @@ static int do_platform_entry(const char *filename,
sprintf(alias, PLATFORM_MODULE_PREFIX "%s", *name);
return 1;
}
-ADD_TO_DEVTABLE("platform", platform_device_id, do_platform_entry);
static int do_mdio_entry(const char *filename,
void *symval, char *alias)
@@ -1035,7 +962,6 @@ static int do_mdio_entry(const char *filename,
return 1;
}
-ADD_TO_DEVTABLE("mdio", mdio_device_id, do_mdio_entry);
/* Looks like: zorro:iN. */
static int do_zorro_entry(const char *filename, void *symval,
@@ -1046,7 +972,6 @@ static int do_zorro_entry(const char *filename, void *symval,
ADD(alias, "i", id != ZORRO_WILDCARD, id);
return 1;
}
-ADD_TO_DEVTABLE("zorro", zorro_device_id, do_zorro_entry);
/* looks like: "pnp:dD" */
static int do_isapnp_entry(const char *filename,
@@ -1062,7 +987,6 @@ static int do_isapnp_entry(const char *filename,
(function >> 12) & 0x0f, (function >> 8) & 0x0f);
return 1;
}
-ADD_TO_DEVTABLE("isapnp", isapnp_device_id, do_isapnp_entry);
/* Looks like: "ipack:fNvNdN". */
static int do_ipack_entry(const char *filename,
@@ -1078,7 +1002,6 @@ static int do_ipack_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("ipack", ipack_device_id, do_ipack_entry);
/*
* Append a match expression for a single masked hex digit.
@@ -1149,7 +1072,6 @@ static int do_amba_entry(const char *filename,
return 1;
}
-ADD_TO_DEVTABLE("amba", amba_id, do_amba_entry);
/*
* looks like: "mipscdmm:tN"
@@ -1165,7 +1087,6 @@ static int do_mips_cdmm_entry(const char *filename,
sprintf(alias, "mipscdmm:t%02X*", type);
return 1;
}
-ADD_TO_DEVTABLE("mipscdmm", mips_cdmm_device_id, do_mips_cdmm_entry);
/* LOOKS like cpu:type:x86,venVVVVfamFFFFmodMMMM:feature:*,FEAT,*
* All fields are numbers. It would be nicer to use strings for vendor
@@ -1190,7 +1111,6 @@ static int do_x86cpu_entry(const char *filename, void *symval,
sprintf(alias + strlen(alias), "%04X*", feature);
return 1;
}
-ADD_TO_DEVTABLE("x86cpu", x86_cpu_id, do_x86cpu_entry);
/* LOOKS like cpu:type:*:feature:*FEAT* */
static int do_cpu_entry(const char *filename, void *symval, char *alias)
@@ -1200,7 +1120,6 @@ static int do_cpu_entry(const char *filename, void *symval, char *alias)
sprintf(alias, "cpu:type:*:feature:*%04X*", feature);
return 1;
}
-ADD_TO_DEVTABLE("cpu", cpu_feature, do_cpu_entry);
/* Looks like: mei:S:uuid:N:* */
static int do_mei_entry(const char *filename, void *symval,
@@ -1219,7 +1138,6 @@ static int do_mei_entry(const char *filename, void *symval,
return 1;
}
-ADD_TO_DEVTABLE("mei", mei_cl_device_id, do_mei_entry);
/* Looks like: rapidio:vNdNavNadN */
static int do_rio_entry(const char *filename,
@@ -1239,7 +1157,6 @@ static int do_rio_entry(const char *filename,
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("rapidio", rio_device_id, do_rio_entry);
/* Looks like: ulpi:vNpN */
static int do_ulpi_entry(const char *filename, void *symval,
@@ -1252,7 +1169,6 @@ static int do_ulpi_entry(const char *filename, void *symval,
return 1;
}
-ADD_TO_DEVTABLE("ulpi", ulpi_device_id, do_ulpi_entry);
/* Looks like: hdaudio:vNrNaN */
static int do_hda_entry(const char *filename, void *symval, char *alias)
@@ -1269,7 +1185,6 @@ static int do_hda_entry(const char *filename, void *symval, char *alias)
add_wildcard(alias);
return 1;
}
-ADD_TO_DEVTABLE("hdaudio", hda_device_id, do_hda_entry);
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
@@ -1302,6 +1217,44 @@ static void do_table(void *symval, unsigned long size,
}
}
+static const struct devtable devtable[] = {
+ {"hid", SIZE_hid_device_id, do_hid_entry},
+ {"ieee1394", SIZE_ieee1394_device_id, do_ieee1394_entry},
+ {"pci", SIZE_pci_device_id, do_pci_entry},
+ {"ccw", SIZE_ccw_device_id, do_ccw_entry},
+ {"ap", SIZE_ap_device_id, do_ap_entry},
+ {"css", SIZE_css_device_id, do_css_entry},
+ {"serio", SIZE_serio_device_id, do_serio_entry},
+ {"acpi", SIZE_acpi_device_id, do_acpi_entry},
+ {"pcmcia", SIZE_pcmcia_device_id, do_pcmcia_entry},
+ {"vio", SIZE_vio_device_id, do_vio_entry},
+ {"input", SIZE_input_device_id, do_input_entry},
+ {"eisa", SIZE_eisa_device_id, do_eisa_entry},
+ {"parisc", SIZE_parisc_device_id, do_parisc_entry},
+ {"sdio", SIZE_sdio_device_id, do_sdio_entry},
+ {"ssb", SIZE_ssb_device_id, do_ssb_entry},
+ {"bcma", SIZE_bcma_device_id, do_bcma_entry},
+ {"virtio", SIZE_virtio_device_id, do_virtio_entry},
+ {"vmbus", SIZE_hv_vmbus_device_id, do_vmbus_entry},
+ {"i2c", SIZE_i2c_device_id, do_i2c_entry},
+ {"spi", SIZE_spi_device_id, do_spi_entry},
+ {"dmi", SIZE_dmi_system_id, do_dmi_entry},
+ {"platform", SIZE_platform_device_id, do_platform_entry},
+ {"mdio", SIZE_mdio_device_id, do_mdio_entry},
+ {"zorro", SIZE_zorro_device_id, do_zorro_entry},
+ {"isapnp", SIZE_isapnp_device_id, do_isapnp_entry},
+ {"ipack", SIZE_ipack_device_id, do_ipack_entry},
+ {"amba", SIZE_amba_id, do_amba_entry},
+ {"mipscdmm", SIZE_mips_cdmm_device_id, do_mips_cdmm_entry},
+ {"x86cpu", SIZE_x86_cpu_id, do_x86cpu_entry},
+ {"cpu", SIZE_cpu_feature, do_cpu_entry},
+ {"mei", SIZE_mei_cl_device_id, do_mei_entry},
+ {"rapidio", SIZE_rio_device_id, do_rio_entry},
+ {"ulpi", SIZE_ulpi_device_id, do_ulpi_entry},
+ {"hdaudio", SIZE_hda_device_id, do_hda_entry},
+ {"of", SIZE_of_device_id, do_of_entry},
+};
+
/* Create MODULE_ALIAS() statements.
* At this time, we cannot write the actual output C source yet,
* so we write into the mod->dev_table_buf buffer. */
@@ -1354,13 +1307,14 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
else if (sym_is(name, namelen, "pnp_card"))
do_pnp_card_entries(symval, sym->st_size, mod);
else {
- struct devtable **p;
- INIT_SECTION(__devtable);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(devtable); i++) {
+ const struct devtable *p = &devtable[i];
- for (p = __start___devtable; p < __stop___devtable; p++) {
- if (sym_is(name, namelen, (*p)->device_id)) {
- do_table(symval, sym->st_size, (*p)->id_size,
- (*p)->device_id, (*p)->function, mod);
+ if (sym_is(name, namelen, p->device_id)) {
+ do_table(symval, sym->st_size, p->id_size,
+ p->device_id, p->function, mod);
break;
}
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 146/168] modpost: file2alias: check prototype of handler
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (144 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 145/168] modpost: file2alias: go back to simple devtable lookup Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 147/168] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete Greg Kroah-Hartman
` (26 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Masahiro Yamada, Mathieu Malaterre,
Nathan Chancellor, Sasha Levin
commit f880eea68fe593342fa6e09be9bb661f3c297aec upstream.
Use specific prototype instead of an opaque pointer so that the
compiler can catch function prototype mismatch.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
scripts/mod/file2alias.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index d0b164084225..4250d3d6f391 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -47,7 +47,7 @@ typedef struct {
struct devtable {
const char *device_id; /* name of table, __mod_<name>__*_device_table. */
unsigned long id_size;
- void *function;
+ int (*do_entry)(const char *filename, void *symval, char *alias);
};
/* Define a variable f that holds the value of field f of struct devid
@@ -1198,12 +1198,11 @@ static bool sym_is(const char *name, unsigned namelen, const char *symbol)
static void do_table(void *symval, unsigned long size,
unsigned long id_size,
const char *device_id,
- void *function,
+ int (*do_entry)(const char *filename, void *symval, char *alias),
struct module *mod)
{
unsigned int i;
char alias[500];
- int (*do_entry)(const char *, void *entry, char *alias) = function;
device_id_check(mod->name, device_id, size, id_size, symval);
/* Leave last one: it's the terminator. */
@@ -1314,7 +1313,7 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
if (sym_is(name, namelen, p->device_id)) {
do_table(symval, sym->st_size, p->id_size,
- p->device_id, p->function, mod);
+ p->device_id, p->do_entry, mod);
break;
}
}
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 147/168] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (145 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 146/168] modpost: file2alias: check prototype of handler Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 148/168] KVM: x86: Dont clear EFER during SMM transitions for 32-bit vCPU Greg Kroah-Hartman
` (25 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jarkko Sakkinen, Stefan Berger,
Jerry Snitselaar, Sasha Levin
commit 442601e87a4769a8daba4976ec3afa5222ca211d upstream
Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.
Cc: stable@vger.kernel.org
Fixes: a2871c62e186 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/tpm/tpm_i2c_atmel.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index dd8f0eb3170a..73f7e0f7e34a 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -65,7 +65,15 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
dev_dbg(&chip->dev,
"%s(buf=%*ph len=%0zx) -> sts=%d\n", __func__,
(int)min_t(size_t, 64, len), buf, len, status);
- return status;
+
+ if (status < 0)
+ return status;
+
+ /* The upper layer does not support incomplete sends. */
+ if (status != len)
+ return -E2BIG;
+
+ return 0;
}
static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 148/168] KVM: x86: Dont clear EFER during SMM transitions for 32-bit vCPU
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (146 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 147/168] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 149/168] iio/gyro/bmg160: Use millidegrees for temperature scale Greg Kroah-Hartman
` (24 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson, Paolo Bonzini
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit 8f4dc2e77cdfaf7e644ef29693fa229db29ee1de upstream.
Neither AMD nor Intel CPUs have an EFER field in the legacy SMRAM save
state area, i.e. don't save/restore EFER across SMM transitions. KVM
somewhat models this, e.g. doesn't clear EFER on entry to SMM if the
guest doesn't support long mode. But during RSM, KVM unconditionally
clears EFER so that it can get back to pure 32-bit mode in order to
start loading CRs with their actual non-SMM values.
Clear EFER only when it will be written when loading the non-SMM state
so as to preserve bits that can theoretically be set on 32-bit vCPUs,
e.g. KVM always emulates EFER_SCE.
And because CR4.PAE is cleared only to play nice with EFER, wrap that
code in the long mode check as well. Note, this may result in a
compiler warning about cr4 being consumed uninitialized. Re-read CR4
even though it's technically unnecessary, as doing so allows for more
readable code and RSM emulation is not a performance critical path.
Fixes: 660a5d517aaab ("KVM: x86: save/load state on SMM switch")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2567,15 +2567,13 @@ static int em_rsm(struct x86_emulate_ctx
* CR0/CR3/CR4/EFER. It's all a bit more complicated if the vCPU
* supports long mode.
*/
- cr4 = ctxt->ops->get_cr(ctxt, 4);
if (emulator_has_longmode(ctxt)) {
struct desc_struct cs_desc;
/* Zero CR4.PCIDE before CR0.PG. */
- if (cr4 & X86_CR4_PCIDE) {
+ cr4 = ctxt->ops->get_cr(ctxt, 4);
+ if (cr4 & X86_CR4_PCIDE)
ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PCIDE);
- cr4 &= ~X86_CR4_PCIDE;
- }
/* A 32-bit code segment is required to clear EFER.LMA. */
memset(&cs_desc, 0, sizeof(cs_desc));
@@ -2589,13 +2587,16 @@ static int em_rsm(struct x86_emulate_ctx
if (cr0 & X86_CR0_PE)
ctxt->ops->set_cr(ctxt, 0, cr0 & ~(X86_CR0_PG | X86_CR0_PE));
- /* Now clear CR4.PAE (which must be done before clearing EFER.LME). */
- if (cr4 & X86_CR4_PAE)
- ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE);
-
- /* And finally go back to 32-bit mode. */
- efer = 0;
- ctxt->ops->set_msr(ctxt, MSR_EFER, efer);
+ if (emulator_has_longmode(ctxt)) {
+ /* Clear CR4.PAE before clearing EFER.LME. */
+ cr4 = ctxt->ops->get_cr(ctxt, 4);
+ if (cr4 & X86_CR4_PAE)
+ ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE);
+
+ /* And finally go back to 32-bit mode. */
+ efer = 0;
+ ctxt->ops->set_msr(ctxt, MSR_EFER, efer);
+ }
smbase = ctxt->ops->get_smbase(ctxt);
if (emulator_has_longmode(ctxt))
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 149/168] iio/gyro/bmg160: Use millidegrees for temperature scale
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (147 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 148/168] KVM: x86: Dont clear EFER during SMM transitions for 32-bit vCPU Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 150/168] iio: ad_sigma_delta: select channel when reading register Greg Kroah-Hartman
` (23 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Looijmans, Stable, Jonathan Cameron
From: Mike Looijmans <mike.looijmans@topic.nl>
commit 40a7198a4a01037003c7ca714f0d048a61e729ac upstream.
Standard unit for temperature is millidegrees Celcius, whereas this driver
was reporting in degrees. Fix the scale factor in the driver.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/gyro/bmg160_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/iio/gyro/bmg160_core.c
+++ b/drivers/iio/gyro/bmg160_core.c
@@ -519,11 +519,10 @@ static int bmg160_read_raw(struct iio_de
} else
return -EINVAL;
case IIO_CHAN_INFO_SCALE:
- *val = 0;
switch (chan->type) {
case IIO_TEMP:
- *val2 = 500000;
- return IIO_VAL_INT_PLUS_MICRO;
+ *val = 500;
+ return IIO_VAL_INT;
case IIO_ANGL_VEL:
{
int i;
@@ -531,6 +530,7 @@ static int bmg160_read_raw(struct iio_de
for (i = 0; i < ARRAY_SIZE(bmg160_scale_table); ++i) {
if (bmg160_scale_table[i].dps_range ==
data->dps_range) {
+ *val = 0;
*val2 = bmg160_scale_table[i].scale;
return IIO_VAL_INT_PLUS_MICRO;
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 150/168] iio: ad_sigma_delta: select channel when reading register
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (148 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 149/168] iio/gyro/bmg160: Use millidegrees for temperature scale Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 151/168] iio: adc: at91: disable adc channel interrupt in timeout case Greg Kroah-Hartman
` (22 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dragos Bogdan, Alexandru Ardelean,
Stable, Jonathan Cameron
From: Dragos Bogdan <dragos.bogdan@analog.com>
commit fccfb9ce70ed4ea7a145f77b86de62e38178517f upstream.
The desired channel has to be selected in order to correctly fill the
buffer with the corresponding data.
The `ad_sd_write_reg()` already does this, but for the
`ad_sd_read_reg_raw()` this was omitted.
Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices")
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/ad_sigma_delta.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/ad_sigma_delta.c
+++ b/drivers/iio/adc/ad_sigma_delta.c
@@ -121,6 +121,7 @@ static int ad_sd_read_reg_raw(struct ad_
if (sigma_delta->info->has_registers) {
data[0] = reg << sigma_delta->info->addr_shift;
data[0] |= sigma_delta->info->read_mask;
+ data[0] |= sigma_delta->comm;
spi_message_add_tail(&t[0], &m);
}
spi_message_add_tail(&t[1], &m);
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 151/168] iio: adc: at91: disable adc channel interrupt in timeout case
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (149 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 150/168] iio: ad_sigma_delta: select channel when reading register Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 152/168] io: accel: kxcjk1013: restore the range after resume Greg Kroah-Hartman
` (21 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Georg Ottinger, Ludovic Desroches,
Stable, Jonathan Cameron
From: Georg Ottinger <g.ottinger@abatec.at>
commit 09c6bdee51183a575bf7546890c8c137a75a2b44 upstream.
Having a brief look at at91_adc_read_raw() it is obvious that in the case
of a timeout the setting of AT91_ADC_CHDR and AT91_ADC_IDR registers is
omitted. If 2 different channels are queried we can end up with a
situation where two interrupts are enabled, but only one interrupt is
cleared in the interrupt handler. Resulting in a interrupt loop and a
system hang.
Signed-off-by: Georg Ottinger <g.ottinger@abatec.at>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/at91_adc.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -702,23 +702,29 @@ static int at91_adc_read_raw(struct iio_
ret = wait_event_interruptible_timeout(st->wq_data_avail,
st->done,
msecs_to_jiffies(1000));
- if (ret == 0)
- ret = -ETIMEDOUT;
- if (ret < 0) {
- mutex_unlock(&st->lock);
- return ret;
- }
-
- *val = st->last_value;
+ /* Disable interrupts, regardless if adc conversion was
+ * successful or not
+ */
at91_adc_writel(st, AT91_ADC_CHDR,
AT91_ADC_CH(chan->channel));
at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel));
- st->last_value = 0;
- st->done = false;
+ if (ret > 0) {
+ /* a valid conversion took place */
+ *val = st->last_value;
+ st->last_value = 0;
+ st->done = false;
+ ret = IIO_VAL_INT;
+ } else if (ret == 0) {
+ /* conversion timeout */
+ dev_err(&idev->dev, "ADC Channel %d timeout.\n",
+ chan->channel);
+ ret = -ETIMEDOUT;
+ }
+
mutex_unlock(&st->lock);
- return IIO_VAL_INT;
+ return ret;
case IIO_CHAN_INFO_SCALE:
*val = st->vref_mv;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 152/168] io: accel: kxcjk1013: restore the range after resume.
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (150 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 151/168] iio: adc: at91: disable adc channel interrupt in timeout case Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 153/168] staging: comedi: vmk80xx: Fix use of uninitialized semaphore Greg Kroah-Hartman
` (20 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, he, bo, Chen, Hu, Hans de Goede,
Stable, Jonathan Cameron
From: he, bo <bo.he@intel.com>
commit fe2d3df639a7940a125a33d6460529b9689c5406 upstream.
On some laptops, kxcjk1013 is powered off when system enters S3. We need
restore the range regiter during resume. Otherwise, the sensor doesn't
work properly after S3.
Signed-off-by: he, bo <bo.he@intel.com>
Signed-off-by: Chen, Hu <hu1.chen@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/accel/kxcjk-1013.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/iio/accel/kxcjk-1013.c
+++ b/drivers/iio/accel/kxcjk-1013.c
@@ -1343,6 +1343,8 @@ static int kxcjk1013_resume(struct devic
mutex_lock(&data->mutex);
ret = kxcjk1013_set_mode(data, OPERATION);
+ if (ret == 0)
+ ret = kxcjk1013_set_range(data, data->range);
mutex_unlock(&data->mutex);
return ret;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 153/168] staging: comedi: vmk80xx: Fix use of uninitialized semaphore
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (151 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 152/168] io: accel: kxcjk1013: restore the range after resume Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 154/168] staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf Greg Kroah-Hartman
` (19 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+54c2f58f15fe6876b6ad, Ian Abbott
From: Ian Abbott <abbotti@mev.co.uk>
commit 08b7c2f9208f0e2a32159e4e7a4831b7adb10a3e upstream.
If `vmk80xx_auto_attach()` returns an error, the core comedi module code
will call `vmk80xx_detach()` to clean up. If `vmk80xx_auto_attach()`
successfully allocated the comedi device private data,
`vmk80xx_detach()` assumes that a `struct semaphore limit_sem` contained
in the private data has been initialized and uses it. Unfortunately,
there are a couple of places where `vmk80xx_auto_attach()` can return an
error after allocating the device private data but before initializing
the semaphore, so this assumption is invalid. Fix it by initializing
the semaphore just after allocating the private data in
`vmk80xx_auto_attach()` before any other errors can be returned.
I believe this was the cause of the following syzbot crash report
<https://syzkaller.appspot.com/bug?extid=54c2f58f15fe6876b6ad>:
usb 1-1: config 0 has no interface number 0
usb 1-1: New USB device found, idVendor=10cf, idProduct=8068, bcdDevice=e6.8d
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
vmk80xx 1-1:0.117: driver 'vmk80xx' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe8/0x16e lib/dump_stack.c:113
assign_lock_key kernel/locking/lockdep.c:786 [inline]
register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
__lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
down+0x12/0x80 kernel/locking/semaphore.c:58
vmk80xx_detach+0x59/0x100 drivers/staging/comedi/drivers/vmk80xx.c:829
comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Reported-by: syzbot+54c2f58f15fe6876b6ad@syzkaller.appspotmail.com
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/comedi/drivers/vmk80xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -809,6 +809,8 @@ static int vmk80xx_auto_attach(struct co
devpriv->model = board->model;
+ sema_init(&devpriv->limit_sem, 8);
+
ret = vmk80xx_find_usb_endpoints(dev);
if (ret)
return ret;
@@ -817,8 +819,6 @@ static int vmk80xx_auto_attach(struct co
if (ret)
return ret;
- sema_init(&devpriv->limit_sem, 8);
-
usb_set_intfdata(intf, devpriv);
if (devpriv->model == VMK8055_MODEL)
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 154/168] staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (152 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 153/168] staging: comedi: vmk80xx: Fix use of uninitialized semaphore Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:09 ` [PATCH 4.4 155/168] staging: comedi: ni_usb6501: Fix use of uninitialized mutex Greg Kroah-Hartman
` (18 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ian Abbott
From: Ian Abbott <abbotti@mev.co.uk>
commit 663d294b4768bfd89e529e069bffa544a830b5bf upstream.
`vmk80xx_alloc_usb_buffers()` is called from `vmk80xx_auto_attach()` to
allocate RX and TX buffers for USB transfers. It allocates
`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`. If the
allocation of `devpriv->usb_tx_buf` fails, it frees
`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
error. Later, `vmk80xx_detach()` will be called from the core comedi
module code to clean up. `vmk80xx_detach()` also frees both
`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
`devpriv->usb_rx_buf` may have already been freed, leading to a
double-free error. Fix it by removing the call to
`kfree(devpriv->usb_rx_buf)` from `vmk80xx_alloc_usb_buffers()`, relying
on `vmk80xx_detach()` to free the memory.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/comedi/drivers/vmk80xx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -691,10 +691,8 @@ static int vmk80xx_alloc_usb_buffers(str
size = le16_to_cpu(devpriv->ep_tx->wMaxPacketSize);
devpriv->usb_tx_buf = kzalloc(size, GFP_KERNEL);
- if (!devpriv->usb_tx_buf) {
- kfree(devpriv->usb_rx_buf);
+ if (!devpriv->usb_tx_buf)
return -ENOMEM;
- }
return 0;
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 155/168] staging: comedi: ni_usb6501: Fix use of uninitialized mutex
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (153 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 154/168] staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf Greg Kroah-Hartman
@ 2019-04-24 17:09 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 156/168] staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf Greg Kroah-Hartman
` (17 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+cf4f2b6c24aff0a3edf6, Ian Abbott
From: Ian Abbott <abbotti@mev.co.uk>
commit 660cf4ce9d0f3497cc7456eaa6d74c8b71d6282c upstream.
If `ni6501_auto_attach()` returns an error, the core comedi module code
will call `ni6501_detach()` to clean up. If `ni6501_auto_attach()`
successfully allocated the comedi device private data, `ni6501_detach()`
assumes that a `struct mutex mut` contained in the private data has been
initialized and uses it. Unfortunately, there are a couple of places
where `ni6501_auto_attach()` can return an error after allocating the
device private data but before initializing the mutex, so this
assumption is invalid. Fix it by initializing the mutex just after
allocating the private data in `ni6501_auto_attach()` before any other
errors can be retturned. Also move the call to `usb_set_intfdata()`
just to keep the code a bit neater (either position for the call is
fine).
I believe this was the cause of the following syzbot crash report
<https://syzkaller.appspot.com/bug?extid=cf4f2b6c24aff0a3edf6>:
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: string descriptor 0 read error: -71
comedi comedi0: Wrong number of endpoints
ni6501 1-1:0.233: driver 'ni6501' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 585 Comm: kworker/0:3 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe8/0x16e lib/dump_stack.c:113
assign_lock_key kernel/locking/lockdep.c:786 [inline]
register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
__lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0xfe/0x12b0 kernel/locking/mutex.c:1072
ni6501_detach+0x5b/0x110 drivers/staging/comedi/drivers/ni_usb6501.c:567
comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Reported-by: syzbot+cf4f2b6c24aff0a3edf6@syzkaller.appspotmail.com
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/comedi/drivers/ni_usb6501.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/staging/comedi/drivers/ni_usb6501.c
+++ b/drivers/staging/comedi/drivers/ni_usb6501.c
@@ -527,6 +527,9 @@ static int ni6501_auto_attach(struct com
if (!devpriv)
return -ENOMEM;
+ mutex_init(&devpriv->mut);
+ usb_set_intfdata(intf, devpriv);
+
ret = ni6501_find_endpoints(dev);
if (ret)
return ret;
@@ -535,9 +538,6 @@ static int ni6501_auto_attach(struct com
if (ret)
return ret;
- mutex_init(&devpriv->mut);
- usb_set_intfdata(intf, devpriv);
-
ret = comedi_alloc_subdevices(dev, 2);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 156/168] staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (154 preceding siblings ...)
2019-04-24 17:09 ` [PATCH 4.4 155/168] staging: comedi: ni_usb6501: Fix use of uninitialized mutex Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 157/168] ALSA: core: Fix card races between register and disconnect Greg Kroah-Hartman
` (16 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ian Abbott
From: Ian Abbott <abbotti@mev.co.uk>
commit af4b54a2e5ba18259ff9aac445bf546dd60d037e upstream.
`ni6501_alloc_usb_buffers()` is called from `ni6501_auto_attach()` to
allocate RX and TX buffers for USB transfers. It allocates
`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`. If the
allocation of `devpriv->usb_tx_buf` fails, it frees
`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
error. Later, `ni6501_detach()` will be called from the core comedi
module code to clean up. `ni6501_detach()` also frees both
`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
`devpriv->usb_rx_buf` may have already beed freed, leading to a
double-free error. Fix it bu removing the call to
`kfree(devpriv->usb_rx_buf)` from `ni6501_alloc_usb_buffers()`, relying
on `ni6501_detach()` to free the memory.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/comedi/drivers/ni_usb6501.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/staging/comedi/drivers/ni_usb6501.c
+++ b/drivers/staging/comedi/drivers/ni_usb6501.c
@@ -472,10 +472,8 @@ static int ni6501_alloc_usb_buffers(stru
size = le16_to_cpu(devpriv->ep_tx->wMaxPacketSize);
devpriv->usb_tx_buf = kzalloc(size, GFP_KERNEL);
- if (!devpriv->usb_tx_buf) {
- kfree(devpriv->usb_rx_buf);
+ if (!devpriv->usb_tx_buf)
return -ENOMEM;
- }
return 0;
}
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 157/168] ALSA: core: Fix card races between register and disconnect
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (155 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 156/168] staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 158/168] crypto: x86/poly1305 - fix overflow during partial reduction Greg Kroah-Hartman
` (15 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+48df349490c36f9f54ab, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac upstream.
There is a small race window in the card disconnection code that
allows the registration of another card with the very same card id.
This leads to a warning in procfs creation as caught by syzkaller.
The problem is that we delete snd_cards and snd_cards_lock entries at
the very beginning of the disconnection procedure. This makes the
slot available to be assigned for another card object while the
disconnection procedure is being processed. Then it becomes possible
to issue a procfs registration with the existing file name although we
check the conflict beforehand.
The fix is simply to move the snd_cards and snd_cards_lock clearances
at the end of the disconnection procedure. The references to these
entries are merely either from the global proc files like
/proc/asound/cards or from the card registration / disconnection, so
it should be fine to shift at the very end.
Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/init.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/sound/core/init.c
+++ b/sound/core/init.c
@@ -405,14 +405,7 @@ int snd_card_disconnect(struct snd_card
card->shutdown = 1;
spin_unlock(&card->files_lock);
- /* phase 1: disable fops (user space) operations for ALSA API */
- mutex_lock(&snd_card_mutex);
- snd_cards[card->number] = NULL;
- clear_bit(card->number, snd_cards_lock);
- mutex_unlock(&snd_card_mutex);
-
- /* phase 2: replace file->f_op with special dummy operations */
-
+ /* replace file->f_op with special dummy operations */
spin_lock(&card->files_lock);
list_for_each_entry(mfile, &card->files_list, list) {
/* it's critical part, use endless loop */
@@ -428,7 +421,7 @@ int snd_card_disconnect(struct snd_card
}
spin_unlock(&card->files_lock);
- /* phase 3: notify all connected devices about disconnection */
+ /* notify all connected devices about disconnection */
/* at this point, they cannot respond to any calls except release() */
#if IS_ENABLED(CONFIG_SND_MIXER_OSS)
@@ -444,6 +437,13 @@ int snd_card_disconnect(struct snd_card
device_del(&card->card_dev);
card->registered = false;
}
+
+ /* disable fops (user space) operations for ALSA API */
+ mutex_lock(&snd_card_mutex);
+ snd_cards[card->number] = NULL;
+ clear_bit(card->number, snd_cards_lock);
+ mutex_unlock(&snd_card_mutex);
+
#ifdef CONFIG_PM
wake_up(&card->power_sleep);
#endif
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 158/168] crypto: x86/poly1305 - fix overflow during partial reduction
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (156 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 157/168] ALSA: core: Fix card races between register and disconnect Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 159/168] arm64: futex: Restore oldval initialization to work around buggy compilers Greg Kroah-Hartman
` (14 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Martin Willi, Jason A. Donenfeld,
Eric Biggers, Herbert Xu
From: Eric Biggers <ebiggers@google.com>
commit 678cce4019d746da6c680c48ba9e6d417803e127 upstream.
The x86_64 implementation of Poly1305 produces the wrong result on some
inputs because poly1305_4block_avx2() incorrectly assumes that when
partially reducing the accumulator, the bits carried from limb 'd4' to
limb 'h0' fit in a 32-bit integer. This is true for poly1305-generic
which processes only one block at a time. However, it's not true for
the AVX2 implementation, which processes 4 blocks at a time and
therefore can produce intermediate limbs about 4x larger.
Fix it by making the relevant calculations use 64-bit arithmetic rather
than 32-bit. Note that most of the carries already used 64-bit
arithmetic, but the d4 -> h0 carry was different for some reason.
To be safe I also made the same change to the corresponding SSE2 code,
though that only operates on 1 or 2 blocks at a time. I don't think
it's really needed for poly1305_block_sse2(), but it doesn't hurt
because it's already x86_64 code. It *might* be needed for
poly1305_2block_sse2(), but overflows aren't easy to reproduce there.
This bug was originally detected by my patches that improve testmgr to
fuzz algorithms against their generic implementation. But also add a
test vector which reproduces it directly (in the AVX2 case).
Fixes: b1ccc8f4b631 ("crypto: poly1305 - Add a four block AVX2 variant for x86_64")
Fixes: c70f4abef07a ("crypto: poly1305 - Add a SSE2 SIMD variant for x86_64")
Cc: <stable@vger.kernel.org> # v4.3+
Cc: Martin Willi <martin@strongswan.org>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Martin Willi <martin@strongswan.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/crypto/poly1305-avx2-x86_64.S | 14 +++++++---
arch/x86/crypto/poly1305-sse2-x86_64.S | 22 ++++++++++------
crypto/testmgr.h | 44 ++++++++++++++++++++++++++++++++-
3 files changed, 67 insertions(+), 13 deletions(-)
--- a/arch/x86/crypto/poly1305-avx2-x86_64.S
+++ b/arch/x86/crypto/poly1305-avx2-x86_64.S
@@ -321,6 +321,12 @@ ENTRY(poly1305_4block_avx2)
vpaddq t2,t1,t1
vmovq t1x,d4
+ # Now do a partial reduction mod (2^130)-5, carrying h0 -> h1 -> h2 ->
+ # h3 -> h4 -> h0 -> h1 to get h0,h2,h3,h4 < 2^26 and h1 < 2^26 + a small
+ # amount. Careful: we must not assume the carry bits 'd0 >> 26',
+ # 'd1 >> 26', 'd2 >> 26', 'd3 >> 26', and '(d4 >> 26) * 5' fit in 32-bit
+ # integers. It's true in a single-block implementation, but not here.
+
# d1 += d0 >> 26
mov d0,%rax
shr $26,%rax
@@ -359,16 +365,16 @@ ENTRY(poly1305_4block_avx2)
# h0 += (d4 >> 26) * 5
mov d4,%rax
shr $26,%rax
- lea (%eax,%eax,4),%eax
- add %eax,%ebx
+ lea (%rax,%rax,4),%rax
+ add %rax,%rbx
# h4 = d4 & 0x3ffffff
mov d4,%rax
and $0x3ffffff,%eax
mov %eax,h4
# h1 += h0 >> 26
- mov %ebx,%eax
- shr $26,%eax
+ mov %rbx,%rax
+ shr $26,%rax
add %eax,h1
# h0 = h0 & 0x3ffffff
andl $0x3ffffff,%ebx
--- a/arch/x86/crypto/poly1305-sse2-x86_64.S
+++ b/arch/x86/crypto/poly1305-sse2-x86_64.S
@@ -251,16 +251,16 @@ ENTRY(poly1305_block_sse2)
# h0 += (d4 >> 26) * 5
mov d4,%rax
shr $26,%rax
- lea (%eax,%eax,4),%eax
- add %eax,%ebx
+ lea (%rax,%rax,4),%rax
+ add %rax,%rbx
# h4 = d4 & 0x3ffffff
mov d4,%rax
and $0x3ffffff,%eax
mov %eax,h4
# h1 += h0 >> 26
- mov %ebx,%eax
- shr $26,%eax
+ mov %rbx,%rax
+ shr $26,%rax
add %eax,h1
# h0 = h0 & 0x3ffffff
andl $0x3ffffff,%ebx
@@ -518,6 +518,12 @@ ENTRY(poly1305_2block_sse2)
paddq t2,t1
movq t1,d4
+ # Now do a partial reduction mod (2^130)-5, carrying h0 -> h1 -> h2 ->
+ # h3 -> h4 -> h0 -> h1 to get h0,h2,h3,h4 < 2^26 and h1 < 2^26 + a small
+ # amount. Careful: we must not assume the carry bits 'd0 >> 26',
+ # 'd1 >> 26', 'd2 >> 26', 'd3 >> 26', and '(d4 >> 26) * 5' fit in 32-bit
+ # integers. It's true in a single-block implementation, but not here.
+
# d1 += d0 >> 26
mov d0,%rax
shr $26,%rax
@@ -556,16 +562,16 @@ ENTRY(poly1305_2block_sse2)
# h0 += (d4 >> 26) * 5
mov d4,%rax
shr $26,%rax
- lea (%eax,%eax,4),%eax
- add %eax,%ebx
+ lea (%rax,%rax,4),%rax
+ add %rax,%rbx
# h4 = d4 & 0x3ffffff
mov d4,%rax
and $0x3ffffff,%eax
mov %eax,h4
# h1 += h0 >> 26
- mov %ebx,%eax
- shr $26,%eax
+ mov %rbx,%rax
+ shr $26,%rax
add %eax,h1
# h0 = h0 & 0x3ffffff
andl $0x3ffffff,%ebx
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -3494,7 +3494,49 @@ static struct hash_testvec poly1305_tv_t
.psize = 80,
.digest = "\x13\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00",
- },
+ }, { /* Regression test for overflow in AVX2 implementation */
+ .plaintext = "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff",
+ .psize = 300,
+ .digest = "\xfb\x5e\x96\xd8\x61\xd5\xc7\xc8"
+ "\x78\xe5\x87\xcc\x2d\x5a\x22\xe1",
+ }
};
/*
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 159/168] arm64: futex: Restore oldval initialization to work around buggy compilers
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (157 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 158/168] crypto: x86/poly1305 - fix overflow during partial reduction Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 160/168] x86/kprobes: Verify stack frame on kretprobe Greg Kroah-Hartman
` (13 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nathan Chancellor, Catalin Marinas
From: Nathan Chancellor <natechancellor@gmail.com>
commit ff8acf929014b7f87315588e0daf8597c8aa9d1c upstream.
Commit 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with
non-zero result value") removed oldval's zero initialization in
arch_futex_atomic_op_inuser because it is not necessary. Unfortunately,
Android's arm64 GCC 4.9.4 [1] does not agree:
../kernel/futex.c: In function 'do_futex':
../kernel/futex.c:1658:17: warning: 'oldval' may be used uninitialized
in this function [-Wmaybe-uninitialized]
return oldval == cmparg;
^
In file included from ../kernel/futex.c:73:0:
../arch/arm64/include/asm/futex.h:53:6: note: 'oldval' was declared here
int oldval, ret, tmp;
^
GCC fails to follow that when ret is non-zero, futex_atomic_op_inuser
returns right away, avoiding the uninitialized use that it claims.
Restoring the zero initialization works around this issue.
[1]: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
Cc: stable@vger.kernel.org
Fixes: 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/futex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -55,7 +55,7 @@
static inline int
arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
{
- int oldval, ret, tmp;
+ int oldval = 0, ret, tmp;
pagefault_disable();
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 160/168] x86/kprobes: Verify stack frame on kretprobe
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (158 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 159/168] arm64: futex: Restore oldval initialization to work around buggy compilers Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 161/168] kprobes: Mark ftrace mcount handler functions nokprobe Greg Kroah-Hartman
` (12 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrea Righi, Masami Hiramatsu,
Steven Rostedt, Linus Torvalds, Mathieu Desnoyers,
Peter Zijlstra, Thomas Gleixner, Ingo Molnar
From: Masami Hiramatsu <mhiramat@kernel.org>
commit 3ff9c075cc767b3060bdac12da72fc94dd7da1b8 upstream.
Verify the stack frame pointer on kretprobe trampoline handler,
If the stack frame pointer does not match, it skips the wrong
entry and tries to find correct one.
This can happen if user puts the kretprobe on the function
which can be used in the path of ftrace user-function call.
Such functions should not be probed, so this adds a warning
message that reports which function should be blacklisted.
Tested-by: Andrea Righi <righi.andrea@gmail.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/155094059185.6137.15527904013362842072.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 26 ++++++++++++++++++++++++++
include/linux/kprobes.h | 1 +
2 files changed, 27 insertions(+)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -541,6 +541,7 @@ void arch_prepare_kretprobe(struct kretp
unsigned long *sara = stack_addr(regs);
ri->ret_addr = (kprobe_opcode_t *) *sara;
+ ri->fp = sara;
/* Replace the return addr with trampoline addr */
*sara = (unsigned long) &kretprobe_trampoline;
@@ -742,15 +743,21 @@ __visible __used void *trampoline_handle
unsigned long flags, orig_ret_address = 0;
unsigned long trampoline_address = (unsigned long)&kretprobe_trampoline;
kprobe_opcode_t *correct_ret_addr = NULL;
+ void *frame_pointer;
+ bool skipped = false;
INIT_HLIST_HEAD(&empty_rp);
kretprobe_hash_lock(current, &head, &flags);
/* fixup registers */
#ifdef CONFIG_X86_64
regs->cs = __KERNEL_CS;
+ /* On x86-64, we use pt_regs->sp for return address holder. */
+ frame_pointer = ®s->sp;
#else
regs->cs = __KERNEL_CS | get_kernel_rpl();
regs->gs = 0;
+ /* On x86-32, we use pt_regs->flags for return address holder. */
+ frame_pointer = ®s->flags;
#endif
regs->ip = trampoline_address;
regs->orig_ax = ~0UL;
@@ -772,8 +779,25 @@ __visible __used void *trampoline_handle
if (ri->task != current)
/* another task is sharing our hash bucket */
continue;
+ /*
+ * Return probes must be pushed on this hash list correct
+ * order (same as return order) so that it can be poped
+ * correctly. However, if we find it is pushed it incorrect
+ * order, this means we find a function which should not be
+ * probed, because the wrong order entry is pushed on the
+ * path of processing other kretprobe itself.
+ */
+ if (ri->fp != frame_pointer) {
+ if (!skipped)
+ pr_warn("kretprobe is stacked incorrectly. Trying to fixup.\n");
+ skipped = true;
+ continue;
+ }
orig_ret_address = (unsigned long)ri->ret_addr;
+ if (skipped)
+ pr_warn("%ps must be blacklisted because of incorrect kretprobe order\n",
+ ri->rp->kp.addr);
if (orig_ret_address != trampoline_address)
/*
@@ -791,6 +815,8 @@ __visible __used void *trampoline_handle
if (ri->task != current)
/* another task is sharing our hash bucket */
continue;
+ if (ri->fp != frame_pointer)
+ continue;
orig_ret_address = (unsigned long)ri->ret_addr;
if (ri->rp && ri->rp->handler) {
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -197,6 +197,7 @@ struct kretprobe_instance {
struct kretprobe *rp;
kprobe_opcode_t *ret_addr;
struct task_struct *task;
+ void *fp;
char data[0];
};
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 161/168] kprobes: Mark ftrace mcount handler functions nokprobe
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (159 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 160/168] x86/kprobes: Verify stack frame on kretprobe Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 162/168] kprobes: Fix error check when reusing optimized probes Greg Kroah-Hartman
` (11 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Francis Deslauriers, Andrea Righi,
Masami Hiramatsu, Steven Rostedt, Linus Torvalds,
Mathieu Desnoyers, Peter Zijlstra, Thomas Gleixner, Ingo Molnar
From: Masami Hiramatsu <mhiramat@kernel.org>
commit fabe38ab6b2bd9418350284c63825f13b8a6abba upstream.
Mark ftrace mcount handler functions nokprobe since
probing on these functions with kretprobe pushes
return address incorrectly on kretprobe shadow stack.
Reported-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: Andrea Righi <righi.andrea@gmail.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/155094062044.6137.6419622920568680640.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/ftrace.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -32,6 +32,7 @@
#include <linux/list.h>
#include <linux/hash.h>
#include <linux/rcupdate.h>
+#include <linux/kprobes.h>
#include <trace/events/sched.h>
@@ -5165,7 +5166,7 @@ static struct ftrace_ops control_ops = {
INIT_OPS_HASH(control_ops)
};
-static inline void
+static nokprobe_inline void
__ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ignored, struct pt_regs *regs)
{
@@ -5214,11 +5215,13 @@ static void ftrace_ops_list_func(unsigne
{
__ftrace_ops_list_func(ip, parent_ip, NULL, regs);
}
+NOKPROBE_SYMBOL(ftrace_ops_list_func);
#else
static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip)
{
__ftrace_ops_list_func(ip, parent_ip, NULL, NULL);
}
+NOKPROBE_SYMBOL(ftrace_ops_no_ops);
#endif
/*
@@ -5239,6 +5242,7 @@ static void ftrace_ops_recurs_func(unsig
trace_clear_recursion(bit);
}
+NOKPROBE_SYMBOL(ftrace_ops_recurs_func);
/**
* ftrace_ops_get_func - get the function a trampoline should call
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 162/168] kprobes: Fix error check when reusing optimized probes
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (160 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 161/168] kprobes: Mark ftrace mcount handler functions nokprobe Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 163/168] mac80211: do not call driver wake_tx_queue op during reconfig Greg Kroah-Hartman
` (10 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Masami Hiramatsu,
Anil S Keshavamurthy, David S . Miller, Linus Torvalds,
Naveen N . Rao, Peter Zijlstra, Thomas Gleixner, Ingo Molnar
From: Masami Hiramatsu <mhiramat@kernel.org>
commit 5f843ed415581cfad4ef8fefe31c138a8346ca8a upstream.
The following commit introduced a bug in one of our error paths:
819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()")
it missed to handle the return value of kprobe_optready() as
error-value. In reality, the kprobe_optready() returns a bool
result, so "true" case must be passed instead of 0.
This causes some errors on kprobe boot-time selftests on ARM:
[ ] Beginning kprobe tests...
[ ] Probe ARM code
[ ] kprobe
[ ] kretprobe
[ ] ARM instruction simulation
[ ] Check decoding tables
[ ] Run test cases
[ ] FAIL: test_case_handler not run
[ ] FAIL: Test andge r10, r11, r14, asr r7
[ ] FAIL: Scenario 11
...
[ ] FAIL: Scenario 7
[ ] Total instruction simulation tests=1631, pass=1433 fail=198
[ ] kprobe tests failed
This can happen if an optimized probe is unregistered and next
kprobe is registered on same address until the previous probe
is not reclaimed.
If this happens, a hidden aggregated probe may be kept in memory,
and no new kprobe can probe same address. Also, in that case
register_kprobe() will return "1" instead of minus error value,
which can mislead caller logic.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: David S . Miller <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # v5.0+
Fixes: 819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()")
Link: http://lkml.kernel.org/r/155530808559.32517.539898325433642204.stgit@devnote2
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/kprobes.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -668,7 +668,6 @@ static void unoptimize_kprobe(struct kpr
static int reuse_unused_kprobe(struct kprobe *ap)
{
struct optimized_kprobe *op;
- int ret;
BUG_ON(!kprobe_unused(ap));
/*
@@ -682,9 +681,8 @@ static int reuse_unused_kprobe(struct kp
/* Enable the probe again */
ap->flags &= ~KPROBE_FLAG_DISABLED;
/* Optimize it again (remove from op->list) */
- ret = kprobe_optready(ap);
- if (ret)
- return ret;
+ if (!kprobe_optready(ap))
+ return -EINVAL;
optimize_kprobe(ap);
return 0;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 163/168] mac80211: do not call driver wake_tx_queue op during reconfig
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (161 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 162/168] kprobes: Fix error check when reusing optimized probes Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 164/168] Revert "kbuild: use -Oz instead of -Os when using clang" Greg Kroah-Hartman
` (9 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Felix Fietkau, Johannes Berg
From: Felix Fietkau <nbd@nbd.name>
commit 4856bfd230985e43e84c26473c91028ff0a533bd upstream.
There are several scenarios in which mac80211 can call drv_wake_tx_queue
after ieee80211_restart_hw has been called and has not yet completed.
Driver private structs are considered uninitialized until mac80211 has
uploaded the vifs, stations and keys again, so using private tx queue
data during that time is not safe.
The driver can also not rely on drv_reconfig_complete to figure out when
it is safe to accept drv_wake_tx_queue calls again, because it is only
called after all tx queues are woken again.
To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
is set.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/driver-ops.h | 3 +++
1 file changed, 3 insertions(+)
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1157,6 +1157,9 @@ static inline void drv_wake_tx_queue(str
{
struct ieee80211_sub_if_data *sdata = vif_to_sdata(txq->txq.vif);
+ if (local->in_reconfig)
+ return;
+
if (!check_sdata_in_driver(sdata))
return;
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 164/168] Revert "kbuild: use -Oz instead of -Os when using clang"
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (162 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 163/168] mac80211: do not call driver wake_tx_queue op during reconfig Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 165/168] sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup Greg Kroah-Hartman
` (8 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Zijlstra, Matthias Kaehlcke,
Nick Desaulniers, Masahiro Yamada, Nathan Chancellor,
Sasha Levin
commit a75bb4eb9e565b9f5115e2e8c07377ce32cbe69a upstream.
The clang option -Oz enables *aggressive* optimization for size,
which doesn't necessarily result in smaller images, but can have
negative impact on performance. Switch back to the less aggressive
-Os.
This reverts commit 6748cb3c299de1ffbe56733647b01dbcc398c419.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 7bf3fb717921..cc621fbe6c62 100644
--- a/Makefile
+++ b/Makefile
@@ -639,7 +639,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
KBUILD_CFLAGS += $(call cc-disable-warning, attribute-alias)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS += $(call cc-option,-Oz,-Os)
+KBUILD_CFLAGS += -Os
else
ifdef CONFIG_PROFILE_ALL_BRANCHES
KBUILD_CFLAGS += -O2
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 165/168] sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (163 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 164/168] Revert "kbuild: use -Oz instead of -Os when using clang" Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 166/168] device_cgroup: fix RCU imbalance in error case Greg Kroah-Hartman
` (7 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Phil Auld, Peter Zijlstra (Intel),
Anton Blanchard, Ben Segall, Linus Torvalds, Thomas Gleixner,
Ingo Molnar, Sasha Levin
[ Upstream commit 2e8e19226398db8265a8e675fcc0118b9e80c9e8 ]
With extremely short cfs_period_us setting on a parent task group with a large
number of children the for loop in sched_cfs_period_timer() can run until the
watchdog fires. There is no guarantee that the call to hrtimer_forward_now()
will ever return 0. The large number of children can make
do_sched_cfs_period_timer() take longer than the period.
NMI watchdog: Watchdog detected hard LOCKUP on cpu 24
RIP: 0010:tg_nop+0x0/0x10
<IRQ>
walk_tg_tree_from+0x29/0xb0
unthrottle_cfs_rq+0xe0/0x1a0
distribute_cfs_runtime+0xd3/0xf0
sched_cfs_period_timer+0xcb/0x160
? sched_cfs_slack_timer+0xd0/0xd0
__hrtimer_run_queues+0xfb/0x270
hrtimer_interrupt+0x122/0x270
smp_apic_timer_interrupt+0x6a/0x140
apic_timer_interrupt+0xf/0x20
</IRQ>
To prevent this we add protection to the loop that detects when the loop has run
too many times and scales the period and quota up, proportionally, so that the timer
can complete before then next period expires. This preserves the relative runtime
quota while preventing the hard lockup.
A warning is issued reporting this state and the new values.
Signed-off-by: Phil Auld <pauld@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Anton Blanchard <anton@ozlabs.org>
Cc: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190319130005.25492-1-pauld@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/sched/fair.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7671ae95753f..d706cf4fda99 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4016,12 +4016,15 @@ static enum hrtimer_restart sched_cfs_slack_timer(struct hrtimer *timer)
return HRTIMER_NORESTART;
}
+extern const u64 max_cfs_quota_period;
+
static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
{
struct cfs_bandwidth *cfs_b =
container_of(timer, struct cfs_bandwidth, period_timer);
int overrun;
int idle = 0;
+ int count = 0;
raw_spin_lock(&cfs_b->lock);
for (;;) {
@@ -4029,6 +4032,28 @@ static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
if (!overrun)
break;
+ if (++count > 3) {
+ u64 new, old = ktime_to_ns(cfs_b->period);
+
+ new = (old * 147) / 128; /* ~115% */
+ new = min(new, max_cfs_quota_period);
+
+ cfs_b->period = ns_to_ktime(new);
+
+ /* since max is 1s, this is limited to 1e9^2, which fits in u64 */
+ cfs_b->quota *= new;
+ cfs_b->quota = div64_u64(cfs_b->quota, old);
+
+ pr_warn_ratelimited(
+ "cfs_period_timer[cpu%d]: period too short, scaling up (new cfs_period_us %lld, cfs_quota_us = %lld)\n",
+ smp_processor_id(),
+ div_u64(new, NSEC_PER_USEC),
+ div_u64(cfs_b->quota, NSEC_PER_USEC));
+
+ /* reset count so we don't come right back in here */
+ count = 0;
+ }
+
idle = do_sched_cfs_period_timer(cfs_b, overrun);
}
if (idle)
--
2.19.1
^ permalink raw reply related [flat|nested] 178+ messages in thread* [PATCH 4.4 166/168] device_cgroup: fix RCU imbalance in error case
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (164 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 165/168] sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 167/168] mm/vmstat.c: fix /proc/vmstat format for CONFIG_DEBUG_TLBFLUSH=y CONFIG_SMP=n Greg Kroah-Hartman
` (6 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jann Horn, Michal Hocko, Tejun Heo
From: Jann Horn <jannh@google.com>
commit 0fcc4c8c044e117ac126ab6df4138ea9a67fa2a9 upstream.
When dev_exception_add() returns an error (due to a failed memory
allocation), make sure that we move the RCU preemption count back to where
it was before we were called. We dropped the RCU read lock inside the loop
body, so we can't just "break".
sparse complains about this, too:
$ make -s C=2 security/device_cgroup.o
./include/linux/rcupdate.h:647:9: warning: context imbalance in
'propagate_exception' - unexpected unlock
Fixes: d591fb56618f ("device_cgroup: simplify cgroup tree walk in propagate_exception()")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/device_cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -568,7 +568,7 @@ static int propagate_exception(struct de
devcg->behavior == DEVCG_DEFAULT_ALLOW) {
rc = dev_exception_add(devcg, ex);
if (rc)
- break;
+ return rc;
} else {
/*
* in the other possible cases:
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 167/168] mm/vmstat.c: fix /proc/vmstat format for CONFIG_DEBUG_TLBFLUSH=y CONFIG_SMP=n
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (165 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 166/168] device_cgroup: fix RCU imbalance in error case Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 17:10 ` [PATCH 4.4 168/168] ALSA: info: Fix racy addition/deletion of nodes Greg Kroah-Hartman
` (5 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khlebnikov,
Vlastimil Babka, Roman Gushchin, Jann Horn, Andrew Morton,
Linus Torvalds
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
commit e8277b3b52240ec1caad8e6df278863e4bf42eac upstream.
Commit 58bc4c34d249 ("mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly")
depends on skipping vmstat entries with empty name introduced in
7aaf77272358 ("mm: don't show nr_indirectly_reclaimable in
/proc/vmstat") but reverted in b29940c1abd7 ("mm: rename and change
semantics of nr_indirectly_reclaimable_bytes").
So skipping no longer works and /proc/vmstat has misformatted lines " 0".
This patch simply shows debug counters "nr_tlb_remote_*" for UP.
Link: http://lkml.kernel.org/r/155481488468.467.4295519102880913454.stgit@buzz
Fixes: 58bc4c34d249 ("mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Roman Gushchin <guro@fb.com>
Cc: Jann Horn <jannh@google.com>
Cc: <stable@vger.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>
---
mm/vmstat.c | 5 -----
1 file changed, 5 deletions(-)
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -857,13 +857,8 @@ const char * const vmstat_text[] = {
#endif
#endif /* CONFIG_MEMORY_BALLOON */
#ifdef CONFIG_DEBUG_TLBFLUSH
-#ifdef CONFIG_SMP
"nr_tlb_remote_flush",
"nr_tlb_remote_flush_received",
-#else
- "", /* nr_tlb_remote_flush */
- "", /* nr_tlb_remote_flush_received */
-#endif /* CONFIG_SMP */
"nr_tlb_local_flush_all",
"nr_tlb_local_flush_one",
#endif /* CONFIG_DEBUG_TLBFLUSH */
^ permalink raw reply [flat|nested] 178+ messages in thread* [PATCH 4.4 168/168] ALSA: info: Fix racy addition/deletion of nodes
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (166 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 167/168] mm/vmstat.c: fix /proc/vmstat format for CONFIG_DEBUG_TLBFLUSH=y CONFIG_SMP=n Greg Kroah-Hartman
@ 2019-04-24 17:10 ` Greg Kroah-Hartman
2019-04-24 22:25 ` [PATCH 4.4 000/168] 4.4.179-stable review kernelci.org bot
` (4 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-24 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+48df349490c36f9f54ab, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 8c2f870890fd28e023b0fcf49dcee333f2c8bad7 upstream.
The ALSA proc helper manages the child nodes in a linked list, but its
addition and deletion is done without any lock. This leads to a
corruption if they are operated concurrently. Usually this isn't a
problem because the proc entries are added sequentially in the driver
probe procedure itself. But the card registrations are done often
asynchronously, and the crash could be actually reproduced with
syzkaller.
This patch papers over it by protecting the link addition and deletion
with the parent's mutex. There is "access" mutex that is used for the
file access, and this can be reused for this purpose as well.
Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/info.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/sound/core/info.c
+++ b/sound/core/info.c
@@ -724,8 +724,11 @@ snd_info_create_entry(const char *name,
INIT_LIST_HEAD(&entry->children);
INIT_LIST_HEAD(&entry->list);
entry->parent = parent;
- if (parent)
+ if (parent) {
+ mutex_lock(&parent->access);
list_add_tail(&entry->list, &parent->children);
+ mutex_unlock(&parent->access);
+ }
return entry;
}
@@ -809,7 +812,12 @@ void snd_info_free_entry(struct snd_info
list_for_each_entry_safe(p, n, &entry->children, list)
snd_info_free_entry(p);
- list_del(&entry->list);
+ p = entry->parent;
+ if (p) {
+ mutex_lock(&p->access);
+ list_del(&entry->list);
+ mutex_unlock(&p->access);
+ }
kfree(entry->name);
if (entry->private_free)
entry->private_free(entry);
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 000/168] 4.4.179-stable review
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (167 preceding siblings ...)
2019-04-24 17:10 ` [PATCH 4.4 168/168] ALSA: info: Fix racy addition/deletion of nodes Greg Kroah-Hartman
@ 2019-04-24 22:25 ` kernelci.org bot
2019-04-25 10:05 ` Naresh Kamboju
` (3 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: kernelci.org bot @ 2019-04-24 22:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
stable-rc/linux-4.4.y boot: 83 boots: 2 failed, 73 passed with 8 offline (v4.4.178-169-ge340a9c1b725)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.178-169-ge340a9c1b725/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.178-169-ge340a9c1b725/
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.178-169-ge340a9c1b725
Git Commit: e340a9c1b725b0f93827ba2f4947bf276ec5a97c
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 43 unique boards, 21 SoC families, 14 builds out of 190
Boot Regressions Detected:
arm:
multi_v7_defconfig:
gcc-7:
exynos5422-odroidxu3:
lab-baylibre: new failure (last pass: v4.4.178-98-g93a1a2b3b035)
Boot Failures Detected:
arm:
multi_v7_defconfig:
gcc-7:
exynos5422-odroidxu3: 1 failed lab
arm64:
defconfig:
gcc-7:
qcom-qdf2400: 1 failed lab
Offline Platforms:
arm:
imx_v6_v7_defconfig:
gcc-7
vf610-colibri-eval-v3: 1 offline lab
multi_v7_defconfig:
gcc-7
bcm72521-bcm97252sffe: 1 offline lab
bcm7445-bcm97445c: 1 offline lab
meson8b-odroidc1: 1 offline lab
stih410-b2120: 1 offline lab
tegra20-iris-512: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab
tegra_defconfig:
gcc-7
tegra20-iris-512: 1 offline lab
---
For more info write to <info@kernelci.org>
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 000/168] 4.4.179-stable review
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (168 preceding siblings ...)
2019-04-24 22:25 ` [PATCH 4.4 000/168] 4.4.179-stable review kernelci.org bot
@ 2019-04-25 10:05 ` Naresh Kamboju
2019-04-25 11:55 ` Jon Hunter
` (2 subsequent siblings)
172 siblings, 0 replies; 178+ messages in thread
From: Naresh Kamboju @ 2019-04-25 10:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Wed, 24 Apr 2019 at 22:48, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.4.179 release.
> There are 168 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 26 Apr 2019 05:07:28 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.179-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
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.4.179-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 83003200d9b5aee33e831b6fa85b8c8a2964591d
git describe: v4.4.178-169-g83003200d9b5
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.178-169-g83003200d9b5
No regressions (compared to build v4.4.178-169-ge340a9c1b725)
No fixes (compared to build v4.4.178-169-ge340a9c1b725)
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 000/168] 4.4.179-stable review
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (169 preceding siblings ...)
2019-04-25 10:05 ` Naresh Kamboju
@ 2019-04-25 11:55 ` Jon Hunter
2019-04-25 16:03 ` shuah
2019-04-25 19:37 ` Guenter Roeck
172 siblings, 0 replies; 178+ messages in thread
From: Jon Hunter @ 2019-04-25 11:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 24/04/2019 18:07, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.179 release.
> There are 168 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 26 Apr 2019 05:07:28 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.179-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
All tests are passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
19 tests: 19 pass, 0 fail
Linux version: 4.4.179-rc1-ge340a9c
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 000/168] 4.4.179-stable review
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (170 preceding siblings ...)
2019-04-25 11:55 ` Jon Hunter
@ 2019-04-25 16:03 ` shuah
2019-04-25 19:37 ` Guenter Roeck
172 siblings, 0 replies; 178+ messages in thread
From: shuah @ 2019-04-25 16:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 4/24/19 11:07 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.179 release.
> There are 168 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 26 Apr 2019 05:07:28 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.179-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
^ permalink raw reply [flat|nested] 178+ messages in thread* Re: [PATCH 4.4 000/168] 4.4.179-stable review
2019-04-24 17:07 [PATCH 4.4 000/168] 4.4.179-stable review Greg Kroah-Hartman
` (171 preceding siblings ...)
2019-04-25 16:03 ` shuah
@ 2019-04-25 19:37 ` Guenter Roeck
172 siblings, 0 replies; 178+ messages in thread
From: Guenter Roeck @ 2019-04-25 19:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Wed, Apr 24, 2019 at 07:07:24PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.179 release.
> There are 168 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 26 Apr 2019 05:07:28 PM UTC.
> Anything received after that time might be too late.
>
For v4.4.178-170-gc824a7e447d3:
Build results:
total: 171 pass: 171 fail: 0
Qemu test results:
total: 296 pass: 296 fail: 0
Guenter
^ permalink raw reply [flat|nested] 178+ messages in thread