Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8 ---
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
On Sat, 22 Feb 2014, Tejun Heo wrote:
Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8 ---
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
On 02/22/2014 10:14 AM, Alan Stern wrote:
On Sat, 22 Feb 2014, Tejun Heo wrote:
Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8 ---
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as
On Sat, 22 Feb 2014, Tejun Heo wrote:
On Sat, Feb 22, 2014 at 10:14:48AM -0500, Alan Stern wrote:
Is the cancel_delayed_work_sync(hub-init_work) call in hub_quiesce()
going to get confused by all this?
Yeah, you can't cancel a work item which hasn't been initialzed.
Maybe move init of
Hey, Alan.
On Sat, Feb 22, 2014 at 06:03:04PM -0500, Alan Stern wrote:
then a single init work could be queued to
the system_unbound_wq which doesn't care about running times.
This sort of thing sounds like the best approach. Tejun, do you want
to rewrite the patch, getting rid of the
