linux-kernel - Re: Is adding requeue_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:	Sat, 22 Aug 2009 12:35:47 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Roland Dreier <rdreier@...co.com>
CC:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: Is adding requeue_delayed_work() a good idea

Roland Dreier wrote:
[Oleg Nesterov wrote]
> Perhaps the semantics are sufficiently fuzzy and not general enough, so
> that the best answer is my special-case open coded change for my
> specific case.  I don't know whether other places would even want a
> requeue_delayed_work() ... I simply raise this point because when I find
> myself reimplementing the structure of work_struct + timer because
> delayed_work API is lacking, then it seems prudent to consider extending
> delayed_work API instead.

There are two or three use cases of rescheduling a delayed work in 
drivers/firewire, but in one regard they are simpler than your case:

The work only needs to be pushed back in time, never scheduled earlier 
than it was originally scheduled.  This is easily implemented with the 
existing delayed work API by letting the work check whether it is 
entered too early; if yes, reschedule itself.

Further requirements of this use case:
   - It doesn't matter on which CPU this kind of work runs on.
   - If the event which necessitates rescheduling happens when the
     work is already running, then it might depend on the outcome of
     the work whether it needs to be scheduled again.  I think the
     requeue_delayed_work should do nothing in that case and the
     work needs to test how it went and rearm if necessary.

Well, considering the latter point, there is no harm in keeping all of 
the requeue_delayed_work logic concentrated in the work itself in these 
FireWire use cases.

[These use cases are high-level protocols for resource acquisition over 
the FireWire bus.  Cooperative fairness schemes require them to be timed 
after a grace period for resource re-acquisition by holders of older 
resources, following after bus reset events which may happen any time.]

So, the question is whether there is any user besides IB which needs to 
pull a delayed work forward in time.

Or another thought:  Would it hurt if you ignored any shortening of 
timeouts, i.e. reduce your use case also to only ever _deferring_ work, 
never rescheduling to an earlier point in time?
-- 
Stefan Richter
-=====-==--= =--- =-==-
http://arcgraph.de/sr/
--
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/