netdev - Re: [PATCH net-next 09/10] mptcp: preserve const qualifier in mptcp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+xOmDmD2=1EQF0U5F5+GQb_HfAWmQD=1FP+6L=qK-E5w@mail.gmail.com>
Date:   Fri, 17 Mar 2023 10:47:08 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Matthieu Baerts <matthieu.baerts@...sares.net>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        David Ahern <dsahern@...nel.org>,
        Simon Horman <simon.horman@...igine.com>,
        Willem de Bruijn <willemb@...gle.com>,
        eric.dumazet@...il.com, MPTCP Upstream <mptcp@...ts.linux.dev>
Subject: Re: [PATCH net-next 09/10] mptcp: preserve const qualifier in mptcp_sk()

On Fri, Mar 17, 2023 at 10:32 AM Matthieu Baerts
<matthieu.baerts@...sares.net> wrote:
>
> Hi Eric,
>
> On 17/03/2023 16:55, Eric Dumazet wrote:
> > We can change mptcp_sk() to propagate its argument const qualifier,
> > thanks to container_of_const().
> >
> > We need to change few things to avoid build errors:
> >
> > mptcp_set_datafin_timeout() and mptcp_rtx_head() have to accept
> > non-const sk pointers.
> >
> > @msk local variable in mptcp_pending_tail() must be const.
> >
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > Cc: Matthieu Baerts <matthieu.baerts@...sares.net>
>
> Good idea!
>
> Thank you for this patch and for having Cced me.
>
> It looks good to me. I just have one question below if you don't mind.
>
> (...)
>
> > diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> > index 61fd8eabfca2028680e04558b4baca9f48bbaaaa..4ed8ffffb1ca473179217e640a23bc268742628d 100644
> > --- a/net/mptcp/protocol.h
> > +++ b/net/mptcp/protocol.h
>
> (...)
>
> > @@ -381,7 +378,7 @@ static inline struct mptcp_data_frag *mptcp_pending_tail(const struct sock *sk)
> >       return list_last_entry(&msk->rtx_queue, struct mptcp_data_frag, list);
> >  }
> >
> > -static inline struct mptcp_data_frag *mptcp_rtx_head(const struct sock *sk)
> > +static inline struct mptcp_data_frag *mptcp_rtx_head(struct sock *sk)
>
> It was not clear to me why you had to remove the "const" qualifier here
> and not just have to add one when assigning the msk just below. But then
> I looked at what was behind the list_first_entry_or_null() macro used in
> this function and understood what was the issue.
>
>
> My naive approach would be to modify this macro but I guess we don't
> want to go down that road, right?
>
> -------------------- 8< --------------------
> diff --git a/include/linux/list.h b/include/linux/list.h
> index f10344dbad4d..cd770766f451 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -550,7 +550,7 @@ static inline void list_splice_tail_init(struct
> list_head *list,
>   * Note that if the list is empty, it returns NULL.
>   */
>  #define list_first_entry_or_null(ptr, type, member) ({ \
> -       struct list_head *head__ = (ptr); \
> +       const struct list_head *head__ = (ptr); \
>         struct list_head *pos__ = READ_ONCE(head__->next); \
>         pos__ != head__ ? list_entry(pos__, type, member) : NULL; \
>  })
> -------------------- 8< --------------------

This could work, but it is a bit awkward.

mptcp_rtx_head() is used  in a context where we are changing the
socket, not during a readonly lookup ?

>
>
> It looks safe to me to do that but I would not trust myself on a Friday
> evening :)
> (I'm sure I'm missing something, I'm sorry if it is completely wrong)
>
> Anyway if we cannot modify list_first_entry_or_null() one way or
> another, I'm fine with your modification!
>
> Reviewed-by: Matthieu Baerts <matthieu.baerts@...sares.net>
>

Thanks !