tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?



> Date: Fri, 10 Aug 2018 19:05:28 +0200
> From: Edgar Fuß <ef%math.uni-bonn.de@localhost>
> 
> > More likely is that the socket is prematurely freed before unp_gc 
> > grabs it at all.
> But then the mutex_oncpu() in the if above the do...while would panic, no?

Yes -- isn't that the symptom you're seeing, or did I miss something?

> > You could do something like create a global variable that stores the
> > socket pointer that unp_gc is currently working on, shortly before it
> > tries solock, and kassert that soclose isn't given that.
> I thought about something like that but thought that was too simplistic.
> How do I synchronize the variable value amongst threads?

It doesn't really matter since (a) only one thread ever sets the
variable, (b) there are no invariants around it, and (c) you never
dereference it.  So, as soon as unp_gc decides it will use a
particular socket, it should just store the pointer to that socket in
some global unp_gc_current_socket, and when it's done (before closef),
it should set unp_gc_current_socket to null; then in soput/sofree,
just KASSERT(so != unp_gc_current_socket).


Home | Main Index | Thread Index | Old Index