linux-kernel - Re: Overview of concurrency managed workqueue

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:	Wed, 16 Jun 2010 21:20:36 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Daniel Walker <dwalker@...eaurora.org>
CC:	mingo@...e.hu, awalls@...ix.net, linux-kernel@...r.kernel.org,
	jeff@...zik.org, akpm@...ux-foundation.org, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com,
	arjan@...ux.intel.com, johannes@...solutions.net, oleg@...hat.com,
	axboe@...nel.dk
Subject: Re: Overview of concurrency managed workqueue

On 06/16/2010 08:46 PM, Tejun Heo wrote:
> * I'm very sorry I'm breaking your hacky workaround but seriously
>   that's another problem to solve.  Let's talk about the problem
>   itself instead of your hacky workaround.  (I think for most cases
>   not using workqueue in RT path would be the right thing to do.)

For example, for the actual case of amba-pl022.c you mentioned, where
interrupt handler sometimes offloads to workqueue, convert
amba-pl022.c to use threaded interrupt handler.  That's why it's
there.

If you actually _solve_ the problem like this, other users wouldn't
experience the problem at all once the update reaches them and you
won't have to worry about your workaround breaking with the next
kernel update or unexpected suspend/resume and we won't be having this
discussion about adjusting workqueue priorities from userland.

There are many wrong things about working around RT latency problems
by setting workqueue priorities from userland.  Please think about why
the driver would have a separate workqueue for itself in the first
place.  It was to work around the limitation of workqueue facility and
you're arguing that, because that work around allows yet another very
fragile workaround, the property which made the original work around
necessary in the first place needs to stay.  That sounds really
perverse to me.

-- 
tejun
--
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/