Messages in this thread | | | Date | Tue, 11 Mar 2003 10:16:25 -0700 | From | Andreas Dilger <> | Subject | Re: [RFC] Improved inode number allocation for HTree |
| |
On Mar 11, 2003 14:41 +0100, Daniel Phillips wrote: > On Tue 11 Mar 03 14:00, Helge Hafting wrote: > > I'm happy nobody _can_ lock a directory like that. Think of it - unable > > to create or delete files while some slow-moving program is traversing > > the directory? Ouch. Plenty of options for DOS attacks too. > > And how to do "rm *.bak" if rm locks the dir for traversal? > > <wishful thinking> > Now that you mention it, just locking out create and rename during directory > traversal would eliminate the pain. Delete is easy enough to handle during > traversal. For a B-Tree, coalescing could simply be deferred until the > traversal is finished, so reading the directory in physical storage order > would be fine. Way, way cleaner than what we have to do now. > </wishful thinking>
The other problem, of course, is that this would essentially mean that a user-space application has a lock that prevents other processes (even the kernel) from doing anything. At best we have to worry about an application going sour, and at worst it is a DOS hole as Helge says.
How about something like:
death: for each directory while readdir(directory, large_buffer) if (directory) run death(directory) readdir(directory, small_buffer)
sleep forever
The first getdents walks recursively down to the leaves, and then does a single getdents with enough space to hold a single dirent, locking the directory, but then never progressing. It also does the single-dirent getdents on the way up the tree. Now, everything is locked out of the entire directory tree.
Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
- 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/
| |