Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: [PATCH] SUNRPC: Use poll() to fix up the socket requeue races
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <e0a1f082b017aadb98dec3f8df6de7a49c078fac.camel@hammerspace.com>
Date:   Tue, 19 Feb 2019 10:20:41 -0500
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <255A7507-061E-41C3-84A4-211DFFB702ED@oracle.com>
References: <20190219140616.123141-1-trond.myklebust@hammerspace.com>
 <A2BBC175-F60D-4C61-B70F-479952D2CD21@oracle.com>
 <e0a1f082b017aadb98dec3f8df6de7a49c078fac.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Feb 19, 2019, at 10:13 AM, Trond Myklebust =
<trondmy@hammerspace.com> wrote:
>=20
> On Tue, 2019-02-19 at 09:54 -0500, Chuck Lever wrote:
>> Hi Trond-
>>=20
>>> On Feb 19, 2019, at 9:06 AM, Trond Myklebust <trondmy@gmail.com>
>>> wrote:
>>>=20
>>> Because we clear XPRT_SOCK_DATA_READY before reading, we can end up
>>> with a situation where new data arrives, causing xs_data_ready() to
>>> queue up a second receive worker job for the same socket, which
>>> then
>>> immediately gets stuck waiting on the transport receive mutex.
>>> The fix is to only clear XPRT_SOCK_DATA_READY once we're done
>>> reading,
>>> and then to use poll() to check if we might need to queue up a new
>>> job in order to deal with any new data.
>>=20
>> Does this fix an application-visible hang, or is it merely a
>> performance
>> optimization?
>=20
> I'm not aware of any hang associated with this behaviour. The patch is
> rather intended as an optimisation to avoid having these threads block
> uselessly on a mutex.

That was my guess, thanks, just wanted to make certain.

--
Chuck Lever