summaryrefslogtreecommitdiffstats
path: root/crypto
diff options
context:
space:
mode:
authorSteffen Klassert <steffen.klassert@secunet.com>2010-07-07 15:31:26 +0200
committerHerbert Xu <herbert@gondor.apana.org.au>2010-07-14 20:29:29 +0800
commit33e54450683c5e970ac007489d7921ba792d093c (patch)
tree1e3d0a7fcc007bfa97c88c68d411b8e1691bb7e5 /crypto
parentee836555120140f770005b8ce6673c913d1b9a98 (diff)
downloadlinux-stable-33e54450683c5e970ac007489d7921ba792d093c.tar.gz
linux-stable-33e54450683c5e970ac007489d7921ba792d093c.tar.bz2
linux-stable-33e54450683c5e970ac007489d7921ba792d093c.zip
padata: Handle empty padata cpumasks
This patch fixes a bug when the padata cpumask does not intersect with the active cpumask. In this case we get a division by zero in padata_alloc_pd and we end up with a useless padata instance. Padata can end up with an empty cpumask for two reasons: 1. A user removed the last cpu that belongs to the padata cpumask and the active cpumask. 2. The last cpu that belongs to the padata cpumask and the active cpumask goes offline. We introduce a function padata_validate_cpumask to check if the padata cpumask does intersect with the active cpumask. If the cpumasks do not intersect we mark the instance as invalid, so it can't be used. We do not allocate the cpumask dependend recources in this case. This fixes the division by zero and keeps the padate instance in a consistent state. It's not possible to trigger this bug by now because the only padata user, pcrypt uses always the possible cpumask. Reported-by: Dan Kruchinin <dkruchinin@acm.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions