Re: NFSd state: nfs4_lock_state() and nfs4_lock_state()

["bfields@fieldses.org" <bfields@fieldses.org>]

On Tue, Nov 27, 2012 at 11:54:30AM +0400, Stanislav Kinsbursky wrote:
> 27.11.2012 02:36, bfields@fieldses.org пишет:
> >On Fri, Nov 23, 2012 at 03:31:11PM +0400, Stanislav Kinsbursky wrote:
> >>19.11.2012 16:46, bfields@fieldses.org пишет:
> >>>On Mon, Nov 19, 2012 at 12:39:23PM +0400, Stanislav Kinsbursky wrote:
> >>>>16.11.2012 20:58, bfields@fieldses.org пишет:
> >>>>>
> >>>>>A patch follows: note it's a two-line patch, with 20 lines of changelog
> >>>>>showing that I looked at what state might be shared by other threads and
> >>>>>explaining why I think this is safe.
> >>>>>
> >>>>
> >>>>Acked-by: Stanislav Kinsburskiy <skinsbursky@parallels.com>
> >>>>
> >>>>>I think that's what we need to do: little patches that remove it from
> >>>>>one or another part of the code with careful explanation of why it
> >>>>>works.
> >>>>>
> >>>>
> >>>>Yes, thanks. I'll also try to simplify nfsd_open() by little patches.
> >>>>In general it looks like client_mutex protect two different things:
> >>>>open owner state (which is containerised already, actually) and
> >>>>files access.
> >>>>So, probably, this client mutex have to be converted into two:
> >>>>per-net one, which protects open owner state, and static one, which
> >>>>protects files operations.
> >>>>What do you think about it?
> >>>
> >>>That sounds right.
> >>>
> >>
> >>Looked into the code, and few more questions raised.
> >>So, currently, this mutex protects different NFS4 state structures and VFS file operations (like open, read, write, etc.).
> >>I would like this mutex to be converted into per-net one. Since NFS4
> >>state structures are per-net already (with my previous patch set),
> >>the only thing left is VFS operations.
> >>But do we really need to protect them somehow from concurrent access?
> >>I.e. do we have some RPCs, which does more that one file manipulation, but this manipulations sequence have to be "atomic" in NFSd terms?
> >
> >Probably not, but open is the most likely problem, as it does several
> >things which are not all atomic from the point of view of the vfs.  The
> >mutex can't prevent races between an nfs client and a local user, but it
> >can at least prevent races between nfs clients.
> >
> 
> Ok then.
> You said, that you are going to optimize open a bit?

It's on my todo list, but I'm not sure when it will be done.

> I think client_mutex containerization can be delayed for a while.

OK.--b.