Re: kern/57552: fileassoc(9) causes rm to take kernel lock even when never used

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/57552; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57552: fileassoc(9) causes rm to take kernel lock even when
 never used
Date: Mon, 31 Jul 2023 00:55:55 +0000

 On Sun, Jul 30, 2023 at 03:40:00PM +0000, campbell+netbsd%mumble.net@localhost wrote:
  > If veriexec is compiled into the kernel, then fileassoc_domain is
  > initialized via main -> veriexec_init -> fileassoc_register ->
  > RUN_ONCE(..., fileassoc_init) -> fileassoc_init.
 
 None of the rest of fileassoc uses the kernel lock so there's maybe no
 reason to bother with this part either? :-)
 
 It should be sufficient to set a global "I've been used" flag in
 fileassoc_add() and test it in fileassoc_file_delete().
 
 The whole thing should be ripped out though. In addition to there being no
 locking, the call of fileassoc_file_delete is a stray piece of
 veriexec_removechk that escaped somehow.
 
  > (It's also not clear vp->v_mount is safe inside fileassoc_file_lookup.)
 
 That one I don't follow. The mount shouldn't be able to go away while
 the caller is holding a vnode.
 
  > Maybe just use a global thmap (lazily initialized) for these
  > associations instead of fussing around with specificdata keys and
  > wotsits.  Won't fix any fundamental locking problems of the API but
  > it might help avoid touching the kernel lock.
 
 From what I can tell, fileassoc is a halfassed and broken specificdata
 interface for vnodes. Given that there's a native specificdata
 interface for mounts in the vfs code, if we want to be able to do what
 veriexec does with it we should probably create a native specificdata
 interface for vnodes. There are reasons this is not completely
 straightforward (especially if, unlike fileassoc, it's expected to
 work) but there shouldn't be any fundamental barriers...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost