Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 31 May 2022 15:51:10 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Baolu Lu <baolu.lu@linux.intel.com>,
        Joerg Roedel <joro@8bytes.org>,
        Kevin Tian <kevin.tian@intel.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Christoph Hellwig <hch@infradead.org>,
        Will Deacon <will@kernel.org>, Liu Yi L <yi.l.liu@intel.com>,
        Jacob jun Pan <jacob.jun.pan@intel.com>,
        iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in
 debugfs
Message-ID: <20220531185110.GJ1343366@nvidia.com>
References: <20220530121412.GX1343366@nvidia.com>
 <42623a73-c288-1c0d-7021-93caff4ffb6f@linux.intel.com>
 <20220531131052.GD1343366@nvidia.com>
 <60318d83-e22f-f922-436f-6c31bce24d59@linux.intel.com>
 <20220531145301.GE1343366@nvidia.com>
 <a7d6d830-cb06-e0d7-0688-028f9af900e5@arm.com>
 <20220531151332.GF1343366@nvidia.com>
 <b66a2e3b-9adc-5150-fe00-d68b141b1c28@arm.com>
 <20220531162152.GH1343366@nvidia.com>
 <10f16c13-c50d-892c-a20d-979b2135c953@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10f16c13-c50d-892c-a20d-979b2135c953@arm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yvznQFJqbQEKb0DSn6NNlKIgAq9KIvQ7z2MP6fIbP3NGTg17MU6XKNUTKPUs?=
 =?us-ascii?Q?DPVfns8+zP8Zkd0+ziMJ6mkeFWyrOW+wGGougIXPgs09A8ZgIweNQLKX2F6e?=
 =?us-ascii?Q?qfOBvVHrML01IHYM9H4hJLSM3A1bQeHsPHpfUnty4x9YSIj1eBHJZ4bCc/TW?=
 =?us-ascii?Q?YcVhFFqqop/aa1So5H4Qray32l55HN2tl3fkMUdBpS3IHh6qtzhfhtqyPBv4?=
 =?us-ascii?Q?P+AWGf8A6u1/6+cjZyJBe5St7rNUAO9CnSYwFDI3MVoiee8723DwL6MRnQ/2?=
 =?us-ascii?Q?YhITDcgeiJFIUw07gSuRW/pEbtvSOqxZjvKuuQUT9d7VPTMpjsiFwcr2p9NQ?=
 =?us-ascii?Q?fHQYRq8HX4//XQ9/ouu3djaPBFEyMMGXirooPukPLZP2dMwf7qjndEz40B1C?=
 =?us-ascii?Q?BR7HYmIrXjWYhbpRMIJWL5XnI6Ph5GhyBbdN6PFava4Th4gdLjzh8c0KEX5V?=
 =?us-ascii?Q?HLRP32C5Apmw3TrmpJq1hPanyjRRzzMd2dcyF+xHKifOdGl2kAdOt/4FftoW?=
 =?us-ascii?Q?Ts3fARjl9IJKIV1sJ7Yb2hYRU7SsqEx/VpnrUQuM1DH3xxG81R6Ut+MoULwe?=
 =?us-ascii?Q?wUR4ZYDzY/w1wxJ4xeXjBeK3sWtruuLP9Uq1XxU8X9VkfGxGGvGQqVVyrPg+?=
 =?us-ascii?Q?n1Er3s9C1UWxC0D47ngKBI8g0/AA5xMTSvq85FlFka9DGwehVlJTGrVr1lQm?=
 =?us-ascii?Q?mmVNJl1IKJEUHRvlrXoLkIKubj1GTMsf4DjSWAe5KO4ubKSHuLcS49cq4XoA?=
 =?us-ascii?Q?BfoTkOmq5z8quLaE0+3cYkETo62iyn2sHoOw61JSS5PC49Rc917Ss8Q6Wm2g?=
 =?us-ascii?Q?f+dLU04viPwiDZ70pBoMemfNzel+vHyTISeEII1Nx70m6vj85K7bqTU64VSl?=
 =?us-ascii?Q?EwmHllgrXp3lhaBmlNADDW569AIiLkXoU89N9DbFXb0cetW6yG+QF1pVYfxQ?=
 =?us-ascii?Q?8UIVE+EnvaWpAvuCo9G3gh2MXtQ1lU7mnZ+eKqfMnN7xSOMRthOLEIwvKUyX?=
 =?us-ascii?Q?LzFlyV/DGsXIeaC39vkqFUFL3Cdp5SOStMVCn4N3e6WsqU6wUFWigT5i5je0?=
 =?us-ascii?Q?nIE5CehqvIQSS2YsHRNvpwjX4/mYpWeEGK3mX5Ooz4FxhEDQUWzAwlp2d1i0?=
 =?us-ascii?Q?qA4F5Hp7BBWVr5CuW10h6gqj5hNRrEU7GUpVpO2EWvrZ0/xqSF/fKmISfksP?=
 =?us-ascii?Q?EvtgtVHwBsIXJmR2WkBRO/gVr0eWuAa1a2LUeAEktt7oR736xXNMoc0SLRa+?=
 =?us-ascii?Q?CtzaUlxt4zIGXiOZl/nE6C131mOk85PkiTXrmr0kmnUYtwBX3KqpIOeaPFjX?=
 =?us-ascii?Q?/xkh8uyIQmbZzGT0J7cNsgWL+Q0Q5AQZF2cz0qCKGtjbrVDyp9/AnIyDvxBG?=
 =?us-ascii?Q?F8NTkreiUTm/w/4DDvu35/SaAQ8bOHuo/3AlU7j2Z6jha1qqK01v4vSREPL8?=
 =?us-ascii?Q?2dVxvZbQacX3IFe666/SnRWQwHuzxrfUU2K76Mt5MCoPqj0vhcl0/klM1pmT?=
 =?us-ascii?Q?qV9pKNJ2Zb5BP2kggckwg7adV0wtPQNI68StpL/FuAexSP+JEHgoREzbES+l?=
 =?us-ascii?Q?u/AkxZN6DqsdxxJh8d5Sb/PVnlY1MPhDc2sJBbuLp2h1zHbYM7uZLaGttAVw?=
 =?us-ascii?Q?A2EG2rOTbCbVqg5GJAYaimQJruFJirvnpTrP3e/n+qTGDL7ZMR1Wrcq/OfY5?=
 =?us-ascii?Q?I3/U8ltq3MR/u+ycBbDV5ceGUzQpNF7miBcClSf/Ve8axgBT1Hlgj+pSpu8P?=
 =?us-ascii?Q?1/vxKyjotg=3D=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cce3b50-466a-4b15-61ef-08da4336880b
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2022 18:51:11.7807
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Pc8xGKB7hg4ts5xVuL4ldewSiqBx2gJ6MpDru4RsnyNGymiAh2wtcSiLwmb32pHu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3443
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, May 31, 2022 at 07:07:32PM +0100, Robin Murphy wrote:

