On Wed, Feb 24, 2021 at 1:34 AM Petr Mladek wrote:
>
> On Tue 2021-02-23 14:29:37, Yiwei Zhang wrote:
> > > > which is not cool because it will make the
> > > > asynchronous effort a no-op. Is there a way we can include caller
> > > > thread metadata(task_struct pointer?) when it enqueues the work
On Tue 2021-02-23 14:29:37, Yiwei Zhang wrote:
> > > which is not cool because it will make the
> > > asynchronous effort a no-op. Is there a way we can include caller
> > > thread metadata(task_struct pointer?) when it enqueues the work so
> > > that the RT worker thread won't preempt the caller t
> > which is not cool because it will make the
> > asynchronous effort a no-op. Is there a way we can include caller
> > thread metadata(task_struct pointer?) when it enqueues the work so
> > that the RT worker thread won't preempt the caller thread when that
> > queued work gets scheduled? Probabl
On Mon 2021-02-22 16:58:46, Yiwei Zhang wrote:
> Since you awesome guys are here, I do have another kthread related
> question, and hopefully to get some suggestions:
>
> Below are the conditions:
> 1. The caller threads queuing the work are normal threads(non-RT).
> 2. The worker thread is a real
Since you awesome guys are here, I do have another kthread related
question, and hopefully to get some suggestions:
Below are the conditions:
1. The caller threads queuing the work are normal threads(non-RT).
2. The worker thread is a realtime kernel thread with relatively high prio.
3. We are not
On Fri, Feb 19, 2021 at 2:56 AM Petr Mladek wrote:
>
> On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> > The existing kthread_mod_delayed_work api will queue a new work if
> > failing to cancel the current work due to no longer being pending.
> > However, there's a case that the same work can be
On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> The existing kthread_mod_delayed_work api will queue a new work if
> failing to cancel the current work due to no longer being pending.
> However, there's a case that the same work can be enqueued from both
> an async request and a delayed work, and
On Fri, Feb 19, 2021 at 11:27:13AM +0100, Petr Mladek wrote:
> I am personally fine with adding this API. I am going to
> comment the original code. Well, there might be a push-back
> from other people because there will be no in-tree user.
Adding a new API without an intree user is a complete no-
On Thu 2021-02-18 22:29:24, Yiwei Zhang wrote:
> > 2. User triggered clean up races with the clean up triggered by
> > timeout. You try to handle this scenario by this patch.
> Yes, exactly.
>
> > 3. User does clean up after the clean up has already been done
> > by the timeout.
> This case is
> 2. User triggered clean up races with the clean up triggered by
> timeout. You try to handle this scenario by this patch.
Yes, exactly.
> 3. User does clean up after the clean up has already been done
> by the timeout.
This case is well handled. So only (2) has a potential race.
Let me clar
On Tue 2021-02-16 10:58:36, Yiwei Zhang wrote:
> On Mon, Feb 15, 2021 at 5:28 AM Petr Mladek wrote:
> >
> > On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> > > The existing kthread_mod_delayed_work api will queue a new work if
> > > failing to cancel the current work due to no longer being pendin
On Mon, Feb 15, 2021 at 5:28 AM Petr Mladek wrote:
>
> On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> > The existing kthread_mod_delayed_work api will queue a new work if
> > failing to cancel the current work due to no longer being pending.
> > However, there's a case that the same work can be
On Sun, Feb 14, 2021 at 12:06:11AM +, Yiwei Zhang wrote:
> The existing kthread_mod_delayed_work api will queue a new work if
> failing to cancel the current work due to no longer being pending.
> However, there's a case that the same work can be enqueued from both
> an async request and a dela
On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> The existing kthread_mod_delayed_work api will queue a new work if
> failing to cancel the current work due to no longer being pending.
> However, there's a case that the same work can be enqueued from both
> an async request and a delayed work, and
The existing kthread_mod_delayed_work api will queue a new work if
failing to cancel the current work due to no longer being pending.
However, there's a case that the same work can be enqueued from both
an async request and a delayed work, and a racing could happen if the
async request comes right
15 matches
Mail list logo
