On Thu, Feb 11, 2016 at 11:19:56AM +0100, Hans Petter Selasky wrote: > On 02/11/16 11:14, Konstantin Belousov wrote: > > On Thu, Feb 11, 2016 at 07:54:57AM +0100, Hans Petter Selasky wrote: > >> On 02/11/16 03:02, Greg Quinlan wrote: > >>> Hi HPS, > >>> Note: Does not happen on FreeBSD 10.1-Stable! > >>> > >> > >> Yes, that's because WITNESS is off in 10.x by default. > >> > >> Does the attached patch solve your problem? > > > > No, the patch below does not solve the issue, it only papers over it. > > I object against committing this change. > > For cases where the returned pointer is not deferred, but only checked > for a module's presence in the kernel you don't need a lock to protect > anything. Maybe make a separate API for this? How checking for bool (i.e. == NULL) would fix anything ? The fact that the module is loaded could be invalidated in parallel, so the answer you get is already wrong. The bool value you obtained is equally wrong. > > > > > Issue is that, if called unlocked, the result from module_lookupbyname() > > could become invalid right after receiving. It is the duty of the caller > > of the function to ensure that the result is still valid, and the only > > way to achieve it is to own the lock around the whole code region which > > calls the function and utilizes its result. > > > > A bug is in the OSS code. > > Yes, so why not factor out the solution? Maybe more port KLD's will trip > over this? Solution is for OSS code to take a lock around the whole region where the answer is needed.Received on Thu Feb 11 2016 - 09:40:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC