[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y4z8uzqw.fsf_-_@x220.int.ebiederm.org>
Date: Mon, 14 Apr 2014 00:38:47 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Rob Landley <rob@...dley.net>,
Miklos Szeredi <miklos@...redi.hu>,
Christoph Hellwig <hch@...radead.org>,
Karel Zak <kzak@...hat.com>,
"J. Bruce Fields" <bfields@...ldses.org>,
Fengguang Wu <fengguang.wu@...el.com>, tytso@....edu
Subject: [RFC][PATCH 0/4] No I/O from mntput
There are a lot of ways we could approach this, and I sat down and wrote
the simplest variant I could think of, so hopefully there are not silly
bugs that get overlooked.
The code move all cleanup from mntput that would do filesystem I/O into
work queues.
The code waits in mntput for that I/O to complete if we wait today.
The code has been tested and it works, and it succeeds in running
deactivate_super in a stack from with just short of 7500 bytes free.
7500 bytes should be enough for anybody!
I want to double check that I am using work queues correctly, they used
to be deadlock prone, and sleep on everything before I commit to a final
version but this version is probably good enough.
I may be going overboard in the case where we auto close BSD accounting
files, but at this point I figure better safe than sorry.
Eric W. Biederman (4):
vfs: Remove useless loop in mntput_no_expire
vfs: Move autoclose of BSD accounting into a work queue
vfs: In mntput run deactivate_super on a shallow stack.
vfs: Block intuitively in the case of BSD accounting files
fs/mount.h | 14 +++++++++++---
fs/namespace.c | 43 +++++++++++++++++++++++++++++++++++--------
kernel/acct.c | 25 ++++++++++++++++++++-----
3 files changed, 66 insertions(+), 16 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists