[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181011220631.GB128397@gmail.com>
Date: Fri, 12 Oct 2018 00:06:31 +0200
From: Ingo Molnar <mingo@...nel.org>
To: peterz@...radead.org, hofrat@...dl.org,
torvalds@...ux-foundation.org, john.garry@...wei.com,
tglx@...utronix.de, linux-kernel@...r.kernel.org, hpa@...or.com
Cc: linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched/completions/Documentation: Clean up the
document some more
hi Nicholas,
I was wondering about this paragraph:
> Using on-stack completions for code that calls any of the _timeout or
> _interruptible/_killable variants is not advisable as they will require
> additional synchronization to prevent the on-stack completion object in
> the timeout/signal cases from going out of scope. Consider using dynamically
> allocated completions when intending to use the _interruptible/_killable
> or _timeout variants of wait_for_completion().
What exact race related to _timeout()/_interruptible() waits and on-stack
completions were you trying to highlight here?
Is it the fact that if a signal is already pending for the current task,
that the _interruptible() variant might return prematurely, while any
kthread that has the completion pointer passed to it might still be using
it?
In that case the kthread should indeed be waited for.
How would a dynamically allocated completion object help in this case - or do
you mean a refcounted dynamic object?
A specific example might be useful here, instead of this rather vague,
generic description.
Thanks,
Ingo
Powered by blists - more mailing lists