linux.git/fs/nfsd, branch v4.15

nfsd: auth: Fix gid sorting when rootsquash enabled

2018-01-23T04:13:07+00:00

Commit bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility
group_info allocators") appears to break nfsd rootsquash in a pretty
major way.

It adds a call to groups_sort() inside the loop that copies/squashes
gids, which means the valid gids are sorted along with the following
garbage.  The net result is that the highest numbered valid gids are
replaced with any lower-valued garbage gids, possibly including 0.

We should sort only once, after filling in all the gids.

Fixes: bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility ...")
Signed-off-by: Ben Hutchings 
Acked-by: J. Bruce Fields 
Signed-off-by: Linus Torvalds

kernel: make groups_sort calling a responsibility group_info allocators

2017-12-15T00:00:49+00:00

In testing, we found that nfsd threads may call set_groups in parallel
for the same entry cached in auth.unix.gid, racing in the call of
groups_sort, corrupting the groups for that entry and leading to
permission denials for the client.

This patch:
 - Make groups_sort globally visible.
 - Move the call to groups_sort to the modifiers of group_info
 - Remove the call to groups_sort from set_groups

Link: http://lkml.kernel.org/r/20171211151420.18655-1-thiago.becker@gmail.com
Signed-off-by: Thiago Rafael Becker 
Reviewed-by: Matthew Wilcox 
Reviewed-by: NeilBrown 
Acked-by: "J. Bruce Fields" 
Cc: Al Viro 
Cc: Martin Schwidefsky 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lockd: fix "list_add double add" caused by legacy signal interface

2017-11-27T21:45:11+00:00

restart_grace() uses hardcoded init_net.
It can cause to "list_add double add" in following scenario:

1) nfsd and lockd was started in several net namespaces
2) nfsd in init_net was stopped (lockd was not stopped because
 it have users from another net namespaces)
3) lockd got signal, called restart_grace() -> set_grace_period()
 and enabled lock_manager in hardcoded init_net.
4) nfsd in init_net is started again,
 its lockd_up() calls set_grace_period() and tries to add
 lock_manager into init_net 2nd time.

Jeff Layton suggest:
"Make it safe to call locks_start_grace multiple times on the same
lock_manager. If it's already on the global grace_list, then don't try
to add it again.  (But we don't intentionally add twice, so for now we
WARN about that case.)

With this change, we also need to ensure that the nfsd4 lock manager
initializes the list before we call locks_start_grace. While we're at
it, move the rest of the nfsd_net initialization into
nfs4_state_create_net. I see no reason to have it spread over two
functions like it is today."

Suggested patch was updated to generate warning in described situation.

Suggested-by: Jeff Layton 
Signed-off-by: Vasily Averin 
Signed-off-by: J. Bruce Fields

race of nfsd inetaddr notifiers vs nn->nfsd_serv change

2017-11-27T21:45:11+00:00

nfsd_inet[6]addr_event uses nn->nfsd_serv without taking nfsd_mutex,
which can be changed during execution of notifiers and crash the host.

Moreover if notifiers were enabled in one net namespace they are enabled
in all other net namespaces, from creation until destruction.

This patch allows notifiers to access nn->nfsd_serv only after the
pointer is correctly initialized and delays cleanup until notifiers are
no longer in use.

Signed-off-by: Vasily Averin 
Tested-by: Scott Mayhew 
Signed-off-by: J. Bruce Fields

NFSD: make cache_detail structures const

2017-11-27T21:45:11+00:00

Make these const as they are only getting passed to the function
cache_create_net having the argument as const.

Signed-off-by: Bhumika Goyal 
Reviewed-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

nfsd: check for use of the closed special stateid

2017-11-27T21:45:11+00:00

Prevent the use of the closed (invalid) special stateid by clients.

Signed-off-by: Andrew Elble 
Signed-off-by: J. Bruce Fields

nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat

2017-11-27T21:45:11+00:00

From kernel 4.9, my two nfsv4 servers sometimes suffer from
    "panic: unable to handle kernel page request"
in posix_unblock_lock() called from nfs4_laundromat().

These panics diseappear if we revert the commit "nfsd: add a LRU list
for blocked locks".

The cause appears to be a typo in nfs4_laundromat(), which is also
present in nfs4_state_shutdown_net().

Cc: stable@vger.kernel.org
Fixes: 7919d0a27f1e "nfsd: add a LRU list for blocked locks"
Cc: jlayton@redhat.com
Reveiwed-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

nfsd: fix locking validator warning on nfs4_ol_stateid->st_mutex class

2017-11-27T21:45:10+00:00

The use of the st_mutex has been confusing the validator. Use the
proper nested notation so as to not produce warnings.

Signed-off-by: Andrew Elble 
Signed-off-by: J. Bruce Fields

nfsd: remove net pointer from debug messages

2017-11-27T21:45:10+00:00

Publishing of net pointer is not safe,
replace it in debug meesages by net->ns.inum

[  119.989161] nfsd: initializing export module (net: f00001e7).
[  171.767188] NFSD: starting 90-second grace period (net f00001e7)
[  322.185240] nfsd: shutting down export module (net: f00001e7).
[  322.186062] nfsd: export shutdown complete (net: f00001e7).

Signed-off-by: Vasily Averin 
Signed-off-by: J. Bruce Fields

nfsd: Fix races with check_stateid_generation()

2017-11-27T21:45:10+00:00

The various functions that call check_stateid_generation() in order
to compare a client-supplied stateid with the nfs4_stid state, usually
need to atomically check for closed state. Those that perform the
check after locking the st_mutex using nfsd4_lock_ol_stateid()
should now be OK, but we do want to fix up the others.

Signed-off-by: Trond Myklebust 
Signed-off-by: J. Bruce Fields