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:38:19 -0800 Message-ID: <20141119203819.GA31321@kroah.com> References: <20141119173910.GC31260@kroah.com> <546CE51B.6010802@googlemail.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: <546CE51B.6010802@googlemail.com> Sender: stable-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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 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 lis= t 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 dentr= y_lru_del() in dentry_kill() > >>> b4f0354e968f5fabd39bc85b99fedae4a97589fe new helper: dentry_free(= ) > >>> 5c47e6d0ad608987b91affbcf7d1fc12dfbe8fb4 fold try_prune_one_dentr= y() > >>> 03b3b889e79cdb6b806fc0ba9be0d71c186bbfaa fold d_kill() and d_free= () > >>> > >>> And there are 7 patches to fix the above patches: > >>> > >>> 00fe425bc28f0ccba034a77783c09c15af4 dcache: add missing lockdep a= nnotation > >> > >> This commit does not exist and seems to be the truncated hash of t= he > >> last one (9f12600f..). I guess copypasta salad. > >> > >>> 8cbf74da435d1bd13dbb790f94c7ff67b2fb6af4 dentry_kill() doesn't ne= ed the second argument now > >>> b2b80195d8829921506880f6dccd21cabd163d0d dealing with the rest of= shrink_dentry_list() livelock > >>> 046b961b45f93a92e4c70525a12f3d378bced130 shrink_dentry_list(): ta= ke parent's ->d_lock earlier > >>> ff2fde9929feb2aef45377ce56b8b12df85dda69 expand dentry_kill(dentr= y, 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 l= ockdep annotation > >>> > >>> I don't follow vfs development so could easily miss something her= e, Al > >>> should know much better than I do and may come up with a much eas= ier > >>> way to fix it. Please evaluate this. > >> > >> I can confirm that these apply correctly (in reverse order per par= agraph) over > >> 3.14.19 and that it still compiles. > >=20 > > Compiling is nice, what I would like to see is a way to reproduce t= he > > original problem and proof that backporting all of these intrusive > > patches is worth it. Given that the git commit ids in the list are= n'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 n= ot > only applies & compiles but also runs and doesn't result in any regre= ssions, > 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 jus= t > now checked via cgit that e.g. the last commit 64fd72 is exactly wher= e > it is supposed to be. >=20 > 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