Mark Brown writes:
> On Mon, Feb 27, 2017 at 08:17:10PM +0100, Harald Geyer wrote:
> > Mark Brown writes:
>
> > > I'd need to figure out exactly what the restrictions are and like I say
> > > the name of the function itself is confusing, I suspect because it
> > > predates SMP.
>
> > I guess you
On Mon, Feb 27, 2017 at 08:17:10PM +0100, Harald Geyer wrote:
> Mark Brown writes:
> > I'd need to figure out exactly what the restrictions are and like I say
> > the name of the function itself is confusing, I suspect because it
> > predates SMP.
> I guess you know that, but just to avoid any co
Hello,
On Tue, Mar 07, 2017 at 12:29:32PM +0100, Harald Geyer wrote:
> On 06.03.2017 23:22, Tejun Heo wrote:
> > I don't think it's a matter of "fixing" the existing
> > mod_delayed_work(). What the new function is implementing wouldn't
> > fit use cases where the timeout should only be shortened
On Mon, Mar 06, 2017 at 05:22:12PM -0500, Tejun Heo wrote:
> On Thu, Feb 23, 2017 at 09:34:49AM -0800, Mark Brown wrote:
> > It is *very* non-obvious that mod_delayed_work() will have a problem
> > from the documentation, there's "mod_delayed_work_on() on local CPU" as
> > the body of the descript
On 06.03.2017 23:22, Tejun Heo wrote:
I don't think it's a matter of "fixing" the existing
mod_delayed_work(). What the new function is implementing wouldn't
fit use cases where the timeout should only be shortened (IIRC,
writeback code does that).
I'm not against adding new interface to handle
Hello,
On Thu, Feb 23, 2017 at 09:34:49AM -0800, Mark Brown wrote:
> It is *very* non-obvious that mod_delayed_work() will have a problem
> from the documentation, there's "mod_delayed_work_on() on local CPU" as
> the body of the description but honestly I'm struggling to tell if
> that's even the
Mark Brown writes:
> On Fri, Feb 24, 2017 at 12:22:37AM +0100, Harald Geyer wrote:
> > Mark Brown writes:
>
> > > detail. I'd expect to see some words describing the situations where it
> > > can be used or something, both the name and the lack of any information
> > > about issues suggest it's th
On Fri, Feb 24, 2017 at 12:22:37AM +0100, Harald Geyer wrote:
> Mark Brown writes:
> > detail. I'd expect to see some words describing the situations where it
> > can be used or something, both the name and the lack of any information
> > about issues suggest it's the default thing and will work s
Mark Brown writes:
> > > The obvious question here, especially in the case of
> > > mod_delayed_work(), is why not fix the existing functions to have
> > > the expected behaviour?
>
> > AFAICS the existing functions behave as documented. I don't feel
> > to be an authority to decide that the docum
On Wed, Feb 22, 2017 at 09:06:23PM +0100, Harald Geyer wrote:
> Mark Brown writes:
> > On Wed, Feb 22, 2017 at 05:41:24PM +, Harald Geyer wrote:
> > > Drivers calling queue_delayed_work() or mod_delayed_work() multiple times
> > > on the same work without coordination get undefined behaviour. A
Mark Brown writes:
> On Wed, Feb 22, 2017 at 05:41:24PM +, Harald Geyer wrote:
> > Drivers calling queue_delayed_work() or mod_delayed_work() multiple times
> > on the same work without coordination get undefined behaviour. Add a new
> > function, which is easier to use.
>
> The obvious questi
On Wed, Feb 22, 2017 at 05:41:24PM +, Harald Geyer wrote:
> Drivers calling queue_delayed_work() or mod_delayed_work() multiple times
> on the same work without coordination get undefined behaviour. Add a new
> function, which is easier to use.
The obvious question here, especially in the case
Drivers calling queue_delayed_work() or mod_delayed_work() multiple times
on the same work without coordination get undefined behaviour. Add a new
function, which is easier to use.
Signed-off-by: Harald Geyer
---
include/linux/workqueue.h | 17 +
kernel/workqueue.c| 41 ++
13 matches
Mail list logo
