Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Message-ID: <338C33D2-A5F2-40D0-9D8B-6E6334D361A8@oracle.com>
Date:   Thu, 3 Dec 2020 08:59:37 -0800 (PST)
From:   Chuck Lever <chuck.lever@oracle.com>
To:     Frank van der Linden <fllinden@amazon.com>
Cc:     "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>,
        Olga Kornievskaia <aglo@umich.edu>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        trondmy <trondmy@hammerspace.com>
Subject: Re: Kernel OPS when using xattr
References: <2137763922.1852883.1606983653611.JavaMail.zimbra@desy.de>
 <CAN-5tyEWYqXiqLdJE-DLH2b+LrVfPkviJDGQY=MyitS5aW4bJw@mail.gmail.com>
 <1296195278.2032485.1607010192169.JavaMail.zimbra@desy.de>
 <20201203161858.GA27349@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
In-Reply-To: <20201203161858.GA27349@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


> On Dec 3, 2020, at 11:18 AM, Frank van der Linden =
<fllinden@amazon.com> wrote:
>=20
> On Thu, Dec 03, 2020 at 04:43:12PM +0100, Mkrtchyan, Tigran wrote:
>>=20
>> Hi Olga,
>>=20
>> Franks patches are not applied. I will check with Trond's patch and
>> then will try those as well.
>>=20
>> Regards,
>>   Tigran.
>=20
> Since my change no longer uses SPARSE_PAGES, it'll probably avoid the
> oops, so give it a try.
>=20
> Having said that, fixing SPARSE_PAGES seems like a better option.. My
> ideal outcome would be to have a working SPARSE_PAGES for all =
transports.
> That would allow GETXATTR and LISTXATTRS to just always specify a max
> size array of pages, giving it maximum flexibility to cache the =
received
> result no matter what, and avoiding allocations that are too large.

SPARSE_PAGES (at least for RDMA) always allocates the full set of
pages, because it has to set the receive buffer up before the request
is sent and it has no way to know the actual size of the reply.=20

There is really no savings when the transport does it, and it is less
reliable because the transport runs in a context where GFP_KERNEL
allocations are not allowed.


> For now, though, I'm happy with the v2 patch I sent in.
>=20
> - Frank

--
Chuck Lever