> > And we expect the iommu driver to be unable to free page table levels
> > that have IOVA boundaries in them?
> 
> I'm not entirely sure what you mean there, but in general an unmap request
> is expected to match some previous map request 

atomic cmpxchg is OK for inserting new page table levels but it can't
protect you against concurrent freeing of page table levels. So
without locks it means that page tables can't usually be freed. Which
seems to match what the Intel driver does - at least from a cursory
look.

This is one of the reasons the mm has the mmap/etc lock and spinlocks
because we do expect page table levels to get wiped out when VMA's are
zap'd - all the different locks provide the protection against page
tables disappearing under from something manipulating them.

Basically every "lockless" walk in (process) MM land is actually
protected by some kind of lock that blocks zap_page_range() from
removing the page table levels themselves.

> They might either unmap the entire region originally mapped, or just
> the requested part, or might fail entirely (IIRC there was some
> nasty code in VFIO for detecting a particular behaviour).

This is something I did differently in iommufd. It always generates
unmaps that are strict supersets of the maps it issued. So it would be
a kernel bug if the driver unmaps more or less than requested.

> Oh, I've spent the last couple of weeks hacking up horrible things
> manipulating entries in init_mm, and never realised that that was actually
> the special case. Oh well, live and learn.

The init_mm is sort of different, it doesn't have zap in quite the
same way, for example. I was talking about the typical process mm.

Anyhow, the right solution is to use RCU as I described before, Baolu
do you want to try?

Jason