From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with SMTP id 0C4C25F0001 for ; Tue, 14 Apr 2009 03:38:57 -0400 (EDT) Subject: Re: [RFC][PATCH 0/9] File descriptor hot-unplug support References: <49E4000E.10308@kernel.org> From: ebiederm@xmission.com (Eric W. Biederman) Date: Tue, 14 Apr 2009 00:39:25 -0700 In-Reply-To: <49E4000E.10308@kernel.org> (Tejun Heo's message of "Tue\, 14 Apr 2009 12\:16\:30 +0900") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org To: Tejun Heo Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Al Viro , Hugh Dickins , Alexey Dobriyan , Linus Torvalds , Alan Cox , Greg Kroah-Hartman List-ID: Tejun Heo writes: > Hello, Eric. > > Eric W. Biederman wrote: >> A couple of weeks ago I found myself looking at the uio, seeing that >> it does not support pci hot-unplug, and thinking "Great yet another >> implementation of hotunplug logic that needs to be added". >> >> I decided to see what it would take to add a generic implementation of >> the code we have for supporting hot unplugging devices in sysfs, proc, >> sysctl, tty_io, and now almost in the tun driver. >> >> Not long after I touched the tun driver and made it safe to delete the >> network device while still holding it's file descriptor open I someone >> else touch the code adding a different feature and my careful work >> went up in flames. Which brought home another point at the best of it >> this is ultimately complex tricky code that subsystems should not need >> to worry about. > > I like the way it's headed. I'm trying to add similar 'revoke' or > 'sever' mechanism at block and char device layers so that low level > drivers don't have to worry about object lifetimes and so on. Doing > it at the file layer makes sense and can probably replace whatever > mechanism at the chardev. > > The biggest obstacle was the extra in-use reference count overhead. I > thought it could be solved by implementing generic percpu reference > count similar to the one used for module reference counting. Hot path > overhead could be reduced to local_t cmpxchg (w/o LOCK prefix) on > per-cpu variable + one branch, which was pretty good. The problem was > that space and access overhead for dynamic per-cpu variables wasn't > too good, so I started working on dynamic percpu allocator. > > The dynamic per-cpu allocator is pretty close to completion. Only > several archs need to be converted and it's likely to happen during > next few months. The plan after that was 1. add per-cpu local_t > accessors (might replace local_t completely) 2. add generic per-cpu > reference counter and move module reference counting to it > 3. implement block/chardev sever (or revoke) support. > > I think #3 can be merged with what you're working on. What do you > think? Sounds reasonable. Do you know of a case where we actually have multiple tasks accessing a file simultaneously? I just instrumented up my patch an so far the only case I have found are multiple processes closing the same file. Some weird part of bash forking extra processes. Eric -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org