[PATCH v2] lockdep: Fix fs_reclaim warning.

2018-02-08 Thread Tetsuo Handa
>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: [PATCH v2] lockdep: Fix fs_reclaim warning.

2018-02-12 Thread Tetsuo Handa
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 > __clear_exten

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

2018-02-19 Thread Tetsuo Handa
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: [4.15-rc9] fs_reclaim lockdep trace

2018-02-01 Thread Tetsuo Handa
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 > > >

[PATCH] printk: Remove no longer used LOG_PREFIX.

2019-02-22 Thread Tetsuo Handa
) removed the last LOG_PREFIX check, setting LOG_PREFIX via KERN_DEFAULT etc. is no longer meaningful. Therefore, we can remove LOG_PREFIX and make KERN_DEFAULT empty string. Signed-off-by: Tetsuo Handa --- include/linux/kern_levels.h | 2 +- include/linux/printk.h | 1 - kernel/printk/printk

Re: [Bug 199931] New: systemd/rtorrent file data corruption when using echo 3 >/proc/sys/vm/drop_caches

2018-06-05 Thread Tetsuo Handa
On 2018/06/06 5:03, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Tue, 05 Jun 2018 18:01:36 + bugzilla-dae...@bugzilla.kernel.org wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=199931 >> >>

Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache

2016-11-18 Thread Tetsuo Handa
On 2016/11/18 6:49, Vlastimil Babka wrote: > On 11/16/2016 02:39 PM, E V wrote: >> System panic'd overnight running 4.9rc5 & rsync. Attached a photo of >> the stack trace, and the 38 call traces in a 2 minute window shortly >> before, to the bugzilla case for those not on it's e-mail list: >> >> ht

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

2016-12-17 Thread Tetsuo Handa
Michal Hocko wrote: > On Fri 16-12-16 12:31:51, Johannes Weiner wrote: >>> @@ -3737,6 +3752,16 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int >>> order, >>> */ >>> WARN_ON_ONCE(order > PAGE_ALLOC_COSTLY_ORDER); >>> >>> + /* >>> +* Help non-f

Re: OOM: Better, but still there on

2016-12-17 Thread Tetsuo Handa
On 2016/12/17 21:59, Nils Holland wrote: > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote: >> mount -t tracefs none /debug/trace >> echo 1 > /debug/trace/events/vmscan/enable >> cat /debug/trace/trace_pipe > trace.log >> >> should help >> [...] > > No problem! I enabled writing the t

Re: OOM: Better, but still there on

2016-12-17 Thread Tetsuo Handa
Nils Holland wrote: > On Sat, Dec 17, 2016 at 11:44:45PM +0900, Tetsuo Handa wrote: > > On 2016/12/17 21:59, Nils Holland wrote: > > > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote: > > >> mount -t tracefs none /debug/trace > > >>

Re: OOM: Better, but still there on

2016-12-21 Thread Tetsuo Handa
Michal Hocko wrote: > TL;DR > there is another version of the debugging patch. Just revert the > previous one and apply this one instead. It's still not clear what > is going on but I suspect either some misaccounting or unexpeted > pages on the LRU lists. I have added one more tracepoint, so pleas

Re: OOM: Better, but still there on

2016-12-22 Thread Tetsuo Handa
Nils Holland wrote: > Well, the issue is that I could only do everything via ssh today and > don't have any physical access to the machines. In fact, both seem to > have suffered a genuine kernel panic, which is also visible in the > last few lines of the log I provided today. So, basically, both >