Messages in this thread | | | Subject | Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line | From | He Zhe <> | Date | Tue, 25 Sep 2018 23:31:05 +0800 |
| |
On 2018年09月25日 21:31, Sergey Senozhatsky wrote: > On (09/25/18 14:23), Petr Mladek wrote: >> The 32GB was mentioned as an example one year ego. This is not enough >> for a new syscall from my point of view. > I agree. I didn't think of syslog(); was merely thinking about logbuf > and flushing it to the consoles. syslog() stuff is a bit complex. We > sort of don't expect user space to allocate 64G to read all log_buf > messages, do we. > > I'm wondering if we can do something like this > > --- > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index cf275f4d7912..1b48b61da8fe 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1110,9 +1110,15 @@ static void __init log_buf_len_update(unsigned size) > /* save requested log_buf_len since it's too early to process it */ > static int __init log_buf_len_setup(char *str) > { > - unsigned size = memparse(str, &str); > + u64 size = memparse(str, &str); > > - log_buf_len_update(size); > + if (size > UINT_MAX) { > + size = UINT_MAX; > + pr_err("log_buf over 4G is not supported. " > + "Please contact printk maintainers.\n"); > + } > + > + log_buf_len_update((unsigned int)size); > > return 0; > } > > --- > > So we could know that "the day has come".
I agree on this idea, a good way to collect the potential requirement. I can send v4 with it if no objection from other people.
Thanks, Zhe
> > -ss >
| |