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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18992C433EF for ; Wed, 23 Feb 2022 14:06:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241368AbiBWOHJ (ORCPT ); Wed, 23 Feb 2022 09:07:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240378AbiBWOHI (ORCPT ); Wed, 23 Feb 2022 09:07:08 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1A1BCF7; Wed, 23 Feb 2022 06:06:38 -0800 (PST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 6EDC86163C; Wed, 23 Feb 2022 14:06:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51924C340E7; Wed, 23 Feb 2022 14:06:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1645625197; bh=kaQNLSRDBE325nfkuijY1O4okV2QY/aI8g0iNsvKP8o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mIf5t5vUzELeIt8jiwumutbtFDinp/+l80a1tHDs4R1gZYZ9RaY/ILEy2aHbcJwmv 6ibaQTHCFb6xh+dxniBzBQtOo/+6Ne32E//8fLOeVa69dlbrkF3TkrZ10bOBNwH9zr rRNHpmmNgs4iMjBiLWHjtJGKVBeAniymXOagtnkU= Date: Wed, 23 Feb 2022 15:06:35 +0100 From: Greg Kroah-Hartman To: Jason Gunthorpe Cc: Robin Murphy , Lu Baolu , Christoph Hellwig , Joerg Roedel , Alex Williamson , Bjorn Helgaas , Kevin Tian , Ashok Raj , kvm@vger.kernel.org, rafael@kernel.org, David Airlie , linux-pci@vger.kernel.org, Thierry Reding , Diana Craciun , Dmitry Osipenko , Will Deacon , Stuart Yoder , Jonathan Hunter , Chaitanya Kulkarni , Dan Williams , Cornelia Huck , linux-kernel@vger.kernel.org, Li Yang , iommu@lists.linux-foundation.org, Jacob jun Pan , Daniel Vetter Subject: Re: [PATCH v6 02/11] driver core: Add dma_cleanup callback in bus_type Message-ID: References: <1d8004d3-1887-4fc7-08d2-0e2ee6b5fdcb@arm.com> <20220221234837.GA10061@nvidia.com> <1acb8748-8d44-688d-2380-f39ec820776f@arm.com> <20220222151632.GB10061@nvidia.com> <3d4c3bf1-fed6-f640-dc20-36d667de7461@arm.com> <20220222235353.GF10061@nvidia.com> <171bec90-5ea6-b35b-f027-1b5e961f5ddf@linux.intel.com> <880a269d-d39d-bab3-8d19-b493e874ec99@arm.com> <20220223134627.GO10061@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220223134627.GO10061@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Feb 23, 2022 at 09:46:27AM -0400, Jason Gunthorpe wrote: > On Wed, Feb 23, 2022 at 01:04:00PM +0000, Robin Murphy wrote: > > > 1 - tmp->driver is non-NULL because tmp is already bound. > > 1.a - If tmp->driver->driver_managed_dma == 0, the group must currently be > > DMA-API-owned as a whole. Regardless of what driver dev has unbound from, > > its removal does not release someone else's DMA API (co-)ownership. > > This is an uncommon locking pattern, but it does work. It relies on > the mutex being an effective synchronization barrier for an unlocked > store: > > WRITE_ONCE(dev->driver, NULL) Only the driver core should be messing with the dev->driver pointer as when it does so, it already has the proper locks held. Do I need to move that to a "private" location so that nothing outside of the driver core can mess with it? thanks, greg k-h