On 11/19/14 18:39, Greg KH wrote: > On Fri, Oct 03, 2014 at 08:24:34PM +0000, Holger Hoffstätte wrote: >> >> On Thu, 02 Oct 2014 13:50:24 -0700, Cong Wang wrote: >> >>> Hello, >>> >>> >>> Sorry to request for backporting another large fixes to stable. >>> >>> We have seen a list corruption on 3.14 stable kernel (see the end of >>> this email), which I think is probably fixed by the following list of >>> patches from Al: >>> >>> fe91522a7ba82ca1a51b07e19954b3825e4aaa22 don't remove from shrink list in select_collect() >>> 41edf278fc2f042f4e22a12ed87d19c5201210e1 dentry_kill(): don't try to remove from shrink list >>> 01b6035190b024240a43ac1d8e9c6f964f5f1c63 expand the call of dentry_lru_del() in dentry_kill() >>> b4f0354e968f5fabd39bc85b99fedae4a97589fe new helper: dentry_free() >>> 5c47e6d0ad608987b91affbcf7d1fc12dfbe8fb4 fold try_prune_one_dentry() >>> 03b3b889e79cdb6b806fc0ba9be0d71c186bbfaa fold d_kill() and d_free() >>> >>> And there are 7 patches to fix the above patches: >>> >>> 00fe425bc28f0ccba034a77783c09c15af4 dcache: add missing lockdep annotation >> >> This commit does not exist and seems to be the truncated hash of the >> last one (9f12600f..). I guess copypasta salad. >> >>> 8cbf74da435d1bd13dbb790f94c7ff67b2fb6af4 dentry_kill() doesn't need the second argument now >>> b2b80195d8829921506880f6dccd21cabd163d0d dealing with the rest of shrink_dentry_list() livelock >>> 046b961b45f93a92e4c70525a12f3d378bced130 shrink_dentry_list(): take parent's ->d_lock earlier >>> ff2fde9929feb2aef45377ce56b8b12df85dda69 expand dentry_kill(dentry, 0) in shrink_dentry_list() >>> e55fd011549eae01a230e3cace6f4d031b6a3453 split dentry_kill() >>> 64fd72e0a44bdd62c5ca277cb24d0d02b2d8e9dc lift the "already marked killed" case into shrink_dentry_list() >>> >>> ...and one more to fix up from Linus: >>> >>> 9f12600fe425bc28f0ccba034a77783c09c15af4 dcache: add missing lockdep annotation >>> >>> I don't follow vfs development so could easily miss something here, Al >>> should know much better than I do and may come up with a much easier >>> way to fix it. Please evaluate this. >> >> I can confirm that these apply correctly (in reverse order per paragraph) over >> 3.14.19 and that it still compiles. > > Compiling is nice, what I would like to see is a way to reproduce the > original problem and proof that backporting all of these intrusive > patches is worth it. Given that the git commit ids in the list aren't > even correct, I'm a bit loath to do so, sorry. I should have been more clear - by "still compiles" I meant that it not only applies & compiles but also runs and doesn't result in any regressions, at least I have not noticed any on my 3 machines. As for the hashes: I picked all commits from Linus' main tree and just now checked via cgit that e.g. the last commit 64fd72 is exactly where it is supposed to be. Not sure if that helps..still your call. :) thanks Holger -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html