From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: mhocko@kernel.org Cc: akpm@linux-foundation.org, andrea@kernel.org, kirill@shutemov.name, oleg@redhat.com, wenwei.tww@alibaba-inc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer Date: Sat, 12 Aug 2017 00:46:18 +0900 [thread overview] Message-ID: <201708120046.AFI81780.OHMFtFSOFVQJOL@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <20170811120825.GG30811@dhcp22.suse.cz> Michal Hocko wrote: > On Fri 11-08-17 16:54:36, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 11-08-17 11:28:52, Tetsuo Handa wrote: > > > > Will you explain the mechanism why random values are written instead of zeros > > > > so that this patch can actually fix the race problem? > > > > > > I am not sure what you mean here. Were you able to see a write with an > > > unexpected content? > > > > Yes. See http://lkml.kernel.org/r/201708072228.FAJ09347.tOOVOFFQJSHMFL@I-love.SAKURA.ne.jp . > > Ahh, I've missed that random part of your output. That is really strange > because AFAICS the oom reaper shouldn't really interact here. We are > only unmapping anonymous memory and even if a refault slips through we > should always get zeros. > > Your test case doesn't mmap MAP_PRIVATE of a file so we shouldn't even > get any uninitialized data from a file by missing CoWed content. The > only possible explanations would be that a page fault returned a > non-zero data which would be a bug on its own or that a file write > extend the file without actually writing to it which smells like a fs > bug to me. As I wrote at http://lkml.kernel.org/r/201708112053.FIG52141.tHJSOQFLOFMFOV@I-love.SAKURA.ne.jp , I don't think it is a fs bug. > > Anyway I wasn't able to reproduce this and I was running your usecase > in the loop for quite some time (with xfs storage). How reproducible > is this? If you can reproduce easily can you simply comment out > unmap_page_range in __oom_reap_task_mm and see if that makes any change > just to be sure that the oom reaper can be ruled out? Frequency of writing not-zero values is lower than frequency of writing zero values. But if I comment out unmap_page_range() in __oom_reap_task_mm(), I can't even reproduce writing zero values. As far as I tested, writing not-zero values occurs only if the OOM reaper is involved.
WARNING: multiple messages have this Message-ID (diff)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: mhocko@kernel.org Cc: akpm@linux-foundation.org, andrea@kernel.org, kirill@shutemov.name, oleg@redhat.com, wenwei.tww@alibaba-inc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer Date: Sat, 12 Aug 2017 00:46:18 +0900 [thread overview] Message-ID: <201708120046.AFI81780.OHMFtFSOFVQJOL@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <20170811120825.GG30811@dhcp22.suse.cz> Michal Hocko wrote: > On Fri 11-08-17 16:54:36, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 11-08-17 11:28:52, Tetsuo Handa wrote: > > > > Will you explain the mechanism why random values are written instead of zeros > > > > so that this patch can actually fix the race problem? > > > > > > I am not sure what you mean here. Were you able to see a write with an > > > unexpected content? > > > > Yes. See http://lkml.kernel.org/r/201708072228.FAJ09347.tOOVOFFQJSHMFL@I-love.SAKURA.ne.jp . > > Ahh, I've missed that random part of your output. That is really strange > because AFAICS the oom reaper shouldn't really interact here. We are > only unmapping anonymous memory and even if a refault slips through we > should always get zeros. > > Your test case doesn't mmap MAP_PRIVATE of a file so we shouldn't even > get any uninitialized data from a file by missing CoWed content. The > only possible explanations would be that a page fault returned a > non-zero data which would be a bug on its own or that a file write > extend the file without actually writing to it which smells like a fs > bug to me. As I wrote at http://lkml.kernel.org/r/201708112053.FIG52141.tHJSOQFLOFMFOV@I-love.SAKURA.ne.jp , I don't think it is a fs bug. > > Anyway I wasn't able to reproduce this and I was running your usecase > in the loop for quite some time (with xfs storage). How reproducible > is this? If you can reproduce easily can you simply comment out > unmap_page_range in __oom_reap_task_mm and see if that makes any change > just to be sure that the oom reaper can be ruled out? Frequency of writing not-zero values is lower than frequency of writing zero values. But if I comment out unmap_page_range() in __oom_reap_task_mm(), I can't even reproduce writing zero values. As far as I tested, writing not-zero values occurs only if the OOM reaper is involved. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-08-11 15:46 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-07 11:38 [PATCH 0/2] mm, oom: fix oom_reaper fallouts Michal Hocko 2017-08-07 11:38 ` Michal Hocko 2017-08-07 11:38 ` [PATCH 1/2] mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS Michal Hocko 2017-08-07 11:38 ` Michal Hocko 2017-08-15 0:49 ` David Rientjes 2017-08-15 0:49 ` David Rientjes 2017-08-07 11:38 ` [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer Michal Hocko 2017-08-07 11:38 ` Michal Hocko 2017-08-08 17:48 ` Andrea Arcangeli 2017-08-08 17:48 ` Andrea Arcangeli 2017-08-08 23:35 ` Tetsuo Handa 2017-08-08 23:35 ` Tetsuo Handa 2017-08-09 18:36 ` Andrea Arcangeli 2017-08-09 18:36 ` Andrea Arcangeli 2017-08-10 8:21 ` Michal Hocko 2017-08-10 8:21 ` Michal Hocko 2017-08-10 13:33 ` Michal Hocko 2017-08-10 13:33 ` Michal Hocko 2017-08-11 2:28 ` Tetsuo Handa 2017-08-11 2:28 ` Tetsuo Handa 2017-08-11 7:09 ` Michal Hocko 2017-08-11 7:09 ` Michal Hocko 2017-08-11 7:54 ` Tetsuo Handa 2017-08-11 7:54 ` Tetsuo Handa 2017-08-11 10:22 ` Andrea Arcangeli 2017-08-11 10:22 ` Andrea Arcangeli 2017-08-11 10:42 ` Andrea Arcangeli 2017-08-11 10:42 ` Andrea Arcangeli 2017-08-11 11:53 ` Tetsuo Handa 2017-08-11 11:53 ` Tetsuo Handa 2017-08-11 12:08 ` Michal Hocko 2017-08-11 12:08 ` Michal Hocko 2017-08-11 15:46 ` Tetsuo Handa [this message] 2017-08-11 15:46 ` Tetsuo Handa 2017-08-14 13:59 ` Michal Hocko 2017-08-14 13:59 ` Michal Hocko 2017-08-14 22:51 ` Tetsuo Handa 2017-08-15 6:55 ` Michal Hocko 2017-08-15 6:55 ` Michal Hocko 2017-08-15 8:41 ` Michal Hocko 2017-08-15 8:41 ` Michal Hocko 2017-08-15 10:06 ` Tetsuo Handa 2017-08-15 12:26 ` Michal Hocko 2017-08-15 12:26 ` Michal Hocko 2017-08-15 12:58 ` Tetsuo Handa 2017-08-17 13:58 ` Michal Hocko 2017-08-17 13:58 ` Michal Hocko 2017-08-15 5:30 ` Tetsuo Handa 2017-08-07 13:28 ` [PATCH 0/2] mm, oom: fix oom_reaper fallouts Tetsuo Handa 2017-08-07 13:28 ` Tetsuo Handa 2017-08-07 14:04 ` Michal Hocko 2017-08-07 14:04 ` Michal Hocko 2017-08-07 15:23 ` Tetsuo Handa 2017-08-07 15:23 ` Tetsuo Handa 2017-08-15 12:29 ` Michal Hocko 2017-08-15 12:29 ` Michal Hocko -- strict thread matches above, loose matches on Subject: below -- 2017-08-04 8:32 Re: [PATCH] mm, oom: fix potential data corruption when oom_reaper races with writer Michal Hocko 2017-08-04 8:33 ` [PATCH 1/2] mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS Michal Hocko 2017-08-04 8:33 ` [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer Michal Hocko 2017-08-04 8:33 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=201708120046.AFI81780.OHMFtFSOFVQJOL@I-love.SAKURA.ne.jp \ --to=penguin-kernel@i-love.sakura.ne.jp \ --cc=akpm@linux-foundation.org \ --cc=andrea@kernel.org \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=oleg@redhat.com \ --cc=wenwei.tww@alibaba-inc.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.