From: Petr Machata <petrm@nvidia•com>
To: <Daniel.Machon@microchip•com>
Cc: <vladimir.oltean@nxp•com>, <netdev@vger•kernel.org>,
<Allan.Nielsen@microchip•com>, <UNGLinuxDriver@microchip•com>,
<maxime.chevallier@bootlin•com>, <petrm@nvidia•com>,
<kuba@kernel•org>, <vinicius.gomes@intel•com>,
<thomas.petazzoni@bootlin•com>
Subject: Re: [RFC PATCH net-next 2/2] net: dcb: add new apptrust attribute
Date: Mon, 12 Sep 2022 18:30:08 +0200 [thread overview]
Message-ID: <874jxceemc.fsf@nvidia.com> (raw)
In-Reply-To: <Yx7b5Jg051jFhLea@DEN-LT-70577>
<Daniel.Machon@microchip•com> writes:
> Den Fri, Sep 09, 2022 at 12:29:50PM +0000 skrev Vladimir Oltean:
>
>> Let's say I have a switch which only looks at VLAN PCP/DEI if the bridge
>> vlan_filtering setting is enabled (otherwise, the switch is completely
>> VLAN unaware, including for QoS purposes).
>>
>> Would it be ok to report through ieee_getapptrust() that the PCP
>> selector is trusted when under a vlan_filtering bridge, not trusted when
>> not under a vlan_filtering bridge, and deny changes to ieee_setapptrust()
>> for the PCP selector? I see the return value is not cached anywhere
>> within the kernel, just passed to the user.
>
> Therefore, in your particular case, with the vlan_filtering on/off,
> yes that would be OK IMO. Any concerns?
Yeah, it would make sense to me. With the 802.1q bridge, the reported
trust level would be [PCP], with 802.1d it would be [].
As a service to the user, I would accept set requests that just reassert
the only valid configuration, but otherwise it sounds OK to me.
next prev parent reply other threads:[~2022-09-12 16:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 12:04 [RFC PATCH net-next 0/2] Add PCP selector and new APPTRUST attribute Daniel Machon
2022-09-08 12:04 ` [RFC PATCH net-next 1/2] net: dcb: add new pcp selector to app object Daniel Machon
2022-09-12 16:15 ` Petr Machata
2022-09-13 6:33 ` Daniel.Machon
2022-09-08 12:04 ` [RFC PATCH net-next 2/2] net: dcb: add new apptrust attribute Daniel Machon
2022-09-09 12:29 ` Vladimir Oltean
2022-09-12 7:03 ` Daniel.Machon
2022-09-12 16:30 ` Petr Machata [this message]
2022-09-12 17:16 ` Vladimir Oltean
2022-09-12 14:31 ` Petr Machata
2022-09-13 9:01 ` Daniel.Machon
2022-09-13 11:25 ` Petr Machata
2022-09-13 19:22 ` 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=874jxceemc.fsf@nvidia.com \
--to=petrm@nvidia$(echo .)com \
--cc=Allan.Nielsen@microchip$(echo .)com \
--cc=Daniel.Machon@microchip$(echo .)com \
--cc=UNGLinuxDriver@microchip$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=maxime.chevallier@bootlin$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=thomas.petazzoni@bootlin$(echo .)com \
--cc=vinicius.gomes@intel$(echo .)com \
--cc=vladimir.oltean@nxp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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