linux-kernel - Re: corruption causing crash in __queue

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: <20151217155032.GJ4026@mtj.duckdns.org>
Date:	Thu, 17 Dec 2015 10:50:32 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Nikolay Borisov <kernel@...p.com>
Cc:	Mike Snitzer <snitzer@...hat.com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	SiteGround Operations <operations@...eground.com>,
	Alasdair Kergon <agk@...hat.com>,
	device-mapper development <dm-devel@...hat.com>
Subject: Re: corruption causing crash in __queue_work

Hello, Nikolay.

On Thu, Dec 17, 2015 at 05:43:12PM +0200, Nikolay Borisov wrote:
> Right, but my initial understanding was that when canceling the delayed
> work and then issuing flush_workqueue would act the same way as if
> cancel_delayed_work_sync is called wrt to this particular delayed item, no?

Not necessarily.  cancel_delayed_work() cancels whatever is currently
pending.  flush_workqueue() flushes whatever is pending and in flight
at the time of invocation.  Imagine the following scenario.

1. Work item is running but hasn't requeued itself yet.

2. cancel_delayed_work_sync() doesn't do anything as it's not pending.

3. flush_workqueue() starts and waits for the running instance.

4. The running instance requeues itself but this isn't included in the
   scope of the above flush_workqueue().

5. flush_workqueue() returns when the work item is finished (but it's
   still queued).

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/