> On Jul 21, 2022, at 10:03 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > Following up, using NFS loopback with a 5GB scratch device on a Google > Compute Engine VM, generic/476 passes using a 4.14 LTS, 4.19 LTS, and > 5.4 LTS kernel. So this looks like it's a regression which is in 5.10 > LTS and newer kernels, and so instead of patching it out of the test, > I think the right thing to do is to add it to a kernel > version-specific exclude file and then filing a bug with the NFS > folks. Quite apart from the question of whether to exclude that test rather than troubleshoot, I would like to state that testing NFS in loopback, while possibly convenient for Q/A, is pretty fraught. - Loopback means the client and server are part of the direct reclaim path on the same system, which makes livelock or deadlock much more likely. Given that these test systems are typically small, that pushes the stack even further into this territory. - Loopback means there's often no way to know which part of the stack (client or server) is the problem. Any NFS test needs to have no less than two test systems, otherwise what you're really testing is how the system handles memory exhaustion. An important test, no doubt, but it doesn't paint a full picture. -- Chuck Lever
