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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).