Messages in this thread |  | | | Date | Thu, 31 May 2012 16:53:00 -0400 | | From | "J. Bruce Fields" <> | | Subject | Re: nfsd changes for 3.5 |
| |
On Thu, May 31, 2012 at 01:17:26PM -0700, Linus Torvalds wrote: > On Thu, May 31, 2012 at 1:01 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > > > Right. By default it's 90 seconds before we'll give up on the client. > > So a slightly buggy client can basically DoS the server by getting a > delegation and then crashing or something. Everybody else that tries > to read that directory (not that file) will be dead in the water. > Definitely not good. > > > I hate that too, and originally tried to avoid it with something like: > > > > retry: > > acquire locks > > lookup inode > > ret = try_to_break_deleg(inode); > > if (ret) > > drop locks > > really_break_deleg(inode); > > goto retry; > > ... do the real work ... > > drop locks > > > > I felt like I was making already complicated code logic like rename's > > even harder to follow. > > I do think it's the only thing we can reasonably do.
OK, I can give that another try. Al, does that sound like the more sensible choice to you?
Uh, that means ditching some work in my public git tree. Which I haven't rebased in years. So, a stupid process question; would you rather I:
- continue to be strict about rebasing and apply a bunch of reverts? - ditch it and start over?
#1 looks like a mess to me, so I guess #2's my default. Probably nobody will notice but me.
> I'd love to have > some kind of per-dentry lock for unlink/rename, but we don't. > Long-term, we really do need to do something about the directory > locking, though, because it's also a huge problem for readdir() > concurrency. Or at least it used to be (samba in particular). Making > it an rwsem might help readdir a tiny amount, but I suspect people > actually depend on the mutex in readdir right now.
Al called this all "highly non-trivial":
http://marc.info/?l=linux-fsdevel&m=132726495726326&w=2
I don't know who'd have the cycles.
--b.
> > > And those operations don't really know the inode till they acquire the > > locks, so in pathological cases that could continue forever. > > I suspect at some point you just have to say "screw it". -- 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/
|  |