Sergey Senozhatsky wrote:
> To my personal taste, "baud rate of registered and enabled consoles"
> approach is drastically more relevant than hard coded 10 * HZ or
> 60 * HZ magic numbers... But not in the form of that "min baud rate"
> brain fart, which I have posted.
I'm saying that my 60 * HZ
Sergey Senozhatsky wrote:
> On (10/17/18 12:28), Michal Hocko wrote:
> > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > that patch is appropriate because that patch does not ratelimit
> > >
> > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl,
Sergey Senozhatsky wrote:
> On (10/17/18 12:28), Michal Hocko wrote:
> > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > that patch is appropriate because that patch does not ratelimit
> > >
> > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl,
/09/10 15:07, Tetsuo Handa wrote:
> On 2018/09/03 20:44, Tetsuo Handa wrote:
>> We are getting reports from syzbot where running task seems to be
>> relevant to a hung task problem but NMI backtrace does not print useful
>> information [1].
>
> According to my local cach
/09/10 15:07, Tetsuo Handa wrote:
> On 2018/09/03 20:44, Tetsuo Handa wrote:
>> We are getting reports from syzbot where running task seems to be
>> relevant to a hung task problem but NMI backtrace does not print useful
>> information [1].
>
> According to my local cach
f4c33a47c1192d2d62d2e03efffa64
[2] https://lkml.kernel.org/r/20181010151135.25766-1-mho...@kernel.org
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Johannes Weiner
Cc: Michal Hocko
---
mm/oom_kill.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.
f4c33a47c1192d2d62d2e03efffa64
[2] https://lkml.kernel.org/r/20181010151135.25766-1-mho...@kernel.org
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Johannes Weiner
Cc: Michal Hocko
---
mm/oom_kill.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.
Petr Mladek wrote:
> On Sat 2018-10-13 13:39:40, Tetsuo Handa wrote:
> > +struct printk_buffer;
> > +#if defined(CONFIG_PRINTK_LINE_BUFFERED)
> > +struct printk_buffer *get_printk_buffer(void);
> > +void flush_printk_buffer(struct printk_buffer *ptr);
> > +__prin
Petr Mladek wrote:
> On Sat 2018-10-13 13:39:40, Tetsuo Handa wrote:
> > +struct printk_buffer;
> > +#if defined(CONFIG_PRINTK_LINE_BUFFERED)
> > +struct printk_buffer *get_printk_buffer(void);
> > +void flush_printk_buffer(struct printk_buffer *ptr);
> > +__prin
On 2018/10/16 18:20, Michal Hocko wrote:
>> Anyway, I'm OK if we apply _BOTH_ your patch and my patch. Or I'm OK with
>> simplified
>> one shown below (because you don't like per memcg limit).
>
> My patch is adding a rate-limit! I really fail to see why we need yet
> another one on top of it.
On 2018/10/16 18:20, Michal Hocko wrote:
>> Anyway, I'm OK if we apply _BOTH_ your patch and my patch. Or I'm OK with
>> simplified
>> one shown below (because you don't like per memcg limit).
>
> My patch is adding a rate-limit! I really fail to see why we need yet
> another one on top of it.
On 2018/10/15 22:35, Michal Hocko wrote:
>> Nobody can prove that it never kills some machine. This is just one example
>> result of
>> one example stress tried in my environment. Since I am secure programming
>> man from security
>> subsystem, I really hate your "Can you trigger it?"
On 2018/10/15 22:35, Michal Hocko wrote:
>> Nobody can prove that it never kills some machine. This is just one example
>> result of
>> one example stress tried in my environment. Since I am secure programming
>> man from security
>> subsystem, I really hate your "Can you trigger it?"
On 2018/10/15 20:24, Michal Hocko wrote:
> On Mon 15-10-18 19:57:35, Tetsuo Handa wrote:
>> On 2018/10/15 17:19, Michal Hocko wrote:
>>> As so many dozens of times before, I will point you to an incremental
>>> nature of changes we really prefer in the mm land. We are
On 2018/10/15 20:24, Michal Hocko wrote:
> On Mon 15-10-18 19:57:35, Tetsuo Handa wrote:
>> On 2018/10/15 17:19, Michal Hocko wrote:
>>> As so many dozens of times before, I will point you to an incremental
>>> nature of changes we really prefer in the mm land. We are
On 2018/10/15 17:19, Michal Hocko wrote:
> As so many dozens of times before, I will point you to an incremental
> nature of changes we really prefer in the mm land. We are also after a
> simplicity which your proposal lacks in many aspects. You seem to ignore
> that general approach and I have
On 2018/10/15 17:19, Michal Hocko wrote:
> As so many dozens of times before, I will point you to an incremental
> nature of changes we really prefer in the mm land. We are also after a
> simplicity which your proposal lacks in many aspects. You seem to ignore
> that general approach and I have
On 2018/10/13 20:22, Johannes Weiner wrote:
> On Sat, Oct 13, 2018 at 08:09:30PM +0900, Tetsuo Handa wrote:
>> -- Michal's patch --
>>
>> 73133 lines (5.79MB) of kernel messages per one run
>>
>> [root@ccsecurity ~]# time ./a.out
>>
>>
On 2018/10/13 20:22, Johannes Weiner wrote:
> On Sat, Oct 13, 2018 at 08:09:30PM +0900, Tetsuo Handa wrote:
>> -- Michal's patch --
>>
>> 73133 lines (5.79MB) of kernel messages per one run
>>
>> [root@ccsecurity ~]# time ./a.out
>>
>>
On 2018/10/12 21:58, Tetsuo Handa wrote:
> On 2018/10/12 21:41, Johannes Weiner wrote:
>> On Fri, Oct 12, 2018 at 09:10:40PM +0900, Tetsuo Handa wrote:
>>> On 2018/10/12 21:08, Michal Hocko wrote:
>>>>> So not more than 10 dumps in each 5s interval. That looks re
On 2018/10/12 21:58, Tetsuo Handa wrote:
> On 2018/10/12 21:41, Johannes Weiner wrote:
>> On Fri, Oct 12, 2018 at 09:10:40PM +0900, Tetsuo Handa wrote:
>>> On 2018/10/12 21:08, Michal Hocko wrote:
>>>>> So not more than 10 dumps in each 5s interval. That looks re
=> buf = get_printk_buffer();
printk("World.\n"); buffered_printk(buf, "Hello\n");
buffered_printk(buf, "World.\n");
put_printk_buffer(buf);
Note that bpr_devel() and bpr_debug() are not defined. Th
=> buf = get_printk_buffer();
printk("World.\n"); buffered_printk(buf, "Hello\n");
buffered_printk(buf, "World.\n");
put_printk_buffer(buf);
Note that bpr_devel() and bpr_debug() are not defined. Th
Calling printk() people. ;-)
On 2018/10/12 21:41, Johannes Weiner wrote:
> On Fri, Oct 12, 2018 at 09:10:40PM +0900, Tetsuo Handa wrote:
>> On 2018/10/12 21:08, Michal Hocko wrote:
>>>> So not more than 10 dumps in each 5s interval. That looks reasonable
>>>> to m
Calling printk() people. ;-)
On 2018/10/12 21:41, Johannes Weiner wrote:
> On Fri, Oct 12, 2018 at 09:10:40PM +0900, Tetsuo Handa wrote:
>> On 2018/10/12 21:08, Michal Hocko wrote:
>>>> So not more than 10 dumps in each 5s interval. That looks reasonable
>>>> to m
On 2018/10/12 21:08, Michal Hocko wrote:
>> So not more than 10 dumps in each 5s interval. That looks reasonable
>> to me. By the time it starts dropping data you have more than enough
>> information to go on already.
>
> Yeah. Unless we have a storm coming from many different cgroups in
>
On 2018/10/12 21:08, Michal Hocko wrote:
>> So not more than 10 dumps in each 5s interval. That looks reasonable
>> to me. By the time it starts dropping data you have more than enough
>> information to go on already.
>
> Yeah. Unless we have a storm coming from many different cgroups in
>
On 2018/10/11 15:37, Tetsuo Handa wrote:
> Michal Hocko wrote:
>> Once we are here, make sure that the reason to trigger the OOM is
>> printed without ratelimiting because this is really valuable to
>> debug what happened.
>
> Here is my version.
>
Hmm, per mem_cg
On 2018/10/11 15:37, Tetsuo Handa wrote:
> Michal Hocko wrote:
>> Once we are here, make sure that the reason to trigger the OOM is
>> printed without ratelimiting because this is really valuable to
>> debug what happened.
>
> Here is my version.
>
Hmm, per mem_cg
On 2018/10/10 19:14, Tetsuo Handa wrote:
> On 2018/10/10 6:19, Tetsuo Handa wrote:
>> Do you think that adding cmpxchg() & retry logic to this API generates better
>> result than simple fallback? buffered_printk() does not add a new locking
>> dependency
>> is a
On 2018/10/10 19:14, Tetsuo Handa wrote:
> On 2018/10/10 6:19, Tetsuo Handa wrote:
>> Do you think that adding cmpxchg() & retry logic to this API generates better
>> result than simple fallback? buffered_printk() does not add a new locking
>> dependency
>> is a
Michal Hocko wrote:
> Once we are here, make sure that the reason to trigger the OOM is
> printed without ratelimiting because this is really valuable to
> debug what happened.
Here is my version.
>From 0c9ab34fd01837d4c85794042ecb9e922c9eed5a Mon Sep 17 00:00:00 2001
From: Tetsuo
Michal Hocko wrote:
> Once we are here, make sure that the reason to trigger the OOM is
> printed without ratelimiting because this is really valuable to
> debug what happened.
Here is my version.
>From 0c9ab34fd01837d4c85794042ecb9e922c9eed5a Mon Sep 17 00:00:00 2001
From: Tetsuo
On 2018/10/10 20:35, Michal Hocko wrote:
What should we do if memcg-OOM found no killable task because the
allocating task
was oom_score_adj == -1000 ? Flooding printk() until RCU stall watchdog
fires
(which seems to be caused by commit 3100dab2aa09dc6e ("mm:
On 2018/10/10 20:35, Michal Hocko wrote:
What should we do if memcg-OOM found no killable task because the
allocating task
was oom_score_adj == -1000 ? Flooding printk() until RCU stall watchdog
fires
(which seems to be caused by commit 3100dab2aa09dc6e ("mm:
On 2018/10/10 21:36, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 2:29 PM, Dmitry Vyukov wrote:
>> On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
>>> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
On (10/10/18 13:35), Michal Hocko wrote:
>> Just flooding out of memory
On 2018/10/10 21:36, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 2:29 PM, Dmitry Vyukov wrote:
>> On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
>>> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
On (10/10/18 13:35), Michal Hocko wrote:
>> Just flooding out of memory
On 2018/10/10 17:59, Michal Hocko wrote:
> On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
>> syzbot is hitting RCU stall due to memcg-OOM event.
>> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
>
> This is really interesting. If we do not
On 2018/10/10 17:59, Michal Hocko wrote:
> On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
>> syzbot is hitting RCU stall due to memcg-OOM event.
>> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
>
> This is really interesting. If we do not
On 2018/10/10 6:19, Tetsuo Handa wrote:
> Do you think that adding cmpxchg() & retry logic to this API generates better
> result than simple fallback? buffered_printk() does not add a new locking
> dependency
> is a good point of this API. Showing the backtrace (by enabling a
On 2018/10/10 6:19, Tetsuo Handa wrote:
> Do you think that adding cmpxchg() & retry logic to this API generates better
> result than simple fallback? buffered_printk() does not add a new locking
> dependency
> is a good point of this API. Showing the backtrace (by enabling a
syzbot is hitting RCU stall due to memcg-OOM event.
https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
What should we do if memcg-OOM found no killable task because the allocating
task
was oom_score_adj == -1000 ? Flooding printk() until RCU stall watchdog fires
syzbot is hitting RCU stall due to memcg-OOM event.
https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
What should we do if memcg-OOM found no killable task because the allocating
task
was oom_score_adj == -1000 ? Flooding printk() until RCU stall watchdog fires
On 2018/10/09 23:52, Petr Mladek wrote:
> On Tue 2018-10-09 05:48:33, Tetsuo Handa wrote:
>> On 2018/10/09 1:03, Petr Mladek wrote:
>>> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
>>>> A structure named "struct printk_buffer" is introduced for b
On 2018/10/09 23:52, Petr Mladek wrote:
> On Tue 2018-10-09 05:48:33, Tetsuo Handa wrote:
>> On 2018/10/09 1:03, Petr Mladek wrote:
>>> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
>>>> A structure named "struct printk_buffer" is introduced for b
On 2018/10/09 22:26, Michal Hocko wrote:
> On Tue 09-10-18 22:14:24, Tetsuo Handa wrote:
>> On 2018/10/09 21:58, Michal Hocko wrote:
>>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote:
>>>> On 2018/10/09 20:10, Michal Hocko wrote:
>>>>> On Tue 09-10-18
On 2018/10/09 22:26, Michal Hocko wrote:
> On Tue 09-10-18 22:14:24, Tetsuo Handa wrote:
>> On 2018/10/09 21:58, Michal Hocko wrote:
>>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote:
>>>> On 2018/10/09 20:10, Michal Hocko wrote:
>>>>> On Tue 09-10-18
On 2018/10/09 21:58, Michal Hocko wrote:
> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote:
>> On 2018/10/09 20:10, Michal Hocko wrote:
>>> On Tue 09-10-18 19:00:44, Tetsuo Handa wrote:
>>>>> 2) add OOM_SCORE_ADJ_MIN and do not kill tasks sharing mm and do not
&
On 2018/10/09 21:58, Michal Hocko wrote:
> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote:
>> On 2018/10/09 20:10, Michal Hocko wrote:
>>> On Tue 09-10-18 19:00:44, Tetsuo Handa wrote:
>>>>> 2) add OOM_SCORE_ADJ_MIN and do not kill tasks sharing mm and do not
&
On 2018/10/09 20:10, Michal Hocko wrote:
> On Tue 09-10-18 19:00:44, Tetsuo Handa wrote:
>>> 2) add OOM_SCORE_ADJ_MIN and do not kill tasks sharing mm and do not
>>> reap the mm in the rare case of the race.
>>
>> That is no problem. The mistake we made in 4.6 was
On 2018/10/09 20:10, Michal Hocko wrote:
> On Tue 09-10-18 19:00:44, Tetsuo Handa wrote:
>>> 2) add OOM_SCORE_ADJ_MIN and do not kill tasks sharing mm and do not
>>> reap the mm in the rare case of the race.
>>
>> That is no problem. The mistake we made in 4.6 was
On 2018/10/09 16:50, Michal Hocko wrote:
> On Tue 09-10-18 08:35:41, Michal Hocko wrote:
>> [I have only now noticed that the patch has been reposted]
>>
>> On Mon 08-10-18 18:27:39, Tetsuo Handa wrote:
>>> On 2018/10/08 17:38, Yong-Taek Lee wrote:
> [...]
>>
On 2018/10/09 16:50, Michal Hocko wrote:
> On Tue 09-10-18 08:35:41, Michal Hocko wrote:
>> [I have only now noticed that the patch has been reposted]
>>
>> On Mon 08-10-18 18:27:39, Tetsuo Handa wrote:
>>> On 2018/10/08 17:38, Yong-Taek Lee wrote:
> [...]
>>
On 2018/10/09 1:03, Petr Mladek wrote:
> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
>> A structure named "struct printk_buffer" is introduced for buffering
>> up to LOG_LINE_MAX bytes of printk() output which did not end with '\n'.
>>
>> A calle
On 2018/10/09 1:03, Petr Mladek wrote:
> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
>> A structure named "struct printk_buffer" is introduced for buffering
>> up to LOG_LINE_MAX bytes of printk() output which did not end with '\n'.
>>
>> A calle
g feature XYZ..");
this_may_blow_up_because_of_hw_bugs();
printk(KERN_CONT " ... ok\n");
to
printk("Testing feature XYZ..\n");
this_may_blow_up_because_of_hw_bugs();
printk("... feature XYZ ok\n");
and eventually remove pr_cont/print
g feature XYZ..");
this_may_blow_up_because_of_hw_bugs();
printk(KERN_CONT " ... ok\n");
to
printk("Testing feature XYZ..\n");
this_may_blow_up_because_of_hw_bugs();
printk("... feature XYZ ok\n");
and eventually remove pr_cont/print
On 2018/10/08 17:38, Yong-Taek Lee wrote:
>>
>> On 2018/10/08 15:14, Yong-Taek Lee wrote:
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
>
On 2018/10/08 17:38, Yong-Taek Lee wrote:
>>
>> On 2018/10/08 15:14, Yong-Taek Lee wrote:
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
>
On 2018/10/08 15:14, Yong-Taek Lee wrote:
>> On 2018/10/08 10:19, Yong-Taek Lee wrote:
>>> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
>>> oom_adj, bool legacy)
>>> struct mm_struct *mm = NULL;
>>> struct task_struct *task;
>>> int err = 0;
>>> +
On 2018/10/08 15:14, Yong-Taek Lee wrote:
>> On 2018/10/08 10:19, Yong-Taek Lee wrote:
>>> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
>>> oom_adj, bool legacy)
>>> struct mm_struct *mm = NULL;
>>> struct task_struct *task;
>>> int err = 0;
>>> +
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> + int mm_users = 0;
>
> task =
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> + int mm_users = 0;
>
> task =
On 2018/10/01 11:37, Sergey Senozhatsky wrote:
> On (09/29/18 20:15), Tetsuo Handa wrote:
>>
>> Because there is no guarantee that memory information is dumped under the
>> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
>> cannot be held when
On 2018/10/01 11:37, Sergey Senozhatsky wrote:
> On (09/29/18 20:15), Tetsuo Handa wrote:
>>
>> Because there is no guarantee that memory information is dumped under the
>> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
>> cannot be held when
On 2018/09/29 20:13, Sergey Senozhatsky wrote:
> On (09/28/18 20:21), Tetsuo Handa wrote:
>> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
>>> The good thing about cont buffer is that we flush it on panic. E.g.
>>> core/arch early boot stage can do:
>>
On 2018/09/29 20:13, Sergey Senozhatsky wrote:
> On (09/28/18 20:21), Tetsuo Handa wrote:
>> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
>>> The good thing about cont buffer is that we flush it on panic. E.g.
>>> core/arch early boot stage can do:
>>
On 2018/09/29 19:51, Sergey Senozhatsky wrote:
> On (09/28/18 20:01), Tetsuo Handa wrote:
>>> Yes, this makes sense. At the same time we can keep pr_line buffer
>>> in .bss
>>>
>>> static char buffer[1024];
>>> static DEFINE_PR_LINE_BUF(
On 2018/09/29 19:51, Sergey Senozhatsky wrote:
> On (09/28/18 20:01), Tetsuo Handa wrote:
>>> Yes, this makes sense. At the same time we can keep pr_line buffer
>>> in .bss
>>>
>>> static char buffer[1024];
>>> static DEFINE_PR_LINE_BUF(
On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> The good thing about cont buffer is that we flush it on panic. E.g.
> core/arch early boot stage can do:
>
> pr_cont("going to call early_init_foo()...");
> early_init_foo();
> pr_cont("OK\n");
>
Is printing
going to call
On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> The good thing about cont buffer is that we flush it on panic. E.g.
> core/arch early boot stage can do:
>
> pr_cont("going to call early_init_foo()...");
> early_init_foo();
> pr_cont("OK\n");
>
Is printing
going to call
On 2018/09/28 18:09, Sergey Senozhatsky wrote:
> On (09/24/18 17:11), Tetsuo Handa wrote:
>> The reason of using statically preallocated global buffers is that I think
>> that it is inconvenient for KERN_CONT users to calculate necessary bytes
>> only for avoiding message tr
On 2018/09/28 18:09, Sergey Senozhatsky wrote:
> On (09/24/18 17:11), Tetsuo Handa wrote:
>> The reason of using statically preallocated global buffers is that I think
>> that it is inconvenient for KERN_CONT users to calculate necessary bytes
>> only for avoiding message tr
On 2018/09/28 7:19, Dave Chinner wrote:> IOWs, the security_file_ioctl() hook
is almost completely useless in
> cases like this - you can't isolate the ioctl based on the file
> argument, because it can point to any file or directory in the
> filesystem. And without actually parsing, decoding and
On 2018/09/28 7:19, Dave Chinner wrote:> IOWs, the security_file_ioctl() hook
is almost completely useless in
> cases like this - you can't isolate the ioctl based on the file
> argument, because it can point to any file or directory in the
> filesystem. And without actually parsing, decoding and
On 2018/09/24 17:11, Tetsuo Handa wrote:
> On 2018/09/19 20:02, Tetsuo Handa wrote:
>> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>>> static buffer. Either we need to require sync
On 2018/09/24 17:11, Tetsuo Handa wrote:
> On 2018/09/19 20:02, Tetsuo Handa wrote:
>> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>>> static buffer. Either we need to require sync
On 2018/09/25 17:55, Petr Mladek wrote:
>> I guess the patch below fixes it, however the kworker should not really be
>> blocked by this I think ... adding a few more printk folks to double-check
>> why the kworker would get stuck due to massive printk() flood.
>
> It seems that the many
On 2018/09/25 17:55, Petr Mladek wrote:
>> I guess the patch below fixes it, however the kworker should not really be
>> blocked by this I think ... adding a few more printk folks to double-check
>> why the kworker would get stuck due to massive printk() flood.
>
> It seems that the many
On 2018/09/24 22:31, Dmitry Vyukov wrote:
> On Mon, Sep 24, 2018 at 3:19 PM, Jiri Kosina wrote:
>> On Sun, 16 Sep 2018, Amir Goldstein wrote:
>>
> syzbot found the following crash on:
>
> HEAD commit:11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output:
On 2018/09/24 22:31, Dmitry Vyukov wrote:
> On Mon, Sep 24, 2018 at 3:19 PM, Jiri Kosina wrote:
>> On Sun, 16 Sep 2018, Amir Goldstein wrote:
>>
> syzbot found the following crash on:
>
> HEAD commit:11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output:
On 2018/09/24 7:03, Ming Lei wrote:
> On Sat, Sep 22, 2018 at 09:39:02PM +0900, Tetsuo Handa wrote:
>> Hello, Ming Lei.
>>
>> I'd like to hear your comment on this patch regarding the ordering of
>> stopping kernel thread.
>>
>> > In order to
On 2018/09/24 7:03, Ming Lei wrote:
> On Sat, Sep 22, 2018 at 09:39:02PM +0900, Tetsuo Handa wrote:
>> Hello, Ming Lei.
>>
>> I'd like to hear your comment on this patch regarding the ordering of
>> stopping kernel thread.
>>
>> > In order to
On 2018/09/19 20:02, Tetsuo Handa wrote:
> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>> static buffer. Either we need to require synchronization - umm... and
>> document it - or to provid
On 2018/09/19 20:02, Tetsuo Handa wrote:
> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>> static buffer. Either we need to require synchronization - umm... and
>> document it - or to provid
ext.
After almost all users are converted to use below one, we might be able
to get rid of KERN_CONT support.
>From d5e0e422142ced2b7097040e96ba7c5528a460db Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 19 Sep 2018 14:39:07 +0900
Subject: [PATCH v2] printk: Add best-effort prin
ext.
After almost all users are converted to use below one, we might be able
to get rid of KERN_CONT support.
>From d5e0e422142ced2b7097040e96ba7c5528a460db Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 19 Sep 2018 14:39:07 +0900
Subject: [PATCH v2] printk: Add best-effort prin
On 2018/09/17 8:00, Kees Cook wrote:
> On Sun, Sep 16, 2018 at 11:49 AM, Casey Schaufler
> wrote:
>> One solution is to leave security= as is, not affecting "minor"
>> modules and only allowing specification of one major module, and adding
>
> I would much prefer this, yes.
>
> A question
On 2018/09/17 8:00, Kees Cook wrote:
> On Sun, Sep 16, 2018 at 11:49 AM, Casey Schaufler
> wrote:
>> One solution is to leave security= as is, not affecting "minor"
>> modules and only allowing specification of one major module, and adding
>
> I would much prefer this, yes.
>
> A question
On 2018/09/15 11:33, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=141ffbca40
> kernel config:
On 2018/09/15 11:33, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=141ffbca40
> kernel config:
On 2018/09/14 20:50, Sergey Senozhatsky wrote:
>>> +#define DEFINE_PR_LINE_BUF(lev, name, buf, sz) \
>>> + struct pr_line name = {\
>>> + .sb = __SEQ_BUF_INITIALIZER(buf, (sz)), \
>>> + .level = lev,
On 2018/09/14 20:50, Sergey Senozhatsky wrote:
>>> +#define DEFINE_PR_LINE_BUF(lev, name, buf, sz) \
>>> + struct pr_line name = {\
>>> + .sb = __SEQ_BUF_INITIALIZER(buf, (sz)), \
>>> + .level = lev,
On 2018/09/14 15:57, Sergey Senozhatsky wrote:
> On (09/13/18 23:28), Sergey Senozhatsky wrote:
>> Not that I see any problems with pr_line_flush(). But can drop it, sure.
>> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
>> buffering.
>
> OK, attached.
> Let me know
On 2018/09/14 15:57, Sergey Senozhatsky wrote:
> On (09/13/18 23:28), Sergey Senozhatsky wrote:
>> Not that I see any problems with pr_line_flush(). But can drop it, sure.
>> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
>> buffering.
>
> OK, attached.
> Let me know
On 2018/09/13 21:58, Dmitry Vyukov wrote:
> On Wed, May 2, 2018 at 1:23 PM, Dmitry Vyukov wrote:
>> On Wed, May 2, 2018 at 12:30 PM, Tetsuo Handa
>> wrote:
>>> Dmitry Vyukov wrote:
>>>>> syzbot is reporting various bugs which involve /dev/loopX.
>>>
On 2018/09/13 21:58, Dmitry Vyukov wrote:
> On Wed, May 2, 2018 at 1:23 PM, Dmitry Vyukov wrote:
>> On Wed, May 2, 2018 at 12:30 PM, Tetsuo Handa
>> wrote:
>>> Dmitry Vyukov wrote:
>>>>> syzbot is reporting various bugs which involve /dev/loopX.
>>>
On 2018/09/03 20:44, Tetsuo Handa wrote:
> We are getting reports from syzbot where running task seems to be
> relevant to a hung task problem but NMI backtrace does not print useful
> information [1].
According to my local cache, 69% of hung task reports from syzbot say that
one CPU wa
On 2018/09/03 20:44, Tetsuo Handa wrote:
> We are getting reports from syzbot where running task seems to be
> relevant to a hung task problem but NMI backtrace does not print useful
> information [1].
According to my local cache, 69% of hung task reports from syzbot say that
one CPU wa
This report contains "getblk(): executed=9 bh_count=0 bh_state=0" lines.
Thus,
#syz dup: INFO: task hung in generic_file_write_iter
701 - 800 of 3819 matches
Mail list logo
