On 2018年09月28日 15:35, Sergey Senozhatsky wrote:
> On (09/26/18 13:05), Petr Mladek wrote:
>> First, I would move the check into log_buf_len_update() so that
>> we catch the overflow also in other situations.
> OK.
>
>> Second, please, keep only the first line.
> OK.
>
>> It is enough to describe
On (09/26/18 13:05), Petr Mladek wrote:
> First, I would move the check into log_buf_len_update() so that
> we catch the overflow also in other situations.
OK.
> Second, please, keep only the first line.
OK.
> It is enough to describe the problem.
OK.
He Zhe, will you pick it up?
-ss
On Tue 2018-09-25 22:31:43, 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 flu
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
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
On (09/25/18 14:23), Petr Mladek wrote:
>
> Thanks for pointing this out. Well, it seems that the change would
> require a new syscall to pass the buffer size as long. We need to
> be sure that people would use this in the real life.
Agreed.
> This thread suggested this change to avoid a checkpa
On Tue 2018-09-25 21:01:35, Sergey Senozhatsky wrote:
> On (09/21/18 09:37), Petr Mladek wrote:
> >
> > I would personally keep the size as unsigned int. IMHO, a support
> > for a log buffer bigger than 4GB is not worth the complexity.
> >
>
> ftrace dumps are bothering me.
>
> Steven Rostedt w
On (09/22/18 23:36), He Zhe wrote:
> I'd like to fix the above issues. But can I have your opinions about how to
> handle the syscall?
Hmm. This part is complex, I need to look at it more.
A signed int is a good buffer size limit for 32-bit user space.
But this also means that syslog might experie
On (09/21/18 09:37), Petr Mladek wrote:
>
> I would personally keep the size as unsigned int. IMHO, a support
> for a log buffer bigger than 4GB is not worth the complexity.
>
ftrace dumps are bothering me.
Steven Rostedt wrote [0]:
>
> Especially when I have a machine with 240 CPUs. But it als
On 2018年09月21日 15:37, Petr Mladek wrote:
> On Thu 2018-09-20 12:30:56, Steven Rostedt wrote:
>> On Fri, 21 Sep 2018 00:16:50 +0800
>> He Zhe wrote:
>>
>>> On 2018年09月19日 10:43, Steven Rostedt wrote:
On Wed, 19 Sep 2018 11:39:32 +0900
Sergey Senozhatsky wrote:
> On (09/19/1
On Thu 2018-09-20 12:30:56, Steven Rostedt wrote:
> On Fri, 21 Sep 2018 00:16:50 +0800
> He Zhe wrote:
>
> > On 2018年09月19日 10:43, Steven Rostedt wrote:
> > > On Wed, 19 Sep 2018 11:39:32 +0900
> > > Sergey Senozhatsky wrote:
> > >
> > >> On (09/19/18 10:27), He Zhe wrote:
> > >>> On 2018年09
On Fri, 21 Sep 2018 00:16:50 +0800
He Zhe wrote:
> On 2018年09月19日 10:43, Steven Rostedt wrote:
> > On Wed, 19 Sep 2018 11:39:32 +0900
> > Sergey Senozhatsky wrote:
> >
> >> On (09/19/18 10:27), He Zhe wrote:
> >>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> On (09/19/18 01:17)
On 2018年09月19日 10:43, Steven Rostedt wrote:
> On Wed, 19 Sep 2018 11:39:32 +0900
> Sergey Senozhatsky wrote:
>
>> On (09/19/18 10:27), He Zhe wrote:
>>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
On (09/19/18 01:17), zhe...@windriver.com wrote:
> @@ -1048,7 +1048,14 @@ static
On 2018年09月19日 14:44, Sergey Senozhatsky wrote:
> On (09/19/18 10:27), He Zhe wrote:
>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
>>> On (09/19/18 01:17), zhe...@windriver.com wrote:
@@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
/* save requested lo
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len since it's too early to process it */
> >>
On Wed, 19 Sep 2018 11:47:54 +0900
Sergey Senozhatsky wrote:
> On (09/18/18 22:43), Steven Rostedt wrote:
> > > First - switch to u64 size.
> > > Second - check for NULL str.
> > >
> > I think I would switch it around. Check for NULL first, and then switch
> > to u64. It was always an int,
On (09/18/18 22:43), Steven Rostedt wrote:
> > First - switch to u64 size.
> > Second - check for NULL str.
> >
> I think I would switch it around. Check for NULL first, and then switch
> to u64. It was always an int, do we need to backport converting it to
> u64 to stable? The NULL check is a
On Wed, 19 Sep 2018 11:39:32 +0900
Sergey Senozhatsky wrote:
> On (09/19/18 10:27), He Zhe wrote:
> > On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > > On (09/19/18 01:17), zhe...@windriver.com wrote:
> > >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned
> > >> siz
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len since it's too early to process it */
> >>
On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> On (09/19/18 01:17), zhe...@windriver.com wrote:
>> @@ -1048,7 +1048,14 @@ 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 *
On (09/19/18 01:17), zhe...@windriver.com wrote:
> @@ -1048,7 +1048,14 @@ 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);
>
21 matches
Mail list logo
