"Luis R. Rodriguez" <[email protected]> writes: > On Thu, Jun 15, 2017 at 9:22 AM, Paul E. McKenney > <[email protected]> wrote: >> On Thu, Jun 15, 2017 at 05:50:39PM +0200, Luis R. Rodriguez wrote: >>> On Wed, Jun 14, 2017 at 04:43:45PM -0700, Paul E. McKenney wrote: >>> > On Wed, Jun 14, 2017 at 04:06:39PM -0700, Luis R. Rodriguez wrote:
>>> > > Signed-off-by: Luis R. Rodriguez <[email protected]> >>> > > --- >>> > > >>> > > The killable swaits were just posted [1] as part of a series where >>> > > SIGCHLD >>> > > was detected as interrupting and killing kernel calls waiting using >>> > > non-killable swaits [1]. The fragility here made curious about other >>> > > callers >>> > > and seeing if they really meant to use such broad wait which captures a >>> > > lot >>> > > of signals. >>> > > >>> > > I can't see why we'd want to have these killed by other signals, >>> > > specialy >>> > > since it seems we don't even check for the return value... Granted to >>> > > abort >>> > > properly we'd have to check for the return value for -ERESTARTSYS, but >>> > > yeah, >>> > > none of this is done, so it would seem we don't want fragile signals >>> > > interrupting these ? >>> > >>> > The later WARN_ON(signal_pending(current)) complains if a signal somehow >>> > makes it to this task. Assuming that the signal is nonfatal, anyway. >>> >>> I see, how about just using swait_event_timeout() and removing the >>> WARN_ON()? >>> Is there a reason for having the interruptible ? >> >> If sleeping-uninterruptible kthreads are now excluded from the load average, >> no reason. But if sleeping-uninterruptible kthreads are still included in >> the load average, it must stay interruptible. > > Got it! There is now TASK_IDLE that is uninterruptible and does not contribute to load avearage. see: task_contributes_to_load. So a swait_event_idle() could be written for this case. Eric
