Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Regression in 5.1.20: Reading long directory fails
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <FAA4DD3D-C58A-4628-8FD5-A7E2E203B75A@redhat.com>
Date:   Wed, 11 Sep 2019 13:54:14 -0400
Cc:     Jason L Tibbitts III <tibbs@math.uh.edu>,
        Bruce Fields <bfields@fieldses.org>,
        Wolfgang Walter <linux@stwm.de>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        km@cm4all.com, linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8CDE765-7DCE-4257-91E1-CC85CB7F87F7@oracle.com>
References: <ufak1bhyuew.fsf@epithumia.math.uh.edu>
 <4418877.15LTP4gqqJ@stwm.de> <ufapnkhqjwm.fsf@epithumia.math.uh.edu>
 <4198657.JbNDGbLXiX@h2o.as.studentenwerk.mhn.de>
 <ufad0ggrfrk.fsf@epithumia.math.uh.edu> <20190906144837.GD17204@fieldses.org>
 <ufapnkdw3s3.fsf@epithumia.math.uh.edu>
 <75F810C6-E99E-40C3-B5E1-34BA2CC42773@oracle.com>
 <DD6B77EE-3E25-4A65-9D0E-B06EEAD32B31@redhat.com>
 <0089DF80-3A1C-4F0B-A200-28FF7CFD0C65@oracle.com>
 <429B2B1F-FB55-46C5-8BC5-7644CE9A5894@redhat.com>
 <F1EC95D2-47A3-4390-8178-CAA8C045525B@oracle.com>
 <8D7EFCEB-4AE6-4963-B66F-4A8EEA5EA42A@redhat.com>
 <FAA4DD3D-C58A-4628-8FD5-A7E2E203B75A@redhat.com>
To:     Benjamin Coddington <bcodding@redhat.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Sep 11, 2019, at 1:50 PM, Benjamin Coddington <bcodding@redhat.com> =
wrote:
>=20
> On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
>=20
>> On 11 Sep 2019, at 13:29, Chuck Lever wrote:
>>=20
>>>> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington =
<bcodding@redhat.com> wrote:
>>>>=20
>>>>=20
>>>> On 11 Sep 2019, at 12:39, Chuck Lever wrote:
>>>>=20
>>>>>> On Sep 11, 2019, at 12:25 PM, Benjamin Coddington =
<bcodding@redhat.com> wrote:
>>>>>>=20
>>>>=20
>>>>>> Instead, I think we want to make sure the mic falls squarely into =
the tail
>>>>>> every time.
>>>>>=20
>>>>> I'm not clear how you could do that. The length of the page data =
is not
>>>>> known to the client before it parses the reply. Are you suggesting =
that
>>>>> gss_unwrap should do it somehow?
>>>>=20
>>>> Is it too niave to always put the mic at the end of the tail?
>>>=20
>>> The size of the page content is variable.
>>>=20
>>> The only way the MIC will fall into the tail is if the page content =
is
>>> exactly the largest expected size. When the page content is smaller =
than
>>> that, the receive logic will place part or all of the MIC in =
->pages.
>>=20
>> Ok, right.  But what I meant is that xdr_buf_read_netobj() should be =
renamed
>> and repurposed to be "move the mic from wherever it is to the end of
>> xdr_buf's tail".
>>=20
>> But now I see what you mean, and I also see that it is already trying =
to do
>> that.. and we don't want to overlap the copy..
>>=20
>> So, really, we need the tail to be larger than twice the mic.. less =
1.  That
>> means the fix is probably just increasing rslack for krb5i.
>=20
> .. or we can keep the tighter tail space, and if we detect the mic =
straddles
> the page and tail, we can move the mic into the tail with 2 copies, =
first
> move the bit in the tail back, then move the bit in the pages.
>=20
> Which is preferred, less allocation, or in the rare case this occurs, =
doing
> copy twice?

It sounds like the bug is that the current code does not deal correctly
when the MIC crosses the boundary between ->pages and ->tail? I'd like
to see that addressed rather than changing rslack.


--
Chuck Lever