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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A6D9C07E9B for ; Tue, 6 Jul 2021 12:49:00 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D66F461D05 for ; Tue, 6 Jul 2021 12:48:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D66F461D05 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 602A46E48D; Tue, 6 Jul 2021 12:48:59 +0000 (UTC) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3C1516E48D for ; Tue, 6 Jul 2021 12:48:57 +0000 (UTC) Received: from maud (unknown [IPv6:2600:8800:8c04:8c00::912b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alyssa) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 600F41F41E9A; Tue, 6 Jul 2021 13:48:52 +0100 (BST) Date: Tue, 6 Jul 2021 08:48:44 -0400 From: Alyssa Rosenzweig To: Steven Price Subject: Re: [PATCH v3 5/7] drm/panfrost: Add a new ioctl to submit batches Message-ID: References: <20210702143225.3347980-1-boris.brezillon@collabora.com> <20210702143225.3347980-6-boris.brezillon@collabora.com> <20210702173843.44b3e322@collabora.com> <20210702201112.4c07c2c7@collabora.com> <20210705104319.7b709530@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jason Ekstrand , Tomeu Vizoso , dri-devel@lists.freedesktop.org, Rob Herring , Boris Brezillon , Alyssa Rosenzweig , Robin Murphy Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > My concern is if we ever find a security bug which requires new > information/behaviour in the submit ABI to properly fix. In this case it > would be appropriate to backport a 'feature' (bug fix) which provides a > new ABI but it would need to be a small change. A flags field where we > can set a "PANFROST_ACTUALLY_BE_SECURE" bit would be useful then - but > we wouldn't want to start bumping version numbers in the backport. > > But at least for now we could just assume we'll expand the ioctl struct > if we ever hit that situation, so no need for an explicit flags field. I'm curious if kbase ever hit something like this? It wouldn't have occurred to me as a possibility.