On Fri 10-02-17 08:14:18, Michal Hocko wrote: > On Fri 10-02-17 11:53:48, Eryu Guan wrote: > > Hi, > > > > I was testing 4.10-rc7 kernel and noticed that xfs_repair reported XFS > > corruption after fstests xfs/297 test. This didn't happen with 4.10-rc6 > > kernel, and git bisect pointed the first bad commit to > > > > commit d1908f52557b3230fbd63c0429f3b4b748bf2b6d > > Author: Michal Hocko <mhocko@xxxxxxxx> > > Date: Fri Feb 3 13:13:26 2017 -0800 > > > > fs: break out of iomap_file_buffered_write on fatal signals > > > > Tetsuo has noticed that an OOM stress test which performs large write > > requests can cause the full memory reserves depletion. He has tracked > > this down to the following path > > .... > > > > It's the sb_fdblocks field reports inconsistency: > > ... > > Phase 2 - using internal log > > - zero log... > > - scan filesystem freespace and inode maps... > > sb_fdblocks 3367765, counted 3367863 > > - 11:37:41: scanning filesystem freespace - 16 of 16 allocation groups done > > - found root inode chunk > > ... > > > > And it can be reproduced almost 100% with all XFS test configurations > > (e.g. xfs_4k xfs_2k_reflink), on all test hosts I tried (so I didn't > > bother pasting my detailed test and host configs, if more info is needed > > please let me know). > > The patch can lead to short writes when the task is killed. Was there > any OOM killer triggered during the test? If not who is killing the > task? I will try to reproduce later today. I have checked both tests and they are killing the test but none of them seems to be using SIGKILL. The patch should make a difference only for fatal signal (aka SIGKILL). Is there any other part that can do SIGKILL except for the OOM killer? -- Michal Hocko SUSE Labs
