From: Greg Kroah-Hartman Date: Thu, 6 Apr 2017 08:07:35 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.9.21~4 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=214a8b64cd31668c5888a272073bf80f54efdbab;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: padata-avoid-race-in-reordering.patch --- diff --git a/queue-4.4/padata-avoid-race-in-reordering.patch b/queue-4.4/padata-avoid-race-in-reordering.patch new file mode 100644 index 00000000000..089f987c31c --- /dev/null +++ b/queue-4.4/padata-avoid-race-in-reordering.patch @@ -0,0 +1,96 @@ +From de5540d088fe97ad583cc7d396586437b32149a5 Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" +Date: Thu, 23 Mar 2017 12:24:43 +0100 +Subject: padata: avoid race in reordering + +From: Jason A. Donenfeld + +commit de5540d088fe97ad583cc7d396586437b32149a5 upstream. + +Under extremely heavy uses of padata, crashes occur, and with list +debugging turned on, this happens instead: + +[87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33 +__list_add+0xae/0x130 +[87487.301868] list_add corruption. prev->next should be next +(ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00). +[87487.339011] [] dump_stack+0x68/0xa3 +[87487.342198] [] ? console_unlock+0x281/0x6d0 +[87487.345364] [] __warn+0xff/0x140 +[87487.348513] [] warn_slowpath_fmt+0x4a/0x50 +[87487.351659] [] __list_add+0xae/0x130 +[87487.354772] [] ? _raw_spin_lock+0x64/0x70 +[87487.357915] [] padata_reorder+0x1e6/0x420 +[87487.361084] [] padata_do_serial+0xa5/0x120 + +padata_reorder calls list_add_tail with the list to which its adding +locked, which seems correct: + +spin_lock(&squeue->serial.lock); +list_add_tail(&padata->list, &squeue->serial.list); +spin_unlock(&squeue->serial.lock); + +This therefore leaves only place where such inconsistency could occur: +if padata->list is added at the same time on two different threads. +This pdata pointer comes from the function call to +padata_get_next(pd), which has in it the following block: + +next_queue = per_cpu_ptr(pd->pqueue, cpu); +padata = NULL; +reorder = &next_queue->reorder; +if (!list_empty(&reorder->list)) { + padata = list_entry(reorder->list.next, + struct padata_priv, list); + spin_lock(&reorder->lock); + list_del_init(&padata->list); + atomic_dec(&pd->reorder_objects); + spin_unlock(&reorder->lock); + + pd->processed++; + + goto out; +} +out: +return padata; + +I strongly suspect that the problem here is that two threads can race +on reorder list. Even though the deletion is locked, call to +list_entry is not locked, which means it's feasible that two threads +pick up the same padata object and subsequently call list_add_tail on +them at the same time. The fix is thus be hoist that lock outside of +that block. + +Signed-off-by: Jason A. Donenfeld +Acked-by: Steffen Klassert +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/padata.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/kernel/padata.c ++++ b/kernel/padata.c +@@ -189,19 +189,20 @@ static struct padata_priv *padata_get_ne + + reorder = &next_queue->reorder; + ++ spin_lock(&reorder->lock); + if (!list_empty(&reorder->list)) { + padata = list_entry(reorder->list.next, + struct padata_priv, list); + +- spin_lock(&reorder->lock); + list_del_init(&padata->list); + atomic_dec(&pd->reorder_objects); +- spin_unlock(&reorder->lock); + + pd->processed++; + ++ spin_unlock(&reorder->lock); + goto out; + } ++ spin_unlock(&reorder->lock); + + if (__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index) { + padata = ERR_PTR(-ENODATA); diff --git a/queue-4.4/series b/queue-4.4/series index 5b041565e9e..54654af50f4 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -23,3 +23,4 @@ kvm-kvm_io_bus_unregister_dev-should-never-fail.patch power-reset-at91-poweroff-timely-shutdown-lpddr-memories.patch blk-improve-order-of-bio-handling-in-generic_make_request.patch blk-ensure-users-for-current-bio_list-can-see-the-full-list.patch +padata-avoid-race-in-reordering.patch