[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <13D041DB-A26D-4EC1-A585-7DBA266CF18A@oracle.com>
Date: Tue, 15 Mar 2011 11:43:32 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: roel <roel.kluin@...il.com>, Neil Brown <neilb@...e.de>,
linux-nfs@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] SUNRPC: svc_register error overwritten in next iteration
On Mar 14, 2011, at 6:36 PM, J. Bruce Fields wrote:
> On Sat, Mar 12, 2011 at 02:27:35PM +0100, roel wrote:
>> The break is in the inner loop, the svc_register() error is overwritten
>> in the next iteration. Only the error in the last iteration is returned.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@...il.com>
>> ---
>> net/sunrpc/svc.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> Is this needed?
>>
>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>> index 08e05a8..5fd08c0 100644
>> --- a/net/sunrpc/svc.c
>> +++ b/net/sunrpc/svc.c
>> @@ -889,6 +889,8 @@ int svc_register(const struct svc_serv *serv, const int family,
>> if (error < 0)
>> break;
>
> May as well just "goto out" or "return error" here?
>
> But: aren't we missing some cleanup? If we succesfully register one
> program then fail at a second one, don't we need to unregister the
> first?
Right. I don't understand what is the intended effect here (of the original code): Best effort registration, or "all or none"?
> --b.
>
>> }
>> + if (error < 0)
>> + break;
>> }
>>
>> return error;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists