On Wed, Nov 19, 2014 at 07:44:43PM +0100, Holger Hoffstätte wrote: > 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. :) Ok, I'll consider it for a future 3.14 stable release when things slow down a bit, right now I have plenty for this next release already. thanks, greg k-h -- 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
