linux-kernel - Re: nfsd changes for 3.5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120531205300.GG25955@fieldses.org>
Date:	Thu, 31 May 2012 16:53:00 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-nfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
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@...ldses.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/