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.
next prev parent reply other threads:[~2013-06-07 11:39 UTC|newest]
Thread overview: 12+ 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 ` [PATCH net-next 1/3] net: sctp: let sctp_destroy_sock destroy related members Daniel Borkmann
2013-06-07 10:54 ` Neil Horman
2013-06-07 11:36 ` Daniel Borkmann
2013-06-09 0:20 ` Neil Horman
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 11:00 ` Neil Horman
2013-06-07 11:38 ` Daniel Borkmann [this message]
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 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 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).