Re: [RFC PATCH] kthread: do not modify running work

2020-10-05 Thread Petr Mladek
On Mon 2020-10-05 18:21:05, Hillf Danton wrote: > On Mon, 5 Oct 2020 10:38:29 Petr Mladek wrote: > > On Sun 2020-10-04 10:12:13, Hillf Danton wrote: > > > What is the difference of invoking kthread_queue_delayed_work() from the > > > callback from kthread_mod_delayed_work()? > > > >

Re: [RFC PATCH] kthread: do not modify running work

2020-10-05 Thread Petr Mladek
On Mon 2020-10-05 10:38:29, Petr Mladek wrote: > On Sun 2020-10-04 10:12:13, Hillf Danton wrote: > > On Fri, 02 Oct 2020 10:32:32 Thomas Gleixner wrote: > > > So having a consistent behaviour accross all these facilities makes > > > absolutely sense and I don't agree with your sentiment in the

Re: [RFC PATCH] kthread: do not modify running work

2020-10-05 Thread Petr Mladek
On Sun 2020-10-04 10:12:13, Hillf Danton wrote: > > On Fri, 02 Oct 2020 10:32:32 Thomas Gleixner wrote: > > On Fri, Oct 02 2020 at 10:34, Hillf Danton wrote: > > > On Thu, 01 Oct 2020 15:59:38 +0200 Thomas Gleixner wrote: > > >> On Thu, Oct 01 2020 at 17:51, Hillf Danton wrote: > > >> Aside of

Re: [RFC PATCH] kthread: do not modify running work

2020-10-02 Thread Thomas Gleixner
On Fri, Oct 02 2020 at 10:34, Hillf Danton wrote: > On Thu, 01 Oct 2020 15:59:38 +0200 Thomas Gleixner wrote: >> On Thu, Oct 01 2020 at 17:51, Hillf Danton wrote: >> Aside of that it's pretty irrelevant whether there is a user at the >> moment which reschedules work from the callback or not. >>

Re: [RFC PATCH] kthread: do not modify running work

2020-10-01 Thread Thomas Gleixner
On Thu, Oct 01 2020 at 17:51, Hillf Danton wrote: > On Wed, 30 Sep 2020 17:01:09 +0200 Petr Mladek wrote: >> On Sat 2020-09-26 12:04:26, Hillf Danton wrote: >> > >> > It does not make much sense to rearm timer for the delayed work if >> > it is worker's current work atm because it's good to do

Re: [RFC PATCH] kthread: do not modify running work

2020-09-30 Thread Petr Mladek
On Sat 2020-09-26 12:04:26, Hillf Danton wrote: > > It does not make much sense to rearm timer for the delayed work if > it is worker's current work atm because it's good to do work only > once. Quite typical scenario is to queue delayed work from its own callback. It allows to do the work in