On Fri, Jun 04, 2010 at 04:38:18AM -0400, Christoph Hellwig wrote: > On Fri, Jun 04, 2010 at 04:43:08PM +1000, Nick Piggin wrote: > > Lock tty_files with a new spinlock, tty_files_lock; provide helpers to > > manipulate the per-sb files list; unexport the files_lock spinlock. > > I'm still not entirely happy with this. You keep making the tty a > special case by removing it from the files per-sb files list while > nothing else in the system is removed from it. > > Thinks would be much better if you could untangle the tty code from > abuse of file->f_u.fu_list entirely. And from a naive look at the > tty code that actually seems pretty easy. file->private for ttys > currently directly points to the tty struct. If you add a tty_private > there which points back to the file, the tty and contains a list_head > the open files in tty code tracking code can be completely divorced > from the per-sb file tracking. Well it is already a special case, I just switched it to using a different lock for its private list. I wanted to keep surgery to a minimum. > After that we can decide what to do > with the per-sb file tracking, where my favourite still is to get > rid of it entirely. Again, this would be nice, but I didn't see an easy way to do it. Even if refcounting obsoleted may_remount_ro, we still have mark_files_ro. It's no more complex to rip this all out after my patch. I don't see the problem in doing this patch. It has good numbers. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
