From: Steffen Klassert <steffen.klassert@secunet.com>
To: Dan Kruchinin <dkruchinin@acm.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Herbert Xu <herbert@gondor.hengli.com.au>
Subject: Re: [PATCH] Fixed division by zero bug in kernel/padata.c
Date: Fri, 2 Jul 2010 14:56:28 +0200 [thread overview]
Message-ID: <20100702125628.GK10072@secunet.com> (raw)
In-Reply-To: <AANLkTimVTMsVkSBHWLve8t76-YkoSYposgv9wHir_wPa@mail.gmail.com>
On Fri, Jul 02, 2010 at 03:59:54PM +0400, Dan Kruchinin wrote:
> When boot CPU(typically CPU #0) is excluded from padata cpumask and
> user enters halt command from console, kernel faults on division by zero;
> This occurs because during the halt kernel shuts down each non-boot CPU one
> by one and after it shuts down the last CPU that is set in the padata cpumask,
> the only working CPU in the system is a boot CPU(#0) and it's the only CPU that
> is set in the cpu_active_mask. Hence when padata_cpu_callback calls
> __padata_remove_cpu(which calls padata_alloc_pd) it appears that
> padata cpumask and
> cpu_active_mask aren't intersect. Hence the following code in
> padata_alloc_pd causes
> a DZ error exception:
> cpumask_and(pd->cpumask, cpumask, cpu_active_mask); // pd->cpumask
> will be empty
> ...
> num_cpus = cpumask_weight(pd->cpumask); // num_cpus = 0
> pd->max_seq_nr = (MAX_SEQ_NR / num_cpus) * num_cpus - 1; // DZ!
>
Good catch!
>
> Signed-off-by: Dan Kruchinin <dkruchinin@acm.org>
> ---
> kernel/padata.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/padata.c b/kernel/padata.c
> index fdd8ae6..dbe6d26 100644
> --- a/kernel/padata.c
> +++ b/kernel/padata.c
> @@ -434,7 +434,7 @@ static struct parallel_data
> *padata_alloc_pd(struct padata_instance *pinst,
> atomic_set(&queue->num_obj, 0);
> }
>
> - num_cpus = cpumask_weight(pd->cpumask);
> + num_cpus = cpumask_weight(pd->cpumask) + 1;
> pd->max_seq_nr = (MAX_SEQ_NR / num_cpus) * num_cpus - 1;
>
num_cpus should stay the number of cpus in this cpumask, this is required
to handle a smooth overrun of the sequence numbers.
I think it's better to return with an error and to stop the instance
if somebody takes away the last cpu in our cpumask. We can't run with an
empty cpumask anyway.
Let us look again at this on monday.
Thanks again for catching this,
Steffen
next prev parent reply other threads:[~2010-07-02 12:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-02 11:59 [PATCH] Fixed division by zero bug in kernel/padata.c Dan Kruchinin
2010-07-02 12:56 ` Steffen Klassert [this message]
2010-07-02 13:24 ` Dan Kruchinin
2010-07-05 13:18 ` Steffen Klassert
2010-07-05 13:35 ` Dan Kruchinin
2010-07-05 13:43 ` Herbert Xu
2010-07-05 13:53 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100702125628.GK10072@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=dkruchinin@acm.org \
--cc=herbert@gondor.hengli.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox