All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: linux-sctp@vger.kernel.org
Subject: Re: NULL primary_path
Date: Thu, 07 Mar 2013 15:44:14 +0000	[thread overview]
Message-ID: <5138B5CE.2080404@gmail.com> (raw)
In-Reply-To: <CAGugRbVkLt2AzKkxX3SzJhjDfyPJpviD64_Y5-hgtqxSTwzQiA@mail.gmail.com>

On 03/07/2013 10:29 AM, Neil Horman wrote:
> On Thu, Mar 07, 2013 at 03:52:35PM +0100, Cristian Constantin wrote:
>> On Wed, Mar 06, 2013 at 08:53:02PM -0500, Vlad Yasevich wrote:
>>> On 03/06/2013 05:57 PM, Karl Heiss wrote:
>>>> I am getting kernel panics due to a NULL dereference in
>>>> sctp_getsockopt_sctp_status() when calling getsockopt() with
>>>> SCTP_STATUS immediately after establishing a connection.  This occurs
>>>> when transport = asoc->peer.primary_path; is NULL and transport is
>>>> later dereferenced.  Is there any way that an association would be
>>>> present but have no primary_path?
>>>
>>> No, that shouldn't happen.  The very first transport that is added
>>> to the association is assigned to the primary_path.  Primary_path can
>>> never be null since the association must have at least 1 transport and
>>> that 1 transport will always be primary.
>>
>> cristian: hi!
>>
>> but, vlad, at least in 2.6.30.2 (which I have on my hdd with
>> the "tags" already computed), sctp_getsockopt_primary_addr() is a little
>> bit more conservative and does:
>>
>>      ...
>>      asoc = sctp_id2assoc(sk, prim.ssp_assoc_id);
>>      if (!asoc)
>>          return -EINVAL;
>>
>>      if (!asoc->peer.primary_path)
>>          return -ENOTCONN;
>>      ...
>>
>> any idea if is there any big difference btw. the two getsockopt()s? behind
>> them, everything is assumed to be asynch., right? (in the sense that
>> the assoc. can come and go at any time)
>>
> All paths that touch primary_path hold the associated socket lock for the socket
> that owns the transport path, so there shouldn't be any changing of the primary
> path while accessing it here, at least not in the upstream kernel.

Right.  I don't this that condition is possible.  Association can't live 
without at least 1 transport and that 1 transport will always be primary.

-vlad

>
> Regards
> Neil
>
>> thanks!
>> bye now!
>> cristian
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


  parent reply	other threads:[~2013-03-07 15:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 22:57 NULL primary_path Karl Heiss
2013-03-07  1:53 ` Vlad Yasevich
2013-03-07 14:52 ` Cristian Constantin
2013-03-07 15:29 ` Neil Horman
2013-03-07 15:44 ` Vlad Yasevich [this message]
2013-03-07 15:48 ` Vlad Yasevich
2013-03-07 17:06 ` Karl Heiss
2013-03-07 17:17 ` Vlad Yasevich
2013-03-07 21:51 ` Karl Heiss
2013-03-07 22:08 ` Vlad Yasevich
2013-03-07 23:09 ` Vlad Yasevich
2013-03-08 13:52 ` Karl Heiss
2013-03-08 14:31 ` Karl Heiss
2013-03-08 14:35 ` Neil Horman
2013-03-08 15:31 ` Vlad Yasevich
2013-03-08 15:37 ` Karl Heiss
2013-03-08 16:42 ` Vlad Yasevich
2013-03-08 17:06 ` Karl Heiss
2013-03-09 20:19 ` Karl Heiss
2013-03-11 21:59 ` Vlad Yasevich
2013-03-11 22:44 ` Karl Heiss
2013-03-11 23:10 ` Vlad Yasevich
2013-03-12  1:05 ` Karl Heiss
2013-03-12 16:18 ` Karl Heiss
2013-03-12 17:23 ` Vlad Yasevich

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=5138B5CE.2080404@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=linux-sctp@vger.kernel.org \
    /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.