All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] net: sctp: sctp_association_init: hold refs in reverse order
Date: Fri, 07 Jun 2013 11:38:56 +0000	[thread overview]
Message-ID: <51B1C650.2000603@redhat.com> (raw)
In-Reply-To: <20130607110054.GB3249@hmsreliant.think-freely.org>

On 06/07/2013 01:00 PM, Neil Horman wrote:
> On Fri, Jun 07, 2013 at 10:35:05AM +0200, Daniel Borkmann wrote:
>> In case we need to bail out for whatever reason during assoc
>> init, we call sctp_endpoint_put() and then sock_put(), however,
>> we've hold both refs in reverse order, so first sctp_endpoint_hold()
>> and then sock_hold(). Reverse this, so that we have sock_hold()
>> with sctp_endpoint_hold() first and then in error case
>> sctp_endpoint_put() and then sock_put(). Actually shouldn't
>> matter much since we just increase an atomic, but that way, it's
>> more clean.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>>   net/sctp/associola.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
>> index 91cfd8f..04795fb 100644
>> --- a/net/sctp/associola.c
>> +++ b/net/sctp/associola.c
>> @@ -86,11 +86,10 @@ static struct sctp_association *sctp_association_init(struct sctp_association *a
>>
>>   	/* Discarding const is appropriate here.  */
>>   	asoc->ep = (struct sctp_endpoint *)ep;
>> -	sctp_endpoint_hold(asoc->ep);
>> -
>> -	/* Hold the sock.  */
>>   	asoc->base.sk = (struct sock *)sk;
>> +
>>   	sock_hold(asoc->base.sk);
>> +	sctp_endpoint_hold(asoc->ep);
>>
>>   	/* Initialize the common base substructure.  */
>>   	asoc->base.type = SCTP_EP_TYPE_ASSOCIATION;
>
> This looks good, but you may want to instead reverse the order in which we do
> the puts at fail_init, as other call sites that hold both endpoint socket do so
> in endpoint, sock order, and it would probably be nice to be consistent in that
> order.

Thanks, will do. When we have clarified the 1st patch, I'll simply respin the
entire patchset and send a v2.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <dborkman@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] net: sctp: sctp_association_init: hold refs in reverse order
Date: Fri, 07 Jun 2013 13:38:56 +0200	[thread overview]
Message-ID: <51B1C650.2000603@redhat.com> (raw)
In-Reply-To: <20130607110054.GB3249@hmsreliant.think-freely.org>

On 06/07/2013 01:00 PM, Neil Horman wrote:
> On Fri, Jun 07, 2013 at 10:35:05AM +0200, Daniel Borkmann wrote:
>> In case we need to bail out for whatever reason during assoc
>> init, we call sctp_endpoint_put() and then sock_put(), however,
>> we've hold both refs in reverse order, so first sctp_endpoint_hold()
>> and then sock_hold(). Reverse this, so that we have sock_hold()
>> with sctp_endpoint_hold() first and then in error case
>> sctp_endpoint_put() and then sock_put(). Actually shouldn't
>> matter much since we just increase an atomic, but that way, it's
>> more clean.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>>   net/sctp/associola.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
>> index 91cfd8f..04795fb 100644
>> --- a/net/sctp/associola.c
>> +++ b/net/sctp/associola.c
>> @@ -86,11 +86,10 @@ static struct sctp_association *sctp_association_init(struct sctp_association *a
>>
>>   	/* Discarding const is appropriate here.  */
>>   	asoc->ep = (struct sctp_endpoint *)ep;
>> -	sctp_endpoint_hold(asoc->ep);
>> -
>> -	/* Hold the sock.  */
>>   	asoc->base.sk = (struct sock *)sk;
>> +
>>   	sock_hold(asoc->base.sk);
>> +	sctp_endpoint_hold(asoc->ep);
>>
>>   	/* Initialize the common base substructure.  */
>>   	asoc->base.type = SCTP_EP_TYPE_ASSOCIATION;
>
> This looks good, but you may want to instead reverse the order in which we do
> the puts at fail_init, as other call sites that hold both endpoint socket do so
> in endpoint, sock order, and it would probably be nice to be consistent in that
> order.

Thanks, will do. When we have clarified the 1st patch, I'll simply respin the
entire patchset and send a v2.

  reply	other threads:[~2013-06-07 11:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-07  8:35 [PATCH net-next 0/3] Minor sctp cleanups Daniel Borkmann
2013-06-07  8:35 ` Daniel Borkmann
2013-06-07  8:35 ` [PATCH net-next 1/3] net: sctp: let sctp_destroy_sock destroy related members Daniel Borkmann
2013-06-07  8:35   ` Daniel Borkmann
2013-06-07 10:54   ` Neil Horman
2013-06-07 10:54     ` Neil Horman
2013-06-07 11:36     ` Daniel Borkmann
2013-06-07 11:36       ` Daniel Borkmann
2013-06-09  0:20       ` Neil Horman
2013-06-09  0:20         ` Neil Horman
2013-06-09  9:14         ` Daniel Borkmann
2013-06-09  9:14           ` Daniel Borkmann
2013-06-07  8:35 ` [PATCH net-next 2/3] net: sctp: sctp_association_init: hold refs in reverse order Daniel Borkmann
2013-06-07  8:35   ` Daniel Borkmann
2013-06-07 11:00   ` Neil Horman
2013-06-07 11:00     ` Neil Horman
2013-06-07 11:38     ` Daniel Borkmann [this message]
2013-06-07 11:38       ` Daniel Borkmann
2013-06-09  0:21       ` Neil Horman
2013-06-09  0:21         ` Neil Horman
2013-06-07  8:35 ` [PATCH net-next 3/3] net: sctp: minor: remove variable in sctp_init_sock Daniel Borkmann
2013-06-07  8:35   ` Daniel Borkmann
2013-06-07 11:04   ` Neil Horman
2013-06-07 11:04     ` Neil Horman

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=51B1C650.2000603@redhat.com \
    --to=dborkman@redhat.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.