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 A2F2EECAAD3 for ; Wed, 14 Sep 2022 20:56:40 +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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=g9HCvpFccd/zN75s/CXUKl2glhIvE4MSgX8NoqltUdk=; b=YSoJI2PVs7JCnD Byk5PkvtvTUBHefbxdOFOEo/8pm00oBWY7RrfyPyhQeZ7UeRZCl4tUqbzFrxfL63KEfcoSdWyU9XX saCc5ctj4Aua06MJE1H8frBZ8ECqg7Jrk/XRhBFUkT5zwM+eZGhFVqx/iryJbXhthJyhE/U9XUH8W L9Yyl+aou0nFrGnb1suDCwtvh14K69Eh55Z1QZKCTdaGL/ro7Y/uBHpM/5NOXDCk9Pf7Nsvi87S/c 0jSx32yAUv076awdWRpNFI/xVS0SRinCu4Noqcx4sYEL37Z1UpQC5FCZAxmCIUOQ+ceYZb6kao3Wx +k1hJDUcgrzCcW03RZeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYZPx-009a9l-7E; Wed, 14 Sep 2022 20:55:33 +0000 Received: from mail-bn8nam11on2040.outbound.protection.outlook.com ([40.107.236.40] helo=NAM11-BN8-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYZPu-009a7g-Dk; Wed, 14 Sep 2022 20:55:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NseF4qWINJNbdOFlXYdlMnc2n9rlnQsoDjb0pDuR1ZYdt3z/gSe9bjY6Zj5mc8p4rotUvphHKVMCuZq0nOOHlZ8AVBuG76jr0JfRKPnk/Y3HQuUWwu2uaNVv7hwfNXbBqv3kr224xOQinzTxSdxPxgDvBa0LFULCfW9JVzBpcDFtxa/GlER4S7F0X4GqvRiGezSgT9Lxr7sb3GT1CF3cLLPefMUr3knGefWoI40yG8MfddJPkheAvPhR1A3k5zsfBeLSw1n9pChWr46y2PJ5ggK+r3SyK48AZYPPhsqWSCQSfrTp7nCexip+iRtyAXMbFt+ulroTP0TePeefKYvGjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6MrNWONtzhKXiENWB2WK+9D25r0wj9sBSpYtVTAguhQ=; b=NgVB47fh4hIJlBqIiXRmItbS7PBvCqrzkgQ4kn5cia9MBz3A4BleWwgb87d+UUayY/KU3jOmMA6E3dWbsMl+SvefjgosQEnshWyGkLMotdtSGVlMe3PrFr/EquqUb2jbEUoU73bqUo226133D4ckQNDzOZwi1U+zRQ79Qq/P53SLwcmQLKZX+rnWJzswgQQWQ3UP4zahxsaSwUX5wcYNzH/AKnkyhzDmut68bbBWky0fNUtZUf9L0n39mkhqrwzyHqixxk4+jd7IBEfTEYB2k8DSheYYRMv7IhExw8nNCV5M4EeYGTOvBMWe4mIAV7Z2o1tuy+3uPwFtlsOZDkWO4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.117.161) smtp.rcpttodomain=arm.com smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6MrNWONtzhKXiENWB2WK+9D25r0wj9sBSpYtVTAguhQ=; b=TGOCK9MfpOtplPaGLkYrnE3UybAsIuwEuXQ9tXRq7kzFfYO+DFaCf+QRCIoWyAZxv9qFuB5WdfbE2pLQQQadnJQ5Yo3km9KK01ihxwVQ0okGUMm4rl3fd1W35740WTLoH63EZ59d3WIiEdCCOl7ntiNaR/XmldSxBkup7Jw1uTylimdK+1NepwdJFi/2dUi4c60rH4yzVsXpoY/NUXPPnhlSn8A2BBjPtiSuNEruUkwWeFtjaIDNy/pQaq4pjwCw9/rxzBpWAVTLICqvm58hRSrE1N/UY1fQa5wYv1z3PusIaZJO6NgpvryldSVbj7bGTI9i6AYIO4LxdSvdJDxIqA== Received: from DS7PR03CA0004.namprd03.prod.outlook.com (2603:10b6:5:3b8::9) by PH7PR12MB5856.namprd12.prod.outlook.com (2603:10b6:510:1d7::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.22; Wed, 14 Sep 2022 20:55:26 +0000 Received: from DM6NAM11FT086.eop-nam11.prod.protection.outlook.com (2603:10b6:5:3b8:cafe::68) by DS7PR03CA0004.outlook.office365.com (2603:10b6:5:3b8::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.22 via Frontend Transport; Wed, 14 Sep 2022 20:55:26 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.161) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.117.161 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (216.228.117.161) by DM6NAM11FT086.mail.protection.outlook.com (10.13.173.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.12 via Frontend Transport; Wed, 14 Sep 2022 20:55:26 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by mail.nvidia.com (10.129.200.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.26; Wed, 14 Sep 2022 13:55:12 -0700 Received: from rnnvmail201.nvidia.com (10.129.68.8) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Wed, 14 Sep 2022 13:55:12 -0700 Received: from Asurada-Nvidia (10.127.8.11) by mail.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29 via Frontend Transport; Wed, 14 Sep 2022 13:55:10 -0700 Date: Wed, 14 Sep 2022 13:55:08 -0700 From: Nicolin Chen To: Robin Murphy Subject: Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions Message-ID: References: <20220913082448.31120-1-nicolinc@nvidia.com> <20220913082448.31120-5-nicolinc@nvidia.com> <5f049bb8-76e6-901a-9f8e-b48d270bc4a0@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5f049bb8-76e6-901a-9f8e-b48d270bc4a0@arm.com> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT086:EE_|PH7PR12MB5856:EE_ X-MS-Office365-Filtering-Correlation-Id: 37464c23-4ea2-44f6-a788-08da96937336 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eFYiVF9rjky36BTr9CulQLvdOrhn2kFapkMMigQNjatMhqAQXKQ7doria7++uAD5b5WQSpGSBNSfxUPtSYNB5Tt1tRzmoFx3s10Lz0ylhXkhJiNdBT/FHcGCAYUAxj8DxClzaXzuon+1vHOeWP/l0yuVyGaipCrVGJTfO8ctDdee2idUB/bf3NuuaSEFKs0uVir6GW4Vx/sUDkSHSY5FEQahB9P4JvnBZqDoj+o3fW1IhLgSstsIqqbD92gB4X8AvLtfy9bd0eWd/a66TdZyVbKF1fz5njtWhs7MK2++N4hq4cJHyCbU1WqQDhbT7sNxQNDHvKTxiKuiQQ2zrw2yp47B23zfrgX5FjkdFJLp2CDyhc5nCCEGmyn18MVB0bTX4H49r2qVHYV9e7VilTZrslgoEeVtohAhW4TMCc+Bu4NDymNDXXo0B91+4j3NrRD9q6KtIOMDaAtDuwBgezQd2MwAISPePm2nRYCD7ro6jjpIE0nHSdTvqs13+21YgGv8ryN8zYx1Ij2esD3ovs8QBlwF2hW6XGFhS5E+s2FNDMv7A11IJB4VxLsk4V+KD12/z3r+bc5OYKOFhtiw9HJ1LCMPzvk0semrXGB6Aaz+4bkdvcQkdkreAWBO/j+DtT4yNU+koBB+qECjnjnGFyhBYpWMUr2ac5MQJNjtxXakTd5jVrFYKGwpIqNxi7yiKHeN5WIuDUkt0ZfUQ/DA3GIuqu+4WeQE/XBuP9gRpTBpuR1AL91vOkjAvJMWRWdZULq3xB6gqWwICvJ0zL2N8t8E1g== X-Forefront-Antispam-Report: CIP:216.228.117.161;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:dc6edge2.nvidia.com;CAT:NONE;SFS:(13230022)(4636009)(136003)(396003)(346002)(39860400002)(376002)(451199015)(46966006)(40470700004)(36840700001)(7636003)(40460700003)(336012)(2906002)(86362001)(33716001)(70586007)(82310400005)(316002)(53546011)(47076005)(54906003)(36860700001)(83380400001)(9686003)(7416002)(426003)(26005)(478600001)(186003)(5660300002)(7406005)(70206006)(8676002)(356005)(8936002)(82740400003)(41300700001)(4326008)(40480700001)(55016003)(6916009);DIR:OUT;SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2022 20:55:26.2104 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 37464c23-4ea2-44f6-a788-08da96937336 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT086.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5856 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220914_135530_489738_FCD86E6F X-CRM114-Status: GOOD ( 40.05 ) 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: , Cc: heiko@sntech.de, konrad.dybcio@somainline.org, bjorn.andersson@linaro.org, linux-tegra@vger.kernel.org, thierry.reding@gmail.com, will@kernel.org, Jean-Philippe Brucker , zhang.lyra@gmail.com, joro@8bytes.org, jon@solid-run.com, jonathanh@nvidia.com, linux-rockchip@lists.infradead.org, iommu@lists.linux.dev, agross@kernel.org, linux-arm-kernel@lists.infradead.org, Jason Gunthorpe , yangyingliang@huawei.com, orsonzhai@gmail.com, linux-arm-msm@vger.kernel.org, christophe.jaillet@wanadoo.fr, baolin.wang@linux.alibaba.com, thunder.leizhen@huawei.com, matthias.bgg@gmail.com, tglx@linutronix.de, virtualization@lists.linux-foundation.org, yong.wu@mediatek.com, dwmw2@infradead.org, linux-kernel@vger.kernel.org, shameerali.kolothum.thodi@huawei.com, robdclark@gmail.com, suravee.suthikulpanit@amd.com, linux-mediatek@lists.infradead.org, sricharan@codeaurora.org, baolu.lu@linux.intel.com 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 Hi Robin, On Wed, Sep 14, 2022 at 08:53:07PM +0100, Robin Murphy wrote: > External email: Use caution opening links or attachments > > > On 2022-09-14 18:58, Nicolin Chen wrote: > > On Wed, Sep 14, 2022 at 10:49:42AM +0100, Jean-Philippe Brucker wrote: > > > External email: Use caution opening links or attachments > > > > > > > > > On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote: > > > > On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote: > > > > > I think in the future it will be too easy to forget about the constrained > > > > > return value of attach() while modifying some other part of the driver, > > > > > and let an external helper return EINVAL. So I'd rather not propagate ret > > > > > from outside of viommu_domain_attach() and finalise(). > > > > > > > > Fortunately, if -EINVAL is wrongly returned it only creates an > > > > inefficiency, not a functional problem. So we do not need to be > > > > precise here. > > > > > > Ah fair. In that case the attach_dev() documentation should indicate that > > > EINVAL is a hint, so that callers don't rely on it (currently words "must" > > > and "exclusively" indicate that returning EINVAL for anything other than > > > device-domain incompatibility is unacceptable). The virtio-iommu > > > implementation may well return EINVAL from the virtio stack or from the > > > host response. > > > > How about this? > > > > + * * EINVAL - mainly, device and domain are incompatible, or something went > > + * wrong with the domain. It's suggested to avoid kernel prints > > + * along with this errno. And it's better to convert any EINVAL > > + * returned from kAPIs to ENODEV if it is device-specific, or to > > + * some other reasonable errno being listed below > > FWIW, I'd say something like: > > "The device and domain are incompatible. If this is due to some previous > configuration of the domain, drivers should not log an error, since it > is legitimate for callers to test reuse of an existing domain. > Otherwise, it may still represent some fundamental problem." OK. I will use this narrative. > And then at the public interfaces state it from other angle: > > "The device and domain are incompatible. If the domain has already been > used or configured in some way, attaching the same device to a different > domain may be expected to succeed. Otherwise, it may still represent > some fundamental problem." I assume this should go to kdocs of iommu_attach_device/group(). > [ and to save another mail, I'm not sure copying the default comment for > ENOSPC is all that helpful either - what is "space" for something that > isn't a storage device? I'd guess limited hardware resources in some > form, but in the IOMMU context, potential confusion with address space > is maybe a little too close for comfort? ] How about "non-ENOMEM type of resource allocation failure"? > > > > > Since we can't guarantee that APIs like virtio or ida won't ever return > > > > > EINVAL, we should set all return values: > > > > > > > > I dislike this alot, it squashes all return codes to try to optimize > > > > an obscure failure path :( > > > > Hmm...should I revert all the driver changes back to this version? > > Yeah, I don't think we need to go too mad here. Drivers shouldn't emit > their *own* -EINVAL unless appropriate, but if it comes back from some > external API then that implies something's gone unexpectedly wrong > anyway - maybe it's a transient condition and a subsequent different > attach might actually work out OK? We can't really say in general. OK. Then there's even no need to convert EINVAL to ENODEV. > Besides, if the driver sees an error which implies it's done something > wrong itself, it probably shouldn't be trusted to try to reason about it > further. The caller can handle any error as long as we set their > expectations correctly. Yea. As Jason remarked, a wrongly returned EINVAL would make things a bit inefficient: VFIO/IOMMUFD would keep trying attach_dev() with its existing domain list and a new domain but fail all of them. I will change things in v2 back to this 2-patch version, and maybe limit a bit further the changes in the first NODEV patch. Thanks! Nic _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel