Date: Thu, 11 Feb 2016 12:40:27 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: Greg Quinlan <gwq_uk@yahoo.com>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL PANIC FreeBSD-11 Message-ID: <20160211104027.GP91220@kib.kiev.ua> In-Reply-To: <56BC604C.4060206@selasky.org> References: <56BB0BDB.2090203@selasky.org> <872763758.2494245.1455156152295.JavaMail.yahoo@mail.yahoo.com> <56BC3041.7050203@selasky.org> <20160211101418.GO91220@kib.kiev.ua> <56BC604C.4060206@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160211104027.GP91220>