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 10:10:52 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Baolu Lu <baolu.lu@linux.intel.com>
Cc:     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>,
        Robin Murphy <robin.murphy@arm.com>,
        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: <20220531131052.GD1343366@nvidia.com>
References: <20220527063019.3112905-1-baolu.lu@linux.intel.com>
 <20220527063019.3112905-2-baolu.lu@linux.intel.com>
 <20220527145910.GQ1343366@nvidia.com>
 <eda4d688-257b-d12a-56c0-0f9d3a10ef8c@linux.intel.com>
 <20220530121412.GX1343366@nvidia.com>
 <42623a73-c288-1c0d-7021-93caff4ffb6f@linux.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42623a73-c288-1c0d-7021-93caff4ffb6f@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Z8APMk00/F+FZhQ6FkWP5J+j4OhiWS9FrPSz4cRRh2XXkL2agoSH/bzmDI1H?=
 =?us-ascii?Q?MD6CXdsZX0nzvA5/sPIVQMLFjZvSdh82EKwiHJ/LJ9y6B4yPm2KrC7YgKdGm?=
 =?us-ascii?Q?TU0X2UbUXHFx3Jq3hvmpy2dbyCf/W5ainAJg0DG+ihbbkzL7lgY4u64FHOkv?=
 =?us-ascii?Q?/SgV08g4Ybj62xAmJjmScsqNKzQ/duUrMcLVxuQ4ulEWG7YCh9odBRaBRGLK?=
 =?us-ascii?Q?qhPwNaaSl+o3bIsEhY/0mzZmBqyUzXieO7S2/V4ME+2/NKsthJIwzbeSj7oG?=
 =?us-ascii?Q?Tw+8MFFZr2WH0r8OCS/LwIC/zmcdnrMGNbbyci8gKWJcmxa+Og4V4sWkg+ik?=
 =?us-ascii?Q?KKDR1GWhq7wv0Tf7MSbOXfUG4KMcB+pljguZQMSDIB6lpbBxjvfkgPZXjtPs?=
 =?us-ascii?Q?60Nzz571BdbwavWiK5eEyG1xe/OojlYHKXOHe/icgcZuY9yYqsK9u368MZ29?=
 =?us-ascii?Q?FZGM2UOOp37wscSijqD9OPlv6UAf9/E1kFgaP7Im1XgJWkUiwrRhrmZIWlMi?=
 =?us-ascii?Q?P6ymAILMMSo9DLnornRWDQNsNAhkL0LZCEEFtpHHhTaBqkHhSeVFAb5GqdQM?=
 =?us-ascii?Q?0XlMJ4dWkPmwPnsQ5bW33rcmlwSXxVxTpvIKafQt4KnNFRRkR6STzfsZ4OvD?=
 =?us-ascii?Q?CHCm0qVGSimmqx6uaW85K6oPRfHa+XMNlq8VbRbduPVyWoMjDeZBJlrNKuCw?=
 =?us-ascii?Q?93nEX4/9/wxTySlvq6ruCE+6fzLh19YzRf116ZiBLOezKZchD87v9sVQe5z6?=
 =?us-ascii?Q?kmvV3a7n5xlqjTrVgF7QZlDbtvmh6OXUmrsEqX4/lY1ogoJ/QLVy2mCy+WPF?=
 =?us-ascii?Q?by9O4T31iy52LtEHcXdEdgb0clykxZAHeOJyszcPczdcbp0AFLj6sTp2WD+o?=
 =?us-ascii?Q?QE8UwszsNUibQZbARCWmAZRNHCKmyDzsaJNE6TrwShR3c7sq3qE6oGhKSOtq?=
 =?us-ascii?Q?PbxFwlpu0F+LjBGoXSG7OOdiydGvtFOsaalKPWpJHhjoJpZq9H8M7XbzU/B3?=
 =?us-ascii?Q?FIuHUtnBDJnjQkPhU/66gM3O3GKu8LvHgu62F/rv/dG9pHDEvR2DWeW66nEt?=
 =?us-ascii?Q?ovmkswFO0FMEmvn3dHEEPQvw7upngeLEx8uBJobwpyi+5cQb82ToUHJV5aR4?=
 =?us-ascii?Q?o5vC31yLK16YV10rqzwq8Dq80G34Rzc+PQNfKxCGIpUbmazsEr5Zyj5wgnnU?=
 =?us-ascii?Q?yPmXf/jsF7XOnhRooI4iYGazfriIjP9oSX91r/THvdAuqyCx/yakOqTmrQ1X?=
 =?us-ascii?Q?P58c8V/3btULqdKy9zWYt91TLRNd89ovqj+W+YP1BKf7eYdze3lvPcRg0rBL?=
 =?us-ascii?Q?g1NT9KPs8lVphUYXE1fw4p3QY6kHdZGzGjlMWHkvP0lvRiAjmnBDOeTunHZO?=
 =?us-ascii?Q?W3OPkPd6KafAwYKaLUaPexymueEbjGSgGMnVctEd6pzp4wea82lj7Hk71MhI?=
 =?us-ascii?Q?lh1GRHsVqam7EF/C3ahWQrupFrLXQ8nOhnbsvfcZlS6F3eM9lajoRO0R4nud?=
 =?us-ascii?Q?V3oDa+laQczx7kMmvDMnIyGFFz2/hNebf5rTWsUqg/ngScjxGdTbyIu0LZLg?=
 =?us-ascii?Q?aHcxHhlct6CMBgjV7PjLobDqei/ca4IEc3TXEWhXpZtN1PV2pgTwQRX3y3Zw?=
 =?us-ascii?Q?dUyb1d58qudCKKSN/irhSJDrKHOSJjXsfQW+UgcVVTqKejm/8fEehU943Q/Y?=
 =?us-ascii?Q?zuGw6T57do67ms9utBKGavh7WlJfBTLKIDqnEyMqopIlVNxRR2FFyPZJt0ve?=
 =?us-ascii?Q?h+Uc/bn72Q=3D=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ed524bc-ad2b-4efb-6670-08da4306fda3
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2022 13:10:53.3055
 (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: MmwWfu6JXLco+l3hNTA8iUyj3h7GtQfljthij9ApaKEECxZjK/VfODokH7cpnppq
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3686
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 11:02:06AM +0800, Baolu Lu wrote:

> For case 2, it is a bit weird. I tried to add a rwsem lock to make the
> iommu_unmap() and dumping tables in debugfs exclusive. This does not
> work because debugfs may depend on the DMA of the devices to work. It
> seems that what we can do is to allow this race, but when we traverse
> the page table in debugfs, we will check the validity of the physical
> address retrieved from the page table entry. Then, the worst case is to
> print some useless information.

Sounds horrible, don't you have locking around the IOPTEs of some
kind? How does updating them work reliably?

It is just debugfs, so maybe it is not the end of the world, but
still..

Jason