David Howells f89ea63f1c
netfs, 9p: Fix race between umount and async request completion
There's a problem in 9p's interaction with netfslib whereby a crash occurs
because the 9p_fid structs get forcibly destroyed during client teardown
(without paying attention to their refcounts) before netfslib has finished
with them.  However, it's not a simple case of deferring the clunking that
p9_fid_put() does as that requires the p9_client record to still be
present.

The problem is that netfslib has to unlock pages and clear the IN_PROGRESS
flag before destroying the objects involved - including the fid - and, in
any case, nothing checks to see if writeback completed barring looking at
the page flags.

Fix this by keeping a count of outstanding I/O requests (of any type) and
waiting for it to quiesce during inode eviction.

Reported-by: syzbot+df038d463cca332e8414@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000005be0aa061846f8d6@google.com/
Reported-by: syzbot+d7c7a495a5e466c031b6@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/000000000000b86c5e06130da9c6@google.com/
Reported-by: syzbot+1527696d41a634cc1819@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/000000000000041f960618206d7e@google.com/
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/755891.1716560771@warthog.procyon.org.uk
Tested-by: syzbot+d7c7a495a5e466c031b6@syzkaller.appspotmail.com
Reviewed-by: Dominique Martinet <asmadeus@codewreck.org>
cc: Eric Van Hensbergen <ericvh@kernel.org>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: Christian Schoenebeck <linux_oss@crudebyte.com>
cc: Jeff Layton <jlayton@kernel.org>
cc: Steve French <sfrench@samba.org>
cc: Hillf Danton <hdanton@sina.com>
cc: v9fs@lists.linux.dev
cc: linux-afs@lists.infradead.org
cc: linux-cifs@vger.kernel.org
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Reported-and-tested-by: syzbot+d7c7a495a5e466c031b6@syzkaller.appspotmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-05-27 13:12:13 +02:00
..
2024-01-11 20:11:35 -08:00
2024-05-19 13:45:48 -07:00
2024-05-14 19:42:24 -07:00
2024-03-27 13:17:15 +01:00
2024-05-13 14:14:05 -07:00
2024-05-20 13:23:43 -07:00
2024-05-14 17:35:22 -07:00
2023-12-29 11:58:34 -08:00
2024-03-27 13:17:15 +01:00
\n
2024-05-20 12:31:43 -07:00
2024-05-15 08:43:02 -07:00
\n
2024-05-20 12:49:25 -07:00
2024-03-27 13:17:15 +01:00
2024-05-17 18:34:27 -07:00
2024-04-23 15:37:02 +02:00
2024-05-20 12:55:12 -07:00
2024-05-13 11:40:06 -07:00
2024-03-12 20:03:34 -07:00
2023-10-30 19:28:19 -10:00
2024-04-25 20:56:20 -07:00
2024-05-10 08:26:31 +02:00
2024-03-12 20:03:34 -07:00
2023-12-12 14:24:14 +01:00
2024-03-15 09:00:09 -07:00
2024-03-13 12:53:53 -07:00
2024-04-17 13:49:44 +02:00
2024-03-11 10:21:06 -07:00
2024-05-13 11:40:06 -07:00
2024-03-13 12:53:53 -07:00
2024-03-12 20:03:34 -07:00
2024-03-13 12:53:53 -07:00
2024-02-02 13:11:49 +01:00
2024-03-12 20:03:34 -07:00
2024-05-20 12:55:12 -07:00
2024-05-02 16:28:20 +02:00
2024-05-24 13:34:07 +02:00
2024-03-26 09:01:18 +01:00
\n
2024-05-20 12:31:43 -07:00
2024-04-10 16:23:02 -06:00
2024-02-15 23:43:47 -05:00