On Mon, Jan 30, 2023 at 08:34:29PM +0300, Vitaliy Makkoveev wrote: > > On 30 Jan 2023, at 06:39, Visa Hankala <[email protected]> wrote: > > > > Replace selwakeup() with KNOTE() in tun(4) and tap(4). > > > > This patch makes the tun(4) and tap(4) event filters MP-safe. > > > > This is similar to the change that just got committed to pppac(4) > > and pppx(4). However, tun(4) and tap(4) can be destroyed abruptly, > > so klist_invalidate() has to be kept in tun_clone_destroy(). > > > > The selwakeup() call in tun_dev_close() can be removed. If the device > > is closed peacefully, the klists get cleared automatically and waiters > > notified before the close routine is invoked. On abrupt detach, > > klist_invalidate() in tun_clone_destroy() should clear any lingering > > knotes. > > > > OK? > > > > Does it make sense to introduce something like KNOTE_UNLOCKED() > to push lock acquisition within?
I have not been keen to add a new variant of KNOTE() because the common pattern is, or at least has been, that the klist lock is already held when KNOTE() is called. The idea is that the klist is protected by the lock that also covers the related object, if possible. Examples of this are audio_lock, pipe_lock, and solock. klist_insert() and klist_remove() did not touch locks initially. The locking was added when it turned out that there would be repetition in very many places otherwise. If a new flavor of KNOTE() is really wanted, I would rather cook up a patch that renames KNOTE() to KNOTE_LOCKED() and adds KNOTE() that acquires the klist lock internally. This way the naming would remain consistent with the rest of the klist functions.
