Re: [PATCH net,v5,2/2] net/smc: modify smc_sock structure

[Jeongjun Park <aha310510@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2231 bytes --]

Paolo Abeni wrote:
>
>
>
> On 8/15/24 06:39, Jeongjun Park wrote:
> > Since inet_sk(sk)->pinet6 and smc_sk(sk)->clcsock practically
> > point to the same address, when smc_create_clcsk() stores the newly
> > created clcsock in smc_sk(sk)->clcsock, inet_sk(sk)->pinet6 is corrupted
> > into clcsock. This causes NULL pointer dereference and various other
> > memory corruptions.
> >
> > To solve this, we need to modify the smc_sock structure.
> >
> > Fixes: ac7138746e14 ("smc: establish new socket family")
> > Signed-off-by: Jeongjun Park <aha310510@gmail.com>
> > ---
> >   net/smc/smc.h | 5 ++++-
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/smc/smc.h b/net/smc/smc.h
> > index 34b781e463c4..0d67a02a6ab1 100644
> > --- a/net/smc/smc.h
> > +++ b/net/smc/smc.h
> > @@ -283,7 +283,10 @@ struct smc_connection {
> >   };
> >   
> >   struct smc_sock {                           /* smc sock container */
> > -     struct sock             sk;
> > +     union {
> > +             struct sock             sk;
> > +             struct inet_sock        inet;
> > +     };
> >       struct socket           *clcsock;       /* internal tcp socket */
> >       void                    (*clcsk_state_change)(struct sock *sk);
> >                                               /* original stat_change fct. */
>
> As per the running discussion here:
>
> https://lore.kernel.org/all/5ad4de6f-48d4-4d1b-b062-e1cd2e8b3600@linux.ibm.com/#t
>
> you should include at least a add a comment to the union, describing
> which one is used in which case.

Oh, I forgot this. It's a simple task, so I'll add the comment and send 
you a new patch right away.

>
> My personal preference would be directly replacing 'struct sk' with
> 'struct inet_sock inet;' and adjust all the smc->sk access accordingly,
> likely via a new helper.
>
> I understand that would be much more invasive, but would align with
> other AF.

I agree with this opinion and have suggested it to others, but some people
disagree, so I think it would be better to put this on hold for the time 
being.

Regards,
Jeongjun Park

>
> Thanks,
>
> Paolo
>