Subject: Re: kern/35351 (Re: CVS commit: src/sys/kern)
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 04/07/2007 16:35:02
The following reply was made to PR kern/35351; it has been noted by GNATS.

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: e@murder.org
Cc: tech-kern@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/35351 (Re: CVS commit: src/sys/kern)
Date: Sun,  8 Apr 2007 01:34:20 +0900 (JST)

 > YAMAMOTO Takashi wrote:
 > >> YAMAMOTO Takashi wrote:
 > >>
 > >>> an example which i told you some time ago:
 > >>> 1. thread A calls fileassoc_file_add and sleeps in malloc.
 > >>> 2. thread B calls fileassoc_file_add and successfully allocates and inserts
 > >>>    a new entry.
 > >>> 3. thread A wakes up and inserts a duplicated entry.
 > >> can this scenario happen in netbsd-4 as a result of veriexecctl?
 > >>
 > >> -e.
 > > 
 > > i don't know.
 > 
 > then what are we discussing, really? :)
 > 
 > -e.
 
 the lack of locking in fileassoc.  are you kidding?
 
 as you know, veriexec is not only user of fileassoc.
 do you mean you have investigated all of users and know fileassoc
 doesn't need to have locking on netbsd-4?  otherwise, why do you claim
 it isn't a problem?  to me, these users seem to work basically independently,
 so i think nothing serializes users and thus fileassoc itself needs to
 have locking internally.
 am i missing something obvious?  (i guess i am, given that you are
 an author of all of these fileassoc users.)
 
 YAMAMOTO Takashi