Re: [PATCH] mm: oom: Fix race condition between oom_badness and do_exit of task

Kohli, Gaurav wrote: > > t->alloc_lock is still held when leaving find_lock_task_mm(), which means > > that t->mm != NULL. But nothing prevents t from setting t->mm = NULL at > > exit_mm() from do_exit() and calling exit_creds() from __put_task_struct(t) > > after task_unlock(t) is called. Seems

Re: [PATCH] mm: oom: Fix race condition between oom_badness and do_exit of task

Kohli, Gaurav wrote: > > t->alloc_lock is still held when leaving find_lock_task_mm(), which means > > that t->mm != NULL. But nothing prevents t from setting t->mm = NULL at > > exit_mm() from do_exit() and calling exit_creds() from __put_task_struct(t) > > after task_unlock(t) is called. Seems

Re: [PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

Andrew Morton wrote: > On Wed, 28 Feb 2018 06:50:02 +0900 Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > > > > This warning is caused by commit d92a8cfcb37ecd13 ("locking/lockdep: Rework > > FS_RECLAIM annotation") which

Re: [PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

Andrew Morton wrote: > On Wed, 28 Feb 2018 06:50:02 +0900 Tetsuo Handa > wrote: > > > > > This warning is caused by commit d92a8cfcb37ecd13 ("locking/lockdep: Rework > > FS_RECLAIM annotation") which replaced lockdep_set_current_reclaim_state()/ &g

Re: [PATCH] mm: oom: Fix race condition between oom_badness and do_exit of task

On 2018/03/08 13:51, Kohli, Gaurav wrote: > On 3/8/2018 2:26 AM, David Rientjes wrote: > >> On Wed, 7 Mar 2018, Gaurav Kohli wrote: >> >>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c >>> index 6fd9773..5f4cc4b 100644 >>> --- a/mm/oom_kill.c >>> +++ b/mm/oom_kill.c >>> @@ -114,9 +114,11 @@ struct

Re: [PATCH] mm: oom: Fix race condition between oom_badness and do_exit of task

On 2018/03/08 13:51, Kohli, Gaurav wrote: > On 3/8/2018 2:26 AM, David Rientjes wrote: > >> On Wed, 7 Mar 2018, Gaurav Kohli wrote: >> >>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c >>> index 6fd9773..5f4cc4b 100644 >>> --- a/mm/oom_kill.c >>> +++ b/mm/oom_kill.c >>> @@ -114,9 +114,11 @@ struct

Re: [PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

I assumed this patch goes to mainline via locking tree, but neither Peter nor Ingo is responding. Andrew, can you pick up this patch? Tetsuo Handa wrote: > From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>

Re: [PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

I assumed this patch goes to mainline via locking tree, but neither Peter nor Ingo is responding. Andrew, can you pick up this patch? Tetsuo Handa wrote: > From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Thu, 8 Feb 2018 10:35:35 +0900

Re: [RFC v2 1/2] WhiteEgret: Add WhiteEgret core functions.

Masanobu Koike wrote: > On Friday, March 02, 2018 12:43 AM, Casey Schaufler wrote: > > On 2/28/2018 11:38 PM, Masanobu Koike wrote: > > > @@ -264,6 +266,9 @@ choice > > > config DEFAULT_SECURITY_APPARMOR > > > bool "AppArmor" if SECURITY_APPARMOR=y > > > > > > + config

Re: [RFC v2 1/2] WhiteEgret: Add WhiteEgret core functions.

Masanobu Koike wrote: > On Friday, March 02, 2018 12:43 AM, Casey Schaufler wrote: > > On 2/28/2018 11:38 PM, Masanobu Koike wrote: > > > @@ -264,6 +266,9 @@ choice > > > config DEFAULT_SECURITY_APPARMOR > > > bool "AppArmor" if SECURITY_APPARMOR=y > > > > > > + config

Re: [lkp-robot] [printk] c162d5b433: BUG:KASAN:use-after-scope_in_c

Forwarded by penguin-ker...@i-love.sakura.ne.jp --- Original Message ------- From:Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> To: Petr Mladek <pmla...@suse.com> Cc: kernel test robot <shun@intel.com>, Cong Wang <xiyou.wan

Re: [lkp-robot] [printk] c162d5b433: BUG:KASAN:use-after-scope_in_c

Forwarded by penguin-ker...@i-love.sakura.ne.jp --- Original Message ------- From:Tetsuo Handa To: Petr Mladek Cc: kernel test robot , Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus

[PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Thu, 8 Feb 2018 10:35:35 +0900 Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep

[PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Thu, 8 Feb 2018 10:35:35 +0900 Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep warnings. WARN

Public news servers for reading Linux kernel related posts?

Hello. I'm using news.gmane.org for sending replies to mailing lists which I'm not subscribed to (e.g. linux-mm). But recently I feel that messages seem to be frequently dropped (i.e. messages found on https://marc.info are not found on news.gmane.org) and I can't send replies to messages I want

Public news servers for reading Linux kernel related posts?

Hello. I'm using news.gmane.org for sending replies to mailing lists which I'm not subscribed to (e.g. linux-mm). But recently I feel that messages seem to be frequently dropped (i.e. messages found on https://marc.info are not found on news.gmane.org) and I can't send replies to messages I want

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Peter, are you OK with this patch? Tetsuo Handa wrote: > From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > Date: Thu, 8 Feb 2018 10:35:35 +0900 > Subject: [PATCH v2] lockdep: Fix fs_reclaim warnin

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Peter, are you OK with this patch? Tetsuo Handa wrote: > From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Thu, 8 Feb 2018 10:35:35 +0900 > Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. > > Dave Jones reported fs_reclai

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Nikolay Borisov wrote: > I think I've hit another incarnation of that one. The call stack is: > http://paste.opensuse.org/3f22d013 > > The cleaned up callstack of all the ? entries look like: > > __lock_acquire+0x2d8a/0x4b70 > lock_acquire+0x110/0x330 > kmem_cache_alloc+0x29/0x2c0 >

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Nikolay Borisov wrote: > I think I've hit another incarnation of that one. The call stack is: > http://paste.opensuse.org/3f22d013 > > The cleaned up callstack of all the ? entries look like: > > __lock_acquire+0x2d8a/0x4b70 > lock_acquire+0x110/0x330 > kmem_cache_alloc+0x29/0x2c0 >

Re: [PATCH] khungtaskd: Kick stuck processes

Chris Wilson wrote: > Quoting Tetsuo Handa (2018-02-08 23:10:43) > > Chris Wilson wrote: > > > After spotting a stuck process, and having decided not to panic, give > > > the task a kick to see if that helps it to recover (e.g. to paper over a > > > missed w

Re: [PATCH] khungtaskd: Kick stuck processes

Chris Wilson wrote: > Quoting Tetsuo Handa (2018-02-08 23:10:43) > > Chris Wilson wrote: > > > After spotting a stuck process, and having decided not to panic, give > > > the task a kick to see if that helps it to recover (e.g. to paper over a > > > missed w

Re: [PATCH] khungtaskd: Kick stuck processes

s Wilson <ch...@chris-wilson.co.uk> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > Cc: Andrew Morton <a...@linux-foundation.org> > --- > kernel/hung_task.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff

Re: [PATCH] khungtaskd: Kick stuck processes

is Wilson > Cc: Ingo Molnar > Cc: Tetsuo Handa > Cc: Andrew Morton > --- > kernel/hung_task.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/hung_task.c b/kernel/hung_task.c > index 751593ed7c0b..b32acb6bcc63 100644 > --- a/kernel/hung_task.c >

[PATCH v2] lockdep: Fix fs_reclaim warning.

>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Thu, 8 Feb 2018 10:35:35 +0900 Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep

[PATCH v2] lockdep: Fix fs_reclaim warning.

>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Thu, 8 Feb 2018 10:35:35 +0900 Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep warnings. WARN

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 08:47:20PM +0900, Tetsuo Handa wrote: > > Peter Zijlstra wrote: > > > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > >

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 08:47:20PM +0900, Tetsuo Handa wrote: > > Peter Zijlstra wrote: > > > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > >

Re: [PATCH] virtio_balloon: use non-blocking allocation

Michael S. Tsirkin wrote: > On Tue, Jan 02, 2018 at 11:50:21PM +0900, Tetsuo Handa wrote: > > Commit c7cdff0e864713a0 ("virtio_balloon: fix deadlock on OOM") tried to > > avoid OOM lockup by moving memory allocations to outside of balloon_lock. > > > > No

Re: [PATCH] virtio_balloon: use non-blocking allocation

Michael S. Tsirkin wrote: > On Tue, Jan 02, 2018 at 11:50:21PM +0900, Tetsuo Handa wrote: > > Commit c7cdff0e864713a0 ("virtio_balloon: fix deadlock on OOM") tried to > > avoid OOM lockup by moving memory allocations to outside of balloon_lock. > > > > No

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > ("locking/lockdep: Rework FS_RECLAIM annotation") which moved the > > location of > >

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > ("locking/lockdep: Rework FS_RECLAIM annotation") which moved the > > location of > >

Re: kernel panic: Out of memory and no killable processes... (2)

syzbot wrote: > syzbot hit the following crash on net-next commit > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +) > Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed' > > C reproducer is attached. > syzkaller reproducer is attached. > Raw console output is

Re: kernel panic: Out of memory and no killable processes... (2)

syzbot wrote: > syzbot hit the following crash on net-next commit > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +) > Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed' > > C reproducer is attached. > syzkaller reproducer is attached. > Raw console output is

Re: [4.15-rc9] fs_reclaim lockdep trace

Dave, would you try below patch? >From cae2cbf389ae3cdef1b492622722b4aeb07eb284 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Sun, 28 Jan 2018 14:17:14 +0900 Subject: [PATCH] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclai

Re: [4.15-rc9] fs_reclaim lockdep trace

Dave, would you try below patch? >From cae2cbf389ae3cdef1b492622722b4aeb07eb284 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sun, 28 Jan 2018 14:17:14 +0900 Subject: [PATCH] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep warni

Re: [4.15-rc9] fs_reclaim lockdep trace

On 2018/01/28 10:16, Tetsuo Handa wrote: > Linus Torvalds wrote: >> On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones <da...@codemonkey.org.uk> wrote: >>> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >>> > Just triggered this on a server I was r

Re: [4.15-rc9] fs_reclaim lockdep trace

On 2018/01/28 10:16, Tetsuo Handa wrote: > Linus Torvalds wrote: >> On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >>> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >>> > Just triggered this on a server I was rsync'ing to. >>> >>

Re: [4.15-rc9] fs_reclaim lockdep trace

Linus Torvalds wrote: > On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >> > Just triggered this on a server I was rsync'ing to. >> >> Actually, I can trigger this really easily, even with an rsync from

Re: [4.15-rc9] fs_reclaim lockdep trace

Linus Torvalds wrote: > On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >> > Just triggered this on a server I was rsync'ing to. >> >> Actually, I can trigger this really easily, even with an rsync from one >> disk to another.

Re: [virtio-dev] Re: [PATCH v25 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

On 2018/01/26 12:31, Wei Wang wrote: > On 01/26/2018 10:42 AM, Michael S. Tsirkin wrote: >> On Fri, Jan 26, 2018 at 09:40:44AM +0800, Wei Wang wrote: >>> On 01/25/2018 09:49 PM, Michael S. Tsirkin wrote: On Thu, Jan 25, 2018 at 05:14:06PM +0800, Wei Wang wrote: > >>> The controversy is

Re: [virtio-dev] Re: [PATCH v25 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

On 2018/01/26 12:31, Wei Wang wrote: > On 01/26/2018 10:42 AM, Michael S. Tsirkin wrote: >> On Fri, Jan 26, 2018 at 09:40:44AM +0800, Wei Wang wrote: >>> On 01/25/2018 09:49 PM, Michael S. Tsirkin wrote: On Thu, Jan 25, 2018 at 05:14:06PM +0800, Wei Wang wrote: > >>> The controversy is

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

Eric Wheeler wrote: > Hi Tetsuo, > > Thank you for looking into this! > > I tried running this C program in 4.14.15 but did not get a deadlock, just > OOM kills. Is the patch required to induce the deadlock? This reproducer must not trigger actual deadlock. Running this reproducer with this

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

Eric Wheeler wrote: > Hi Tetsuo, > > Thank you for looking into this! > > I tried running this C program in 4.14.15 but did not get a deadlock, just > OOM kills. Is the patch required to induce the deadlock? This reproducer must not trigger actual deadlock. Running this reproducer with this

Re: [PATCH v24 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

On 2018/01/25 12:32, Wei Wang wrote: > On 01/25/2018 01:15 AM, Michael S. Tsirkin wrote: >> On Wed, Jan 24, 2018 at 06:42:42PM +0800, Wei Wang wrote: >> + >> +static void report_free_page_func(struct work_struct *work) >> +{ >> +struct virtio_balloon *vb; >> +unsigned long flags; >> + >> +

Re: [PATCH v24 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

On 2018/01/25 12:32, Wei Wang wrote: > On 01/25/2018 01:15 AM, Michael S. Tsirkin wrote: >> On Wed, Jan 24, 2018 at 06:42:42PM +0800, Wei Wang wrote: >> + >> +static void report_free_page_func(struct work_struct *work) >> +{ >> +struct virtio_balloon *vb; >> +unsigned long flags; >> + >> +

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

Using a debug patch and a reproducer shown below, we can trivially form a circular locking dependency shown below. diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 8219001..240efb1 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -950,7 +950,7 @@ static

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

Using a debug patch and a reproducer shown below, we can trivially form a circular locking dependency shown below. diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 8219001..240efb1 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -950,7 +950,7 @@ static

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

Michal Hocko wrote: > On Wed 15-11-17 09:00:20, Johannes Weiner wrote: > > In any case, Minchan's lock breaking seems way preferable over that > > level of headscratching complexity for an unusual case like Shakeel's. > > agreed! I would go the more complex way only if it turns out that early >

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

Michal Hocko wrote: > On Wed 15-11-17 09:00:20, Johannes Weiner wrote: > > In any case, Minchan's lock breaking seems way preferable over that > > level of headscratching complexity for an unusual case like Shakeel's. > > agreed! I would go the more complex way only if it turns out that early >

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

Michael S. Tsirkin wrote: > > > > >> + * the page if the vq is full. We are adding one entry each > > > > >> time, > > > > >> + * which essentially results in no memory allocation, so the > > > > >> + * GFP_KERNEL flag below can be ignored. > > > > >> + */ > > > > >> +if

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

Michael S. Tsirkin wrote: > > > > >> + * the page if the vq is full. We are adding one entry each > > > > >> time, > > > > >> + * which essentially results in no memory allocation, so the > > > > >> + * GFP_KERNEL flag below can be ignored. > > > > >> + */ > > > > >> +if

Re: [mm 4.15-rc8] Random oopses under memory pressure.

just works against all 'struct page' > pointers. But with classic sparsemem, it doesn't. > > Let's restructure code a bit and add necessary check. > > Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> > Reported-by: Tetsuo Handa <penguin-ker...@i-love.sa

Re: [mm 4.15-rc8] Random oopses under memory pressure.

pointers. But with classic sparsemem, it doesn't. > > Let's restructure code a bit and add necessary check. > > Signed-off-by: Kirill A. Shutemov > Reported-by: Tetsuo Handa > Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") > Cc: sta...@vger.kernel.org

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

Michael S. Tsirkin wrote: > On Thu, Jan 18, 2018 at 10:30:18PM +0900, Tetsuo Handa wrote: > > On 2018/01/18 1:44, Michael S. Tsirkin wrote: > > >> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, > > >> uint32_t len) > > >

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

Michael S. Tsirkin wrote: > On Thu, Jan 18, 2018 at 10:30:18PM +0900, Tetsuo Handa wrote: > > On 2018/01/18 1:44, Michael S. Tsirkin wrote: > > >> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, > > >> uint32_t len) > > >

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

On 2018/01/18 1:44, Michael S. Tsirkin wrote: >> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t >> len) >> +{ >> +struct scatterlist sg; >> +unsigned int unused; >> +int err; >> + >> +sg_init_table(, 1); >> +sg_set_page(, pfn_to_page(pfn), len, 0);

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

On 2018/01/18 1:44, Michael S. Tsirkin wrote: >> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t >> len) >> +{ >> +struct scatterlist sg; >> +unsigned int unused; >> +int err; >> + >> +sg_init_table(, 1); >> +sg_set_page(, pfn_to_page(pfn), len, 0);

Re: [mm 4.15-rc8] Random oopses under memory pressure.

Tetsuo Handa wrote: > OK. I missed the mark. I overlooked that 4.11 already has this problem. > > I needed to bisect between 4.10 and 4.11, and I got plausible culprit. > > I haven't completed bisecting between b4fb8f66f1ae2e16 and c470abd4fde40ea6, > but > b4fb8f66f1ae

Re: [mm 4.15-rc8] Random oopses under memory pressure.

Tetsuo Handa wrote: > OK. I missed the mark. I overlooked that 4.11 already has this problem. > > I needed to bisect between 4.10 and 4.11, and I got plausible culprit. > > I haven't completed bisecting between b4fb8f66f1ae2e16 and c470abd4fde40ea6, > but > b4fb8f66f1ae

Re: [mm 4.15-rc8] Random oopses under memory pressure.

003000] . (found apic 0 pin 2) ... [0.005000] ... failed. [0.005000] ...trying to set up timer as Virtual Wire IRQ... [ 13.12] random: crng init done ". This bug occurs with both CONFIG_FLATMEM=y or CONFIG_SPARSEMEM=y . > On Tue, Jan 16, 2018 at 9:33 AM, Tetsuo Ha

Re: [mm 4.15-rc8] Random oopses under memory pressure.

003000] . (found apic 0 pin 2) ... [0.005000] ... failed. [0.005000] ...trying to set up timer as Virtual Wire IRQ... [ 13.12] random: crng init done ". This bug occurs with both CONFIG_FLATMEM=y or CONFIG_SPARSEMEM=y . > On Tue, Jan 16, 2018 at 9:33 AM, Tetsuo Han

Re: [mm 4.15-rc8] Random oopses under memory pressure.

Linus Torvalds wrote: > On Mon, Jan 15, 2018 at 5:15 PM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > > > I can't reproduce this with CONFIG_FLATMEM=y . But I'm not sure whether > > we are hitting a bug in CONFIG_SPARSEMEM=y code, for the bug

Re: [mm 4.15-rc8] Random oopses under memory pressure.

Linus Torvalds wrote: > On Mon, Jan 15, 2018 at 5:15 PM, Tetsuo Handa > wrote: > > > > I can't reproduce this with CONFIG_FLATMEM=y . But I'm not sure whether > > we are hitting a bug in CONFIG_SPARSEMEM=y code, for the bug is highly > > timing dependent. > &

Re: [mm 4.15-rc8] Random oopses under memory pressure.

Linus Torvalds wrote: > On Sun, Jan 14, 2018 at 3:54 AM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > This memory corruption bug occurs even on CONFIG_SMP=n CONFIG_PREEMPT_NONE=y > > kernel. This bug highly depends on timing and thus too difficult to bi

Re: [mm 4.15-rc8] Random oopses under memory pressure.

Linus Torvalds wrote: > On Sun, Jan 14, 2018 at 3:54 AM, Tetsuo Handa > wrote: > > This memory corruption bug occurs even on CONFIG_SMP=n CONFIG_PREEMPT_NONE=y > > kernel. This bug highly depends on timing and thus too difficult to bisect. > > This bug seems to exist

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > On Mon, Jan 15, 2018 at 3:25 PM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > Dmitry Vyukov wrote: > >> >> I am not completely following. You previously mentioned raw.log, which > >> >> is a collection of m

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > On Mon, Jan 15, 2018 at 3:25 PM, Tetsuo Handa > wrote: > > Dmitry Vyukov wrote: > >> >> I am not completely following. You previously mentioned raw.log, which > >> >> is a collection of multiple programs, but now you seem to be

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > >> I am not completely following. You previously mentioned raw.log, which > >> is a collection of multiple programs, but now you seem to be talking > >> about a single reproducer. When syzbot manages to reproduce the bug > >> only with syzkaller program but not with a

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > >> I am not completely following. You previously mentioned raw.log, which > >> is a collection of multiple programs, but now you seem to be talking > >> about a single reproducer. When syzbot manages to reproduce the bug > >> only with syzkaller program but not with a

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > > No problem. In the "tty: User triggerable soft lockup." case, I manually > > trimmed the reproducer at https://marc.info/?l=linux-mm=151368630414963 . > > That is, > > > > (1) Can the problem be reproduced even if setup_tun(0, true); is commented > > out? > > > > (2)

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > > No problem. In the "tty: User triggerable soft lockup." case, I manually > > trimmed the reproducer at https://marc.info/?l=linux-mm=151368630414963 . > > That is, > > > > (1) Can the problem be reproduced even if setup_tun(0, true); is commented > > out? > > > > (2)

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > On Mon, Jan 8, 2018 at 11:48 AM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > Dmitry Vyukov wrote: > >> >> Hi Tetsuo, > >> >> > >> >> syzbot always re-runs the same workload on a new machi

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > On Mon, Jan 8, 2018 at 11:48 AM, Tetsuo Handa > wrote: > > Dmitry Vyukov wrote: > >> >> Hi Tetsuo, > >> >> > >> >> syzbot always re-runs the same workload on a new machine. If it > >> >> manages

Re: [mm 4.15-rc7] Random oopses under memory pressure.

This memory corruption bug occurs even on CONFIG_SMP=n CONFIG_PREEMPT_NONE=y kernel. This bug highly depends on timing and thus too difficult to bisect. This bug seems to exist at least since Linux 4.8 (judging from the traces, though the cause might be different). None of debugging configuration

Re: [mm 4.15-rc7] Random oopses under memory pressure.

This memory corruption bug occurs even on CONFIG_SMP=n CONFIG_PREEMPT_NONE=y kernel. This bug highly depends on timing and thus too difficult to bisect. This bug seems to exist at least since Linux 4.8 (judging from the traces, though the cause might be different). None of debugging configuration

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Tejun Heo wrote: > On Wed, Jan 10, 2018 at 07:08:30AM +0900, Tetsuo Handa wrote: > > > * Netconsole tries to send out OOM messages and tries memory > > > allocation which fails which then prints allocation failed messages. > > > Because this happens while al

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Tejun Heo wrote: > On Wed, Jan 10, 2018 at 07:08:30AM +0900, Tetsuo Handa wrote: > > > * Netconsole tries to send out OOM messages and tries memory > > > allocation which fails which then prints allocation failed messages. > > > Because this happens while al

Re: [PATCH v21 2/5 RESEND] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > Michael, could we merge patch 3-5 first? No! I'm repeatedly asking you to propose only VIRTIO_BALLOON_F_SG changes. Please don't ignore me. Patch 4 depends on patch 2. Thus, back to patch 2. Your patch is trying to switch tell_host_sgs() and tell_host() based on

Re: [PATCH v21 2/5 RESEND] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > Michael, could we merge patch 3-5 first? No! I'm repeatedly asking you to propose only VIRTIO_BALLOON_F_SG changes. Please don't ignore me. Patch 4 depends on patch 2. Thus, back to patch 2. Your patch is trying to switch tell_host_sgs() and tell_host() based on

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Tejun Heo wrote: > The code might suck but I think this does replicate what we've been > seeing regularly in the fleet. The console side is pretty slow - IPMI > faithfully emulating serial console. I don't know it's doing 115200 > or even slower. Please consider something like the following.

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Tejun Heo wrote: > The code might suck but I think this does replicate what we've been > seeing regularly in the fleet. The console side is pretty slow - IPMI > faithfully emulating serial console. I don't know it's doing 115200 > or even slower. Please consider something like the following.

Re: [PATCH v21 2/5 RESEND] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > - enable OOM to free inflated pages maintained in the local temporary > list. I do want to see it before applying this patch. Please carefully check how the xbitmap implementation works, and you will find that you are adding a lot of redundant operations with a bug.

Re: [PATCH v21 2/5 RESEND] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > - enable OOM to free inflated pages maintained in the local temporary > list. I do want to see it before applying this patch. Please carefully check how the xbitmap implementation works, and you will find that you are adding a lot of redundant operations with a bug.

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > >> Hi Tetsuo, > >> > >> syzbot always re-runs the same workload on a new machine. If it > >> manages to reproduce the problem, it provides a reproducer. In this > >> case it didn't. > > > > Even if it did not manage to reproduce the problem, showing raw.log in > > C format

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > >> Hi Tetsuo, > >> > >> syzbot always re-runs the same workload on a new machine. If it > >> manages to reproduce the problem, it provides a reproducer. In this > >> case it didn't. > > > > Even if it did not manage to reproduce the problem, showing raw.log in > > C format

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 01/03/2018 10:29 AM, Tetsuo Handa wrote: > > Matthew Wilcox wrote: > >> The radix tree convention is objectively awful, which is why I'm working > >> to change it. Specifying the GFP flags at radix tree initialisation time > >> rather tha

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 01/03/2018 10:29 AM, Tetsuo Handa wrote: > > Matthew Wilcox wrote: > >> The radix tree convention is objectively awful, which is why I'm working > >> to change it. Specifying the GFP flags at radix tree initialisation time > >> rather tha

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Matthew Wilcox wrote: > The radix tree convention is objectively awful, which is why I'm working > to change it. Specifying the GFP flags at radix tree initialisation time > rather than allocation time leads to all kinds of confusion. The preload > API is a pretty awful workaround, and it will

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Matthew Wilcox wrote: > The radix tree convention is objectively awful, which is why I'm working > to change it. Specifying the GFP flags at radix tree initialisation time > rather than allocation time leads to all kinds of confusion. The preload > API is a pretty awful workaround, and it will

[PATCH] virtio_balloon: use non-blocking allocation

OM. But since some process context might start calling balloon_page_alloc() in future, this patch does not remove __GFP_NOMEMALLOC. (Only compile tested. Please do runtime tests before committing.) Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Michael S. Tsirkin <m.

[PATCH] virtio_balloon: use non-blocking allocation

OM. But since some process context might start calling balloon_page_alloc() in future, this patch does not remove __GFP_NOMEMALLOC. (Only compile tested. Please do runtime tests before committing.) Signed-off-by: Tetsuo Handa Cc: Michael S. Tsirkin Cc: Wei Wang Cc: Matthew Wilcox Cc: Michal Hoc

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > On Mon, Dec 18, 2017 at 3:52 PM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > On 2017/12/18 17:43, syzbot wrote: > >> Hello, > >> > >> syzkaller hit the following crash on > >> 6084b576dca2e898f5c1

Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote: > On Mon, Dec 18, 2017 at 3:52 PM, Tetsuo Handa > wrote: > > On 2017/12/18 17:43, syzbot wrote: > >> Hello, > >> > >> syzkaller hit the following crash on > >> 6084b576dca2e898f5c101baef151f7bfdbb606d > >> git://gi

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > On (12/28/17 15:48), Sergey Senozhatsky wrote: > [..] > > and I'm actually thinking about returning back the old vprintk_emit() > > behavior > > > >vprintk_emit() > >{ > > + preempt_disable(); > > if (console_trylock()) > >

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > On (12/28/17 15:48), Sergey Senozhatsky wrote: > [..] > > and I'm actually thinking about returning back the old vprintk_emit() > > behavior > > > >vprintk_emit() > >{ > > + preempt_disable(); > > if (console_trylock()) > >

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 12/26/2017 06:38 PM, Tetsuo Handa wrote: > > Wei Wang wrote: > >> On 12/25/2017 10:51 PM, Tetsuo Handa wrote: > >>> Wei Wang wrote: > >>> > >> What we are doing here is to free the pages that were just allocated in > &

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 12/26/2017 06:38 PM, Tetsuo Handa wrote: > > Wei Wang wrote: > >> On 12/25/2017 10:51 PM, Tetsuo Handa wrote: > >>> Wei Wang wrote: > >>> > >> What we are doing here is to free the pages that were just allocated in > &

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 12/25/2017 10:51 PM, Tetsuo Handa wrote: > > Wei Wang wrote: > >>>>>> @@ -173,8 +292,15 @@ static unsigned fill_balloon(struct > >>>>>> virtio_balloon *vb, size_t num) > >>>>>> while ((page = ball

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 12/25/2017 10:51 PM, Tetsuo Handa wrote: > > Wei Wang wrote: > >>>>>> @@ -173,8 +292,15 @@ static unsigned fill_balloon(struct > >>>>>> virtio_balloon *vb, size_t num) > >>>>>> while ((page = ball

<    10   11   12   13   14   15   16   17   18   19   >