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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 4FF21C38BE3 for ; Mon, 24 Feb 2020 19:01:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BCC32080D for ; Mon, 24 Feb 2020 19:01:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="FnR6SEUS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BCC32080D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 786ED6B006E; Mon, 24 Feb 2020 14:01:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 737206B0073; Mon, 24 Feb 2020 14:01:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FF906B0078; Mon, 24 Feb 2020 14:01:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 45A466B006E for ; Mon, 24 Feb 2020 14:01:00 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E37598245578 for ; Mon, 24 Feb 2020 19:00:59 +0000 (UTC) X-FDA: 76525937838.05.ray75_7d063c7c7ea3a X-HE-Tag: ray75_7d063c7c7ea3a X-Filterd-Recvd-Size: 5373 Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Feb 2020 19:00:58 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id n8so4583651qvg.11 for ; Mon, 24 Feb 2020 11:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nS4y9b6My/7+JIxHts6eLm8z0C4thsb5l3wuyiXD29Q=; b=FnR6SEUSqjm6pva9hmjZjjMQWlNtH8BimVmLzNHoyK5KObnwJJd4v62FvcucQXR613 Vs8HRCZGupCTQ5IZ0JUUxDfBksnOmCrAaBY+t9FVQ6WaO9/f1nfENMH64EtLf6mQOl3A ULGnEHBvxwQ+J67AeNEUPMlBMuj+D9qb1H5X2oBhmsBZnIHcb4yro7ts8Lp+wdj45jEW v76e8KPBbvQd89kU+MetflzO8JQksrPwRwleGV8a9HuL+52ruaZpjBkc9Ny6pYP+Y1YO IlJp1zbAGL4jPjja65grNuAP/DFEdsR9iZ2aPGrstIS0jUFiDV/TkZWtZDP/2nIWRKh9 659A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nS4y9b6My/7+JIxHts6eLm8z0C4thsb5l3wuyiXD29Q=; b=Kf08NIpnAmode4BnirDAHDX64dHF17B67Srnqy49c++gHGWyxs85JmSG6iyLPjI2Bg la5TX5WwfbGL2fC1jeoNMHmuwnEeK3H9h8qZ0nT1NxCL4CiBFyQkY3T5uDBag0WbATaB annploDVBAMkOyy+7L0w3y9Z1BaYCClo/tjXndo5Sle2kz0TkGLL4zQldeHS5klw7UyH exPjaRcJrXugjCcD8MalbywHxH/APziUgCQUAwkeWnPkvYhax/7Rq3vxR1XQzBo0VBrD 4HpowQp2IMFg0fMexE6gex1QDrgzHysM2T4mQp4IzbYBdwryQOP6i0LnLLjR56y84dVY vnIg== X-Gm-Message-State: APjAAAX7ZqK4VEpvH1F/Nbdszn87vwmBmVW9WvGba4ZBaJYE28Prz+Re 0FV88qF5vdNJiHF5rhqmaZK4ZQ== X-Google-Smtp-Source: APXvYqyNbYKidHbzZ1XJJ2LbIhIEjWa9RFdUt4bTzm6wm+o3ErpK3Y9OIJTvmpvQbXJ0sVD9TGvEfA== X-Received: by 2002:ad4:4b21:: with SMTP id s1mr47274639qvw.81.1582570858491; Mon, 24 Feb 2020 11:00:58 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id m17sm6086872qki.128.2020.02.24.11.00.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Feb 2020 11:00:57 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1j6IyO-0005Dy-Tk; Mon, 24 Feb 2020 15:00:56 -0400 Date: Mon, 24 Feb 2020 15:00:56 -0400 From: Jason Gunthorpe To: Jean-Philippe Brucker Cc: iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, joro@8bytes.org, robh+dt@kernel.org, mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com, kevin.tian@intel.com, baolu.lu@linux.intel.com, Jonathan.Cameron@huawei.com, jacob.jun.pan@linux.intel.com, christian.koenig@amd.com, yi.l.liu@intel.com, zhangfei.gao@linaro.org, Andrew Morton , Arnd Bergmann , Dimitri Sivanich , Greg Kroah-Hartman Subject: Re: [PATCH v4 01/26] mm/mmu_notifiers: pass private data down to alloc_notifier() Message-ID: <20200224190056.GT31668@ziepe.ca> References: <20200224182401.353359-1-jean-philippe@linaro.org> <20200224182401.353359-2-jean-philippe@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200224182401.353359-2-jean-philippe@linaro.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 24, 2020 at 07:23:36PM +0100, Jean-Philippe Brucker wrote: > The new allocation scheme introduced by 2c7933f53f6b ("mm/mmu_notifiers: > add a get/put scheme for the registration") provides a convenient way > for users to attach notifier data to an mm. However, it would be even > better to create this notifier data atomically. > > Since the alloc_notifier() callback only takes an mm argument at the > moment, some users have to perform the allocation in two times. > alloc_notifier() initially creates an incomplete structure, which is > then finalized using more context once mmu_notifier_get() returns. This > second step requires carrying an initialization lock in the notifier > data and playing dirty tricks to order memory accesses against live > invalidation. This was the intended pattern. Tthere shouldn't be an real issue as there shouldn't be any data on which to invalidate, ie the later patch does: + list_for_each_entry_rcu(bond, &io_mm->devices, mm_head) And that list is empty post-allocation, so no 'dirty tricks' required. The other op callback is release, which also cannot be called as the caller must hold a mmget to establish the notifier. So just use the locking that already exists. There is one function that calls io_mm_get() which immediately calls io_mm_attach, which immediately grabs the global iommu_sva_lock. Thus init the pasid for the first time under that lock and everything is fine. There is nothing inherently wrong with the approach in this patch, but it seems unneeded in this case.. Jason