linux-kernel - Re: [PATCH -rt] disable building all staging drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jun 2009 08:17:01 -0700
From:	Greg KH <greg@...ah.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, linux-kernel@...r.kernel.org,
	linux-rt@...gutronix.de, Ian Abbott <abbotti@....co.uk>,
	Frank Mori Hess <fmhess@...rs.sourceforge.net>
Subject: Re: [PATCH -rt] disable building all staging drivers

On Tue, Jun 23, 2009 at 01:24:19PM +0200, Thomas Gleixner wrote:
> On Mon, 22 Jun 2009, Greg KH wrote:
> > > 17:02:43 E: ERROR: "there_is_no_init_MUTEX_LOCKED_for_RT_semaphores" [drivers/staging/rt2870/rt2870sta.ko] undefined!
> > 
> > What needs to be done in the rt2870 driver to resolve this issue?
> 
> It looks like the semaphores are used to wait for an event. There are
> actually 3 of those:
> 
> 	 init_MUTEX_LOCKED(&(pAd->mlme_semaphore));
> 	 init_MUTEX_LOCKED(&(pAd->RTUSBCmd_semaphore));
> 	 init_MUTEX_LOCKED(&(pAd->RTUSBTimer_semaphore));
> 
> All are used in kernel threads which wait with down_interruptible() on
> them. The up() calls are in some completely non obvious places.
> 
> I had a look into the timer one. The semaphore is the least thing you
> need to worry about there. The open coded timer list management and
> the thread which does timer polling for some obscure reason are the
> things which need to be fixed in the first place. Once this is cleaned
> up the semaphore will be gone anyway.
> 
> But, after looking into that code I really have to ask you whether you
> are serious about fixing it instead of rewriting it from scratch and
> just keep the code as is for reference to the hardware details.

That is exactly what the code is there for.  There are other groups
rewriting these drivers from scratch, and hopefully they will be done in
a kernel release or two and then these drivers can go away.

If, in the mean time, you don't want them to be built for -rt kernels,
just send me a Kconfig patch for the individual drivers, not for the
whole of the staging tree.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/