Re: Locking strategy for device deletion (also see PR kern/48536)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  For most devices, an open() is called each time a process
opens one of the nodes associated with that device.  However, the kernel
only calls the close routine for the device driver when the last close is
called from the last process on the last node that was open for that device
driver.  (Substitute module here for driver in this context.)  This means
you can't use reference counting based on opens and closes, as you've just
discovered.  For details on how this has worked historically, and how I
believe it still works in the NetBSD kernel, see the Design and
Implementation of 4.4BSD.  I'll try to lookup chapter and verse for you in
the next week or so, but if you have a copy of the book handy, look at the
chapter that discusses device drivers and how they work.

Hope that helps.
-Brian

On Jun 8,  7:47pm, Paul Goyette wrote:
} Subject: Re: Locking strategy for device deletion (also see PR kern/48536)
} On Wed, 8 Jun 2016, Paul Goyette wrote:
} 
} > On Tue, 7 Jun 2016, Taylor R Campbell wrote:
} >
} >>   Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
} >>   From: Paul Goyette <paul%whooppee.com@localhost>
} >>
} >>   Can anyone suggest a reliable way to ensure that a device-driver module
} >>   can be _really_ safely detached?
} >> 
} >> General approach:
} >> 
} >> 1. Prevent new references (e.g., devsw_detach).
} >> 
} >> 2. Wait for existing references to drain (or roll back with
} >> devsw_attach if you don't want to wait, and fail with EBUSY).
} >> 
} >> 3. Unload.
} >
} > Yes, of course.  Thanks, I think this will work.
} 
} Well, it almost works!  Just one little problem...  :)
} 
} For some reason, the device's open() routine is being called twice, but 
} the close() routine is only called once.  So every iteration leaves the 
} refcount with a net increment of one.
} 
} I cannot figure out why/how the open routine is called twice.
} 
} If it matters, the device in question is /dev/ipl (for ipfilter) and the 
} open calls are a result of
} 
}  	# ipf -E -f -
}  	^D
}  	#
} 
} Other than the introduction of a mutex-plus-refcount, there are no mods 
} to the original driver code.
} 
} Any hints?
} 
} 
} 
} +------------------+--------------------------+------------------------+
} | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
} | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
} | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
} +------------------+--------------------------+------------------------+
>-- End of excerpt from Paul Goyette