Re: [PATCH v2] netlabel: fix RCU annotation for IPv4 options on socket creation

[Paul Moore <paul@paul-moore.com>]

On Mon, Apr 29, 2024 at 6:10 AM Davide Caratti <dcaratti@redhat.com> wrote:
> On Thu, Apr 25, 2024 at 05:01:36PM -0400, Paul Moore wrote:
> > On Apr 24, 2024 Davide Caratti <dcaratti@redhat.com> wrote:

...

> > > @@ -1876,18 +1878,15 @@ int cipso_v4_sock_setattr(struct sock *sk,
> > >
> > >     sk_inet = inet_sk(sk);
> > >
> > > -   old = rcu_dereference_protected(sk_inet->inet_opt,
> > > -                                   lockdep_sock_is_held(sk));
> > > +   old = rcu_replace_pointer(sk_inet->inet_opt, opt, slock_held);
> > >     if (inet_test_bit(IS_ICSK, sk)) {
> > >             sk_conn = inet_csk(sk);
> > >             if (old)
> > >                     sk_conn->icsk_ext_hdr_len -= old->opt.optlen;
> > > -           sk_conn->icsk_ext_hdr_len += opt->opt.optlen;
> > > +           sk_conn->icsk_ext_hdr_len += opt_len;
> > >             sk_conn->icsk_sync_mss(sk, sk_conn->icsk_pmtu_cookie);
> > >     }
> > > -   rcu_assign_pointer(sk_inet->inet_opt, opt);
> > > -   if (old)
> > > -           kfree_rcu(old, rcu);
> > > +   kfree_rcu(old, rcu);
> >
> > Thanks for sticking with this and posting a v2.
> >
> > These changes look okay to me, but considering the 'Fixes:' tag and the
> > RCU splat it is reasonable to expect that this is going to be backported
> > to the various stable trees.  With that in mind, I think we should try
> > to keep the immediate fix as simple as possible, saving the other
> > changes for a separate patch.  This means sticking with
> > rcu_dereference_protected() and omitting the opt_len optimization; both
> > can be done in a second patch without the 'Fixes:' marking.
> >
> > Unless I missing something and those changes are somehow part of the
> > fix?
>
> just checked, rcu_replace_pointer() can be used also in the oldest LTS
> but I'm not sure if kfree_rcu(NULL, ...) is ok. I agree to keep
> rcu_dereference_protected(), and the useless NULL check - I will
> follow-up with another patch (targeting net-next), after this one is
> merged.

The issue isn't so much about if a particular function is available in
an older kernel, it is more about keeping the patch focused on a
single immediate purpose both to limit any unintended behaviors and
for the simple reason that smaller patches are almost always easier to
port by hand if needed.

-- 
paul-moore.com