2019-05-27 09:55:01 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2007-04-27 02:49:28 +04:00
/* AFS cell and server record management
2005-04-17 02:20:36 +04:00
*
2017-11-02 18:27:50 +03:00
* Copyright ( C ) 2002 , 2017 Red Hat , Inc . All Rights Reserved .
2005-04-17 02:20:36 +04:00
* Written by David Howells ( dhowells @ redhat . com )
*/
# include <linux/slab.h>
2007-04-27 02:57:07 +04:00
# include <linux/key.h>
# include <linux/ctype.h>
2010-08-04 18:16:38 +04:00
# include <linux/dns_resolver.h>
Detach sched.h from mm.h
First thing mm.h does is including sched.h solely for can_do_mlock() inline
function which has "current" dereference inside. By dealing with can_do_mlock()
mm.h can be detached from sched.h which is good. See below, why.
This patch
a) removes unconditional inclusion of sched.h from mm.h
b) makes can_do_mlock() normal function in mm/mlock.c
c) exports can_do_mlock() to not break compilation
d) adds sched.h inclusions back to files that were getting it indirectly.
e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
getting them indirectly
Net result is:
a) mm.h users would get less code to open, read, preprocess, parse, ... if
they don't need sched.h
b) sched.h stops being dependency for significant number of files:
on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
after patch it's only 3744 (-8.3%).
Cross-compile tested on
all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
alpha alpha-up
arm
i386 i386-up i386-defconfig i386-allnoconfig
ia64 ia64-up
m68k
mips
parisc parisc-up
powerpc powerpc-up
s390 s390-up
sparc sparc-up
sparc64 sparc64-up
um-x86_64
x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
as well as my two usual configs.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-21 01:22:52 +04:00
# include <linux/sched.h>
2017-11-02 18:27:47 +03:00
# include <linux/inet.h>
2018-06-15 17:19:22 +03:00
# include <linux/namei.h>
2007-04-27 02:57:07 +04:00
# include <keys/rxrpc-type.h>
2005-04-17 02:20:36 +04:00
# include "internal.h"
2018-04-09 23:12:31 +03:00
static unsigned __read_mostly afs_cell_gc_delay = 10 ;
2018-10-20 02:57:57 +03:00
static unsigned __read_mostly afs_cell_min_ttl = 10 * 60 ;
static unsigned __read_mostly afs_cell_max_ttl = 24 * 60 * 60 ;
2020-10-13 22:51:59 +03:00
static atomic_t cell_debug_id ;
2017-11-02 18:27:50 +03:00
2020-10-15 13:05:01 +03:00
static void afs_queue_cell_manager ( struct afs_net * ) ;
2019-07-23 13:24:59 +03:00
static void afs_manage_cell_work ( struct work_struct * ) ;
2017-11-02 18:27:50 +03:00
static void afs_dec_cells_outstanding ( struct afs_net * net )
{
if ( atomic_dec_and_test ( & net - > cells_outstanding ) )
2018-03-15 13:42:28 +03:00
wake_up_var ( & net - > cells_outstanding ) ;
2017-11-02 18:27:50 +03:00
}
2005-04-17 02:20:36 +04:00
/*
2017-11-02 18:27:50 +03:00
* Set the cell timer to fire after a given delay , assuming it ' s not already
* set for an earlier time .
2005-04-17 02:20:36 +04:00
*/
2017-11-02 18:27:50 +03:00
static void afs_set_cell_timer ( struct afs_net * net , time64_t delay )
2005-04-17 02:20:36 +04:00
{
2017-11-02 18:27:50 +03:00
if ( net - > live ) {
atomic_inc ( & net - > cells_outstanding ) ;
if ( timer_reduce ( & net - > cells_timer , jiffies + delay * HZ ) )
afs_dec_cells_outstanding ( net ) ;
2020-10-15 13:05:01 +03:00
} else {
afs_queue_cell_manager ( net ) ;
2017-11-02 18:27:50 +03:00
}
}
/*
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
* Look up and get an activation reference on a cell record . The caller must
* hold net - > cells_lock at least read - locked .
2017-11-02 18:27:50 +03:00
*/
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
static struct afs_cell * afs_find_cell_locked ( struct afs_net * net ,
2020-10-13 22:51:59 +03:00
const char * name , unsigned int namesz ,
enum afs_cell_trace reason )
2017-11-02 18:27:50 +03:00
{
struct afs_cell * cell = NULL ;
struct rb_node * p ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
int n ;
2017-11-02 18:27:50 +03:00
_enter ( " %*.*s " , namesz , namesz , name ) ;
if ( name & & namesz = = 0 )
return ERR_PTR ( - EINVAL ) ;
if ( namesz > AFS_MAXCELLNAME )
return ERR_PTR ( - ENAMETOOLONG ) ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
if ( ! name ) {
cell = net - > ws_cell ;
if ( ! cell )
return ERR_PTR ( - EDESTADDRREQ ) ;
2019-07-23 13:24:59 +03:00
goto found ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
}
2017-11-02 18:27:50 +03:00
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
p = net - > cells . rb_node ;
while ( p ) {
cell = rb_entry ( p , struct afs_cell , net_node ) ;
2005-04-17 02:20:36 +04:00
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
n = strncasecmp ( cell - > name , name ,
min_t ( size_t , cell - > name_len , namesz ) ) ;
if ( n = = 0 )
n = cell - > name_len - namesz ;
if ( n < 0 )
p = p - > rb_left ;
else if ( n > 0 )
p = p - > rb_right ;
else
goto found ;
}
return ERR_PTR ( - ENOENT ) ;
2005-04-17 02:20:36 +04:00
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
found :
2020-10-13 22:51:59 +03:00
return afs_use_cell ( cell , reason ) ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
}
2019-08-22 15:28:43 +03:00
2019-07-23 13:24:59 +03:00
/*
* Look up and get an activation reference on a cell record .
*/
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
struct afs_cell * afs_find_cell ( struct afs_net * net ,
2020-10-13 22:51:59 +03:00
const char * name , unsigned int namesz ,
enum afs_cell_trace reason )
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
{
struct afs_cell * cell ;
down_read ( & net - > cells_lock ) ;
2020-10-13 22:51:59 +03:00
cell = afs_find_cell_locked ( net , name , namesz , reason ) ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
up_read ( & net - > cells_lock ) ;
return cell ;
2017-11-02 18:27:50 +03:00
}
/*
* Set up a cell record and fill in its name , VL server address list and
* allocate an anonymous key
*/
static struct afs_cell * afs_alloc_cell ( struct afs_net * net ,
const char * name , unsigned int namelen ,
2018-10-20 02:57:57 +03:00
const char * addresses )
2017-11-02 18:27:50 +03:00
{
2019-05-07 17:30:34 +03:00
struct afs_vlserver_list * vllist ;
2017-11-02 18:27:50 +03:00
struct afs_cell * cell ;
int i , ret ;
ASSERT ( name ) ;
if ( namelen = = 0 )
return ERR_PTR ( - EINVAL ) ;
2010-08-04 18:16:38 +04:00
if ( namelen > AFS_MAXCELLNAME ) {
_leave ( " = -ENAMETOOLONG " ) ;
2007-04-27 02:57:07 +04:00
return ERR_PTR ( - ENAMETOOLONG ) ;
2010-08-04 18:16:38 +04:00
}
2020-01-26 04:02:53 +03:00
/* Prohibit cell names that contain unprintable chars, '/' and '@' or
* that begin with a dot . This also precludes " @cell " .
*/
if ( name [ 0 ] = = ' . ' )
2018-04-06 16:17:23 +03:00
return ERR_PTR ( - EINVAL ) ;
2020-01-26 04:02:53 +03:00
for ( i = 0 ; i < namelen ; i + + ) {
char ch = name [ i ] ;
if ( ! isprint ( ch ) | | ch = = ' / ' | | ch = = ' @ ' )
return ERR_PTR ( - EINVAL ) ;
}
2007-04-27 02:57:07 +04:00
2018-10-20 02:57:57 +03:00
_enter ( " %*.*s,%s " , namelen , namelen , name , addresses ) ;
2017-11-02 18:27:50 +03:00
cell = kzalloc ( sizeof ( struct afs_cell ) , GFP_KERNEL ) ;
2005-04-17 02:20:36 +04:00
if ( ! cell ) {
_leave ( " = -ENOMEM " ) ;
2007-04-27 02:55:03 +04:00
return ERR_PTR ( - ENOMEM ) ;
2005-04-17 02:20:36 +04:00
}
2020-06-24 19:00:24 +03:00
cell - > name = kmalloc ( namelen + 1 , GFP_KERNEL ) ;
if ( ! cell - > name ) {
kfree ( cell ) ;
return ERR_PTR ( - ENOMEM ) ;
}
2017-11-02 18:27:45 +03:00
cell - > net = net ;
2017-11-02 18:27:50 +03:00
cell - > name_len = namelen ;
for ( i = 0 ; i < namelen ; i + + )
cell - > name [ i ] = tolower ( name [ i ] ) ;
2020-06-24 19:00:24 +03:00
cell - > name [ i ] = 0 ;
2017-11-02 18:27:50 +03:00
2022-07-06 12:52:14 +03:00
refcount_set ( & cell - > ref , 1 ) ;
2019-07-23 13:24:59 +03:00
atomic_set ( & cell - > active , 0 ) ;
INIT_WORK ( & cell - > manager , afs_manage_cell_work ) ;
2023-11-07 20:59:33 +03:00
init_rwsem ( & cell - > vs_lock ) ;
2020-04-30 03:03:49 +03:00
cell - > volumes = RB_ROOT ;
INIT_HLIST_HEAD ( & cell - > proc_volumes ) ;
seqlock_init ( & cell - > volume_lock ) ;
cell - > fs_servers = RB_ROOT ;
seqlock_init ( & cell - > fs_lock ) ;
2018-10-20 02:57:57 +03:00
rwlock_init ( & cell - > vl_servers_lock ) ;
afs: Detect cell aliases 1 - Cells with root volumes
Put in the first phase of cell alias detection. This part handles alias
detection for cells that have root.cell volumes (which is expected to be
likely).
When a cell becomes newly active, it is probed for its root.cell volume,
and if it has one, this volume is compared against other root.cell volumes
to find out if the list of fileserver UUIDs have any in common - and if
that's the case, do the address lists of those fileservers have any
addresses in common. If they do, the new cell is adjudged to be an alias
of the old cell and the old cell is used instead.
Comparing is aided by the server list in struct afs_server_list being
sorted in UUID order and the addresses in the fileserver address lists
being sorted in address order.
The cell then retains the afs_volume object for the root.cell volume, even
if it's not mounted for future alias checking.
This necessary because:
(1) Whilst fileservers have UUIDs that are meant to be globally unique, in
practice they are not because cells get cloned without changing the
UUIDs - so afs_server records need to be per cell.
(2) Sometimes the DNS is used to make cell aliases - but if we don't know
they're the same, we may end up with multiple superblocks and multiple
afs_server records for the same thing, impairing our ability to
deliver callback notifications of third party changes
(3) The fileserver RPC API doesn't contain the cell name, so it can't tell
us which cell it's notifying and can't see that a change made to to
one cell should notify the same client that's also accessed as the
other cell.
Reported-by: Jeffrey Altman <jaltman@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
2020-04-25 12:26:02 +03:00
cell - > flags = ( 1 < < AFS_CELL_FL_CHECK_ALIAS ) ;
2017-11-02 18:27:47 +03:00
2019-05-07 17:30:34 +03:00
/* Provide a VL server list, filling it in if we were given a list of
* addresses to use .
2017-11-02 18:27:50 +03:00
*/
2018-10-20 02:57:57 +03:00
if ( addresses ) {
vllist = afs_parse_text_addrs ( net ,
addresses , strlen ( addresses ) , ' : ' ,
VL_SERVICE , AFS_VL_PORT ) ;
if ( IS_ERR ( vllist ) ) {
ret = PTR_ERR ( vllist ) ;
2017-11-02 18:27:50 +03:00
goto parse_failed ;
}
2007-04-27 02:57:07 +04:00
2019-05-07 17:06:36 +03:00
vllist - > source = DNS_RECORD_FROM_CONFIG ;
vllist - > status = DNS_LOOKUP_NOT_DONE ;
2017-11-02 18:27:50 +03:00
cell - > dns_expiry = TIME64_MAX ;
2018-10-20 02:57:57 +03:00
} else {
2019-05-07 17:30:34 +03:00
ret = - ENOMEM ;
vllist = afs_alloc_vlserver_list ( 0 ) ;
if ( ! vllist )
goto error ;
2019-05-07 17:06:36 +03:00
vllist - > source = DNS_RECORD_UNAVAILABLE ;
vllist - > status = DNS_LOOKUP_NOT_DONE ;
2018-10-20 02:57:57 +03:00
cell - > dns_expiry = ktime_get_real_seconds ( ) ;
2007-04-27 02:57:07 +04:00
}
2019-05-07 17:30:34 +03:00
rcu_assign_pointer ( cell - > vl_servers , vllist ) ;
2019-05-07 17:06:36 +03:00
cell - > dns_source = vllist - > source ;
cell - > dns_status = vllist - > status ;
smp_store_release ( & cell - > dns_lookup_count , 1 ) ; /* vs source/status */
2019-07-23 13:24:59 +03:00
atomic_inc ( & net - > cells_outstanding ) ;
2020-10-13 22:51:59 +03:00
cell - > debug_id = atomic_inc_return ( & cell_debug_id ) ;
trace_afs_cell ( cell - > debug_id , 1 , 0 , afs_cell_trace_alloc ) ;
2019-05-07 17:06:36 +03:00
2007-04-27 02:57:07 +04:00
_leave ( " = %p " , cell ) ;
return cell ;
2017-11-02 18:27:50 +03:00
parse_failed :
if ( ret = = - EINVAL )
printk ( KERN_ERR " kAFS: bad VL server IP address \n " ) ;
2019-05-07 17:30:34 +03:00
error :
2020-06-24 19:00:24 +03:00
kfree ( cell - > name ) ;
2007-04-27 02:57:07 +04:00
kfree ( cell ) ;
_leave ( " = %d " , ret ) ;
return ERR_PTR ( ret ) ;
}
2005-04-17 02:20:36 +04:00
2007-04-27 02:57:07 +04:00
/*
2017-11-02 18:27:50 +03:00
* afs_lookup_cell - Look up or create a cell record .
2017-11-02 18:27:45 +03:00
* @ net : The network namespace
2017-11-02 18:27:50 +03:00
* @ name : The name of the cell .
* @ namesz : The strlen of the cell name .
* @ vllist : A colon / comma separated list of numeric IP addresses or NULL .
* @ excl : T if an error should be given if the cell name already exists .
*
* Look up a cell record by name and query the DNS for VL server addresses if
* needed . Note that that actual DNS query is punted off to the manager thread
* so that this function can return immediately if interrupted whilst allowing
* cell records to be shared even if not yet fully constructed .
2007-04-27 02:57:07 +04:00
*/
2017-11-02 18:27:50 +03:00
struct afs_cell * afs_lookup_cell ( struct afs_net * net ,
const char * name , unsigned int namesz ,
const char * vllist , bool excl )
2007-04-27 02:57:07 +04:00
{
2017-11-02 18:27:50 +03:00
struct afs_cell * cell , * candidate , * cursor ;
struct rb_node * parent , * * pp ;
2019-05-07 17:06:36 +03:00
enum afs_cell_state state ;
2017-11-02 18:27:50 +03:00
int ret , n ;
_enter ( " %s,%s " , name , vllist ) ;
if ( ! excl ) {
2020-10-13 22:51:59 +03:00
cell = afs_find_cell ( net , name , namesz , afs_cell_trace_use_lookup ) ;
2017-11-18 01:40:32 +03:00
if ( ! IS_ERR ( cell ) )
2017-11-02 18:27:50 +03:00
goto wait_for_cell ;
}
2007-04-27 02:57:07 +04:00
2017-11-02 18:27:50 +03:00
/* Assume we're probably going to create a cell and preallocate and
* mostly set up a candidate record . We can then use this to stash the
* name , the net namespace and VL server addresses .
*
* We also want to do this before we hold any locks as it may involve
* upcalling to userspace to make DNS queries .
*/
candidate = afs_alloc_cell ( net , name , namesz , vllist ) ;
if ( IS_ERR ( candidate ) ) {
_leave ( " = %ld " , PTR_ERR ( candidate ) ) ;
return candidate ;
2008-03-29 00:15:55 +03:00
}
2017-11-02 18:27:50 +03:00
/* Find the insertion point and check to see if someone else added a
* cell whilst we were allocating .
*/
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
down_write ( & net - > cells_lock ) ;
2017-11-02 18:27:50 +03:00
pp = & net - > cells . rb_node ;
parent = NULL ;
while ( * pp ) {
parent = * pp ;
cursor = rb_entry ( parent , struct afs_cell , net_node ) ;
n = strncasecmp ( cursor - > name , name ,
min_t ( size_t , cursor - > name_len , namesz ) ) ;
if ( n = = 0 )
n = cursor - > name_len - namesz ;
if ( n < 0 )
pp = & ( * pp ) - > rb_left ;
else if ( n > 0 )
pp = & ( * pp ) - > rb_right ;
else
goto cell_already_exists ;
2007-04-27 02:57:07 +04:00
}
2017-11-02 18:27:50 +03:00
cell = candidate ;
candidate = NULL ;
2019-07-23 13:24:59 +03:00
atomic_set ( & cell - > active , 2 ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , refcount_read ( & cell - > ref ) , 2 , afs_cell_trace_insert ) ;
2017-11-02 18:27:50 +03:00
rb_link_node_rcu ( & cell - > net_node , parent , pp ) ;
rb_insert_color ( & cell - > net_node , & net - > cells ) ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
up_write ( & net - > cells_lock ) ;
2005-04-17 02:20:36 +04:00
2020-10-13 22:51:59 +03:00
afs_queue_cell ( cell , afs_cell_trace_get_queue_new ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
wait_for_cell :
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , refcount_read ( & cell - > ref ) , atomic_read ( & cell - > active ) ,
2020-10-13 22:51:59 +03:00
afs_cell_trace_wait ) ;
2017-11-02 18:27:50 +03:00
_debug ( " wait_for_cell " ) ;
2019-05-07 17:06:36 +03:00
wait_var_event ( & cell - > state ,
( {
state = smp_load_acquire ( & cell - > state ) ; /* vs error */
2020-10-16 15:21:14 +03:00
state = = AFS_CELL_ACTIVE | | state = = AFS_CELL_REMOVED ;
2019-05-07 17:06:36 +03:00
} ) ) ;
/* Check the state obtained from the wait check. */
2020-10-16 15:21:14 +03:00
if ( state = = AFS_CELL_REMOVED ) {
2017-11-02 18:27:50 +03:00
ret = cell - > error ;
goto error ;
}
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
_leave ( " = %p [cell] " , cell ) ;
2007-04-27 02:55:03 +04:00
return cell ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
cell_already_exists :
_debug ( " cell exists " ) ;
cell = cursor ;
if ( excl ) {
ret = - EEXIST ;
} else {
2020-10-13 22:51:59 +03:00
afs_use_cell ( cursor , afs_cell_trace_use_lookup ) ;
2017-11-02 18:27:50 +03:00
ret = 0 ;
}
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
up_write ( & net - > cells_lock ) ;
2019-07-23 13:24:59 +03:00
if ( candidate )
2020-10-13 22:51:59 +03:00
afs_put_cell ( candidate , afs_cell_trace_put_candidate ) ;
2017-11-02 18:27:50 +03:00
if ( ret = = 0 )
goto wait_for_cell ;
2017-11-02 18:27:50 +03:00
goto error_noput ;
2007-04-27 02:49:28 +04:00
error :
2020-10-13 22:51:59 +03:00
afs_unuse_cell ( net , cell , afs_cell_trace_unuse_lookup ) ;
2017-11-02 18:27:50 +03:00
error_noput :
2017-11-02 18:27:50 +03:00
_leave ( " = %d [error] " , ret ) ;
2007-04-27 02:55:03 +04:00
return ERR_PTR ( ret ) ;
2007-04-27 02:49:28 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2007-04-27 02:55:03 +04:00
* set the root cell information
* - can be called with a module parameter string
* - can be called from a write to / proc / fs / afs / rootcell
2005-04-17 02:20:36 +04:00
*/
2017-11-02 18:27:50 +03:00
int afs_cell_init ( struct afs_net * net , const char * rootcell )
2005-04-17 02:20:36 +04:00
{
struct afs_cell * old_root , * new_root ;
2017-11-02 18:27:50 +03:00
const char * cp , * vllist ;
size_t len ;
2005-04-17 02:20:36 +04:00
_enter ( " " ) ;
if ( ! rootcell ) {
/* module is loaded with no parameters, or built statically.
* - in the future we might initialize cell DB here .
*/
2007-04-27 02:55:03 +04:00
_leave ( " = 0 [no root] " ) ;
2005-04-17 02:20:36 +04:00
return 0 ;
}
cp = strchr ( rootcell , ' : ' ) ;
2017-11-02 18:27:50 +03:00
if ( ! cp ) {
2010-08-04 18:16:38 +04:00
_debug ( " kAFS: no VL server IP addresses specified " ) ;
2017-11-02 18:27:50 +03:00
vllist = NULL ;
len = strlen ( rootcell ) ;
} else {
vllist = cp + 1 ;
len = cp - rootcell ;
}
2005-04-17 02:20:36 +04:00
/* allocate a cell record for the root cell */
2017-11-02 18:27:50 +03:00
new_root = afs_lookup_cell ( net , rootcell , len , vllist , false ) ;
2007-04-27 02:55:03 +04:00
if ( IS_ERR ( new_root ) ) {
_leave ( " = %ld " , PTR_ERR ( new_root ) ) ;
return PTR_ERR ( new_root ) ;
2005-04-17 02:20:36 +04:00
}
2018-04-09 23:12:31 +03:00
if ( ! test_and_set_bit ( AFS_CELL_FL_NO_GC , & new_root - > flags ) )
2020-10-13 22:51:59 +03:00
afs_use_cell ( new_root , afs_cell_trace_use_pin ) ;
2017-11-02 18:27:50 +03:00
2007-04-27 02:55:03 +04:00
/* install the new cell */
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
down_write ( & net - > cells_lock ) ;
2020-10-13 22:51:59 +03:00
afs_see_cell ( new_root , afs_cell_trace_see_ws ) ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
old_root = net - > ws_cell ;
net - > ws_cell = new_root ;
up_write ( & net - > cells_lock ) ;
2005-04-17 02:20:36 +04:00
2020-10-13 22:51:59 +03:00
afs_unuse_cell ( net , old_root , afs_cell_trace_unuse_ws ) ;
2007-04-27 02:55:03 +04:00
_leave ( " = 0 " ) ;
return 0 ;
2007-04-27 02:49:28 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2017-11-02 18:27:50 +03:00
* Update a cell ' s VL server address list from the DNS .
2005-04-17 02:20:36 +04:00
*/
2019-05-07 17:06:36 +03:00
static int afs_update_cell ( struct afs_cell * cell )
2005-04-17 02:20:36 +04:00
{
2019-05-07 17:06:36 +03:00
struct afs_vlserver_list * vllist , * old = NULL , * p ;
2018-10-20 02:57:57 +03:00
unsigned int min_ttl = READ_ONCE ( afs_cell_min_ttl ) ;
unsigned int max_ttl = READ_ONCE ( afs_cell_max_ttl ) ;
time64_t now , expiry = 0 ;
2019-05-07 17:06:36 +03:00
int ret = 0 ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
_enter ( " %s " , cell - > name ) ;
2018-10-20 02:57:57 +03:00
vllist = afs_dns_query ( cell , & expiry ) ;
2019-05-07 17:06:36 +03:00
if ( IS_ERR ( vllist ) ) {
ret = PTR_ERR ( vllist ) ;
_debug ( " %s: fail %d " , cell - > name , ret ) ;
if ( ret = = - ENOMEM )
goto out_wake ;
vllist = afs_alloc_vlserver_list ( 0 ) ;
2023-12-21 18:09:31 +03:00
if ( ! vllist ) {
if ( ret > = 0 )
ret = - ENOMEM ;
2019-05-07 17:06:36 +03:00
goto out_wake ;
2023-12-21 18:09:31 +03:00
}
2019-05-07 17:06:36 +03:00
switch ( ret ) {
case - ENODATA :
case - EDESTADDRREQ :
vllist - > status = DNS_LOOKUP_GOT_NOT_FOUND ;
break ;
case - EAGAIN :
case - ECONNREFUSED :
vllist - > status = DNS_LOOKUP_GOT_TEMP_FAILURE ;
break ;
default :
vllist - > status = DNS_LOOKUP_GOT_LOCAL_FAILURE ;
break ;
}
}
_debug ( " %s: got list %d %d " , cell - > name , vllist - > source , vllist - > status ) ;
cell - > dns_status = vllist - > status ;
2018-10-20 02:57:57 +03:00
now = ktime_get_real_seconds ( ) ;
if ( min_ttl > max_ttl )
max_ttl = min_ttl ;
if ( expiry < now + min_ttl )
expiry = now + min_ttl ;
else if ( expiry > now + max_ttl )
expiry = now + max_ttl ;
2019-05-07 17:06:36 +03:00
_debug ( " %s: status %d " , cell - > name , vllist - > status ) ;
if ( vllist - > source = = DNS_RECORD_UNAVAILABLE ) {
switch ( vllist - > status ) {
case DNS_LOOKUP_GOT_NOT_FOUND :
2018-10-20 02:57:57 +03:00
/* The DNS said that the cell does not exist or there
* weren ' t any addresses to be had .
*/
cell - > dns_expiry = expiry ;
2017-11-02 18:27:50 +03:00
break ;
2017-11-02 18:27:50 +03:00
2019-05-07 17:06:36 +03:00
case DNS_LOOKUP_BAD :
case DNS_LOOKUP_GOT_LOCAL_FAILURE :
case DNS_LOOKUP_GOT_TEMP_FAILURE :
case DNS_LOOKUP_GOT_NS_FAILURE :
2017-11-02 18:27:50 +03:00
default :
2018-10-20 02:57:57 +03:00
cell - > dns_expiry = now + 10 ;
2017-11-02 18:27:50 +03:00
break ;
}
} else {
cell - > dns_expiry = expiry ;
}
2010-08-11 12:38:04 +04:00
2019-05-07 17:06:36 +03:00
/* Replace the VL server list if the new record has servers or the old
* record doesn ' t .
*/
write_lock ( & cell - > vl_servers_lock ) ;
p = rcu_dereference_protected ( cell - > vl_servers , true ) ;
if ( vllist - > nr_servers > 0 | | p - > nr_servers = = 0 ) {
rcu_assign_pointer ( cell - > vl_servers , vllist ) ;
cell - > dns_source = vllist - > source ;
old = p ;
}
write_unlock ( & cell - > vl_servers_lock ) ;
afs_put_vlserverlist ( cell - > net , old ) ;
2010-08-11 12:38:04 +04:00
2019-05-07 17:06:36 +03:00
out_wake :
smp_store_release ( & cell - > dns_lookup_count ,
cell - > dns_lookup_count + 1 ) ; /* vs source/status */
wake_up_var ( & cell - > dns_lookup_count ) ;
_leave ( " = %d " , ret ) ;
return ret ;
2007-04-27 02:49:28 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2017-11-02 18:27:50 +03:00
* Destroy a cell record
2005-04-17 02:20:36 +04:00
*/
2017-11-02 18:27:50 +03:00
static void afs_cell_destroy ( struct rcu_head * rcu )
2005-04-17 02:20:36 +04:00
{
2017-11-02 18:27:50 +03:00
struct afs_cell * cell = container_of ( rcu , struct afs_cell , rcu ) ;
2019-07-23 13:24:59 +03:00
struct afs_net * net = cell - > net ;
2022-07-06 12:52:14 +03:00
int r ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
_enter ( " %p{%s} " , cell , cell - > name ) ;
2005-04-17 02:20:36 +04:00
2022-07-06 12:52:14 +03:00
r = refcount_read ( & cell - > ref ) ;
ASSERTCMP ( r , = = , 0 ) ;
trace_afs_cell ( cell - > debug_id , r , atomic_read ( & cell - > active ) , afs_cell_trace_free ) ;
2017-11-02 18:27:50 +03:00
2019-07-23 13:24:59 +03:00
afs_put_vlserverlist ( net , rcu_access_pointer ( cell - > vl_servers ) ) ;
2020-10-13 22:51:59 +03:00
afs_unuse_cell ( net , cell - > alias_of , afs_cell_trace_unuse_alias ) ;
2017-11-02 18:27:50 +03:00
key_put ( cell - > anonymous_key ) ;
2020-06-24 19:00:24 +03:00
kfree ( cell - > name ) ;
2017-11-02 18:27:50 +03:00
kfree ( cell ) ;
2019-07-23 13:24:59 +03:00
afs_dec_cells_outstanding ( net ) ;
2017-11-02 18:27:50 +03:00
_leave ( " [destroyed] " ) ;
2007-04-27 02:49:28 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2017-11-02 18:27:50 +03:00
* Queue the cell manager .
2005-04-17 02:20:36 +04:00
*/
2017-11-02 18:27:50 +03:00
static void afs_queue_cell_manager ( struct afs_net * net )
2005-04-17 02:20:36 +04:00
{
2017-11-02 18:27:50 +03:00
int outstanding = atomic_inc_return ( & net - > cells_outstanding ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
_enter ( " %d " , outstanding ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
if ( ! queue_work ( afs_wq , & net - > cells_manager ) )
afs_dec_cells_outstanding ( net ) ;
}
/*
* Cell management timer . We have an increment on cells_outstanding that we
* need to pass along to the work item .
*/
void afs_cells_timer ( struct timer_list * timer )
{
struct afs_net * net = container_of ( timer , struct afs_net , cells_timer ) ;
_enter ( " " ) ;
if ( ! queue_work ( afs_wq , & net - > cells_manager ) )
afs_dec_cells_outstanding ( net ) ;
}
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
/*
* Get a reference on a cell record .
*/
2020-10-13 22:51:59 +03:00
struct afs_cell * afs_get_cell ( struct afs_cell * cell , enum afs_cell_trace reason )
2017-11-02 18:27:50 +03:00
{
2022-07-06 12:52:14 +03:00
int r ;
2020-10-13 22:51:59 +03:00
2022-07-06 12:52:14 +03:00
__refcount_inc ( & cell - > ref , & r ) ;
trace_afs_cell ( cell - > debug_id , r + 1 , atomic_read ( & cell - > active ) , reason ) ;
2017-11-02 18:27:50 +03:00
return cell ;
}
2017-11-02 18:27:50 +03:00
/*
* Drop a reference on a cell record .
*/
2020-10-13 22:51:59 +03:00
void afs_put_cell ( struct afs_cell * cell , enum afs_cell_trace reason )
2019-07-23 13:24:59 +03:00
{
if ( cell ) {
2020-10-13 22:51:59 +03:00
unsigned int debug_id = cell - > debug_id ;
2022-07-06 12:52:14 +03:00
unsigned int a ;
bool zero ;
int r ;
2019-07-23 13:24:59 +03:00
2020-10-13 22:51:59 +03:00
a = atomic_read ( & cell - > active ) ;
2022-07-06 12:52:14 +03:00
zero = __refcount_dec_and_test ( & cell - > ref , & r ) ;
trace_afs_cell ( debug_id , r - 1 , a , reason ) ;
if ( zero ) {
2019-07-23 13:24:59 +03:00
a = atomic_read ( & cell - > active ) ;
WARN ( a ! = 0 , " Cell active count %u > 0 \n " , a ) ;
call_rcu ( & cell - > rcu , afs_cell_destroy ) ;
}
}
}
/*
* Note a cell becoming more active .
*/
2020-10-13 22:51:59 +03:00
struct afs_cell * afs_use_cell ( struct afs_cell * cell , enum afs_cell_trace reason )
2019-07-23 13:24:59 +03:00
{
2022-07-06 12:52:14 +03:00
int r , a ;
2019-07-23 13:24:59 +03:00
2022-07-06 12:52:14 +03:00
r = refcount_read ( & cell - > ref ) ;
WARN_ON ( r = = 0 ) ;
2020-10-13 22:51:59 +03:00
a = atomic_inc_return ( & cell - > active ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , r , a , reason ) ;
2019-07-23 13:24:59 +03:00
return cell ;
}
/*
* Record a cell becoming less active . When the active counter reaches 1 , it
* is scheduled for destruction , but may get reactivated .
*/
2020-10-13 22:51:59 +03:00
void afs_unuse_cell ( struct afs_net * net , struct afs_cell * cell , enum afs_cell_trace reason )
2017-11-02 18:27:50 +03:00
{
2020-10-27 13:42:56 +03:00
unsigned int debug_id ;
2017-11-02 18:27:50 +03:00
time64_t now , expire_delay ;
2022-07-06 12:52:14 +03:00
int r , a ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
if ( ! cell )
2005-04-17 02:20:36 +04:00
return ;
2017-11-02 18:27:50 +03:00
_enter ( " %s " , cell - > name ) ;
2007-04-27 02:55:03 +04:00
2017-11-02 18:27:50 +03:00
now = ktime_get_real_seconds ( ) ;
cell - > last_inactive = now ;
expire_delay = 0 ;
2019-05-07 17:06:36 +03:00
if ( cell - > vl_servers - > nr_servers )
2017-11-02 18:27:50 +03:00
expire_delay = afs_cell_gc_delay ;
2005-04-17 02:20:36 +04:00
2020-10-27 13:42:56 +03:00
debug_id = cell - > debug_id ;
2022-07-06 12:52:14 +03:00
r = refcount_read ( & cell - > ref ) ;
2019-07-23 13:24:59 +03:00
a = atomic_dec_return ( & cell - > active ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( debug_id , r , a , reason ) ;
2019-07-23 13:24:59 +03:00
WARN_ON ( a = = 0 ) ;
if ( a = = 1 )
/* 'cell' may now be garbage collected. */
afs_set_cell_timer ( net , expire_delay ) ;
}
2005-04-17 02:20:36 +04:00
2020-10-13 22:51:59 +03:00
/*
* Note that a cell has been seen .
*/
void afs_see_cell ( struct afs_cell * cell , enum afs_cell_trace reason )
{
2022-07-06 12:52:14 +03:00
int r , a ;
2020-10-13 22:51:59 +03:00
2022-07-06 12:52:14 +03:00
r = refcount_read ( & cell - > ref ) ;
2020-10-13 22:51:59 +03:00
a = atomic_read ( & cell - > active ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , r , a , reason ) ;
2020-10-13 22:51:59 +03:00
}
2019-07-23 13:24:59 +03:00
/*
* Queue a cell for management , giving the workqueue a ref to hold .
*/
2020-10-13 22:51:59 +03:00
void afs_queue_cell ( struct afs_cell * cell , enum afs_cell_trace reason )
2019-07-23 13:24:59 +03:00
{
2020-10-13 22:51:59 +03:00
afs_get_cell ( cell , reason ) ;
2019-07-23 13:24:59 +03:00
if ( ! queue_work ( afs_wq , & cell - > manager ) )
2020-10-13 22:51:59 +03:00
afs_put_cell ( cell , afs_cell_trace_put_queue_fail ) ;
2007-04-27 02:49:28 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2017-11-02 18:27:50 +03:00
* Allocate a key to use as a placeholder for anonymous user security .
2005-04-17 02:20:36 +04:00
*/
2017-11-02 18:27:50 +03:00
static int afs_alloc_anon_key ( struct afs_cell * cell )
2005-04-17 02:20:36 +04:00
{
2017-11-02 18:27:50 +03:00
struct key * key ;
char keyname [ 4 + AFS_MAXCELLNAME + 1 ] , * cp , * dp ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
/* Create a key to represent an anonymous user. */
memcpy ( keyname , " afs@ " , 4 ) ;
dp = keyname + 4 ;
cp = cell - > name ;
do {
* dp + + = tolower ( * cp ) ;
} while ( * cp + + ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
key = rxrpc_get_null_key ( keyname ) ;
if ( IS_ERR ( key ) )
return PTR_ERR ( key ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
cell - > anonymous_key = key ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
_debug ( " anon key %p{%x} " ,
cell - > anonymous_key , key_serial ( cell - > anonymous_key ) ) ;
return 0 ;
}
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
/*
* Activate a cell .
*/
static int afs_activate_cell ( struct afs_net * net , struct afs_cell * cell )
{
2018-10-12 00:45:49 +03:00
struct hlist_node * * p ;
struct afs_cell * pcell ;
2017-11-02 18:27:50 +03:00
int ret ;
if ( ! cell - > anonymous_key ) {
ret = afs_alloc_anon_key ( cell ) ;
if ( ret < 0 )
return ret ;
2007-04-27 02:55:03 +04:00
}
2018-05-18 13:46:15 +03:00
ret = afs_proc_cell_setup ( cell ) ;
2017-11-02 18:27:50 +03:00
if ( ret < 0 )
return ret ;
2018-06-15 17:19:22 +03:00
mutex_lock ( & net - > proc_cells_lock ) ;
2018-10-12 00:45:49 +03:00
for ( p = & net - > proc_cells . first ; * p ; p = & ( * p ) - > next ) {
pcell = hlist_entry ( * p , struct afs_cell , proc_link ) ;
if ( strcmp ( cell - > name , pcell - > name ) < 0 )
break ;
}
cell - > proc_link . pprev = p ;
cell - > proc_link . next = * p ;
rcu_assign_pointer ( * p , & cell - > proc_link . next ) ;
if ( cell - > proc_link . next )
cell - > proc_link . next - > pprev = & cell - > proc_link . next ;
2018-06-15 17:19:22 +03:00
afs_dynroot_mkdir ( net , cell ) ;
mutex_unlock ( & net - > proc_cells_lock ) ;
2017-11-02 18:27:50 +03:00
return 0 ;
}
/*
* Deactivate a cell .
*/
static void afs_deactivate_cell ( struct afs_net * net , struct afs_cell * cell )
{
_enter ( " %s " , cell - > name ) ;
2005-04-17 02:20:36 +04:00
2018-05-18 13:46:15 +03:00
afs_proc_cell_remove ( cell ) ;
2005-04-17 02:20:36 +04:00
2018-06-15 17:19:22 +03:00
mutex_lock ( & net - > proc_cells_lock ) ;
2018-10-12 00:45:49 +03:00
hlist_del_rcu ( & cell - > proc_link ) ;
2018-06-15 17:19:22 +03:00
afs_dynroot_rmdir ( net , cell ) ;
mutex_unlock ( & net - > proc_cells_lock ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
_leave ( " " ) ;
2007-04-27 02:49:28 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2017-11-02 18:27:50 +03:00
* Manage a cell record , initialising and destroying it , maintaining its DNS
* records .
2005-04-17 02:20:36 +04:00
*/
2019-07-23 13:24:59 +03:00
static void afs_manage_cell ( struct afs_cell * cell )
2005-04-17 02:20:36 +04:00
{
2017-11-02 18:27:50 +03:00
struct afs_net * net = cell - > net ;
2019-07-23 13:24:59 +03:00
int ret , active ;
2017-11-02 18:27:50 +03:00
_enter ( " %s " , cell - > name ) ;
again :
_debug ( " state %u " , cell - > state ) ;
switch ( cell - > state ) {
case AFS_CELL_INACTIVE :
case AFS_CELL_FAILED :
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
down_write ( & net - > cells_lock ) ;
2019-07-23 13:24:59 +03:00
active = 1 ;
2020-10-16 15:21:14 +03:00
if ( atomic_try_cmpxchg_relaxed ( & cell - > active , & active , 0 ) ) {
2017-11-02 18:27:50 +03:00
rb_erase ( & cell - > net_node , & net - > cells ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , refcount_read ( & cell - > ref ) , 0 ,
2020-10-13 22:51:59 +03:00
afs_cell_trace_unuse_delete ) ;
2020-10-16 15:21:14 +03:00
smp_store_release ( & cell - > state , AFS_CELL_REMOVED ) ;
2019-07-23 13:24:59 +03:00
}
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
up_write ( & net - > cells_lock ) ;
2020-10-16 15:21:14 +03:00
if ( cell - > state = = AFS_CELL_REMOVED ) {
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto final_destruction ;
2020-10-16 15:21:14 +03:00
}
2017-11-02 18:27:50 +03:00
if ( cell - > state = = AFS_CELL_FAILED )
goto done ;
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_UNSET ) ;
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto again ;
case AFS_CELL_UNSET :
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_ACTIVATING ) ;
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto again ;
case AFS_CELL_ACTIVATING :
ret = afs_activate_cell ( net , cell ) ;
if ( ret < 0 )
goto activation_failed ;
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_ACTIVE ) ;
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto again ;
case AFS_CELL_ACTIVE :
2019-07-23 13:24:59 +03:00
if ( atomic_read ( & cell - > active ) > 1 ) {
2019-05-07 17:06:36 +03:00
if ( test_and_clear_bit ( AFS_CELL_FL_DO_LOOKUP , & cell - > flags ) ) {
ret = afs_update_cell ( cell ) ;
if ( ret < 0 )
cell - > error = ret ;
}
2017-11-02 18:27:50 +03:00
goto done ;
}
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_DEACTIVATING ) ;
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto again ;
case AFS_CELL_DEACTIVATING :
2019-07-23 13:24:59 +03:00
if ( atomic_read ( & cell - > active ) > 1 )
2017-11-02 18:27:50 +03:00
goto reverse_deactivation ;
afs_deactivate_cell ( net , cell ) ;
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_INACTIVE ) ;
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto again ;
2020-10-16 15:21:14 +03:00
case AFS_CELL_REMOVED :
goto done ;
2017-11-02 18:27:50 +03:00
default :
break ;
}
_debug ( " bad state %u " , cell - > state ) ;
BUG ( ) ; /* Unhandled state */
activation_failed :
cell - > error = ret ;
afs_deactivate_cell ( net , cell ) ;
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_FAILED ) ; /* vs error */
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
goto again ;
reverse_deactivation :
2019-05-07 17:06:36 +03:00
smp_store_release ( & cell - > state , AFS_CELL_ACTIVE ) ;
wake_up_var ( & cell - > state ) ;
2017-11-02 18:27:50 +03:00
_leave ( " [deact->act] " ) ;
return ;
done :
_leave ( " [done %u] " , cell - > state ) ;
return ;
final_destruction :
2019-07-23 13:24:59 +03:00
/* The root volume is pinning the cell */
2023-11-08 16:01:11 +03:00
afs_put_volume ( cell - > root_volume , afs_volume_trace_put_cell_root ) ;
2019-07-23 13:24:59 +03:00
cell - > root_volume = NULL ;
2020-10-13 22:51:59 +03:00
afs_put_cell ( cell , afs_cell_trace_put_destroy ) ;
2019-07-23 13:24:59 +03:00
}
static void afs_manage_cell_work ( struct work_struct * work )
{
struct afs_cell * cell = container_of ( work , struct afs_cell , manager ) ;
afs_manage_cell ( cell ) ;
2020-10-13 22:51:59 +03:00
afs_put_cell ( cell , afs_cell_trace_put_queue_work ) ;
2017-11-02 18:27:50 +03:00
}
/*
* Manage the records of cells known to a network namespace . This includes
* updating the DNS records and garbage collecting unused cells that were
* automatically added .
*
* Note that constructed cell records may only be removed from net - > cells by
* this work item , so it is safe for this work item to stash a cursor pointing
* into the tree and then return to caller ( provided it skips cells that are
* still under construction ) .
*
* Note also that we were given an increment on net - > cells_outstanding by
* whoever queued us that we need to deal with before returning .
*/
void afs_manage_cells ( struct work_struct * work )
{
struct afs_net * net = container_of ( work , struct afs_net , cells_manager ) ;
struct rb_node * cursor ;
time64_t now = ktime_get_real_seconds ( ) , next_manage = TIME64_MAX ;
bool purging = ! net - > live ;
2005-04-17 02:20:36 +04:00
_enter ( " " ) ;
2017-11-02 18:27:50 +03:00
/* Trawl the cell database looking for cells that have expired from
* lack of use and cells whose DNS results have expired and dispatch
* their managers .
*/
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
down_read ( & net - > cells_lock ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
for ( cursor = rb_first ( & net - > cells ) ; cursor ; cursor = rb_next ( cursor ) ) {
struct afs_cell * cell =
rb_entry ( cursor , struct afs_cell , net_node ) ;
2019-07-23 13:24:59 +03:00
unsigned active ;
2017-11-02 18:27:50 +03:00
bool sched_cell = false ;
2007-04-27 02:55:03 +04:00
2019-07-23 13:24:59 +03:00
active = atomic_read ( & cell - > active ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , refcount_read ( & cell - > ref ) ,
2020-10-13 22:51:59 +03:00
active , afs_cell_trace_manage ) ;
2017-11-02 18:27:50 +03:00
2019-07-23 13:24:59 +03:00
ASSERTCMP ( active , > = , 1 ) ;
2017-11-02 18:27:50 +03:00
if ( purging ) {
2020-10-13 22:51:59 +03:00
if ( test_and_clear_bit ( AFS_CELL_FL_NO_GC , & cell - > flags ) ) {
active = atomic_dec_return ( & cell - > active ) ;
2022-07-06 12:52:14 +03:00
trace_afs_cell ( cell - > debug_id , refcount_read ( & cell - > ref ) ,
2020-10-13 22:51:59 +03:00
active , afs_cell_trace_unuse_pin ) ;
}
2017-11-02 18:27:50 +03:00
}
2005-04-17 02:20:36 +04:00
2019-07-23 13:24:59 +03:00
if ( active = = 1 ) {
2019-05-07 17:06:36 +03:00
struct afs_vlserver_list * vllist ;
2017-11-02 18:27:50 +03:00
time64_t expire_at = cell - > last_inactive ;
2005-04-17 02:20:36 +04:00
2019-05-07 17:06:36 +03:00
read_lock ( & cell - > vl_servers_lock ) ;
vllist = rcu_dereference_protected (
cell - > vl_servers ,
lockdep_is_held ( & cell - > vl_servers_lock ) ) ;
if ( vllist - > nr_servers > 0 )
2017-11-02 18:27:50 +03:00
expire_at + = afs_cell_gc_delay ;
2019-05-07 17:06:36 +03:00
read_unlock ( & cell - > vl_servers_lock ) ;
2017-11-02 18:27:50 +03:00
if ( purging | | expire_at < = now )
sched_cell = true ;
else if ( expire_at < next_manage )
next_manage = expire_at ;
2005-04-17 02:20:36 +04:00
}
2017-11-02 18:27:50 +03:00
if ( ! purging ) {
2019-05-07 17:06:36 +03:00
if ( test_bit ( AFS_CELL_FL_DO_LOOKUP , & cell - > flags ) )
2017-11-02 18:27:50 +03:00
sched_cell = true ;
}
if ( sched_cell )
2020-10-13 22:51:59 +03:00
afs_queue_cell ( cell , afs_cell_trace_get_queue_manage ) ;
2017-11-02 18:27:50 +03:00
}
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
up_read ( & net - > cells_lock ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
/* Update the timer on the way out. We have to pass an increment on
* cells_outstanding in the namespace that we are in to the timer or
* the work scheduler .
*/
if ( ! purging & & next_manage < TIME64_MAX ) {
now = ktime_get_real_seconds ( ) ;
2005-04-17 02:20:36 +04:00
2017-11-02 18:27:50 +03:00
if ( next_manage - now < = 0 ) {
if ( queue_work ( afs_wq , & net - > cells_manager ) )
atomic_inc ( & net - > cells_outstanding ) ;
} else {
afs_set_cell_timer ( net , next_manage - now ) ;
2005-04-17 02:20:36 +04:00
}
}
2017-11-02 18:27:50 +03:00
afs_dec_cells_outstanding ( net ) ;
_leave ( " [%d] " , atomic_read ( & net - > cells_outstanding ) ) ;
}
/*
* Purge in - memory cell database .
*/
void afs_cell_purge ( struct afs_net * net )
{
struct afs_cell * ws ;
_enter ( " " ) ;
afs: Fix rapid cell addition/removal by not using RCU on cells tree
There are a number of problems that are being seen by the rapidly mounting
and unmounting an afs dynamic root with an explicit cell and volume
specified (which should probably be rejected, but that's a separate issue):
What the tests are doing is to look up/create a cell record for the name
given and then tear it down again without actually using it to try to talk
to a server. This is repeated endlessly, very fast, and the new cell
collides with the old one if it's not quick enough to reuse it.
It appears (as suggested by Hillf Danton) that the search through the RB
tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and
that it's not blocking the write_seqlock(), despite taking two passes at
it. He suggested that the code should take a ref on the cell it's
attempting to look at - but this shouldn't be necessary until we've
compared the cell names. It's possible that I'm missing a barrier
somewhere.
However, using an RCU search for this is overkill, really - we only need to
access the cell name in a few places, and they're places where we're may
end up sleeping anyway.
Fix this by switching to an R/W semaphore instead.
Additionally, draw the down_read() call inside the function (renamed to
afs_find_cell()) since all the callers were taking the RCU read lock (or
should've been[*]).
[*] afs_probe_cell_name() should have been, but that doesn't appear to be
involved in the bug reports.
The symptoms of this look like:
general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf]
...
RIP: 0010:strncasecmp lib/string.c:52 [inline]
RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43
afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88
afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249
afs_parse_source fs/afs/super.c:290 [inline]
...
Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
cc: syzkaller-bugs@googlegroups.com
2020-10-09 16:11:58 +03:00
down_write ( & net - > cells_lock ) ;
ws = net - > ws_cell ;
net - > ws_cell = NULL ;
up_write ( & net - > cells_lock ) ;
2020-10-13 22:51:59 +03:00
afs_unuse_cell ( net , ws , afs_cell_trace_unuse_ws ) ;
2017-11-02 18:27:50 +03:00
_debug ( " del timer " ) ;
if ( del_timer_sync ( & net - > cells_timer ) )
atomic_dec ( & net - > cells_outstanding ) ;
_debug ( " kick mgr " ) ;
afs_queue_cell_manager ( net ) ;
_debug ( " wait " ) ;
2018-03-15 13:42:28 +03:00
wait_var_event ( & net - > cells_outstanding ,
! atomic_read ( & net - > cells_outstanding ) ) ;
2005-04-17 02:20:36 +04:00
_leave ( " " ) ;
2007-04-27 02:49:28 +04:00
}