On 21/10/19(Mon) 13:28, Alexandr Nedvedicky wrote: > Hello, > > </snip> > > > > > The vnode is not locked in this path > > > either so it won't end up waiting on the ongoing vclean(). > > > > That leads to an interesting question: should we serialize device access > > at the vnode level or should we generalize the existing "solution" and > > assume that the descriptor can be NULL/invalid at the "pseudo-driver" > > level? > > > my preference is to fix it at pseudo-driver level. Dealing with it at > driver > level keeps scope of locks small. I'm just afraid the `big lock` on vnode > may > bite us later.
Well the vnode lock is already taken for read/write/close. That's why the race is visible here with ioctl, which doesn't grab the lock. It might be also possible to trigger a race with open. That said I'm fine with fixing this issue at the driver level. Does that mean all bpfilter_lookup() should be audited since they can return NULL? At least ioctl/poll/kqfilter aren't serialized with close. Or am I missing something?
