Date: Tue, 14 Dec 2021 09:19:52 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: RFC: What to do about Allocate in the NFS server for FreeBSD13? Message-ID: <5b07d437-a81e-9151-b7a4-82c843ef266a@FreeBSD.org> In-Reply-To: <Ybd1NFXuRjM5W1zj@kib.kiev.ua> References: <YQXPR0101MB0968EEFD5AE3B86F1D2DF667DD749@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <Ybd1NFXuRjM5W1zj@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/13/21 8:30 AM, Konstantin Belousov wrote:
> On Mon, Dec 13, 2021 at 04:26:42PM +0000, Rick Macklem wrote:
>> Hi,
>>
>> There are two problems with Allocate in the NFSv4.2 server in FreeBSD13:
>> 1 - It uses the thread credentials instead of the ones for the RPC.
>> 2 - It does not ensure that file changes are committed to stable storage.
>> These problems are fixed by commit f0c9847a6c47 in main, which added
>> ioflag and cred arguments to VOP_ALLOCATE().
>>
>> I can think of 3 ways to fix Allocate in FreeBSD13:
>> 1 - Apply a *hackish* patch like this:
>> + savcred = p->td_ucred;
>> + td->td_ucred = cred;
>> do {
>> olen = len;
>> error = VOP_ALLOCATE(vp, &off, &len);
>> if (error == 0 && len > 0 && olen > len)
>> maybe_yield();
>> } while (error == 0 && len > 0 && olen > len);
>> + p->td_ucred = savcred;
>> if (error == 0 && len > 0)
>> error = NFSERR_IO;
>> + if (error == 0)
>> + error = VOP_FSYNC(vp, MNT_WAIT, p);
>> The worst part of it is temporarily setting td_ucred to cred.
>>
>> 2 - MFC'ng commit f0c9847a6c47. Normally changes to the
>> VOP/VFS are not MFC'd. However, in this case, it might be
>> ok to do so, since it is unlikely there is an out of source tree
>> file system with a custom VOP_ALLOCATE() method?
> I do not see much wrong with #2, this is what I would do myself.
I also think this is fine.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5b07d437-a81e-9151-b7a4-82c843ef266a>