nfs_mount ignores FSINFO RPC failures

[earlchew]

During nfs_mount(), an FSINFO RPC is used to determine the characteristics of the remote file system. The results of the RPC are used without first checking if the RPC succeeded.

[earlchew]

This one was reproducible with effort, but took a fair amount of time to pin down.

[sahlberg]

Merged.

How did you reproduce this? I think the decode buffer is guaranteed to be zeroed out when the original request pdu is allocated. Thus read max and write max should read out as zero and then you other change to check for the min should catch this?

[earlchew]

I used a live reproduction in which I have a unit test written for an application that performs a mount, a small amount of IO, and some directory operations. The unit test is mostly intended to test application behaviour, but in this case is useful for verifying operation (in a limited scenario) of libnfs. In this case, libnfs is used to connect to a storage cluster, and to obtain test scenario coverage, the test also involves failing the connection to the storage cluster network. Carnage from the latter triggers this failure.

Generally speaking, my experience has been that relying on actual faults to exercise infrequently used code paths is not very effective. It requires a lot of effort to get a good amount of coverage. For other projects recently, I prefer to use direct software fault simulation in order to force threads of execution to take under-used code paths. Once configured, I have found that it is possible to get good coverage for little ongoing effort.

I think the decode buffer is guaranteed to be zeroed out when the original request pdu is allocated. Thus read max and write max should read out as zero and then you other change to check for the min should catch this?

You are right. Without those changes, this defect might have manifested as a division by zero, but instead shows its hand as the application allocating all the the memory available.