Messages in this thread | | | Date | Tue, 15 Aug 2017 08:55:44 +0200 | From | Michal Hocko <> | Subject | Re: Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer |
| |
On Tue 15-08-17 07:51:02, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > > Were you able to reproduce with other filesystems? > > Yes, I can reproduce this problem using both xfs and ext4 on 4.11.11-200.fc25.x86_64 > on Oracle VM VirtualBox on Windows. > > I believe that this is not old data from disk, for I can reproduce this problem > using newly attached /dev/sdb which has never written any data (other than data > written by mkfs.xfs and mkfs.ext4). > > /dev/sdb /tmp ext4 rw,seclabel,relatime,data=ordered 0 0 > > The garbage pattern (the last 4096 bytes) is identical for both xfs and ext4.
Thanks a lot for retesting. It is now obvious that FS doesn't have anything to do with this issue which is in line with my investigation from yesterday and Friday. I simply cannot see any way the file position would be updated with a zero length write. So this must be something else. I have double checked the MM side of the page fault I couldn't find anything there either so this smells like a stray pte while the underlying page got reused or something TLB related.
> > I wonder what is > > different in my testing because I cannot reproduce this at all. Well, I > > had to reduce the number of competing writer threads to 128 because I > > quickly hit the trashing behavior with more of them (and 4 CPUs). I will > > try on a larger machine. > > I don't think a larger machine is necessary. > I can reproduce this problem with 8 competing writer threads on 4 CPUs.
OK, I will try with fewer writers which should make it easier to have it run for long time without any trashing.
> I don't have native Linux environment. Maybe that is the difference. > Can you try VMware Workstation Player or Oracle VM VirtualBox environment?
Hmm, I do not have any of those handy for use, unfortunately. I will keep focusing on the native HW and KVM for today.
Thanks! -- Michal Hocko SUSE Labs
| |