public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pan Xinhui <xinhuix.pan@intel.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	tj@kernel.org, peterz@infradead.org, sudeep.holla@arm.com,
	mina86@mina86.com, "mnipxh@163.com" <mnipxh@163.com>,
	Alexey Klimov <klimov.linux@gmail.com>
Subject: Re: [PATCH] lib/bitmap.c: return -EINVAL for grouping errors in __bitmap_parselist
Date: Tue, 30 Jun 2015 16:37:48 +0800	[thread overview]
Message-ID: <5592555C.4080702@intel.com> (raw)
In-Reply-To: <CAAH8bW9r0n87A5qx6eQOxh2tH6sXiTcmmsPEBn6eFyWoLK2YMw@mail.gmail.com>

hi, Yury

On 2015年06月30日 16:32, Yury Norov wrote:
> 2015-07-01 4:37 GMT+03:00 Pan Xinhui <xinhuix.pan@intel.com>:
>> hi, Yury
>>          thanks for your nice reply.
>>
>> On 2015年06月29日 21:39, Yury Norov wrote:
>>>>
>>>> Sometimes the input from user may cause an unexpected result.
>>>
>>>
>>> Could you please provide specific example?
>>>
>> I wrote some scripts to do some tests about irqs.
>> echo "1-3," > /proc/irq/<xxx>/smp_affinity_list
>> this command ends with ',' by mistake.
>> actually __bitmap_parselist() will report "0-3" for the final result which
>> is wrong.
>>
>
> Hmm...
> I don't think this is wrong passing echo "1-3,".
> With or without a comma, the final result must be the same.
> More flexible format is useful for hard scripts (for your one).
> It's not too difficult to imagine a script producing a line:
>           "1-24,  ,   ,,, ,  12-64, 92,92,92,,,"
> And I don't think we should reject user with this once the range is valid.
> Even more, to spend a time writing some additional code for it, and make
> user spend his time as well.
>
> I just tried
>            cd /home/yury///./././/work
> and it works perfectly well for me, and it's fine.
>
> The true problem is that a and b variables
> goes zero after comma, and EOL after comma just takes it:
>   514     do {
>   ...
>   517         a = b = 0;                                           //
> <--- comma makes it 0 here
>   ...
>   520         while (buflen) {
>   ...
>   539             /* A '\0' or a ',' signal the end of a cpu# or range */
>   540             if (c == '\0' || c == ',')                     //
> <---here we just break after '\0'
>   541                 break;
>   559         }
>   ...
>   565             while (a <= b) {
>   566                 set_bit(a, maskp);                   // <--- and
> here we set unneeded 0 bit.
>   567                 a++;
>   568             }
>
> So currently, "1-3,\0" is the same as "1-3,0,\0". And this is definitely wrong.
>
yes, you are right.
current codes did not check if there is any digit between ',' or '\0'.
I has sent out patch V2, which rewrite two functions.
could you help have a code review if you have free time? thanks for your nice reply :)

thanks,
xinhui

>>
>>>>
>>>> just like __bitmap_parse, we return -EINVAL if there is no avaiable digit
>>>> in each
>>>> parsing procedures.
>>>>
>>>> Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
>>>
>>>
>>> Hello, Pan.
>>>
>>> (Adding Alexey Klimov, Rasmus Villemoes)
>>>
>>>> ---
>>>>     lib/bitmap.c | 7 +++++--
>>>>     1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/lib/bitmap.c b/lib/bitmap.c
>>>> index 64c0926..995fca2 100644
>>>> --- a/lib/bitmap.c
>>>> +++ b/lib/bitmap.c
>>>> @@ -504,7 +504,7 @@ static int __bitmap_parselist(const char *buf,
>>>> unsigned int buflen,
>>>>             int nmaskbits)
>>>>     {
>>>>         unsigned a, b;
>>>> -    int c, old_c, totaldigits;
>>>> +    int c, old_c, totaldigits, ndigits;
>>>>         const char __user __force *ubuf = (const char __user __force
>>>> *)buf;
>>>>         int exp_digit, in_range;
>>>>
>>>> @@ -514,6 +514,7 @@ static int __bitmap_parselist(const char *buf,
>>>> unsigned int buflen,
>>>>             exp_digit = 1;
>>>>             in_range = 0;
>>>>             a = b = 0;
>>>> +        ndigits = 0;
>>>>
>>>>             /* Get the next cpu# or a range of cpu#'s */
>>>>             while (buflen) {
>>>> @@ -555,8 +556,10 @@ static int __bitmap_parselist(const char *buf,
>>>> unsigned int buflen,
>>>>                 if (!in_range)
>>>>                     a = b;
>>>>                 exp_digit = 0;
>>>> -            totaldigits++;
>>>> +            ndigits++; totaldigits++;
>>>
>>>
>>> I'm not happy with joining two statements to a single line.
>>> Maybe sometimes it's OK for loop iterators like
>>>
>>>       while (a[i][j]) {
>>>           i++; j++;
>>>       }
>>>
>>> But here it looks nasty. Anyway, it's minor.
>>>
>>
>> thanks for pointing out my mistake about the code style :)
>>
>>>>             }
>>>> +        if (ndigits == 0)
>>>> +            return -EINVAL;
>>>
>>>
>>> You can avoid in-loop incrementation of ndigits if you'll
>>> save current totaldigits to ndigits before loop, and check
>>> ndigits against totaldigits after the loop:
>>>
>>>       ndigits = totaldigits;
>>>       while (...) {
>>>            ...
>>>           totaldigits++;
>>>       }
>>>
>>>       if (ndigits == totaldigits)
>>>           return -EINVAL;
>>>
>>> Maybe it's a good point to rework initial __bitmap_parse() similar way...
>>>
>>
>> your advice is a good idea, thanks.
>> I am also thinking if we can rewrite them into one function for common
>> codes.
>>
>> thanks for your reply again :)
>>
>> thanks
>> xinhui
>>
>>
>>>>             if (!(a <= b))
>>>>                 return -EINVAL;
>>>>             if (b >= nmaskbits)
>>>> --
>>>> 1.9.1

      reply	other threads:[~2015-06-30  8:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30  7:42 [PATCH] lib/bitmap.c: return -EINVAL for grouping errors in __bitmap_parselist Pan Xinhui
2015-06-29 13:39 ` Yury Norov
2015-07-01  1:37   ` Pan Xinhui
2015-06-30  8:01     ` [PATCH] lib/bitmap.c: rewrite __bitmap_parse && __bitmap_parselist Pan Xinhui
2015-06-30  8:31       ` [PATCH V2] " Pan Xinhui
2015-06-30 10:02         ` [PATCH V3] " Pan Xinhui
2015-07-01  3:17           ` Pan Xinhui
2015-07-01  9:16           ` Yury
2015-07-01 11:08             ` Pan Xinhui
2015-06-30  8:32     ` [PATCH] lib/bitmap.c: return -EINVAL for grouping errors in __bitmap_parselist Yury Norov
2015-06-30  8:37       ` Pan Xinhui [this message]

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=5592555C.4080702@intel.com \
    --to=xinhuix.pan@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=klimov.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mina86@mina86.com \
    --cc=mnipxh@163.com \
    --cc=peterz@infradead.org \
    --cc=sudeep.holla@arm.com \
    --cc=tj@kernel.org \
    --cc=yury.norov@gmail.com \
    /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