From: Marcelo Ricardo Leitner <marcelo.leitner@gmail•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Xin Long <lucien.xin@gmail•com>,
network dev <netdev@vger•kernel.org>,
linux-sctp@vger•kernel.org, Vlad Yasevich <vyasevich@gmail•com>,
daniel@iogearbox•net, davem@davemloft•net
Subject: Re: [PATCH net 2/3] sctp: hold transport before we access t->asoc in sctp proc
Date: Thu, 21 Jan 2016 17:37:10 -0200 [thread overview]
Message-ID: <20160121193709.GG3452@mrl.redhat.com> (raw)
In-Reply-To: <1453404456.1223.378.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Jan 21, 2016 at 11:27:36AM -0800, Eric Dumazet wrote:
> On Fri, 2016-01-22 at 01:49 +0800, Xin Long wrote:
> > Previously, before rhashtable, /proc assoc listing was done by
> > read-locking the entire hash entry and dumping all assocs at once, so we
> > were sure that the assoc wasn't freed because it wouldn't be possible to
> > remove it from the hash meanwhile.
> >
> > Now we use rhashtable to list transports, and dump entries one by one.
> > That is, now we have to check if the assoc is still a good one, as the
> > transport we got may be being freed.
> >
> > Signed-off-by: Xin Long <lucien.xin@gmail•com>
> > ---
> > net/sctp/proc.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> > index 684c5b3..c74a810 100644
> > --- a/net/sctp/proc.c
> > +++ b/net/sctp/proc.c
> > @@ -380,6 +380,8 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
> > }
> >
> > transport = (struct sctp_transport *)v;
>
> What protects you from this structure already being freed ?
rcu, rhashtable_walk_start() at sctp_assocs_seq_start() starts an
(implicit from this POV) rcu_read_lock() for us which is unlocked only
when the walking is terminated, thus covering this _show.
> > + if (!sctp_transport_hold(transport))
> > + return 0;
>
> If this is rcu, then you do not need to increment the refcount, and
> decrement it later.
It's an implicit hold on sctp asoc.
This code is using contents from asoc pointer, which is not proctected
by rcu. As transport has a hold on the asoc, it's enough to just hold
the transport and not the asoc too, as we had to do in the previous
patch.
Marcelo
next prev parent reply other threads:[~2016-01-21 19:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 17:49 [PATCH net 0/3] fix the transport dead race check by using atomic_add_unless on refcnt Xin Long
2016-01-21 17:49 ` [PATCH net 1/3] sctp: " Xin Long
2016-01-21 17:53 ` Marcelo Ricardo Leitner
2016-01-22 16:50 ` Vlad Yasevich
2016-01-22 17:18 ` Marcelo Ricardo Leitner
2016-01-22 18:54 ` Vlad Yasevich
2016-01-25 18:44 ` David Miller
2016-01-21 17:49 ` [PATCH net 2/3] sctp: hold transport before we access t->asoc in sctp proc Xin Long
2016-01-21 17:53 ` Marcelo Ricardo Leitner
2016-01-21 19:27 ` Eric Dumazet
2016-01-21 19:37 ` Marcelo Ricardo Leitner [this message]
2016-01-21 19:57 ` Eric Dumazet
2016-01-21 20:08 ` Marcelo Ricardo Leitner
2016-01-21 17:49 ` [PATCH net 3/3] sctp: remove the dead field of sctp_transport Xin Long
2016-01-21 17:54 ` Marcelo Ricardo Leitner
2016-01-21 17:58 ` [PATCH net 0/3] fix the transport dead race check by using atomic_add_unless on refcnt Xin Long
2016-01-28 23:59 ` David Miller
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=20160121193709.GG3452@mrl.redhat.com \
--to=marcelo.leitner@gmail$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=linux-sctp@vger$(echo .)kernel.org \
--cc=lucien.xin@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=vyasevich@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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