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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 D4A29C433E0 for ; Mon, 8 Jun 2020 09:13:26 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A6248206C3 for ; Mon, 8 Jun 2020 09:13:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EfZhtxA1"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="f1XYT8gw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6248206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BxHz8zAjGyniXRRPy28n7kjhbEjZJkPintdPwfkvWfA=; b=EfZhtxA1lnZW21ZAmMKHB4o1J AJsZWEoIWi0bI1skOWuSG8rro4Ij+w6rk3amCaGlVRWtfoUMSs0JF/Lqd9vEs0kT0hjuutEsj+U8T S8OTcnhKa77Q1feYjOsd1k1q+asbcojbD76Fp5fx8+Hj3+ywnOcih7Rp5h1oS0j1r4BfwHM2DPNZa RzBZqOqAxR9UE/mNKP7pRRjBeK30KZkttohwwsOJDyjtBz3IJvjylL2owrzOvQaRPM49jEbu7meiA i5epVVTM9/0zXYKAfHTu9fCFaclNpaJIxdu/C5M8L+ydIOI8GxEFN/RBaxBqReC/5YI0AgbPExv4G bkbdVEhsA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiDqP-0007Gn-05; Mon, 08 Jun 2020 09:13:25 +0000 Received: from mail27.static.mailgun.info ([104.130.122.27]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiDqI-0007GD-U1 for linux-arm-kernel@lists.infradead.org; Mon, 08 Jun 2020 09:13:23 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1591607601; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=GhhsEMufI8UvffSMZZKH6Z/KWhXYBPW2V1EIJtJ4Olg=; b=f1XYT8gwj9Mg4frAjzJi1aqqL5qkR/rUF6XRpsjS4eCOvbbgkREVp4rSGyqIcbXJ1TTTUWej 5Nmt+567SX6dr66XIG+QJhVuSDbBkp2sjKyH+jQX8YIt1zNAw7YO1awCMx5zArBXJVT+Guuk X/xEBELQu1ZOOX2f/dbGupvtt0M= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n06.prod.us-west-2.postgun.com with SMTP id 5ede01203b3439f23a5b15c5 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 08 Jun 2020 09:13:04 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id E9D80C43391; Mon, 8 Jun 2020 09:13:03 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id 219B3C433C6; Mon, 8 Jun 2020 09:13:03 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 08 Jun 2020 14:43:03 +0530 From: Sai Prakash Ranjan To: Will Deacon Subject: Re: [RFC PATCH] iommu/arm-smmu: Remove shutdown callback In-Reply-To: <20200608081846.GA1542@willie-the-truck> References: <20200607110918.1733-1-saiprakash.ranjan@codeaurora.org> <20200608081846.GA1542@willie-the-truck> Message-ID: <08c293eefc20bc2c67f2d2639b93f0a5@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200608_021321_759827_8445D2CA X-CRM114-Status: GOOD ( 20.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-msm@vger.kernel.org, Joerg Roedel , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Will, On 2020-06-08 13:48, Will Deacon wrote: > On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote: >> Remove SMMU shutdown callback since it seems to cause more >> problems than benefits. With this callback, we need to make >> sure that all clients/consumers of SMMU do not perform any >> DMA activity once the SMMU is shutdown and translation is >> disabled. In other words we need to add shutdown callbacks >> for all those clients to make sure they do not perform any >> DMA or else we see all kinds of weird crashes during reboot >> or shutdown. This is clearly not scalable as the number of >> clients of SMMU would vary across SoCs and we would need to >> add shutdown callbacks to almost all drivers eventually. >> This callback was added for kexec usecase where it was known >> to cause memory corruptions when SMMU was not shutdown but >> that does not directly relate to SMMU because the memory >> corruption could be because of the client of SMMU which is >> not shutdown properly before booting into new kernel. So in >> that case, we need to identify the client of SMMU causing >> the memory corruption and add appropriate shutdown callback >> to the client rather than to the SMMU. >> >> Signed-off-by: Sai Prakash Ranjan >> --- >> drivers/iommu/arm-smmu-v3.c | 6 ------ >> drivers/iommu/arm-smmu.c | 6 ------ >> 2 files changed, 12 deletions(-) > > This feels like a giant bodge to me and I think that any driver which > continues to perform DMA after its ->shutdown() function has been > invoked > is buggy. Wouldn't that cause problems with kexec(), for example? > Yes it is definitely a bug in the client driver if DMA is performed after shutdown callback of that respective driver is invoked and it must be fixed in that driver. But here the problem I was describing is not that, most of the drivers do not have a shutdown callback to begin with and adding it just because of shutdown dependency on SMMU doesn't seem so well because we can have many more such clients in the future and then we have to just go on adding the shutdown callbacks everywhere. > There's a clear shutdown dependency ordering, where the clients of the > SMMU need to shutdown before the SMMU itself, but that's not really > the SMMU driver's problem to solve. > The problem with kexec may not be directly related to SMMU as you said above if DMA is performed after the client shutdown callback, then its a bug in the client driver, so that needs to be fixed in the client driver, not the SMMU. So is there any point in having the SMMU shutdown callback? As you see, with this SMMU shutdown callback, we need to add shutdown callbacks in all the client drivers. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel