git: aa8c1f8d84d2 - main - nfs client: block vnode_pager_setsize() calls from nfscl_loadattrcache in nfs_write

[Rick Macklem]

Yasuhiro Kimura wrote:
>> The branch main has been updated by kib:
>>
>> URL: https://cgit.FreeBSD.org/src/commit/?id=aa8c1f8d84d2638a354e71f9593e978d00878243
>>
>> commit aa8c1f8d84d2638a354e71f9593e978d00878243
>> Author:     Konstantin Belousov <kib at FreeBSD.org>
>> AuthorDate: 2021-01-22 21:47:06 +0000
>> Commit:     Konstantin Belousov <kib at FreeBSD.org>
>> CommitDate: 2021-01-23 15:24:32 +0000
>>
>>     nfs client: block vnode_pager_setsize() calls from nfscl_loadattrcache in nfs_write
>>
>>     Otherwise writing thread might wait on sbusy state of the pages which were
>>     busied by itself, similarly to nfs_read().  But also we need to clear
>>     NVNSETSZKSIP flag possibly set by ncl_pager_setsize(), to not undo
>>     extension done by write.
>>
>>     Reported by:    bdrewery
>>     Reviewed by:    rmacklem
>>     Tested by:      pho
>>     MFC after:      1 week
>>     Sponsored by:   The FreeBSD Foundation
>>     Differential Revision:  https://reviews.freebsd.org/D28306
>
>On my 14-CURRENT amd64 environment this commit causes the problem that
>garbage date are written to file mounted with NFS.
>
>I use NFSv4 and autofs to mount home directory on my 12.2-RELEASE
>amd64 server. And I use zsh as login shell and configure it so command
>history is written to history file each time any command is executed.
>
>After update to 519b64e27fddf10c0b7f6a615edbad730b8c6c45, I see
>following error message if I try to execute any command.
>
>----------------------------------------------------------------------
>yasu at rolling-vm-freebsd1[1009]% ls
>zsh: corrupt history file /home/yasu/.zhistory
>yasu at rolling-vm-freebsd1[1010]%
>----------------------------------------------------------------------
>
>I logged in the server and check the content of history file. Then
>some garbase data are written to history file.
>
>I confirmed the problem disappears by reverting this commit.
I was also able to reproduce a problem (a truncated file) during
testing.
For my case, setting the size to n_size instead of va_size fixed
the problem I reproduced, but I do not know if this achieves
what Kostik intended.

My variant of the patch is in D28318.
Maybe you could test this, although you might want to wait
until Kostik comments on this variant of the patch.

rick

---
Yasuhiro Kimura