From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: Daniel Machon <daniel.machon@microchip.com>,
<netdev@vger.kernel.org>, <davem@davemloft.net>,
<maxime.chevallier@bootlin.com>, <thomas.petazzoni@bootlin.com>,
<edumazet@google.com>, <pabeni@redhat.com>,
<lars.povlsen@microchip.com>, <Steen.Hegelund@microchip.com>,
<UNGLinuxDriver@microchip.com>, <joe@perches.com>,
<linux@armlinux.org.uk>, <horatiu.vultur@microchip.com>,
<Julia.Lawall@inria.fr>, <vladimir.oltean@nxp.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object
Date: Tue, 4 Oct 2022 12:51:47 -0700 [thread overview]
Message-ID: <20221004125147.7f76d409@kernel.org> (raw)
In-Reply-To: <87v8ozx3hb.fsf@nvidia.com>
On Tue, 4 Oct 2022 12:52:35 +0200 Petr Machata wrote:
> > The question is whether it's better to do it anyway. My opinion is that
> > if a userspace decides to make assumptions about the contents of a TLV,
> > and neglects to validate the actual TLV type, it's on them, and I'm not
> > obligated to keep them working. We know about this case, but really any
> > attribute addition at all could potentially trip some userspace if they
> > expected something else at this offset.
>
> And re the flag: I think struct dcbmsg.dcb_pad was meant to be the place
> to keep flags when the need arises, but it is not validated anywhere, so
> we cannot use it. It could be a new command, but I'm not a fan. So if we
> need to discriminate userspaces, I think it should be a new attribute.
All good points. I'm fine with not gating the attributes if that's your
preference. Your call.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: Daniel Machon <daniel.machon@microchip.com>,
<netdev@vger.kernel.org>, <davem@davemloft.net>,
<maxime.chevallier@bootlin.com>, <thomas.petazzoni@bootlin.com>,
<edumazet@google.com>, <pabeni@redhat.com>,
<lars.povlsen@microchip.com>, <Steen.Hegelund@microchip.com>,
<UNGLinuxDriver@microchip.com>, <joe@perches.com>,
<linux@armlinux.org.uk>, <horatiu.vultur@microchip.com>,
<Julia.Lawall@inria.fr>, <vladimir.oltean@nxp.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object
Date: Tue, 4 Oct 2022 12:51:47 -0700 [thread overview]
Message-ID: <20221004125147.7f76d409@kernel.org> (raw)
In-Reply-To: <87v8ozx3hb.fsf@nvidia.com>
On Tue, 4 Oct 2022 12:52:35 +0200 Petr Machata wrote:
> > The question is whether it's better to do it anyway. My opinion is that
> > if a userspace decides to make assumptions about the contents of a TLV,
> > and neglects to validate the actual TLV type, it's on them, and I'm not
> > obligated to keep them working. We know about this case, but really any
> > attribute addition at all could potentially trip some userspace if they
> > expected something else at this offset.
>
> And re the flag: I think struct dcbmsg.dcb_pad was meant to be the place
> to keep flags when the need arises, but it is not validated anywhere, so
> we cannot use it. It could be a new command, but I'm not a fan. So if we
> need to discriminate userspaces, I think it should be a new attribute.
All good points. I'm fine with not gating the attributes if that's your
preference. Your call.
next prev parent reply other threads:[~2022-10-04 19:52 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 18:52 [PATCH net-next v2 0/6] Add new PCP and APPTRUST attributes to dcbnl Daniel Machon
2022-09-29 18:52 ` Daniel Machon
2022-09-29 18:52 ` [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object Daniel Machon
2022-09-29 18:52 ` Daniel Machon
2022-09-30 12:20 ` Petr Machata
2022-09-30 12:20 ` Petr Machata
2022-09-30 15:41 ` Petr Machata
2022-09-30 15:41 ` Petr Machata
2022-10-01 0:54 ` Jakub Kicinski
2022-10-01 0:54 ` Jakub Kicinski
2022-10-03 7:52 ` Petr Machata
2022-10-03 7:52 ` Petr Machata
2022-10-03 16:25 ` Jakub Kicinski
2022-10-03 16:25 ` Jakub Kicinski
2022-10-03 21:59 ` Daniel.Machon
2022-10-03 21:59 ` Daniel.Machon
2022-10-03 23:34 ` Jakub Kicinski
2022-10-03 23:34 ` Jakub Kicinski
2022-10-04 10:56 ` Petr Machata
2022-10-04 10:56 ` Petr Machata
2022-10-04 10:20 ` Petr Machata
2022-10-04 10:20 ` Petr Machata
2022-10-04 10:52 ` Petr Machata
2022-10-04 10:52 ` Petr Machata
2022-10-04 19:51 ` Jakub Kicinski [this message]
2022-10-04 19:51 ` Jakub Kicinski
2022-10-03 6:48 ` Daniel.Machon
2022-10-03 6:48 ` Daniel.Machon
2022-10-03 8:22 ` Petr Machata
2022-10-03 8:22 ` Petr Machata
2022-10-03 9:33 ` Daniel.Machon
2022-10-03 9:33 ` Daniel.Machon
2022-10-05 10:09 ` Petr Machata
2022-10-05 10:09 ` Petr Machata
2022-09-29 18:52 ` [PATCH net-next v2 2/6] net: dcb: add new apptrust attribute Daniel Machon
2022-09-29 18:52 ` Daniel Machon
2022-09-30 13:03 ` Petr Machata
2022-09-30 13:03 ` Petr Machata
2022-09-29 18:52 ` [PATCH net-next v2 3/6] net: microchip: sparx5: add support for offloading pcp table Daniel Machon
2022-09-29 18:52 ` Daniel Machon
2022-09-30 20:44 ` kernel test robot
2022-09-29 18:52 ` [PATCH net-next v2 4/6] net: microchip: sparx5: add support for apptrust Daniel Machon
2022-09-29 18:52 ` Daniel Machon
2022-09-30 15:49 ` Petr Machata
2022-09-30 15:49 ` Petr Machata
2022-10-03 6:52 ` Daniel.Machon
2022-10-03 6:52 ` Daniel.Machon
2022-10-03 8:01 ` Petr Machata
2022-10-03 8:01 ` Petr Machata
2022-10-03 8:17 ` Daniel.Machon
2022-10-03 8:17 ` Daniel.Machon
2022-10-03 9:34 ` Petr Machata
2022-10-03 9:34 ` Petr Machata
2022-09-29 18:52 ` [PATCH net-next v2 5/6] net: microchip: sparx5: add support for offloading dscp table Daniel Machon
2022-09-29 18:52 ` Daniel Machon
2022-09-30 23:23 ` kernel test robot
2022-09-29 18:52 ` [PATCH net-next v2 6/6] net: microchip: sparx5: add support for offloading default prio Daniel Machon
2022-09-29 18:52 ` Daniel Machon
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=20221004125147.7f76d409@kernel.org \
--to=kuba@kernel.org \
--cc=Julia.Lawall@inria.fr \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=daniel.machon@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horatiu.vultur@microchip.com \
--cc=joe@perches.com \
--cc=lars.povlsen@microchip.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.oltean@nxp.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 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.