On 2018/06/15 18:19, Dmitry Vyukov wrote:
> On Thu, Jun 14, 2018 at 12:33 PM, Tetsuo Handa
> wrote:
>> On 2018/06/11 16:39, Dmitry Vyukov wrote:
>>> On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra
>>> wrote:
>>>> On Sun, Jun 10, 2018 at 11:47:56PM
This will be essentially same with below one.
ioctl(TIOCVHANGUP) versus ioctl(TCSETS) can race.
#syz dup: KASAN: user-memory-access Write in n_tty_set_termios
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
>From ada7279f7f034c5fd79fc04e1120069ea5f6cef2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 17 May 2018 20:42:50 +0900
Subject: [PATCH] n_tty: Access echo_* variables carefully.
syzbot is report
syzbot wrote:
> INFO: task kworker/u4:1:22 blocked for more than 120 seconds.
> Not tainted 4.17.0-rc5+ #55
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/u4:1D2119222 2 0x8000
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
>
On 2018/08/06 20:56, Tetsuo Handa wrote:
> On 2018/08/06 19:09, Jan Kara wrote:
>> Looks like some kind of a race where device block size gets changed while
>> getblk() runs (and creates buffers for underlying page). I don't have time
>> to nail it down at this moment can
On 2018/12/07 21:43, Tetsuo Handa wrote:
> No response for one month. When can we get to an RCU stall problem syzbot
> reported?
Why not to apply this patch and then think how to address
https://lore.kernel.org/lkml/201810100012.w9a0cjtn047...@www262.sakura.ne.jp/ ?
Stalling inside __getblk_gfp()...
#syz dup: INFO: rcu detected stall in sys_creat
; -#ifdef CONFIG_PRINTK_FROM
> - u32 id = msg->from_id;
> + char caller[18];
> +#ifdef CONFIG_PRINTK_CALLER
> + u32 id = msg->caller_id;
>
> - snprintf(from, sizeof(from), ",from=%c%u",
> + snprintf(caller, sizeof(caller), ",caller
On 2018/12/17 19:08, Dmitry Vyukov wrote:
> On Mon, Dec 17, 2018 at 8:21 AM Al Viro wrote:
>>> slab_pre_alloc_hook mm/slab.h:423 [inline]
>>> slab_alloc mm/slab.c:3365 [inline]
>>> kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539
>>> __d_alloc+0xc8/0xb90 fs/dcache.c:1599
>>> [ cut here
Andrew, will you fold below diff into "mm, oom: add oom victim's memcg to the
oom context information" ?
>From add1e8daddbfc5186417dbc58e9e11e7614868f8 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 19 Dec 2018 16:09:31 +0900
Subject: [PATCH] mm, oom
On 2018/12/19 18:27, syzbot wrote:
> HEAD commit:ddfbab46539f Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b87fa340
> kernel config: https://syzkaller.appspot.com/x/.config?x=861a3573f4e78ba1
> dash
RCU stall warnings. Therefore, calling rcu_lock_break() for
every some fixed jiffies will be safer.
Signed-off-by: Tetsuo Handa
---
kernel/hung_task.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index cb8e3e8..444b8b5 100644
On 2018/12/17 18:33, Michal Hocko wrote:
> On Sun 16-12-18 19:51:57, Matthew Wilcox wrote:
> [...]
>> Ah, yes, that makes perfect sense. Thank you for the explanation.
>>
>> I wonder if the correct fix, however, is not to move the check for
>> GFP_NOFS in out_of_memory() down to below the check wh
On 2018/12/10 15:11, Sergey Senozhatsky wrote:
> On (12/10/18 05:58), Liu, Chuansheng wrote:
>>> On (12/10/18 05:40), Liu, Chuansheng wrote:
@@ -130,6 +130,13 @@ static void check_hung_task(struct task_struct *t,
>>> unsigned long timeout)
init_utsname()->version);
On 2018/12/10 22:09, Petr Mladek wrote:
>> +#ifdef CONFIG_PRINTK_FROM
>> +#define PREFIX_FROM_MAX 16
>> +#define PREFIX_MAX (32 + PREFIX_FROM_MAX)
>> +#define LOG_LINE_MAX(1024 - 32)
>
> This looks suspicious. We either need to limit LOG_LINE_MAX
> by the real
We can save lines/size by removing print_prefix() with buf == NULL.
This patch makes no functional change.
Signed-off-by: Tetsuo Handa
---
kernel/printk/printk.c | 39 ++-
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/kernel/printk/printk.c
On 2018/12/11 10:16, Liu, Chuansheng wrote:
> We may enhance it by:
> - if (sysctl_hung_task_warnings) {
> + if (sysctl_hung_task_panic || sysctl_hung_task_warnings) {
> if (sysctl_hung_task_warnings > 0)
> sysctl_hung_task_warnings--;
Why ignore
>From bdb80508390694456f3f864f9651d047ded109bf Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 11 Dec 2018 19:23:30 +0900
Subject: [PATCH v4] printk: Add caller information to printk() output.
Sometimes we want to print a series of printk() messages to consoles
without being disturbed
On 2018/12/20 10:16, Vineet Gupta wrote:
> On 12/19/18 9:04 AM, Eugeniy Paltsev wrote:
>> As I can see x86 use print_vma_addr() in their show_signal_msg()
>> function which allocate page with __get_free_page(GFP_NOWAIT);
>
> Indeed with that the __get_free_page() lockdep splat is gone.
>
> There'
On 2019/01/03 2:06, Tetsuo Handa wrote:
> On 2018/12/31 17:24, Dmitry Vyukov wrote:
>>>> Since this involves OOMs and looks like a one-off induced memory
>>>> corruption:
>>>>
>>>> #syz dup: kernel panic: corrupted stack end in wb_workfn
>>
On 2019/01/06 22:24, Dmitry Vyukov wrote:
>> A report at 2019/01/05 10:08 from "no output from test machine (2)"
>> ( https://syzkaller.appspot.com/text?tag=CrashLog&x=1700726f40 )
>> says that there are flood of memory allocation failure messages.
>> Since continuous memory allocation failure
On 2019/01/06 22:48, Dmitry Vyukov wrote:
> On Sun, Jan 6, 2019 at 2:31 PM syzbot
> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:3fed6ae4b027 ia64: fix compile without swiotlb
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log
On 2019/01/07 23:38, Michal Hocko wrote:
> From: Michal Hocko
>
> Historically we have called mark_oom_victim only to the main task
> selected as the oom victim because oom victims have access to memory
> reserves and granting the access to all killed tasks could deplete
> memory reserves very qu
On 2019/01/07 23:38, Michal Hocko wrote:
> From: Michal Hocko
>
> Tetsuo has reported [1] that a single process group memcg might easily
> swamp the log with no-eligible oom victim reports due to race between
> the memcg charge and oom_reaper
This explanation is outdated. I reported that one mem
On 2019/01/03 2:26, Jan Kara wrote:
> On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
>> On 2019/01/02 23:40, Jan Kara wrote:
>>> I had a look into this and the only good explanation for this I have is
>>> that sb->s_blocksize is different from (1 <<
>>
On 2019/01/08 17:14, Michal Hocko wrote:
>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>> index af7f18b32389..90eb2e2093e7 100644
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -1387,10 +1387,22 @@ static bool mem_cgroup_out_of_memory(struct
>>> mem_cgroup *memcg, gfp_t gfp_mask,
On 2018/12/31 16:49, Dmitry Vyukov wrote:
> On Mon, Dec 31, 2018 at 8:42 AM syzbot
> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:ef4ab8447aa2 selftests: bpf: install script with_addr.sh
>> git tree: bpf-next
>> console output: https://syzkaller.appspo
Hello, Tejun.
[ 1100.561812] FAULT_INJECTION: forcing a failure.
[ 1100.561812] name failslab, interval 1, probability 0, space 0, times 0
[ 1100.625231] CPU: 1 PID: 29677 Comm: syz-executor0 Not tainted 4.20.0+ #396
[ 1100.632289] Hardware name: Google Google Compute Engine/Google Compute
Engine
On 2019/01/01 12:11, Paul Fulghum wrote:
> NAK to this patch. It causes lost wakeups in both read and write paths.
>
> The write path does not need changing.
>
> The read path can be fixed by setting current to TASK_RUNNING at the top of
> the if (rbuf) block
> so the warning is not triggered by
node->i_blkbits? That should tell us
> whether my theory is right or not. Thanks!
>
OK. Andrew, will you add (or fold into) this change?
>From e6f334380ad2c87457bfc2a4058316c47f75824a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 3 Jan 2019 01:03:35 +0900
Subject: [PATCH] fs
On 2019/01/03 1:16, Tejun Heo wrote:
> Happy new year, Tetsuo.
>
> On Wed, Jan 02, 2019 at 09:08:56PM +0900, Tetsuo Handa wrote:
>> According to commit 633feee310de6b6c ("cgroup: refactor mount path and
>> clearly distinguish v1 and v2 paths"), cgroup_do_mount() is
On 2018/12/31 17:24, Dmitry Vyukov wrote:
>>> Since this involves OOMs and looks like a one-off induced memory corruption:
>>>
>>> #syz dup: kernel panic: corrupted stack end in wb_workfn
>>>
>>
>> Why?
>>
>> RCU stall in this case is likely to be latency caused by flooding of
>> printk().
>
> Ju
On 2019/01/03 2:26, Jan Kara wrote:
> On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
>> On 2019/01/02 23:40, Jan Kara wrote:
>>> I had a look into this and the only good explanation for this I have is
>>> that sb->s_blocksize is different from (1 <<
>>
On 2019/01/03 3:19, Qian Cai wrote:
> On 1/2/19 1:06 PM, Mel Gorman wrote:
>
>> While I recognise there is no test case available, how often does this
>> trigger in syzbot as it would be nice to have some confirmation any
>> patch is really fixing the problem.
>
> I think I did manage to trigger
On 2019/01/03 18:09, Jiri Slaby wrote:
> On 02. 01. 19, 16:04, Tetsuo Handa wrote:
>> +if (wait_event_interruptible(tty->read_wait,
>> + (ret = -EIO, test_bit(TTY_OTHER_CLOSED, &tty->flags)) ||
>> + (ret = 0, tty_hung_up_p(file)) ||
>> +
ep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 4 Jan 2019 15:23:47 +0900
Subject: [PATCH] gpu/drm: Fix lock held when returning to user space.
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
succeed
On 2019/01/04 0:57, Paul Fulghum wrote:
>> On Jan 3, 2019, at 3:32 AM, Tetsuo Handa
>> wrote:
>>
>> On 2019/01/03 18:09, Jiri Slaby wrote:
>>> On 02. 01. 19, 16:04, Tetsuo Handa wrote:
>>>> + if (wait_event_interruptible(tty->read_wait,
>>&
On 2018/08/06 19:09, Jan Kara wrote:
> On Tue 31-07-18 00:07:22, Tetsuo Handa wrote:
>> On 2018/07/21 5:06, Andrew Morton wrote:
>>> On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
>>> wrote:
>>>
>>>>>
>>>>> This report is stallin
appspot.com/bug?id=17d5de7f1fcab794cb8c40032f893f52de899324
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Paul Fulghum
Cc: Arnd Bergmann
Cc: Alan Cox
---
drivers/tty/n_hdlc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/n_hdlc.c b/drivers/tty
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'.
>>
>>
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 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 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 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 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 buff
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
(which
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 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 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 messag
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: memcontrol:
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:
> @@ -3156,6 +3166,13 @@ void exit_mmap(struct mm_struct *mm)
> vma = remove_vma(vma);
> }
> vm_unacct_memory(nr_accounted);
> +
> + /*
> +* Now that the full address space is torn down, make sure the
> +* OOM killer skips ov
On 2018/10/30 15:31, Michal Hocko wrote:
> On Tue 30-10-18 13:45:22, Tetsuo Handa wrote:
>> Michal Hocko wrote:
>>> @@ -3156,6 +3166,13 @@ void exit_mmap(struct mm_struct *mm)
>>> vma = remove_vma(vma);
>>> }
>&
On 2018/10/30 20:39, Michal Hocko wrote:
> On Tue 30-10-18 18:47:43, Tetsuo Handa wrote:
>> On 2018/10/30 15:31, Michal Hocko wrote:
>>> On Tue 30-10-18 13:45:22, Tetsuo Handa wrote:
>>>> Michal Hocko wrote:
>>>>> @@ -3156,6 +3
On 2018/10/30 21:10, Michal Hocko wrote:
> I misunderstood your concern. oom_reaper would back off without
> MMF_OOF_SKIP as well. You are right we cannot assume anything about
> close callbacks so MMF_OOM_SKIP has to come before that. I will move it
> behind the pagetable freeing.
>
And at that
On 2018/09/10 16:31, syzbot wrote:
> HEAD commit: 9a5682765a2e Merge branch 'x86-urgent-for-linus' of git://..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1624858e40
> kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
> dash
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?" resistance.
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. Th
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
4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
[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
On 2018/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 m
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, order=%d
>From dc0d9ec3205a28680dcf2213c0ffe8820e8b5913 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 6 Nov 2018 12:27:36 +0900
Subject: [PATCH] memcg: killed threads should not invoke memcg OOM killer
It is possible that a single process group memcg easily swamps the log
with no-eligible
On 2018/11/06 17:38, Petr Mladek wrote:
> If you would want to avoid buffering, you could set the number
> of buffers to zero. Then it would always fallback to
> the direct printk().
1 lock held by swapper/1/0:
#0:
(
rcu_read_lock
){}
, at: trace_call_bpf+0xf8/0x640 kernel/trace
On 2018/11/06 21:42, Michal Hocko wrote:
> On Tue 06-11-18 18:44:43, Tetsuo Handa wrote:
> [...]
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 6e1469b..a97648a 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -1382,8 +1382,13 @@
On 2018/11/06 23:35, Sergey Senozhatsky wrote:
>> Since we want to remove "struct cont" eventually, we will try to remove
>> both "implicit printk() users who are expecting KERN_CONT behavior" and
>> "explicit pr_cont()/printk(KERN_CONT) users". Therefore, converting to
>> this API is recommended.
On 2018/11/07 19:21, Petr Mladek wrote:
> On Tue 2018-11-06 23:35:02, Sergey Senozhatsky wrote:
>>> Since we want to remove "struct cont" eventually, we will try to remove
>>> both "implicit printk() users who are expecting KERN_CONT behavior" and
>>> "explicit pr_cont()/printk(KERN_CONT) users". T
On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> So, can we just do the following? /* a sketch */
>
> lockdep.c
> printk_safe_enter_irqsave(flags);
> lockdep_report();
> printk_safe_exit_irqrestore(flags);
If buffer size were large enough to hold messages from out_of_memory(),
I
On 2018/11/08 20:24, Petr Mladek wrote:
>> Let's have one more look at what we will fix and what we will break.
>>
>> 'cont' has premature flushes.
>>
>> Why is it good.
>> It preserves the correct order of events.
>>
>> pr_cont("calling foo->init()");
>> foo->init()
>>printk("Can't
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/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/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
> paralle
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
Pointless example:
printk("Hello\n"); => buf = get_printk_buffer();
printk("World.\n"); buffered_printk(buf, "Hello\n");
buffered_printk(buf, "World.\n");
put_printk_buffer(buf);
No
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/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/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 har
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/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 = get_proc_task(
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 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;
>
ail.com
),
we would be able to convert
printk("Testing 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("
On 2018/11/01 23:13, Petr Mladek wrote:
> On Wed 2018-10-24 19:11:10, Tetsuo Handa wrote:
>> After this patch, we will consider how we can add context identifier to
>> each line of printk() output (so that we can group multiple lines into
>> one block when parsing). Theref
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
(U)
1*2048kB
warn_alloc.cold.119+0xb7/0x1bd mm/page_alloc.c:3426
(M)
Signed-off-by: Tetsuo Handa
Cc: Andrew Morton
---
mm/page_alloc.c | 32 +---
1 file changed, 17
uffer(buf);
Note that bpr_devel() and bpr_debug() are not defined. This is
because pr_devel()/pr_debug() should not be followed by pr_cont()
because pr_devel()/pr_debug() are conditionally enabled; output from
pr_devel()/pr_debug() should always end with '\n'.
Previous version was propos
, at: trace_call_bpf+0xf8/0x640 kernel/trace/bpf_trace.c:46
Signed-off-by: Tetsuo Handa
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
kernel/locking/lockdep.c | 268 +++
1 file changed, 155 insertions(+), 113 deletions(-)
diff --git a/kernel
On 2018/11/02 23:40, Matthew Wilcox wrote:
> On Fri, Nov 02, 2018 at 10:31:55PM +0900, Tetsuo Handa wrote:
>> get_printk_buffer() tries to assign a "struct printk_buffer" from
>> statically preallocated array. get_printk_buffer() returns NULL if
>> all "s
On 2018/11/02 22:36, Peter Zijlstra wrote:
> On Fri, Nov 02, 2018 at 10:31:57PM +0900, Tetsuo Handa wrote:
>> syzbot is sometimes getting mixed output like below due to concurrent
>> printk(). Mitigate such output by using line-buffered printk() API.
>>
>> RCU u
On 2018/10/23 21:10, Michal Hocko wrote:
> On Tue 23-10-18 13:42:46, Michal Hocko wrote:
>> On Tue 23-10-18 10:01:08, Tetsuo Handa wrote:
>>> Michal Hocko wrote:
>>>> On Mon 22-10-18 20:45:17, Tetsuo Handa wrote:
>>>>>> diff --git a/mm/memcontr
alled.
Note that bpr_devel() and bpr_debug() are not defined. This is
because pr_devel()/pr_debug() should not be followed by pr_cont()
because pr_devel()/pr_debug() are conditionally enabled; output from
pr_devel()/pr_debug() should always end with '\n'.
Previous version was proposed a
Oleg Nesterov wrote:
> On 10/22, Tetsuo Handa wrote:
> > > And again, I do not know how/if yama ensures that child is rcu-protected,
> > > perhaps
> > > task_is_descendant() needs to check pid_alive(child) right after
> > > rcu_read_lock() ?
> >
On 2018/10/25 20:13, Oleg Nesterov wrote:
> On 10/25, Tetsuo Handa wrote:
>>
>> Oleg Nesterov wrote:
>>> On 10/22, Tetsuo Handa wrote:
>>>>> And again, I do not know how/if yama ensures that child is rcu-protected,
>>>>> perhaps
>>&g
On 2018/10/25 21:17, Oleg Nesterov wrote:
>>> And yes, task_is_descendant() can hit the dead child, if nothing else it can
>>> be killed. This can explain the kasan report.
>>
>> The kasan is reporting that child->real_parent (or maybe
>> child->real_parent->real_parent
>> or child->real_parent->r
On 2018/10/26 0:55, Oleg Nesterov wrote:
> On 10/25, Tetsuo Handa wrote:
>>
>> On 2018/10/25 21:17, Oleg Nesterov wrote:
>>>>> And yes, task_is_descendant() can hit the dead child, if nothing else it
>>>>> can
>>>>> be killed. This ca
On 2018/10/26 22:04, Oleg Nesterov wrote:
>> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
>> when p2 tried to attach on p1, p2->real_parent was pointing to already
>> (or about to be) freed p1.
>
> No, p2->real_parent will be updated. If p1 exits it will re-parent its
> c
On 2018/10/26 23:39, Oleg Nesterov wrote:
> On 10/26, Tetsuo Handa wrote:
>> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
>> when someone tried to attach on p2, p2->real_parent was pointing to already
>> (or about to be) freed p1.
>
>
On 2018/10/27 4:25, Michal Hocko wrote:
>> out_of_memory() bails on task_will_free_mem(current), which
>> specifically *excludes* already reaped tasks. Why are we then adding a
>> separate check before that to bail on already reaped victims?
>
> 696453e66630a has introduced the bail out.
>
>> Do
Looping inside __getblk_gfp().
#syz dup: INFO: rcu detected stall in sys_creat
Looping inside __getblk_gfp().
#syz dup: INFO: rcu detected stall in sys_creat
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 i
601 - 700 of 2177 matches
Mail list logo
