From: Jakub Kicinski <kuba@kernel.org>
To: Maxim Mikityanskiy <maximmi@nvidia.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
Tariq Toukan <tariqt@nvidia.com>, Gal Pressman <gal@nvidia.com>,
"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"edumazet@google.com" <edumazet@google.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Boris Pismenny <borisp@nvidia.com>
Subject: Re: [PATCH net-next] net/tls: Use RCU API to access tls_ctx->netdev
Date: Tue, 2 Aug 2022 08:37:31 -0700 [thread overview]
Message-ID: <20220802083731.22291c3b@kernel.org> (raw)
In-Reply-To: <380eb27278e581012524cdc16f99e1872cee9be0.camel@nvidia.com>
On Tue, 2 Aug 2022 12:03:32 +0000 Maxim Mikityanskiy wrote:
> > For cases like this where we don't actually hold onto the object, just
> > take a peek at the address of it we can save a handful of LoC by using
> > rcu_access_pointer().
>
> The documentation of rcu_access_pointer says it shouldn't be used on
> the update side, because we lose lockdep protection:
>
> --cut--
>
> Although rcu_access_pointer() may also be used in cases
> where update-side locks prevent the value of the pointer from changing,
> you should instead use rcu_dereference_protected() for this use case.
I think what this is trying to say is to not use the
rcu_access_pointer() as a hack against lockdep:
lock(writer_lock);
/* no need for rcu_dereference() because we have writer lock */
ptr = rcu_access_pointer(obj->ptr);
ptr->something = 1;
unlock(writer_lock);
It's still perfectly fine to use access_pointer as intended on
the write side, which is just checking the value of the pointer,
not deferencing it:
lock(writer_lock);
if (rcu_access_pointer(obj->ptr) == target)
so_something(obj);
unlock(writer_lock);
next prev parent reply other threads:[~2022-08-02 15:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 8:00 [PATCH net-next] net/tls: Use RCU API to access tls_ctx->netdev Maxim Mikityanskiy
2022-08-01 19:42 ` Jakub Kicinski
2022-08-02 12:03 ` Maxim Mikityanskiy
2022-08-02 15:37 ` Jakub Kicinski [this message]
2022-08-03 9:33 ` Maxim Mikityanskiy
2022-08-03 14:49 ` Jakub Kicinski
2022-08-03 16:34 ` Paul E. McKenney
2022-08-04 8:08 ` Maxim Mikityanskiy
2022-08-04 16:18 ` Jakub Kicinski
2022-08-05 10:59 ` Maxim Mikityanskiy
2022-08-04 18:40 ` Paul E. McKenney
2022-08-05 10:59 ` Maxim Mikityanskiy
2022-08-01 19:44 ` Jakub Kicinski
2022-08-02 12:07 ` Maxim Mikityanskiy
2022-08-02 15:38 ` Jakub Kicinski
2022-08-02 16:26 ` 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=20220802083731.22291c3b@kernel.org \
--to=kuba@kernel.org \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=john.fastabend@gmail.com \
--cc=maximmi@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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.