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]

Date:	Mon, 24 Dec 2012 10:45:20 -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, again.

On Mon, Dec 24, 2012 at 10:33:34AM -0800, Tejun Heo wrote:
> 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.

I was confused a bit there.  We can't.  Nothing guarantees that the
queuer sees the cleared PENDING before the work item starts execution,
and I think ipc memory hotplug could also be broken from that.  It's
highly unlikely to actually happen and there may be external locking
which prevents the race from actually happening, but there's nothing
synchronizing queueing and the execution of the work item.  Looking at
that part of code only, it's possible that it fails to queue the work
item after a memory hotplug event even though the previous queueing
already started execution and processed a couple notifiers.

And you can see why you don't want this type of tricky micro
optimizations unless it's absolutely necessary and carefully
considered.  Cold paths get much less attention and testing.  Adding
micro optimizations to them is just a bad idea.

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/