[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201512242006.CGJ81784.SVMHOOQtLFFFOJ@I-love.SAKURA.ne.jp>
Date: Thu, 24 Dec 2015 20:06:50 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: mhocko@...nel.org, zwisler@...il.com
Cc: akpm@...ux-foundation.org, mgorman@...e.de, rientjes@...gle.com,
torvalds@...ux-foundation.org, oleg@...hat.com, hughd@...gle.com,
andrea@...nel.org, riel@...hat.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, ross.zwisler@...ux.intel.com
Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper
Michal Hocko wrote:
> This is VM_BUG_ON_PAGE(page_mapped(page), page), right? Could you attach
> the full kernel log? It all smells like a race when OOM reaper tears
> down the mapping and there is a truncate still in progress. But hitting
> the BUG_ON just because of that doesn't make much sense to me. OOM
> reaper is essentially MADV_DONTNEED. I have to think about this some
> more, though, but I am in a holiday mode until early next year so please
> bear with me.
I don't know whether the OOM killer was invoked just before this
VM_BUG_ON_PAGE().
> Is this somehow DAX related?
4.4.0-rc6-next-20151223_new_fsync_v6+ suggests that this kernel
has "[PATCH v6 0/7] DAX fsync/msync support" applied. But I think
http://marc.info/?l=linux-mm&m=145068666428057 should be applied
when retesting. (20151223 does not have this fix.)
[ 235.768779] [<ffffffff811feba4>] ? unmap_mapping_range+0x64/0x130
[ 235.769385] [<ffffffff811febb4>] ? unmap_mapping_range+0x74/0x130
[ 235.770010] [<ffffffff810f5c3f>] ? up_write+0x1f/0x40
[ 235.770501] [<ffffffff811febb4>] ? unmap_mapping_range+0x74/0x130
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists