lkml.org 
[lkml]   [2019]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] padata: use smp_mb in padata_reorder to avoid orphaned padata jobs
On Sat, Jul 13, 2019 at 01:03:21PM +0800, Herbert Xu wrote:
> On Fri, Jul 12, 2019 at 12:07:37PM -0400, Daniel Jordan wrote:
> >
> > modprobe (CPU2) kworker/21:1-293 (CPU21) kworker/5:2-276 (CPU5)
> > -------------------------- ------------------------ ----------------------
> > <submit job, seq_nr=16581>
> > ...
> > padata_do_parallel
> > queue_work_on(21, ...)
> > <sleeps>
> > padata_parallel_worker
> > pcrypt_aead_dec
> > padata_do_serial
> > padata_reorder
>
> This can't happen because if the job started on CPU2 then it must
> go back to CPU2 for completion. IOW padata_do_serial should be
> punting this to a work queue for CPU2 rather than calling
> padata_reorder on CPU21.

I've been wrong before plenty of times, and there's nothing preventing this
from being one of those times :) , but in this case I believe what I'm showing
is correct.

The padata_do_serial call for a given job ensures padata_reorder runs on the
CPU that the job hashed to in padata_do_parallel, which is not necessarily the
same CPU as the one that padata_do_parallel itself ran on.

In this case, the padata job in question started via padata_do_parallel, where
it hashed to CPU 21:

padata_do_parallel // ran on CPU 2
...
target_cpu = padata_cpu_hash(pd); // target_cpu == 21
padata->cpu = target_cpu;
...
queue_work_on(21, ...)

The corresponding kworker then started:

padata_parallel_worker // bound to CPU 21
pcrypt_aead_dec
padata_do_serial
padata_reorder

Daniel

\
 
 \ /
  Last update: 2019-07-15 18:12    [W:0.131 / U:14.708 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site