From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>,
Ben Hutchings <ben@decadent.org.uk>,
Lee Jones <lee.jones@linaro.org>,
Wolfram Sang <wsa@the-dreams.de>,
Roger Tseng <rogerable@realtek.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] rtsx_usb_ms: Use msleep_interruptible() in polling loop
Date: Tue, 3 May 2016 15:40:09 +0200 [thread overview]
Message-ID: <20160503134009.GA26668@redhat.com> (raw)
In-Reply-To: <20160502135634.ccbfb7f58798b7a217319b98@linux-foundation.org>
On 05/02, Andrew Morton wrote:
>
> On Mon, 02 May 2016 23:17:41 +0300 Oleksandr Natalenko <oleksandr@natalenko.name> wrote:
>
> > rtsx_usb_ms creates a task that mostly sleeps, but tasks in
> > uninterruptible sleep still contribute to the load average (for
> > bug-compatibility with Unix).
We have TASK_NOLOAD/TASK_IDLE, you can just use schedule_timeout_idle(HZ).
but msleep_interruptible(1000) is fine too.
> > --- a/drivers/memstick/host/rtsx_usb_ms.c
> > +++ b/drivers/memstick/host/rtsx_usb_ms.c
> > @@ -706,7 +706,8 @@ poll_again:
> > if (host->eject)
> > break;
> >
> > - msleep(1000);
> > + if (msleep_interruptible(1000))
> > + flush_signals(current);
> > }
> >
> > complete(&host->detect_ms_exit);
>
> flush_signals() is a bit scary.
...
> But this isn't a userspace task - it's a kthread. So I don't *think*
> it can get any signals anyway?
Agreed, it is not needed and only adds some confusion, so I think
rtsx_usb_ms-use-msleep_interruptible-in-polling-loop.patch should be
updated.
A kernel thread ignores all signals unless it does allow_signal(), so
you can safely remove flush_signals().
Oleg.
next prev parent reply other threads:[~2016-05-03 13:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 20:17 [PATCH RESEND] rtsx_usb_ms: Use msleep_interruptible() in polling loop Oleksandr Natalenko
2016-05-02 20:56 ` Andrew Morton
2016-05-03 13:40 ` Oleg Nesterov [this message]
2016-05-03 15:22 ` Ben Hutchings
-- strict thread matches above, loose matches on Subject: below --
2015-09-28 0:34 Ben Hutchings
2015-09-28 10:34 ` Lee Jones
2015-09-28 11:10 ` Ben Hutchings
2015-09-28 11:23 ` Lee Jones
2015-10-08 3:37 ` Roger Tseng
2015-10-08 7:19 ` Lee Jones
2015-10-08 19:35 ` Ben Hutchings
2015-10-09 7:18 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160503134009.GA26668@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ben@decadent.org.uk \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr@natalenko.name \
--cc=rogerable@realtek.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.