From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E88F8C433FE for ; Tue, 4 Oct 2022 19:52:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p3FEdY5Qby9jUATKkMbPO9WOABzt/utNWwxDzKhDfjs=; b=p3AtLkRm/rBr0X IbTtIF8xo5Nzwy8WtZmhajEgGaHw85qDqT3F0wKy3yr5NR3B1Me/WeRbtqGyv9i3lTfwMZstZjvlB 65aKEk40dl0+C2GcaAj988s2DQj80DvSDpP4GTUydqmm6oupTD26OvAUTSUCoO1ijA+WZp1/Aoe4p GWMedKT9rbyVdAfaPo/heiiq+FP2nUCTlPnAUXBQX8AsSJ2HrEA4+PAm5JZEr0EtxVs9XUolfiXjL K/j4JJL0Xcgk2G0k9+EkSmsl9g5ZvSVFp4dOJPio0Th3Rz5itGa1Fuwk8euuz+x+jLDamaxbBz1ji bP/pe+F84DI/+WiE5s9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ofnxO-00AqTR-Ty; Tue, 04 Oct 2022 19:51:59 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ofnxK-00AqRP-2q for linux-arm-kernel@lists.infradead.org; Tue, 04 Oct 2022 19:51:55 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 71364B81BBB; Tue, 4 Oct 2022 19:51:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A435C433C1; Tue, 4 Oct 2022 19:51:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664913109; bh=TeN6ehnVEox16o2vQmBTliyjz88d8D/mx70KrdN795g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HE34e9c12tSg4Qi6lrUFpmw592Qbhct2z2qjumi34iWrQzXW68Os8/HzunByR4uU2 kSnSQpc9tRGS1Axi0mWLmI3RTN5V511XEVv6arsnCf9ROZZJ1KMCsdasrue6BSXT3H aAVbErjXfW/OnU7+ir6uxXUTzaxWm0lZlAs9C6a/koE5kygTmfo5alE0bv56GhC8DA 110PiR49JR35hSuwqef1ajI8Lajml2kBwHWwfIIzyDCHZTO6/RbGLYDoJhrUaBnnUe CMF2o0QA9ILreyif3wN/2cqcjI3wzyWoZ4pnY6r/xGXav4AMxOJOfHngHgTE62c2mL hVCTG1bN97SYw== Date: Tue, 4 Oct 2022 12:51:47 -0700 From: Jakub Kicinski To: Petr Machata Cc: Daniel Machon , , , , , , , , , , , , , , , , Subject: Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object Message-ID: <20221004125147.7f76d409@kernel.org> In-Reply-To: <87v8ozx3hb.fsf@nvidia.com> References: <20220929185207.2183473-1-daniel.machon@microchip.com> <20220929185207.2183473-2-daniel.machon@microchip.com> <87leq1uiyc.fsf@nvidia.com> <20220930175452.1937dadd@kernel.org> <87pmf9xrrd.fsf@nvidia.com> <20221003092522.6aaa6d55@kernel.org> <87zgebx3zb.fsf@nvidia.com> <87v8ozx3hb.fsf@nvidia.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221004_125154_303360_DBBE30C9 X-CRM114-Status: GOOD ( 19.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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