From: Simon Horman <horms@kernel.org>
To: James Chapman <jchapman@katalix.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, dsahern@kernel.org,
tparkin@katalix.com
Subject: Re: [PATCH net-next 4/9] l2tp: add tunnel/session get_next helpers
Date: Tue, 6 Aug 2024 15:37:25 +0100 [thread overview]
Message-ID: <20240806143725.GU2636630@kernel.org> (raw)
In-Reply-To: <4067ff5019040bf8ee2bd3c06db9e3d27ca39ded.1722856576.git.jchapman@katalix.com>
On Mon, Aug 05, 2024 at 12:35:28PM +0100, James Chapman wrote:
> l2tp management APIs and procfs/debugfs iterate over l2tp tunnel and
> session lists. Since these lists are now implemented using IDR, we can
> use IDR get_next APIs to iterate them. Add tunnel/session get_next
> functions to do so.
>
> The session get_next functions get the next session in a given tunnel
> and need to account for l2tpv2 and l2tpv3 differences:
>
> * l2tpv2 sessions are keyed by tunnel ID / session ID. Iteration for
> a given tunnel ID, TID, can therefore start with a key given by
> TID/0 and finish when the next entry's tunnel ID is not TID. This
> is possible only because the tunnel ID part of the key is the upper
> 16 bits and the session ID part the lower 16 bits; when idr_next
> increments the key value, it therefore finds the next sessions of
> the current tunnel before those of the next tunnel. Entries with
> session ID 0 are always skipped because they are used internally by
> pppol2tp.
>
> * l2tpv3 sessions are keyed by session ID. Iteration starts at the
> first IDR entry and skips entries where the tunnel does not
> match. Iteration must also consider session ID collisions and walk
> the list of colliding sessions (if any) for one which matches the
> supplied tunnel.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
> Signed-off-by: Tom Parkin <tparkin@katalix.com>
> ---
> net/l2tp/l2tp_core.c | 122 +++++++++++++++++++++++++++++++++++++++++++
> net/l2tp/l2tp_core.h | 3 ++
> 2 files changed, 125 insertions(+)
>
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index 0c661d499a6f..05e388490cd9 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -257,6 +257,28 @@ struct l2tp_tunnel *l2tp_tunnel_get_nth(const struct net *net, int nth)
> }
> EXPORT_SYMBOL_GPL(l2tp_tunnel_get_nth);
>
> +struct l2tp_tunnel *l2tp_tunnel_get_next(const struct net *net, unsigned long *key)
nit: Please consider limiting lines to 80 columns wide,
as is still preferred by Networking code in the general case.
Flagged by checkpatch.pl --max-line-length=80"
...
> @@ -347,6 +369,106 @@ struct l2tp_session *l2tp_session_get_nth(struct l2tp_tunnel *tunnel, int nth)
> }
> EXPORT_SYMBOL_GPL(l2tp_session_get_nth);
>
> +static struct l2tp_session *l2tp_v2_session_get_next(const struct net *net, u16 tid, unsigned long *key)
> +{
> + struct l2tp_net *pn = l2tp_pernet(net);
> + struct l2tp_session *session = NULL;
> +
> + /* Start searching within the range of the tid */
> + if (*key == 0)
> + *key = l2tp_v2_session_key(tid, 0);
> +
> + rcu_read_lock_bh();
> +again:
> + session = idr_get_next_ul(&pn->l2tp_v2_session_idr, key);
> + if (session) {
> + struct l2tp_tunnel *tunnel = READ_ONCE(session->tunnel);
> +
> + /* ignore sessions with id 0 as they are internal for pppol2tp */
> + if (session->session_id == 0) {
> + (*key)++;
> + goto again;
> + }
> +
> + if (tunnel && tunnel->tunnel_id == tid &&
Here it is assumed that tunnel may be NULL.
> + refcount_inc_not_zero(&session->ref_count)) {
> + rcu_read_unlock_bh();
> + return session;
> + }
> +
> + (*key)++;
> + if (tunnel->tunnel_id == tid)
But here tunnel is dereference unconditionally.
Is that safe?
Flagged by Smatch.
> + goto again;
> + }
> + rcu_read_unlock_bh();
> +
> + return NULL;
> +}
...
next prev parent reply other threads:[~2024-08-06 14:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 11:35 [PATCH net-next 0/9] l2tp: misc improvements James Chapman
2024-08-05 11:35 ` [PATCH net-next 1/9] documentation/networking: update l2tp docs James Chapman
2024-08-05 11:35 ` [PATCH net-next 2/9] l2tp: move l2tp_ip and l2tp_ip6 data to pernet James Chapman
2024-08-05 11:35 ` [PATCH net-next 3/9] l2tp: fix handling of hash key collisions in l2tp_v3_session_get James Chapman
2024-08-05 11:35 ` [PATCH net-next 4/9] l2tp: add tunnel/session get_next helpers James Chapman
2024-08-06 14:37 ` Simon Horman [this message]
2024-08-11 13:38 ` Dan Carpenter
2024-08-05 11:35 ` [PATCH net-next 5/9] l2tp: use get_next APIs for management requests and procfs/debugfs James Chapman
2024-08-05 11:35 ` [PATCH net-next 6/9] l2tp: improve tunnel/session refcount helpers James Chapman
2024-08-05 11:35 ` [PATCH net-next 7/9] l2tp: l2tp_eth: use per-cpu counters from dev->tstats James Chapman
2024-08-05 11:35 ` [PATCH net-next 8/9] l2tp: fix lockdep splat James Chapman
2024-08-05 11:35 ` [PATCH net-next 9/9] l2tp: flush workqueue before draining it James Chapman
2024-08-06 14:40 ` [PATCH net-next 0/9] l2tp: misc improvements Simon Horman
2024-08-06 15:53 ` James Chapman
2024-08-09 8:19 ` Simon Horman
-- strict thread matches above, loose matches on Subject: below --
2024-08-11 6:40 [PATCH net-next 4/9] l2tp: add tunnel/session get_next helpers kernel test robot
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=20240806143725.GU2636630@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=jchapman@katalix.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tparkin@katalix.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.