Hello.
As it seems that there is no critical problem (naming preference can easily be
fixed if needed), can these patches go to linux-next?
If these patches are accepted, Kees Cook will submit a patch which removes %n
support from vsnprintf() ( https://lkml.org/lkml/2013/9/16/54 ).
Regards.
[-remi (bouncing), +akpm]
On Thu, Sep 19, 2013 at 9:09 PM, Tetsuo Handa
wrote:
> Hello.
>
> We are discussing about removal of %n support from vsnprintf() at
> https://lkml.org/lkml/2013/9/16/52 , and you are using %n in seq_printf().
>
> I posted https://lkml.org/lkml/diff/2013/9/19/53/1 which i
On Sat, Sep 21, 2013 at 2:28 AM, Tetsuo Handa
wrote:
> Kees Cook wrote:
>> >> - seq_printf(seq, "%*s\n", 127 - len, "");
>> >> + seq_pad(seq, '\n');
>> >
>> > Hmm, seq_pad is unintuitive. I would say it pads the string by '\n'. Of
>> > course it does not, bu
> If you want, we can rename seq_pad() to seq_pad_and_putc(). Also we can pass
> both the padding character (e.g. ' ') and the trailing character (e.g. '\n')
> like seq_pad_and_putc((' ' << 8) | '\n'), though I wonder someone wants to
> use '\0', '\t', '\n' etc. as the padding character...
How abo
Kees Cook wrote:
> >> - seq_printf(seq, "%*s\n", 127 - len, "");
> >> + seq_pad(seq, '\n');
> >
> > Hmm, seq_pad is unintuitive. I would say it pads the string by '\n'. Of
> > course it does not, but...
>
> I don't think this is a very serious problem. Curre
On Fri, 2013-09-20 at 12:24 -0700, Kees Cook wrote:
> There are a few problems that have been discussed on the various
> threads. Namely, we want to minimize the changes to the seq_file
> structure and to not add additional work to all the seq_file users
> that don't care about padding.
I don't th
On Fri, Sep 20, 2013 at 1:08 AM, Jiri Slaby wrote:
> On 09/20/2013 06:09 AM, Tetsuo Handa wrote:
>> --- a/fs/proc/consoles.c
>> +++ b/fs/proc/consoles.c
> ...
>> @@ -47,11 +46,10 @@ static int show_console_dev(struct seq_file *m, void *v)
>> con_flags[a].name : ' ';
>>
On 09/20/2013 06:09 AM, Tetsuo Handa wrote:
> --- a/fs/proc/consoles.c
> +++ b/fs/proc/consoles.c
...
> @@ -47,11 +46,10 @@ static int show_console_dev(struct seq_file *m, void *v)
> con_flags[a].name : ' ';
> flags[a] = 0;
>
> - seq_printf(m, "%s%d%n", con->name,
On Thu, Sep 19, 2013 at 9:23 PM, Joe Perches wrote:
> On Fri, 2013-09-20 at 13:09 +0900, Tetsuo Handa wrote:
>> Hello.
>
> Tetsuo-san:
>
>> We are discussing about removal of %n support from vsnprintf() at
>> https://lkml.org/lkml/2013/9/16/52 , and you are using %n in seq_printf().
>
> Well, I'm
On Fri, 2013-09-20 at 13:09 +0900, Tetsuo Handa wrote:
> Hello.
Tetsuo-san:
> We are discussing about removal of %n support from vsnprintf() at
> https://lkml.org/lkml/2013/9/16/52 , and you are using %n in seq_printf().
Well, I'm not using (mere alcohol isn't using, right?)
but I still have the
Hello.
We are discussing about removal of %n support from vsnprintf() at
https://lkml.org/lkml/2013/9/16/52 , and you are using %n in seq_printf().
I posted https://lkml.org/lkml/diff/2013/9/19/53/1 which introduces
seq_setwidth() / seq_pad() which can avoid use of %n in seq_printf().
Assuming th
On Thu, Sep 19, 2013 at 1:56 AM, Tetsuo Handa
wrote:
> George Spelvin wrote:
>> >> seq_setwidth(m, 21);
>> >> seq_printf(m, "%s%d", con->name, con->index);
>> >> seq_pad(m, '\n');
>>
>> > Ooh, I like this a lot! Much cleaner.
>>
>> That's certainly a good way to do it, too.
>> My "general pr
George Spelvin wrote:
> >> seq_setwidth(m, 21);
> >> seq_printf(m, "%s%d", con->name, con->index);
> >> seq_pad(m, '\n');
>
> > Ooh, I like this a lot! Much cleaner.
>
> That's certainly a good way to do it, too.
> My "general principles" filter thinks it should be in a local variable
> if
>> seq_setwidth(m, 21);
>> seq_printf(m, "%s%d", con->name, con->index);
>> seq_pad(m, '\n');
> Ooh, I like this a lot! Much cleaner.
That's certainly a good way to do it, too.
My "general principles" filter thinks it should be in a local variable
if it can, but if hiding it in the struct s
On Tue, Sep 17, 2013 at 6:06 AM, Tetsuo Handa
wrote:
> Kees Cook wrote:
>> On Mon, Sep 16, 2013 at 1:09 AM, Geert Uytterhoeven
>> wrote:
>> > On Mon, Sep 16, 2013 at 9:43 AM, Kees Cook wrote:
>> >> All users of %n are calculating padding size when using seq_file, so
>> >> instead use the new las
Kees Cook wrote:
> On Mon, Sep 16, 2013 at 1:09 AM, Geert Uytterhoeven
> wrote:
> > On Mon, Sep 16, 2013 at 9:43 AM, Kees Cook wrote:
> >> All users of %n are calculating padding size when using seq_file, so
> >> instead use the new last_len member for discovering the length of the
> >> written s
On Mon, 2013-09-16 at 15:15 -0400, George Spelvin wrote:
> > It'd be consistent with all the other %p types.
> >
> > vsnprintf is already weird enough with %p uses,
> > there's absolutely no reason to stretch it further
> > with yet another odd access/format style.
>
> Well, all the other %p types
> It'd be consistent with all the other %p types.
>
> vsnprintf is already weird enough with %p uses,
> there's absolutely no reason to stretch it further
> with yet another odd access/format style.
Well, all the other %p types actually *use* the void * argument.
They print the thing pointed to, j
On Mon, 2013-09-16 at 12:39 -0400, George Spelvin wrote:
> > %*p (space assumed if not existing)
>
> Yes, that's the fallback, but it requires an ugly dummy pointer argument.
> And some extra kludgery in the code because pointer() doesn't have access
> to the start-of-buffer address.
>
> I'd prefe
On Mon, 2013-09-16 at 13:21 -0400, George Spelvin wrote:
> > My thought was to add a seq_last_len()
>
> In addition to adding per-call overhead to support a rarely-used feature
> (while ->pos comes for free), this has the downside that it matters how
> many separate calls are used to generate the
> My thought was to add a seq_last_len()
In addition to adding per-call overhead to support a rarely-used feature
(while ->pos comes for free), this has the downside that it matters how
many separate calls are used to generate the string.
The advantage of the "read ->pos before and after" techniq
> %*p (space assumed if not existing)
Yes, that's the fallback, but it requires an ugly dummy pointer argument.
And some extra kludgery in the code because pointer() doesn't have access
to the start-of-buffer address.
I'd prefer something that could be detected with the information available
in t
On Mon, 2013-09-16 at 12:07 -0400, George Spelvin wrote:
> it gave me an idea. We could put this padding logic straight
> into vsprintf and clean up all the callers.
[]
> Since the only pad character currently used is space, we could omit the
> argument and use something like %127%, but gcc gets e
> All users of %n are calculating padding size when using seq_file, so
> instead use the new last_len member for discovering the length of the
> written strings.
Obviously, this comment needs to be updated, but once that is done,
Acked-by: George Spelvin .
I actually reviewed all the users and ch
On Mon, 2013-09-16 at 08:25 -0700, Kees Cook wrote:
> On Mon, Sep 16, 2013 at 8:09 AM, Joe Perches wrote:
> > On Mon, 2013-09-16 at 07:59 -0700, Kees Cook wrote:
> >> Perhaps instead of seq->count, there should be an access function?
> >> seq_get_count(seq) or something?
> >
> > My thought was to
On Mon, Sep 16, 2013 at 8:09 AM, Joe Perches wrote:
> On Mon, 2013-09-16 at 07:59 -0700, Kees Cook wrote:
>> Perhaps instead of seq->count, there should be an access function?
>> seq_get_count(seq) or something?
>
> My thought was to add a seq_last_len()
That would mean growing the size of the se
On Mon, Sep 16, 2013 at 4:41 AM, Tetsuo Handa
wrote:
> Kees Cook wrote:
>> - seq_printf(m, "%s%d%n", con->name, con->index, &len);
>> - len = 21 - len;
>> + len = m->count;
>> + seq_printf(m, "%s%d", con->name, con->index);
>> + len = 21 - (m->count - len);
>
> Why not to creat
On Mon, 2013-09-16 at 07:59 -0700, Kees Cook wrote:
> Perhaps instead of seq->count, there should be an access function?
> seq_get_count(seq) or something?
My thought was to add a seq_last_len()
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Mon, Sep 16, 2013 at 1:09 AM, Geert Uytterhoeven
wrote:
> On Mon, Sep 16, 2013 at 9:43 AM, Kees Cook wrote:
>> All users of %n are calculating padding size when using seq_file, so
>> instead use the new last_len member for discovering the length of the
>> written strings.
>
> Would it make sen
Kees Cook wrote:
> - seq_printf(m, "%s%d%n", con->name, con->index, &len);
> - len = 21 - len;
> + len = m->count;
> + seq_printf(m, "%s%d", con->name, con->index);
> + len = 21 - (m->count - len);
Why not to create a new function which returns bytes written?
The new function d
On Mon, Sep 16, 2013 at 9:43 AM, Kees Cook wrote:
> All users of %n are calculating padding size when using seq_file, so
> instead use the new last_len member for discovering the length of the
> written strings.
Would it make sense to provide a seq_pad(...) function instead, to avoid
exposing mor
All users of %n are calculating padding size when using seq_file, so
instead use the new last_len member for discovering the length of the
written strings.
Signed-off-by: Kees Cook
---
fs/proc/consoles.c |5 +++--
fs/proc/nommu.c |6 --
fs/proc/task_mmu.c |6 --
fs/p
32 matches
Mail list logo
