linux-kernel - Re: [PATCH] make cancel_rearming_delayed

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: <20070504170916.GA95@tv-sign.ru>
Date:	Fri, 4 May 2007 21:09:16 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Chinner <dgc@....com>, David Howells <dhowells@...hat.com>,
	Gautham Shenoy <ego@...ibm.com>,
	Jarek Poplawski <jarkao2@...pl>, Ingo Molnar <mingo@...e.hu>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] make cancel_rearming_delayed_work() reliable

On 05/03, Andrew Morton wrote:
>
> On Fri, 4 May 2007 00:42:26 +0400
> Oleg Nesterov <oleg@...sign.ru> wrote:
> 
> > Disadvantages:
> > 
> > 	- this patch adds wmb() to insert_work().
> > 
> > 	- slowdowns the fast path (when del_timer() succeeds on entry) of
> > 	  cancel_rearming_delayed_work(), because wait_on_work() is called
> > 	  unconditionally. In that case, compared to the old version, we are
> > 	  doing "unneeded" lock/unlock for each online CPU.
> > 
> > 	  On the other hand, this means we don't need to use cancel_work_sync()
> > 	  after cancel_rearming_delayed_work().
> > 
> > 	- complicates the code (.text grows by 130 bytes).
> > 
> 
> hm, this is getting complex.

Yes, and I can't say I like this patch very much.

First, I am not really sure it is terribly useful. Yes, cancel_rearming_delayed_work
sucks, but did we have any problem in practice? The most annoying problem is that it
cant't cancel @dwork which doesn't re-arm itself unconditionally. But this is not so
common, and ata_port_flush_task() shows an example how to do this. However, it also
shows that this is not so trivial, and work->func() should participate.

Also, we can solve this problem in more simple way. For example, we can shift
"timer->function = delayed_work_timer_fn" from queue_delayed_work() to INIT_DELAYED_WORK().
Then, roughly,

	cancel_rearming_delayed_work(dwork)
	{
		dwork->timer->function = do_nothing_timer_fn;
		del_timer_sync(&dwork->timer);
		wait_on_work(&dwork->work);
		dwork->timer->function = delayed_work_timer_fn;
		del_timer(&dwork->timer);
		work_clear_pending(&dwork->work
	}

But this is so hackish, and doesn't work if work->func() use queue_work() or
queue_delayed_work(delay = 0) to re-arm itself. Perhaps we can forbid this,
and make a simpler patch.

> > +	while (!try_to_grab_pending(work))
> > +		;
> 
> The patch adds a couple of spinloops.  Normally we put a cpu_relax() into
> such loops.  It can make a very large difference under some circumstances.

Ah, yes. I'll send a fix along with a little comments update.

Oleg.

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