On Thu, Oct 26, 2023 at 09:12:54AM +0800, Wang Jinchao wrote: > 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. 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_A. I will address this issue in subsequent patches.