linux-kernel - Re: workqueue: race in mod_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, 10 May 2016 12:36:25 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: workqueue: race in mod_delayed_work_on?

Hello,

On Tue, May 10, 2016 at 07:28:08PM +0300, Konstantin Khlebnikov wrote:
> On 10.05.2016 11:21, Konstantin Khlebnikov wrote:
> >I've got plenty warnings, bugs and oops around trivial use of mod_delayed_work in drivers/infiniband/core/addr.c
> 
> Looks like problem in mod_delayed_work_on was hidden because add_timer is equal to mod_timer

The timer usages are gated behind PENDING bit, so whether add_timer()
is equal to mod_timer() shouldn't matter.

> but Sasha accidentally backported 874bbfe600a660cba9c776b3957b1ce393151b76
> (workqueue: make sure delayed work run in local cpu) into 3.18.25
> 
> I don't see reason why that commit could break delayed work,
> most likely it highlighted some other problem.

What are you running?  Can you reproduce the issue on upstream kernel?

-- 
tejun