mnt: Identify an RPC reader by kthread, not proc
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 25 Jul 2018 18:52:51 +0000 (14:52 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 30 Jul 2018 20:05:46 +0000 (16:05 -0400)
commitf86fa40b9c2e7905d475c5e7f7be79bfc8574482
tree1db276678bde99ac6de6a69f5f8b40a43e46d352
parent4f9e32a49465a3c0f424049c5529e1c625d1a93c
mnt: Identify an RPC reader by kthread, not proc

This fixes the dreaded mnt mismatch, e.g.:

mnt: proc current->text 18446744072670166253: mismatch from /net/tcp/1/data
? rep 0x0xffff800009cee020 tag 4 fid 1625 T120 R117 rp 5

The old code assumed the struct proc pointer uniquely identified a kernel
thread that was trying to get a response from a mnt chan.  That was never
the case, since you could have the same proc issue multiple syscalls
concurrently.

We had this bug since the beginning, but it was hard to trigger.  Now that
we have RCU CBs to close chans, which kick off an RKM, the kthread that
actually closes the chan is much more likely to not be for the original
process.  In that case, we're able to get the RPC response from some other
kthread, resulting in the mismatch.

Using the struct kthread to identify the kthread that is waiting on an RPC
is much saner.

I left in using current->user.name for the auth/attach name.  In those
cases, we should be in a syscall (which I check for).  Similarly, when
aborting, we just need to bail out if we are handling a process's syscall -
not if we're some arbitrary kthread.  I think.  There might be issues with
that.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/drivers/dev/mnt.c
kern/include/ns.h