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] [day] [month] [year] [list]
Message-ID: <20070423094107.GD1684@ff.dom.local>
Date:	Mon, 23 Apr 2007 11:41:07 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] workqueue: cancel_rearming_delayed_work/workqueue usage warning

On Fri, Apr 20, 2007 at 09:23:48PM +0400, Oleg Nesterov wrote:
> On 04/20, Jarek Poplawski wrote:
> > 
> > Here is my proposal to make things clearer:
> > (this time on 2.6.21-rc7)
> > 
> > CC: David Chinner <dgc@....com>
> > CC: Oleg Nesterov <oleg@...sign.ru>
> > Signed-off-by: Jarek Poplawski <jarkao2@...pl>
> > 
> > ---
> > 
> > diff -Nurp 2.6.21-rc7-/kernel/workqueue.c 2.6.21-rc7/kernel/workqueue.c
> > --- 2.6.21-rc7-/kernel/workqueue.c	2007-04-18 10:14:16.000000000 +0200
> > +++ 2.6.21-rc7/kernel/workqueue.c	2007-04-20 13:56:51.000000000 +0200
> > @@ -662,6 +662,8 @@ EXPORT_SYMBOL(flush_scheduled_work);
> >   * cancel_rearming_delayed_workqueue - reliably kill off a delayed work whose handler rearms the delayed work.
> >   * @wq:   the controlling workqueue structure
> >   * @dwork: the delayed work struct
> > + *
> > + * WARNING: use only with handlers, which rearm unconditionally with delay > 0
> >   */
> 
> Nit: it is ok if the work re-arms itself with delay == 0 "sometimes". What we
> need is that the handler use delay > 0 eventually.

Probably it would be shorter to write it yourself, because I'm not sure
of your intentions: so, you think we can call this function with such
a work?

> 
> I'd suggest to re-diff against -mm tree. I don't think this patch can find its
> way to the soon to be released 2.6.21.

The current thread seems to confirm my initial fear, this function
is not explained enough, so it should help to remove errors as soon
as possible from the current code. And I hope this functions will
work other way soon...

Jarek P.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