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 to wrap around to the > beginning when it hits nr_cpumask_bits. So it cannot return > nr_cpumask_bits. 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 the mask, the end-of-iteration case is triggered. To reassure you and myself :) I ran it and got the expected crash. Passing pd->cpu for the start argument instead avoids that problem, but the one-cpu-in-mask case still needs handling because cpumask_next_wrap always signals end of iteration for that, hence the cpumask_weight check.
