linux-kernel - Re: [PATCH 25/25] ipc: don't use [delayed_]work

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]

Message-ID: <20121224183334.GB11817@htj.dyndns.org>
Date:	Mon, 24 Dec 2012 10:33:34 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()

Hello, Borislav.

On Sat, Dec 22, 2012 at 12:09:29PM +0100, Borislav Petkov wrote:
> Now you say those paths are not fast paths, but the reverse of
> this optimization is also true: what happens if people start using
> schedule_work() in fast paths without checking whether work is pending?
> A useless IRQ disable + locked operation + IRQ enable.

That's a really strange argument.  If we extend from that, we have to
optimize cold paths to prevent fast paths copy from them, which sounds
really silly to me.

If one looks at something happening in a path as cold as memory
hotplug and thinks about optimizing a coupld memory accesses, the
person's priorities need serious reconsideration.  I think approaches
like that are actively harmful.  They lead to unnecessary (and thus
difficult to comprehend) convolutions which don't really help anything
while deteoriorating code base.

I don't think we have cases where this actually matters but it could
be that we can add work_pending() tests to queue_work_on().  I *think*
that shouldn't break work scheduling semantics.  Not completely sure
tho.  Need to think about it more.

Thanks.

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