On Wed, Oct 25, 2023 at 02:12:31PM -0400, Daniel Jordan wrote:
> On Thu, Sep 28, 2023 at 04:53:38PM +0800, Wang Jinchao wrote:
> > -/**
> > - * struct parallel_data - Internal control structure, covers everything
> > - * that depends on the cpumask in use.
> > - *
> > - * @ps: padata_shell object.
> > - * @reorder_list: percpu reorder lists
> > - * @squeue: percpu padata queues used for serialuzation.
> > - * @refcnt: Number of objects holding a reference on this parallel_data.
> > - * @seq_nr: Sequence number of the parallelized data object.
> > - * @processed: Number of already processed objects.
> > - * @cpu: Next CPU to be processed.
> > - * @cpumask: The cpumasks in use for parallel and serial workers.
> > - * @reorder_work: work struct for reordering.
> > - * @lock: Reorder lock.
> > - */
> > -struct parallel_data {
> > - struct padata_shell *ps;
> > - struct padata_list __percpu *reorder_list;
> > - struct padata_serial_queue __percpu *squeue;
> > - refcount_t refcnt;
> > - unsigned int seq_nr;
> > - unsigned int processed;
> > - int cpu;
> > - struct padata_cpumask cpumask;
> > - struct work_struct reorder_work;
> > - spinlock_t ____cacheline_aligned lock;
> > -};
>
> reorder_list used to serialize one sequence of objects per padata_shell,
> but now serial_wq serializes all sequences of objects in one list of
> work_structs. That works in theory, since a total order can maintain
> each sequence's order, but it's possible (not sure yet, need to think
> more) that this could lead to deadlocks or other issues in odd cases
> such as the one that padata_shell was introduced for in bbefa1dd6a6d
> ("crypto: pcrypt - Avoid deadlock by using per-instance padata queues").
>
Yes, you are correct. This version is not only ordered at the padata_shell
level but at the instance level, which indeed doesn't align with the design.
Apart from potential deadlocks, it may also cause a padata_shell_B that
should have completed earlier to be blocked by an unrelated padata_shell_B.
I will address this issue in subsequent patches.
