linux-kernel - Re: linux-next: workqueues tree build failure

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:	Fri, 27 Nov 2009 12:09:18 +0200
From:	Peter Ujfalusi <peter.ujfalusi@...ia.com>
To:	ext Tejun Heo <tj@...nel.org>
Cc:	Takashi Iwai <tiwai@...e.de>, Andy Walls <awalls@...ix.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: linux-next: workqueues tree build failure

Hello,

On Friday 27 November 2009 10:42:27 ext Tejun Heo wrote:
> Hello,
> 
> 11/27/2009 05:37 PM, Takashi Iwai wrote:
> >> Sounds like it should be using bottom half tasklet not workqueue.
> >> Tasklet is exactly designed to handle situations like this.  Is there
> >> any reason tasklet can't be used?
> >
> > Right now the h/w accessing code is using mutex.  I'm not sure whether
> > the deeper part might sleep, though...
> 
> Ah... I see.  Using mutex from a handler where response time is
> critical is strange tho.  Anyways, I don't really think singlethread
> will satisfy the timing requirement under loaded conditions.  IMHO,
> update locking and using tasklets would be the best.

Hmmm, yes, I'm aware that it might be not sufficient to use the singlethread wq, 
but that was the fastest fix that I could think of, and it was needed for the 
linux-next.
In case of the tlv320dac33 driver, I can also play with the codec as well to 
adjust the required latency, but if I hit the wall, than for sure I will look 
for another solution for the problem.
So far this is working for my development needs, but time will tell if I need to 
make bigger modifications.

For the record: on OMAP platforms the I2C implementation is sleeping during the 
transfer (internally using interrupt based transfer), which might be not that 
wise in the tasklet. Since the I2C bus is kind of a slow bus, this could take 
several ms in some cases.

Thank you,
Péter
--
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/