Oh. I tested V1.... Let me check v2 as well. Tigran. ----- Original Message ----- > From: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx> > To: "Frank van der Linden" <fllinden@xxxxxxxxxx> > Cc: "Olga Kornievskaia" <aglo@xxxxxxxxx>, "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>, "trondmy" <trondmy@xxxxxxxxxxxxxxx> > Sent: Thursday, 3 December, 2020 17:36:07 > Subject: Re: Kernel OPS when using xattr > The patch from Frank works. > ( you can attribute with Tested-by if needed) > > Tigran. > > ----- Original Message ----- >> From: "Frank van der Linden" <fllinden@xxxxxxxxxx> >> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx> >> Cc: "Olga Kornievskaia" <aglo@xxxxxxxxx>, "linux-nfs" >> <linux-nfs@xxxxxxxxxxxxxxx>, "trondmy" <trondmy@xxxxxxxxxxxxxxx> >> Sent: Thursday, 3 December, 2020 17:18:58 >> Subject: Re: Kernel OPS when using xattr > >> On Thu, Dec 03, 2020 at 04:43:12PM +0100, Mkrtchyan, Tigran wrote: >>> >>> Hi Olga, >>> >>> Franks patches are not applied. I will check with Trond's patch and >>> then will try those as well. >>> >>> Regards, >>> Tigran. >> >> Since my change no longer uses SPARSE_PAGES, it'll probably avoid the >> oops, so give it a try. >> >> 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. >> >> For now, though, I'm happy with the v2 patch I sent in. >> > > - Frank
