Re: [PATCH net-next v7 1/7] net: introduce rstreason to detect why the RST is sent

[Simon Horman <horms@kernel.org>]

On Tue, Apr 23, 2024 at 10:17:31AM +0800, Jason Xing wrote:
> On Tue, Apr 23, 2024 at 10:14 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Tue, Apr 23, 2024 at 2:28 AM Simon Horman <horms@kernel.org> wrote:
> > >
> > > On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
> > >
> > > ...
> > >
> > > > diff --git a/include/net/rstreason.h b/include/net/rstreason.h
> > >
> > > ...
> > >
> > > > +/**
> > > > + * There are three parts in order:
> > > > + * 1) reset reason in MPTCP: only for MPTCP use
> > > > + * 2) skb drop reason: relying on drop reasons for such as passive reset
> > > > + * 3) independent reset reason: such as active reset reasons
> > > > + */
> > >
> > > Hi Jason,
> > >
> > > A minor nit from my side.
> > >
> > > '/**' denotes the beginning of a Kernel doc,
> > > but other than that, this comment is not a Kernel doc.
> > >
> > > FWIIW, I would suggest providing a proper Kernel doc for enum sk_rst_reason.
> > > But another option would be to simply make this a normal comment,
> > > starting with "/* There are"
> >
> > Thanks Simon. I'm trying to use the kdoc way to make it right :)
> >
> > How about this one:
> > /**
> >  * enum sk_rst_reason - the reasons of socket reset
> >  *
> >  * The reason of skb drop, which is used in DCCP/TCP/MPTCP protocols.
> 
> s/skb drop/sk reset/
> 
> Sorry, I cannot withdraw my previous email in time.
> 
> >  *
> >  * There are three parts in order:
> >  * 1) skb drop reasons: relying on drop reasons for such as passive
> > reset
> >  * 2) independent reset reasons: such as active reset reasons
> >  * 3) reset reasons in MPTCP: only for MPTCP use
> >  */
> > ?
> >
> > I chose to mimic what enum skb_drop_reason does in the
> > include/net/dropreason-core.h file.
> >
> > > +enum sk_rst_reason {
> > > +       /**
> > > +        * Copy from include/uapi/linux/mptcp.h.
> > > +        * These reset fields will not be changed since they adhere to
> > > +        * RFC 8684. So do not touch them. I'm going to list each definition
> > > +        * of them respectively.
> > > +        */
> >
> > Thanks to you, I found another similar point where I smell something
> > wrong as in the above code. I'm going to replace '/**' with '/*' since
> > it's only a comment, not a kdoc.

Likewise, thanks Jason.

I haven't had time to look at v8 properly,
but I see that kernel-doc is happy with the changed
you have made there as discussed above.