Messages in this thread | | | Date | Mon, 24 Oct 2005 22:21:02 -0400 | From | Chris Mason <> | Subject | Re: [PATCH] fix nr_unused accounting, and avoid recursing in iput with I_WILL_FREE set |
| |
On Tue, Oct 18, 2005 at 07:26:46PM -0700, Andrew Morton wrote: > Chris Mason <mason@suse.com> wrote: > > > > On Tue, Oct 18, 2005 at 06:15:48PM -0700, Andrew Morton wrote: > > > > > Well according to my assertion (below), the inode in __sync_single_inode() > > > > > cannot have a zero refcount, so the whole if() statement is never executed. > > > > > > > > generic_forget_inode->write_inode_now->__writeback_single_inode-> > > > > __sync_single_inode > > > > > > oshit. > > > > When does this ever happen? Just for private inodes released during > > put_super right? > > I suppose so, yes.
It's not related to the bug, but prune_icache can jump in at any time during generic_shutdown_super, except during the invalidate_inodes runs. Something like this:
proc1 proc2 generic_shutdown_super s->s_flags &= ~MS_ACTIVE invalidate_inodes put_super shrink_icache_memory prune_icache invalidate_inode_pages try_to_release_page
I doubt any FS triggers this. They would need to generate inodes with pages during the put_super call, and get them onto the unused list. But, I think prune_icache should just skip any inodes where the super doesn't have MS_ACTIVE set.
At any rate, this wasn't the race I was looking for. Aside from the bugs fixed by Andrea's patch, we were seeing inodes go negative thanks to a bad interaction between a latency fix and a backport of something else from mainline. Our latency code has a goto again, and mainline has a big fat comment explaining why goto again isn't needed.
If the super->s_inodes list was long enough to reschedule in invalidate_list, we would process the same inodes in multiple times without removing them.
The short version is that no additional patches should be needed for mainline.
-chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |