Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   <Daniel.Machon@microchip.com>
To:     <petrm@nvidia.com>
CC:     <netdev@vger.kernel.org>, <davem@davemloft.net>,
        <maxime.chevallier@bootlin.com>, <thomas.petazzoni@bootlin.com>,
        <edumazet@google.com>, <kuba@kernel.org>, <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: [net-next v3 1/6] net: dcb: add new pcp selector to app object
Thread-Topic: [net-next v3 1/6] net: dcb: add new pcp selector to app object
Thread-Index: AQHY54e/oXdDISkOjUKo8XH7CRcTxq4gd3gAgAAV3ACAADh8AIABMyYA
Date:   Thu, 27 Oct 2022 09:00:54 +0000
Message-ID: <Y1pLHL/d96VKT3kO@DEN-LT-70577>
References: <20221024091333.1048061-1-daniel.machon@microchip.com>
 <20221024091333.1048061-2-daniel.machon@microchip.com>
 <874jvq28l3.fsf@nvidia.com> <Y1kaErnPh5h4otWe@DEN-LT-70577>
 <87k04mzlc3.fsf@nvidia.com>
In-Reply-To: <87k04mzlc3.fsf@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9Sr9j5mez/zaE9cLXHPkI1zCYa1trgJcQLdLnEzBA5BWLcvHXlcX6emaQgna?=
 =?us-ascii?Q?E6Cm/lGwyREFn7JrGLt4QPb8g2Xy61YaoBEYcI+hbcLiO4JhpbgTHcYBOaNo?=
 =?us-ascii?Q?UUDgTlQMYk+HovrCZNsyXdXYnxgDMlx6d8OFfsHtKja5z3j97qe1eD6raTol?=
 =?us-ascii?Q?L1KJxICGtZqoevgM4Lrly+QRPBT7P6cPFp5TWwG++EK5y5TdAJ5Slagz3dr5?=
 =?us-ascii?Q?TTypCgYOX94QbzR3QBNNGGvnd+iL8Y79ahxkl4WuTzFUIVd46FpquM/ydkwg?=
 =?us-ascii?Q?4RapzzivRlkNXzYsXCjCgJVgB+7UJ5cHi1N6OMQYcSXGxhIQHP2989iKfY8A?=
 =?us-ascii?Q?7UOGcjuHAxpNRRk75I7/yrULKQqm7zfTt58VAxLgk94oJhAapxCg62KmqC1Z?=
 =?us-ascii?Q?jTBeWU29t3yxnDWeyenjSfupMOt4FJh94s11ST9eyJCBxA9fhLVsI8YDmfOX?=
 =?us-ascii?Q?F8dabeS61BFPmV4ctsqURf7VdqvNIhTuTgGWgYPnmXXYPtj0BBt4weJYPuRr?=
 =?us-ascii?Q?RrkiGTVPzc8x8uR5yPQ1M+poOiRWGniCQQC6ekuTZonmeafwTsslkjBmk/VN?=
 =?us-ascii?Q?JmQ36Xc5kvkR/YY5aIHL+7y39oB4ugiB0Zyh6MrimCp1k+3POr2rY9h/a3j+?=
 =?us-ascii?Q?+nXMRR1i6BNGQ1MRTyD7F9AzA72uYSBKHy9tqjqcl5HeMrRuqZw8NptuCdGk?=
 =?us-ascii?Q?+SwNbmtMnfR7bMMhVrePuxP5uMN0L44ym2Fsax6ZjJvQetXFwI/ngBDhkHWl?=
 =?us-ascii?Q?yNWeEYReb5kB7NJVLQdEWTW/wYgMGU8KR2kSPJUtlvtXtDu7nYW6jz9FzYFp?=
 =?us-ascii?Q?5jjW1/1GOKg8CElPKOsEofF/scwlIRJ1pW0OAzx1dG7TuV2jmEW143AVNTM+?=
 =?us-ascii?Q?sz2VGUrsHoX5KveR6ackge7tNSyESPgFxwcrSXaRX1gacoGBfMTHU+LMrbDq?=
 =?us-ascii?Q?tgYEZcEG/lOseweSmbOVsYoFji7hBdxk9PBzsfdt5FP+ecNG1XURqoFjnYEV?=
 =?us-ascii?Q?0UEuJ9eP4D3zeDq5dkDMyPAdI8UsjraXLtzYi+BmBKAGepm3xtalEBPcHLjz?=
 =?us-ascii?Q?YkixQ+FAv3IQHdi2O2n5WAIMDH0Q7IL7jvNPM+3fUu0kNUiS1FYRxbAXWJTZ?=
 =?us-ascii?Q?wqn/imyxSmQb1tkhovy9pLa9t9jwrBqpODWAw9UhEwSEvbvSD1rPfpsrwJi4?=
 =?us-ascii?Q?Y/lzzMC5uMH9mcvTW8DZ/5HA9oB3erTvf7Rn9YXVbS28CaEGR68PZrcmctN+?=
 =?us-ascii?Q?Yu5DWSAqBIQ+vXBMhSNtHiKR1kaLgBX7eAawbZnLcEtu41JndkLW0XVzNpxs?=
 =?us-ascii?Q?OfNi7qWDNFBJlF5IGCWYCDG3pZFxRIK2QaKXdJTLtYOGBEmAAuON2ND6bm52?=
 =?us-ascii?Q?eewH51qvf4RHjXg9fxmF35eEleD+i7z4qUbx5qK0exCXre/wxRazFNeXTB0L?=
 =?us-ascii?Q?4hogmms0Mcosnx2+7RbBrxdQMVIffOeicenj1GipNlxgxei+5Qe1Wqr0mwfv?=
 =?us-ascii?Q?k1WqQm+dlwF+RVeHvAI7shwk7l50TSu+r8GlgQCiLaEy26mhQS2mOVv+V5zO?=
 =?us-ascii?Q?X03Ii67EBBz7P//IXbVPyvuc7dA/m/6VmShWZsfCdOmIoVD5ESN+c2GLwjoP?=
 =?us-ascii?Q?meg3/BoYfDCdCSD+PFGXoXg=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14E13D1DC709EA4CAF7B0D3BEB44104D@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5580.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d1cab282-93c5-477f-b39a-08dab7f9c171
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2022 09:00:54.5915
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cvKAL2iPrENEEUX+DUgVuRziQRkpxstF1cmnP52+gX7/g/CRDbM3h+0YFICdXOMOJQ2W4BsH56KiWAfnDAOuwno77wE7KJwUQbL1y27iSvI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5241
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> >> I'm missing a validation that DCB_APP_SEL_PCP is always sent in
> >> DCB_ATTR_DCB_APP encapsulation. Wouldn't the current code permit
> >> sending it in the IEEE encap? This should be forbidden.
> >
> > Right. Current impl. does not check that the non-std selectors received=
, are
> > sent with a DCB_ATTR_DCB_APP type.  We could introduce a new check
> > dcbnl_app_attr_selector_validate() that checks combination of type and
> > selector, after the type and nla_len(attr) has been checked, so that:
> >
> >  validate type -> validate nla_len(attr) -> validate selector
>=20
> This needs to be validated, otherwise there's no point in having a
> dedicated attribute for the non-standard stuff.

Agree.

>=20
> >> And vice versa: I'm not sure we want to permit sending the standard
> >> attributes in the DCB encap.
> >
> > dcbnl_app_attr_type_get() in dcbnl_ieee_fill() takes care of this. IEEE=
 are
> > always sent in DCB_ATTR_IEEE and non-std are sent in DCB_ATTR_DCB.
>=20
> By "sending" I meant userspace sending this to the kernel. So bounce
> extended opcodes that are wrapped in IEEE and bounce IEEE opcodes
> wrapped in DCB as well.

Right. Then we only need to decide what to do with any opcode in-between
(not defined in uapi, neither ieee or extension opcode, 7-254). If they are=
=20
sent in DCB_ATTR_DCB they should be bounced, because we agreed that we can=
=20
interpret data in the new attr), _but_ if they are sent in DCB_ATTR_IEEE I=
=20
guess we should accept them, to not break userspace that is already sending
them.

Here is what that could look like:

	/* Make sure any non-std selectors is always encapsulated in the non-std
	* DCB_ATTR_DCB_APP attribute.
	*/
	static bool dcbnl_app_attr_selector_validate(enum ieee_attrs_app type, u32=
 selector)
	{
		switch (selector) {
		case DCB_APP_SEL_PCP:
			/* Non-std selector in non-std attr? */
			if (type =3D=3D DCB_ATTR_DCB_APP)
				return true;
		default:
			/* Std selector in std attr? */
			if (type =3D=3D DCB_ATTR_IEEE_APP)
				return true;
		}

		return false;
	}

/ Daniel=