From: Cong Wang on 24 Feb 2010 00:40 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 24 Feb 2010 07:10 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 24 Feb 2010 20:20 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 24 Feb 2010 22:20 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 25 Feb 2010 04:50 > > 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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: sysctl extern cleanup - mm Next: [PATCH -tip] tracing: fix typo in prof_sysexit_enable() |