Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751681AbbGIW5L (ORCPT ); Thu, 9 Jul 2015 18:57:11 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53438 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751131AbbGIW5C (ORCPT ); Thu, 9 Jul 2015 18:57:02 -0400 Date: Thu, 9 Jul 2015 15:57:01 -0700 From: Andrew Morton To: Pan Xinhui Cc: linux-kernel@vger.kernel.org, linux@rasmusvillemoes.dk, tj@kernel.org, mnipxh@163.com, Chris Metcalf Subject: Re: [PATCH] lib/bitmap.c: add some check to correct the parse result Message-Id: <20150709155701.3e3fe2cf5e7527d9aeb72338@linux-foundation.org> In-Reply-To: <558E4462.7060600@intel.com> References: <558E4462.7060600@intel.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3655 Lines: 117 On Sat, 27 Jun 2015 14:36:18 +0800 Pan Xinhui wrote: > Sometimes the input from user may cause an unexpected result. > > for example, echo "1-3," > /proc/irq//smp_affinity_list. > The correct result should be 1-3, however we got 0-4. > > To avoid this issue, we check if there is a ready digit. > If no valid digit is set, we just continue to the next parse. > > Signed-off-by: Pan Xinhui > --- > lib/bitmap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/bitmap.c b/lib/bitmap.c > index 64c0926..3c489c1 100644 > --- a/lib/bitmap.c > +++ b/lib/bitmap.c > @@ -561,6 +561,8 @@ static int __bitmap_parselist(const char *buf, unsigned int buflen, > return -EINVAL; > if (b >= nmaskbits) > return -ERANGE; > + if (unlikely(exp_digit)) > + continue; > while (a <= b) { > set_bit(a, maskp); > a++; This bug might have been fixed by 2528a8b8f457d7 ("__bitmap_parselist: fix bug in empty string handling"), below. Please check? commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 Author: Chris Metcalf AuthorDate: Thu Jun 25 15:02:08 2015 -0700 Commit: Linus Torvalds CommitDate: Thu Jun 25 17:00:40 2015 -0700 __bitmap_parselist: fix bug in empty string handling bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in the mask. The same bug is visible in cpumask_parselist() since it is layered on top of the bitmask code, e.g. if you boot with "isolcpus=", you will actually end up with cpu zero isolated. The bug was introduced in commit 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq") when bitmap_parselist() was generalized to support userspace as well as kernelspace. Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq") Signed-off-by: Chris Metcalf Cc: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds diff --git a/lib/bitmap.c b/lib/bitmap.c index 64c0926..40162f8 100644 --- a/lib/bitmap.c +++ b/lib/bitmap.c @@ -506,12 +506,12 @@ static int __bitmap_parselist(const char *buf, unsigned int buflen, unsigned a, b; int c, old_c, totaldigits; const char __user __force *ubuf = (const char __user __force *)buf; - int exp_digit, in_range; + int at_start, in_range; totaldigits = c = 0; bitmap_zero(maskp, nmaskbits); do { - exp_digit = 1; + at_start = 1; in_range = 0; a = b = 0; @@ -540,11 +540,10 @@ static int __bitmap_parselist(const char *buf, unsigned int buflen, break; if (c == '-') { - if (exp_digit || in_range) + if (at_start || in_range) return -EINVAL; b = 0; in_range = 1; - exp_digit = 1; continue; } @@ -554,16 +553,18 @@ static int __bitmap_parselist(const char *buf, unsigned int buflen, b = b * 10 + (c - '0'); if (!in_range) a = b; - exp_digit = 0; + at_start = 0; totaldigits++; } if (!(a <= b)) return -EINVAL; if (b >= nmaskbits) return -ERANGE; - while (a <= b) { - set_bit(a, maskp); - a++; + if (!at_start) { + while (a <= b) { + set_bit(a, maskp); + a++; + } } } while (buflen && c == ','); return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/