Re: [PATCH 1/2] mount.nfs: silently fails with bad version arguments

[Steve Dickson <SteveD@redhat.com>]

On 06/02/2010 05:34 PM, Chuck Lever wrote:
> On 06/ 2/10 09:41 AM, Steve Dickson wrote:
>> mount.nfs should not only fail when an invalid protocol
>> option is used (as it does), it should also print a
>> diagnostic identifying the problem.
>>
>> Signed-off-by: Steve Dickson<steved@redhat.com>
>> ---
>>   utils/mount/network.c |    4 ++++
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/utils/mount/network.c b/utils/mount/network.c
>> index c541257..de1014d 100644
>> --- a/utils/mount/network.c
>> +++ b/utils/mount/network.c
>> @@ -1254,6 +1254,8 @@ nfs_nfs_version(struct mount_options *options,
>> unsigned long *version)
>>               nfs_error(_("%s: option parsing error\n"),
>>                       progname);
> 
> Watch out for case fall-through.  You need to add:
> 
>             return 0;
> 
> here.
Ah I didn't see that... good catch... 
> 
>>           case PO_BAD_VALUE:
>> +            nfs_error(_("%s: invalid value for 'vers=' option"),
>> +                    progname);
>>               return 0;
>>           }
>>       case 4: /* nfsvers */
>> @@ -1268,6 +1270,8 @@ nfs_nfs_version(struct mount_options *options,
>> unsigned long *version)
>>               nfs_error(_("%s: option parsing error\n"),
>>                       progname);
> 
> Case fall-through here as well.
> 
>>           case PO_BAD_VALUE:
>> +            nfs_error(_("%s: invalid value for 'nfsvers=' option"),
>> +                    progname);
> 
> Why wouldn't you also print a diagnostic if a numeric value was used,
> but the value was out of range?
It did not appear there was any guarantee that &tmp would have been filled
with anything useful, especially with something like nfsvers=v3 is given.

> 
> And, what about similar cases in nfs_nfs_port(), nfs_nfs_program(),
> nfs_mount_program(), nfs_mount_version(), and nfs_mount_port() ?
I was just looking at the version and protocol options and I really
didn't want to make things too verbose. Meaning we don't need to be printing
two or three messages for one error... 

But I do see the need of going back and taking a good hard look
at all the diagnostics that do (and do not) come out of the mount
command in error conditions... since it appears the diagnostics 
messages are a bit light at times..

steved.