On Sun, 29 Sep 2024, Chuck Lever III wrote: > > > > On Sep 25, 2024, at 5:25 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > > > [I fixed Dan's address - sorry about that] > > > > On Thu, 26 Sep 2024, Chuck Lever wrote: > >> Hi Neil - > >> > >> On Wed, Sep 25, 2024 at 05:28:09PM +1000, NeilBrown wrote: > >>> > >>> If the rq_prog is not in the list of programs, then we use the last > >>> program in the list and subsequent tests on 'progp' being NULL are > >>> useless. > >> > >> That's the logic error, but what is the observed unexpected > >> behavior? > > > > The unexpected behaviour is that "if rq_prog is not in the list of > > programs, then we use the last program in the list". Isn't that a > > behaviour? Should I add that "we don't get the expected > > rpc_prog_unavail error? > > I'm thinking of something that would catch the eye of some > overworked support engineer who might not be deeply familiar > with NFS or RPC. > > Clients won't see RPC_PROG_UNAVAIL, but what would they see > instead? Under what conditions would they see this misbehavior? I had thought of this being a bug with no observable consequences in normal circumstance. But upon reflection I realise that if an nfs server was running on a kernel which didn't have NFS_ACL_SUPPORT then a ping of the nfs_acl service on port 2049 would incorrectly report success. Do clients do an RPC ping without checking with portmap first? Maybe, but only at mount time. So if you rebooted a server that had ACL support so that now it doesn't - the result might confuse the client. Maybe. I agree that it can be valuable decoding the likely user-visible effect of a bug. Not always easy. I'll take your suggested way-out of noting that the bug should never appear in a released kernel - only an -rc1 Thanks, NeilBrown > > It's no big deal, since this bug will never reach a stable > kernel. I was thinking out loud, and forgot to label the > remark as such. > > > -- > Chuck Lever > > >
