From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: Please backport shrink dentry list fixes to stable Date: Wed, 19 Nov 2014 12:42:05 -0800 Message-ID: <20141119204205.GA20905@kroah.com> References: <20141119173910.GC31260@kroah.com> <546CE51B.6010802@googlemail.com> <20141119203819.GA31321@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: stable@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Holger =?iso-8859-1?Q?Hoffst=E4tte?= Return-path: Content-Disposition: inline In-Reply-To: <20141119203819.GA31321@kroah.com> Sender: stable-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Nov 19, 2014 at 12:38:19PM -0800, Greg KH wrote: > On Wed, Nov 19, 2014 at 07:44:43PM +0100, Holger Hoffst=E4tte wrote: > > On 11/19/14 18:39, Greg KH wrote: > > > On Fri, Oct 03, 2014 at 08:24:34PM +0000, Holger Hoffst=E4tte wro= te: > > >> > > >> 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 e= nd of > > >>> this email), which I think is probably fixed by the following l= ist of > > >>> patches from Al: > > >>> > > >>> fe91522a7ba82ca1a51b07e19954b3825e4aaa22 don't remove from shri= nk list in select_collect() > > >>> 41edf278fc2f042f4e22a12ed87d19c5201210e1 dentry_kill(): don't t= ry to remove from shrink list > > >>> 01b6035190b024240a43ac1d8e9c6f964f5f1c63 expand the call of den= try_lru_del() in dentry_kill() > > >>> b4f0354e968f5fabd39bc85b99fedae4a97589fe new helper: dentry_fre= e() > > >>> 5c47e6d0ad608987b91affbcf7d1fc12dfbe8fb4 fold try_prune_one_den= try() > > >>> 03b3b889e79cdb6b806fc0ba9be0d71c186bbfaa fold d_kill() and d_fr= ee() > > >>> > > >>> 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(den= try, 0) in shrink_dentry_list() > > >>> e55fd011549eae01a230e3cace6f4d031b6a3453 split dentry_kill() > > >>> 64fd72e0a44bdd62c5ca277cb24d0d02b2d8e9dc lift the "already mark= ed 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 h= ere, Al > > >>> should know much better than I do and may come up with a much e= asier > > >>> way to fix it. Please evaluate this. > > >> > > >> I can confirm that these apply correctly (in reverse order per p= aragraph) over > > >> 3.14.19 and that it still compiles. > > >=20 > > > Compiling is nice, what I would like to see is a way to reproduce= the > > > original problem and proof that backporting all of these intrusiv= e > > > patches is worth it. Given that the git commit ids in the list a= ren't > > > even correct, I'm a bit loath to do so, sorry. > >=20 > > 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 reg= ressions, > > at least I have not noticed any on my 3 machines. > >=20 > > As for the hashes: I picked all commits from Linus' main tree and j= ust > > now checked via cgit that e.g. the last commit 64fd72 is exactly wh= ere > > it is supposed to be. > >=20 > > Not sure if that helps..still your call. :) >=20 > Ok, I'll consider it for a future 3.14 stable release when things slo= w > down a bit, right now I have plenty for this next release already. It looks like Cong provided a better documented / tested series for thi= s as well, so that will make it easier to accept for a future kernel than this assorted list of git commit ids... thanks, greg k-h