linux-kernel - Re: [PATCH 5/9] usb: don't use PREPARE_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]

Date:	Fri, 21 Feb 2014 10:06:05 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:	Tejun Heo <tj@...nel.org>, <laijs@...fujitsu.com>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 5/9] usb: don't use PREPARE_DELAYED_WORK

On Thu, 20 Feb 2014, Greg Kroah-Hartman wrote:

> On Thu, Feb 20, 2014 at 03:44:27PM -0500, Tejun Heo wrote:
> > PREPARE_[DELAYED_]WORK() are being phased out.  They have few users
> > and a nasty surprise in terms of reentrancy guarantee as workqueue
> > considers work items to be different if they don't have the same work
> > function.
> > 
> > usb_hub->init_work is multiplexed with multiple work functions.
> > Introduce hub_init_workfn() which invokes usb_hub->init_workfn and
> > always use it as the work function and update the users to set the
> > ->init_workfn field instead of overriding the work function using
> > PREPARE_DELAYED_WORK().
> > 
> > It looks like that the work items are never queued while in-flight, so

They aren't.  But one work item does get queued by the previous one's 
work function.

> > simply using INIT_DELAYED_WORK() before each queueing could be enough.
> > This patch performs equivalent conversion just in case but we probably
> > wanna clean it up later if that's the case.
> 
> I think it should be fine to use INIT_DELAYED_WORK(), but Alan would
> know best.  Alan?

That's right; INIT_DELAYED_WORK() should be fine.  Provided there's no 
problem doing it from within the previous work routine.

Alan Stern

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