On Thu, 2016-02-18 at 10:57 +0100, Thomas.Betker@xxxxxxxxxxxxxxxxx wrote: > Hello David: > > > > > > > > > Please could you try what's in the tree at > > > http://git.infradead.org/users/dwmw2/jffs2-fixes.git > > > > Your patch looks much simpler, and I will definitely test it. It may > > take a few days, though, as I have to unearth the test scripts, and > > find a time slot for testing. > Here is what I did (sorry for the wait, things were piling up): > > 1) Removed Deng Chao's patch from my kernel, added your patch "jffs2: Fix > page lock / f->sem deadlock". I am still on linux-3.14, but jffs2 hasn't > changed much since then, so this shouldn't make a difference. Added a > printk() before mutex_unlock(&f->sem) to check if the prospective page was > locked, i.e. if the deadlock situation actually occurs. > > 2) On my target system, started wangzaiwei's test (with some fixes), plus > a loop copying a large file over and over (to get GC rolling, which > increases the chance of a deadlock). > > 3) After 24 hours, the system was still alive, and the printk() had been > hit 32 times. > > So yes, I am confident that your patch avoids the deadlock, and if that's > good enough for you, please add my Tested-by:. However, I am going to run > some more stress tests here just to check that there weren't any > unexpected side effects. (Don't get me wrong -- I am sure the patch is > fine, but for me it's a case of "once bitten, twice shy" ...) Can we get this upstream before next release? I don't think there will much more testing at this point. Jocke-- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
