On Thu, Jul 18, 2019 at 10:56:34PM +0800, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:27:30AM -0400, Daniel Jordan wrote:
> >
> > That's what I expected when I first saw it too, but nr_cpumask_bits is
> > returned
> > to signal the end of the iteration. The patch always passes 0 for the
> > '
On Thu, Jul 18, 2019 at 10:49:50PM +0800, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote:
> >
> > Which memory barrier do you mean? I think you're referring to the one that
> > atomic_inc might provide? If so, the memory model maintainers can correct
> > me
> >
On Thu, Jul 18, 2019 at 10:27:30AM -0400, Daniel Jordan wrote:
>
> That's what I expected when I first saw it too, but nr_cpumask_bits is
> returned
> to signal the end of the iteration. The patch always passes 0 for the 'start'
> argument, so when cpumask_next_wrap is called with the last cpu in
On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote:
>
> Which memory barrier do you mean? I think you're referring to the one that
> atomic_inc might provide? If so, the memory model maintainers can correct me
> here, but my understanding is that RMW atomic ops that don't return values
On Thu, Jul 18, 2019 at 11:31:31AM +0800, Herbert Xu wrote:
> On Wed, Jul 17, 2019 at 02:32:27PM -0400, Daniel Jordan wrote:
> >
> > We'll crash when cpumask_next_wrap returns nr_cpumask_bits and later try to
> > get
> > the corresponding per-cpu queue.
>
> The whole point of cpumask_next_wrap is
On Thu, Jul 18, 2019 at 11:30:08AM +0800, Herbert Xu wrote:
> On Wed, Jul 17, 2019 at 07:21:36PM -0400, Daniel Jordan wrote:
> >
> > > @@ -388,12 +336,12 @@ void padata_do_serial(struct padata_priv *padata)
> > > pqueue = per_cpu_ptr(pd->pqueue, cpu);
> > >
> > > spin_lock(&pqueue->reorder.lo
On Wed, Jul 17, 2019 at 02:32:27PM -0400, Daniel Jordan wrote:
>
> We'll crash when cpumask_next_wrap returns nr_cpumask_bits and later try to
> get
> the corresponding per-cpu queue.
The whole point of cpumask_next_wrap is to wrap around to the
beginning when it hits nr_cpumask_bits. So it cann
On Wed, Jul 17, 2019 at 07:21:36PM -0400, Daniel Jordan wrote:
>
> > @@ -388,12 +336,12 @@ void padata_do_serial(struct padata_priv *padata)
> > pqueue = per_cpu_ptr(pd->pqueue, cpu);
> >
> > spin_lock(&pqueue->reorder.lock);
> > - atomic_inc(&pd->reorder_objects);
> > list_add_tail
On Wed, Jul 17, 2019 at 07:11:47PM +0800, Herbert Xu wrote:
> Note that we don't bother removing the work queue in
> padata_flush_queues because the whole premise is broken. You
> cannot flush async crypto requests so it makes no sense to even
> try. A subsequent patch will fix it by replacing it
On Wed, Jul 17, 2019 at 07:11:47PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 12:32:53PM -0400, Daniel Jordan wrote:
> > Testing padata with the tcrypt module on a 5.2 kernel...
>
> Thanks for the patch!
>
> And here is an incremental patch to get rid of the timer that
> appears to be an
10 matches
Mail list logo
