linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bian Naimeng <biannm@cn.fujitsu.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Steve Dickson <SteveD@redhat.com>,
	Mi Jinlong <mijinlong@cn.fujitsu.com>,
	NFSv3 list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] mount: avoid po_destroy to modify errno what we really want
Date: Wed, 01 Dec 2010 09:01:45 +0800	[thread overview]
Message-ID: <4CF59E79.7070009@cn.fujitsu.com> (raw)
In-Reply-To: <D05BF4A3-1BD5-4FC3-8921-A9D9DC5D8634@oracle.com>



Chuck Lever wrote:
> Hi Bian
> 
> On Nov 29, 2010, at 9:05 PM, Bian Naimeng wrote:
> 
>>
>> Steve Dickson wrote:
>>> On 11/29/2010 09:45 AM, Chuck Lever wrote:
>>>> On Nov 25, 2010, at 5:07 AM, Mi Jinlong wrote:
>>>>
>>>>> We should return the errno that was set before po_destroy,
>>>>> rather than the errno that was set at po_destroy.
>>>>>
>>>>> Because the po_destroy function don't affect the return value,
>>>>> this patch just revert the saved errno after po_destroy.
>>>> The only library function used in po_destroy() is free(3).  
>>>> Does free(3) change the value of errno?
>>> Looking at the man page and taking a look a the 
>>> glibc code it appears the answer is no. free(3)
>>> does not set errno.
>>>
>>> Bian, what was the problem you were seeing that this
>>> patch fixed? 
>>>
>> Actually, there's no problem now. But this's not a good style, po_destroy
>> maybe change the errno later on such as adding a printf.
>> So if somebady want modify the po_destroy, he must be careful of it. :)
>>
>> And, i don't think it's a good idea that explicitly set errno, it maybe make
>> some trouble in the future. It's better returning error in nfs_do_mount_v3v2,
>> or save the error in a input parameter. :)
> 
> Perhaps it isn't good style, but I'd rather see all of stropts.c updated to pass errno as an explicit parameter than to have it changed piecemeal.  I agree that we run into trouble everywhere in mount with errno.
> 
> I think this particular patch is unnecessary until we have a need for it.  Basically it confuses a reviewer who sees that we've gone to the trouble here to save and restore errno, but nowhere else, and besides po_destroy() doesn't even alter errno.  Why are we bothering?
> 

  Well, it's okay to me.

Thanks
  Bian

>>> steved.
>>>
>>>>> Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
>>>>> Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
>>>>> ---
>>>>> utils/mount/stropts.c |    8 ++++++--
>>>>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>>>>> index 50a1a2a..d554877 100644
>>>>> --- a/utils/mount/stropts.c
>>>>> +++ b/utils/mount/stropts.c
>>>>> @@ -592,7 +592,7 @@ static int nfs_do_mount_v3v2(struct nfsmount_info *mi,
>>>>> 		struct sockaddr *sap, socklen_t salen)
>>>>> {
>>>>> 	struct mount_options *options = po_dup(mi->options);
>>>>> -	int result = 0;
>>>>> +	int result = 0, save = 0;
>>>>>
>>>>> 	if (!options) {
>>>>> 		errno = ENOMEM;
>>>>> @@ -637,7 +637,9 @@ static int nfs_do_mount_v3v2(struct nfsmount_info *mi,
>>>>> 	result = nfs_sys_mount(mi, options);
>>>>>
>>>>> out_fail:
>>>>> +	save = errno;
>>>>> 	po_destroy(options);
>>>>> +	errno = save;
>>>>> 	return result;
>>>>> }
>>>>>
>>>>> @@ -673,7 +675,7 @@ static int nfs_do_mount_v4(struct nfsmount_info *mi,
>>>>> 		struct sockaddr *sap, socklen_t salen)
>>>>> {
>>>>> 	struct mount_options *options = po_dup(mi->options);
>>>>> -	int result = 0;
>>>>> +	int result = 0, save = 0;
>>>>>
>>>>> 	if (!options) {
>>>>> 		errno = ENOMEM;
>>>>> @@ -724,7 +726,9 @@ static int nfs_do_mount_v4(struct nfsmount_info *mi,
>>>>> 	result = nfs_sys_mount(mi, options);
>>>>>
>>>>> out_fail:
>>>>> +	save = errno;
>>>>> 	po_destroy(options);
>>>>> +	errno = save;
>>>>> 	return result;
>>>>> }
>>>>>
>>>>> -- 
>>>>> 1.7.3.2
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>> -- 
>> Regards
>> Bian Naimeng
>>
> 

-- 
Regards
Bian Naimeng


      reply	other threads:[~2010-12-01  1:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 10:07 [PATCH] mount: avoid po_destroy to modify errno what we really want Mi Jinlong
2010-11-29 14:45 ` Chuck Lever
2010-11-29 15:20   ` Steve Dickson
2010-11-30  2:05     ` Bian Naimeng
2010-11-30 15:11       ` Chuck Lever
2010-12-01  1:01         ` Bian Naimeng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF59E79.7070009@cn.fujitsu.com \
    --to=biannm@cn.fujitsu.com \
    --cc=SteveD@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mijinlong@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).