From: Jakub Kicinski <kuba@kernel.org>
To: Donald Hunter <donald.hunter@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, jiri@resnulli.us, sdf@google.com,
nicolas.dichtel@6wind.com
Subject: Re: [PATCH net-next 00/15] tools: ynl: stop using libmnl
Date: Tue, 27 Feb 2024 07:56:05 -0800 [thread overview]
Message-ID: <20240227075605.18ec70b8@kernel.org> (raw)
In-Reply-To: <m2ttlumbax.fsf@gmail.com>
On Tue, 27 Feb 2024 10:49:42 +0000 Donald Hunter wrote:
> > +static inline bool
> > +__ynl_attr_put_overflow(struct nlmsghdr *nlh, size_t size)
> > +{
> > + bool o;
> > +
> > + /* We stash buffer length on nlmsg_pid. */
> > + o = nlh->nlmsg_len + NLA_HDRLEN + NLMSG_ALIGN(size) > nlh->nlmsg_pid;
>
> The comment confused me here. How about "We compare against stashed buffer
> length in nlmsg_pid".
The comment should give context, rather than describe the code so how
about:
/* ynl_msg_start() stashed buffer length in nlmsg_pid. */
> > + if (o)
> > + nlh->nlmsg_pid = YNL_MSG_OVERFLOW;
>
> It took me a moment to realise that this behaves like a very short
> buffer length for subsequent calls to __ynl_attr_put_overflow(). Is it
> worth extending the comment in ynl_msg_start() to say "buffer length or
> overflow status"?
Added:
/* YNL_MSG_OVERFLOW is < NLMSG_HDRLEN, all subsequent checks
* are guaranteed to fail.
*/
SG?
> > + return o;
> > +}
> > +
> > static inline struct nlattr *
> > ynl_attr_nest_start(struct nlmsghdr *nlh, unsigned int attr_type)
> > {
> > struct nlattr *attr;
> >
> > + if (__ynl_attr_put_overflow(nlh, 0))
> > + return ynl_nlmsg_end_addr(nlh) - NLA_HDRLEN;
>
> Is the idea here to return a struct nlattr * that is safe to use?
> Shouldn't we zero the values in the buffer first?
The only thing that the attr is used for is to call ynl_attr_nest_end().
so I think zero init won't make any difference.
next prev parent reply other threads:[~2024-02-27 15:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 23:55 [PATCH net-next 00/15] tools: ynl: stop using libmnl Jakub Kicinski
2024-02-22 23:56 ` [PATCH net-next 01/15] tools: ynl: give up on libmnl for auto-ints Jakub Kicinski
2024-02-23 13:51 ` Nicolas Dichtel
2024-02-23 14:35 ` Jakub Kicinski
2024-02-23 15:07 ` Nicolas Dichtel
2024-02-23 15:34 ` Donald Hunter
2024-02-22 23:56 ` [PATCH net-next 02/15] tools: ynl: create local attribute helpers Jakub Kicinski
2024-02-23 14:03 ` Nicolas Dichtel
2024-02-23 14:46 ` Jakub Kicinski
2024-02-23 15:09 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 03/15] tools: ynl: create local for_each helpers Jakub Kicinski
2024-02-23 15:16 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 04/15] tools: ynl: create local nlmsg access helpers Jakub Kicinski
2024-02-23 15:20 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 05/15] tools: ynl: create local ARRAY_SIZE() helper Jakub Kicinski
2024-02-23 15:21 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 06/15] tools: ynl: make yarg the first member of struct ynl_dump_state Jakub Kicinski
2024-02-23 15:23 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 07/15] tools: ynl-gen: remove unused parse code Jakub Kicinski
2024-02-23 15:24 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 08/15] tools: ynl: wrap recv() + mnl_cb_run2() into a single helper Jakub Kicinski
2024-02-23 15:33 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 09/15] tools: ynl: use ynl_sock_read_msgs() for ACK handling Jakub Kicinski
2024-02-23 15:35 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 10/15] tools: ynl: stop using mnl_cb_run2() Jakub Kicinski
2024-02-23 15:50 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 11/15] tools: ynl: switch away from mnl_cb_t Jakub Kicinski
2024-02-23 16:04 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 12/15] tools: ynl: switch away from MNL_CB_* Jakub Kicinski
2024-02-23 16:05 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 13/15] tools: ynl: stop using mnl socket helpers Jakub Kicinski
2024-02-23 16:14 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 14/15] tools: ynl: remove the libmnl dependency Jakub Kicinski
2024-02-23 16:14 ` Nicolas Dichtel
2024-02-22 23:56 ` [PATCH net-next 15/15] tools: ynl: use MSG_DONTWAIT for getting notifications Jakub Kicinski
2024-02-23 16:17 ` Nicolas Dichtel
2024-02-23 16:26 ` [PATCH net-next 00/15] tools: ynl: stop using libmnl Donald Hunter
2024-02-23 16:34 ` Jakub Kicinski
2024-02-26 9:04 ` Donald Hunter
2024-02-26 18:00 ` Jakub Kicinski
2024-02-27 10:49 ` Donald Hunter
2024-02-27 15:56 ` Jakub Kicinski [this message]
2024-02-27 16:29 ` Donald Hunter
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=20240227075605.18ec70b8@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=pabeni@redhat.com \
--cc=sdf@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).