<feed xmlns='http://www.w3.org/2005/Atom'>
<title>xavi/android_kernel_m2note/kernel/padata.c, branch o-8.1</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=o-8.1</id>
<link rel='self' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=o-8.1'/>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/'/>
<updated>2017-07-04T10:13:07+00:00</updated>
<entry>
<title>padata: avoid race in reordering</title>
<updated>2017-07-04T10:13:07+00:00</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2017-03-23T11:24:43+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=c3fdcc6ff5092d70d5ca30dd7f06e500a65c7a78'/>
<id>urn:sha1:c3fdcc6ff5092d70d5ca30dd7f06e500a65c7a78</id>
<content type='text'>
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-&gt;next should be next
(ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
[87487.339011]  [&lt;ffffffff9a53d075&gt;] dump_stack+0x68/0xa3
[87487.342198]  [&lt;ffffffff99e119a1&gt;] ? console_unlock+0x281/0x6d0
[87487.345364]  [&lt;ffffffff99d6b91f&gt;] __warn+0xff/0x140
[87487.348513]  [&lt;ffffffff99d6b9aa&gt;] warn_slowpath_fmt+0x4a/0x50
[87487.351659]  [&lt;ffffffff9a58b5de&gt;] __list_add+0xae/0x130
[87487.354772]  [&lt;ffffffff9add5094&gt;] ? _raw_spin_lock+0x64/0x70
[87487.357915]  [&lt;ffffffff99eefd66&gt;] padata_reorder+0x1e6/0x420
[87487.361084]  [&lt;ffffffff99ef0055&gt;] padata_do_serial+0xa5/0x120

padata_reorder calls list_add_tail with the list to which its adding
locked, which seems correct:

spin_lock(&amp;squeue-&gt;serial.lock);
list_add_tail(&amp;padata-&gt;list, &amp;squeue-&gt;serial.list);
spin_unlock(&amp;squeue-&gt;serial.lock);

This therefore leaves only place where such inconsistency could occur:
if padata-&gt;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-&gt;pqueue, cpu);
padata = NULL;
reorder = &amp;next_queue-&gt;reorder;
if (!list_empty(&amp;reorder-&gt;list)) {
       padata = list_entry(reorder-&gt;list.next,
                           struct padata_priv, list);
       spin_lock(&amp;reorder-&gt;lock);
       list_del_init(&amp;padata-&gt;list);
       atomic_dec(&amp;pd-&gt;reorder_objects);
       spin_unlock(&amp;reorder-&gt;lock);

       pd-&gt;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 &lt;Jason@zx2c4.com&gt;
Acked-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>first commit</title>
<updated>2016-08-15T02:19:42+00:00</updated>
<author>
<name>Meizu OpenSource</name>
<email>patchwork@meizu.com</email>
</author>
<published>2016-08-15T02:19:42+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=d2e1446d81725c351dc73a03b397ce043fb18452'/>
<id>urn:sha1:d2e1446d81725c351dc73a03b397ce043fb18452</id>
<content type='text'>
</content>
</entry>
</feed>
