From: Cong Wang on
Cong Wang wrote:
>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>> index 5259727..d8ea839 100644
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>> @@ -2635,6 +2635,140 @@ static int proc_do_cad_pid(struct ctl_table
>> *table, int write,
>
>
> The above line is wrong, it should be a part of previous line.
>
>

Sorry, ignore this, it should be my thunderbird's fault,
it truncated the line. I will fix it...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Octavian Purdila on

On Wednesday 24 February 2010 07:24:00 you wrote:
> Octavian Purdila wrote:
> > Here is a new version of this patch which fixes both the comma and
> > invalid value issues, please give it a try.
>
> Sorry, it is even worse. :(
>
> > [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
> >
> > The new function can be used to read/write large bitmaps via /proc. A
> > comma separated range format is used for compact output and input
> > (e.g. 1,3-4,10-10).
>
> Writing "50000-50100" gets EINVAL, it should be success.
> Writing "50000,50100" fails too.
>

Hmm, they don't fail for me :-/

> Please, at least, do some basic testing.
>

I do test them, I've attached the current test batch I was using.

Anyways, today I've noticed that "1,2 3" does not fail and even more
importantly the final value is "3".

Being that I don't see a way of fixing this without not acknowledging 1,2 even
though we will do set these values, I revisited the "1 2 3" issue. And I don't
understand why this is actually an issue, we are just being more permissive
(i.e. we are allowing as separators both whitespaces and ,).


> Also some comments below.
>
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 5259727..d8ea839 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -2635,6 +2635,140 @@ static int proc_do_cad_pid(struct ctl_table
> > *table, int write,
>
> The above line is wrong, it should be a part of previous line.
>

Probably my email client corrupted the patch, sorry about that, I will be more
careful next time.

> > + int left = *lenp, err = 0;
>
> 'left' should be size_t.
>

Will fix, thanks for catching this.

I will resend the whole patch series once we get this formatting issue
resolved.
From: Cong Wang on
Octavian Purdila wrote:
> On Wednesday 24 February 2010 07:24:00 you wrote:
>> Octavian Purdila wrote:
>>> Here is a new version of this patch which fixes both the comma and
>>> invalid value issues, please give it a try.
>> Sorry, it is even worse. :(
>>
>>> [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
>>>
>>> The new function can be used to read/write large bitmaps via /proc. A
>>> comma separated range format is used for compact output and input
>>> (e.g. 1,3-4,10-10).
>> Writing "50000-50100" gets EINVAL, it should be success.
>> Writing "50000,50100" fails too.
>>
>
> Hmm, they don't fail for me :-/
>
>> Please, at least, do some basic testing.
>>
>
> I do test them, I've attached the current test batch I was using.
>
> Anyways, today I've noticed that "1,2 3" does not fail and even more
> importantly the final value is "3".
>
> Being that I don't see a way of fixing this without not acknowledging 1,2 even
> though we will do set these values, I revisited the "1 2 3" issue. And I don't
> understand why this is actually an issue, we are just being more permissive
> (i.e. we are allowing as separators both whitespaces and ,).
>
>

Oops, after rechecking my test case, it is actually my test case's
fault. Sorry for this. I will fix my test case and run it again.


>
> I will resend the whole patch series once we get this formatting issue
> resolved.
>

Thanks much!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Cong Wang on
Cong Wang wrote:
> Octavian Purdila wrote:
>> On Wednesday 24 February 2010 07:24:00 you wrote:
>>> Octavian Purdila wrote:
>>>> Here is a new version of this patch which fixes both the comma and
>>>> invalid value issues, please give it a try.
>>> Sorry, it is even worse. :(
>>>
>>>> [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
>>>>
>>>> The new function can be used to read/write large bitmaps via /proc. A
>>>> comma separated range format is used for compact output and input
>>>> (e.g. 1,3-4,10-10).
>>> Writing "50000-50100" gets EINVAL, it should be success.
>>> Writing "50000,50100" fails too.
>>>
>>
>> Hmm, they don't fail for me :-/
>>
>>> Please, at least, do some basic testing.
>>>
>>
>> I do test them, I've attached the current test batch I was using.
>>
>> Anyways, today I've noticed that "1,2 3" does not fail and even more
>> importantly the final value is "3".
>> Being that I don't see a way of fixing this without not acknowledging
>> 1,2 even though we will do set these values, I revisited the "1 2 3"
>> issue. And I don't understand why this is actually an issue, we are
>> just being more permissive (i.e. we are allowing as separators both
>> whitespaces and ,).
>>
>>
>
> Oops, after rechecking my test case, it is actually my test case's
> fault. Sorry for this. I will fix my test case and run it again.
>

Hi,

Still a small problem, if I do write(fd, "50000,50100", 12) I will
get a return value of 11, which should mean 11 bytes are written,
however, actually only the first 6 bytes are accepted.

The rest looks better now.

Or am I missing something here? :)

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Octavian Purdila on
>
> Hi,
>
> Still a small problem, if I do write(fd, "50000,50100", 12) I will
> get a return value of 11, which should mean 11 bytes are written,
> however, actually only the first 6 bytes are accepted.
>
> The rest looks better now.
>
> Or am I missing something here? :)
>

Will take a look at this a bit later today, thanks for testing.

In the meanwhile what are your thougths on the "1 2 3" issue, are you OK with accepting spaces as well as commas as separators?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/