From: Jakub Kicinski <kuba@kernel.org>
To: Gal Pressman <gal@nvidia.com>, espeer@gmail.com
Cc: David Ahern <dsahern@gmail.com>, netdev <netdev@vger.kernel.org>,
Andrew Gospodarek <andrew.gospodarek@broadcom.com>,
Michael Chan <michael.chan@broadcom.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [PATCH net-next 1/4] netlink: truncate overlength attribute list in nla_nest_end()
Date: Mon, 5 Jun 2023 11:58:49 -0700 [thread overview]
Message-ID: <20230605115849.0368b8a7@kernel.org> (raw)
In-Reply-To: <cdbd5105-973a-2fa0-279b-0d81a1a637b9@nvidia.com>
[Updating Edwin's email.]
On Mon, 5 Jun 2023 10:28:06 +0300 Gal Pressman wrote:
> On 26/01/2021 19:51, Edwin Peer wrote:
> > On Mon, Jan 25, 2021 at 8:56 PM David Ahern <dsahern@gmail.com> wrote:
> >
> >> I'm not a fan of the skb trim idea. I think it would be better to figure
> >> out how to stop adding to the skb when an attr length is going to exceed
> >> 64kB. Not failing hard with an error (ip link sh needs to succeed), but
> >> truncating the specific attribute of a message with a flag so userspace
> >> knows it is short.
> >
> > Absent the ability to do something useful in terms of actually
> > avoiding the overflow [1], I'm abandoning this approach entirely. I
> > have a different idea that I will propose in due course.
> >
> > [1] https://marc.info/?l=linux-netdev&m=161163943811663
> >
> > Regards,
> > Edwin Peer
>
> Hello Edwin,
>
> I'm also interested in getting this issue resolved, have you had any
> progress since this series? Are you still working on it?
next prev parent reply other threads:[~2023-06-05 18:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-23 4:53 [PATCH net-next 0/4] support for 256 VFs in RTM_GETLINK Edwin Peer
2021-01-23 4:53 ` [PATCH net-next 1/4] netlink: truncate overlength attribute list in nla_nest_end() Edwin Peer
2021-01-23 19:14 ` David Ahern
2021-01-23 20:42 ` Edwin Peer
2021-01-23 21:03 ` Edwin Peer
2021-01-26 4:56 ` David Ahern
2021-01-26 17:51 ` Edwin Peer
2023-06-05 7:28 ` Gal Pressman
2023-06-05 18:58 ` Jakub Kicinski [this message]
2023-06-05 19:27 ` Edwin Peer
2023-06-06 8:01 ` Gal Pressman
2023-06-06 16:17 ` Jakub Kicinski
2023-06-07 13:31 ` Gal Pressman
2023-06-07 16:33 ` Jakub Kicinski
2023-06-07 16:52 ` Stephen Hemminger
2023-06-07 17:29 ` Jakub Kicinski
2021-01-26 4:50 ` David Ahern
2021-01-26 1:43 ` Jakub Kicinski
2021-01-23 4:53 ` [PATCH net-next 2/4] rtnetlink: extend RTEXT_FILTER_SKIP_STATS to IFLA_VF_INFO Edwin Peer
2021-01-26 1:55 ` Jakub Kicinski
2021-01-26 22:48 ` Edwin Peer
2021-01-23 4:53 ` [PATCH net-next 3/4] rtnetlink: refactor IFLA_VF_INFO stats into rtnl_fill_vfstats() Edwin Peer
2021-01-23 4:53 ` [PATCH net-next 4/4] rtnetlink: promote IFLA_VF_STATS to same level as IFLA_VF_INFO Edwin Peer
2021-01-26 2:01 ` Jakub Kicinski
2021-01-26 14:50 ` Edwin Peer
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=20230605115849.0368b8a7@kernel.org \
--to=kuba@kernel.org \
--cc=andrew.gospodarek@broadcom.com \
--cc=dsahern@gmail.com \
--cc=espeer@gmail.com \
--cc=gal@nvidia.com \
--cc=michael.chan@broadcom.com \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.