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:	Tue, 25 Dec 2012 11:46:14 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Tejun Heo <tj@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()

On Mon, Dec 24, 2012 at 07:29:14PM -0800, Tejun Heo wrote:
> The behavior is primarily because we want to enable workqueue users
> to guarantee that a full work item execution happens at least once
> after certain event happens. ie. Let's say there's a work item which
> processes data generated by a device. If it's IRQ handler calls
> queue_work() after getting notified of new data segment by the device,
> it would want to guarantee that whole work item execution would happen
> afterwards. If you clear PENDING after execution, the event may
> overlap with the end of the previous execution and the new data won't
> be processed.

Oh, ok, I didn't realize we did some sort of a one-shot queueing - I
thought users of wq are supposed to be polling PENDING and when it is
cleared, they queue. But come to think of it, we can't be doing that in
an IRQ handler.

[ … ]

> It doesn't have anything to do with memory hotplug event itself.  It's
> a generic memory access ordering / synchronization issue.  There just
> isn't anything preventing test_bit() from seeing PENDING bit from
> before clearing.

That's true. So is it that the whole PENDING bit testing was actually
the wrong sync primitive to use in most cases and we actually really
needed to disable interrupts around testing of that bit?

Which would make your patches actually bugfixes.

/me goes and rereads 0/25 announcement mail.

Yes, it sounds like [delayed_]work_pending() needs to go or at least
needs a big fat comment over it explaining that it is a special, cheaper
alternative to be used *only* in conjunction with other synchronization.

Ok, thanks Tejun, for taking the time and explaining it again to me.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/