Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: [PATCH] tty/n_hdlc: fix sleep in !TASK_RUNNING state warning
From:   Paul Fulghum <paulkf@microgate.com>
In-Reply-To: <cf9b7323-da1c-20cd-4d50-1080fbe52467@i-love.sakura.ne.jp>
Date:   Wed, 2 Jan 2019 12:55:39 -0800
Cc:     Arnd Bergmann <arnd@arndb.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        gregkh@linuxfoundation.org, jslaby@suse.com,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <64B85AC0-CEB5-4F11-8B83-3C2A2CD056FB@microgate.com>
References: <000000000000449587057e1e6f8b@google.com>
 <49b3b189-a51f-6a97-0e1f-bc3f2c305299@I-love.SAKURA.ne.jp>
 <FEBFE826-8D27-4A0B-86A5-BA559921CADC@microgate.com>
 <cf9b7323-da1c-20cd-4d50-1080fbe52467@i-love.sakura.ne.jp>
To:     Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jan 2, 2019, at 7:04 AM, Tetsuo Handa =
<penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>=20
> On 2019/01/01 12:11, Paul Fulghum wrote:
>> NAK to this patch. It causes lost wakeups in both read and write =
paths.
>>=20
>> The write path does not need changing.
>>=20
>> The read path can be fixed by setting current to TASK_RUNNING at the =
top of the if (rbuf) block
>> so the warning is not triggered by copy_to_user(). If this block runs =
the condition is satisfied
>> and it breaks out of the polling loop where it is already being set =
to TASK_RUNNING and removed
>> from the wait queue. This particular path just needs to account for =
the copy_to_user which occurs
>> before breaking out.
>>=20
>> I=E2=80=99ll make a patch to do this when I have the ability to test =
it in a day or two.
>>=20
>=20
> OK. Then, any chance it is rewritten using wait_event_interruptible() =
in order to reduce lines?
> ( wait_event_interruptible() automatically calls might_sleep(), but is =
it acceptable for you? )
>=20

This looks good to me. I applied it and tested blocking (sleep/no sleep) =
and non-blocking (success/EAGAIN) paths for both read and write.=