lkml.org 
[lkml]   [2014]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dcache shrink list corruption?
On Fri, May 02, 2014 at 11:40:22PM +0100, Al Viro wrote:
> On Fri, May 02, 2014 at 02:18:43PM -0700, Linus Torvalds wrote:
> > On Fri, May 2, 2014 at 2:08 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > There's more of the "delete from shrink list not owned by us" in select parent.
> > > Proposed patch appended.
> >
> > Ahh. Clearly this needs more work before I pull.
>
> *nod*
>
> Besides, I want to put Miklos' "don't bother with RCU in shrink_dentry_list()"
> in there as soon as select_collect() has been dealt with. I don't think
> that the currently posted patch for select_collect() is right, though -
> see my reply to parent posting. Basically, I think we should treat "it's
> on the shrink list already" as "increment data->found and keep going". IOW,
> if (on shrink list) {
> data->found++;
> } else {
> if (on lru list)
> d_lru_del
> if (refcount is zero) {
> d_shrink_add
> data->found++;
> }
> }
> if (data->found)
> ret = need_resched() ? D_WALK_QUIT : D_WALK_NORETRY;

While we are at it - BUG() in umount_collect() is probably a bad idea.
At that point we are holding ->s_umount, so it guarantees that a lot
of stuff from that point on will get stuck. Starting with sync(2).
And I really doubt that damage from WARN() instead will be more...


\
 
 \ /
  Last update: 2014-05-03 01:41    [W:0.085 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site