On Tue, Jan 31, 2023 at 06:21:01PM +0000, Visa Hankala wrote: > 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. >
We have the new case, where we have no related objects like in pppx/pppac and tun/tap: mtx_enter(&sc->sc_mtx); KNOTE(&sc->sc_rklist, 0); mtx_leave(&sc->sc_mtx); So I propose to move lock acquisition within KNOTE(9). This looks reasonable, if such cases appeared many times.
