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:   Mon, 24 Oct 2022 13:26:16 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Niklas Schnelle <schnelle@linux.ibm.com>
Cc:     Matthew Rosato <mjrosato@linux.ibm.com>, iommu@lists.linux.dev,
        Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Gerd Bayer <gbayer@linux.ibm.com>,
        Pierre Morel <pmorel@linux.ibm.com>,
        linux-s390@vger.kernel.org, borntraeger@linux.ibm.com,
        hca@linux.ibm.com, gor@linux.ibm.com,
        gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
        svens@linux.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] iommu/s390: Use RCU to allow concurrent domain_list
 iteration
Message-ID: <Y1a8qM4c2ZAM9glJ@nvidia.com>
References: <Y07Dz/NROAMI0Hku@nvidia.com>
 <8e268ab5e0dadf86be5fd7ffaa9debb76cea67f3.camel@linux.ibm.com>
 <Y0/lMCQ8oeXJ2HTg@nvidia.com>
 <f3551bb461b3ef3cfc1a0c644093816be1835b3f.camel@linux.ibm.com>
 <Y1ErcEe82yjJI+ET@nvidia.com>
 <68d91d7a5aadbd46dc34470eccd6b86a84c9e47b.camel@linux.ibm.com>
 <Y1KgX8EwH8T+FgWC@nvidia.com>
 <89a748fb5caee8be5d91806aa5dfd131e92d5d82.camel@linux.ibm.com>
 <Y1K1AqVWEyY0/Uqy@nvidia.com>
 <cef734b9f9b33380c1bbff40b56bb67b3de29341.camel@linux.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cef734b9f9b33380c1bbff40b56bb67b3de29341.camel@linux.ibm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?jOXPyBf3PCQwv44HSmEv6/B0B1ZXv5v2X0GSIhOg6VaAXK3XnIQKzPvNUT8m?=
 =?us-ascii?Q?/NiLVoFXw7Xh9jSo6S1a/Xh29dPQt4vbecLbQj1030yzdApI586dssB54CPK?=
 =?us-ascii?Q?P7xFN+q9NFqgVvmuqVm8+e1gyqyt5qgYKh++f2vxUtv0gMmIYQIGFtGGC7Se?=
 =?us-ascii?Q?YnGWQYznteDckSjNNvXzXD6gftTYu7oDzmKJmmlWb9RgYqXQDsDgDfkyg2Tt?=
 =?us-ascii?Q?hPNETbJ768p3UtOFaZDNA4IJw8CDFtmQd6+Qx7NToHYzrhNllUgtdo8cgNd7?=
 =?us-ascii?Q?ShjcQw/vCEV/cGAVstEX1Y7es+RTwNcJ4RFGesKdwVvWtAVqiAHknU2eEX52?=
 =?us-ascii?Q?jFR5MIosve0CptXKkepXMV7CT+tedXYCW8aEZIg6Hfa5J6wpDNpLnHN4h+9r?=
 =?us-ascii?Q?Qxz0GPQUHLRUh6SEBIoxU/WOeoNrecmpQfaRr+HupobvMoY7+7UluNJgKjUa?=
 =?us-ascii?Q?zbB8fLXtubfSv1LkS1hiF0o4mAt8rzlVmSs5eSlYZ9+Qc10WGA0W/mreRUjn?=
 =?us-ascii?Q?03fa8w7185XArmEqOOmSCxhuriGnpNnX/nIFS0xV1a810DBQnE+bNdIstjaB?=
 =?us-ascii?Q?o2/zrNbu9o1zDWtJPjQ2lA/TYQeTqBcrCRjt78RwdEzwLWArV3gDtLyzDTk/?=
 =?us-ascii?Q?3i5AG3qylmiM6OcD9cizC4thL+jOsRxAqBfjNVkwAaV3zAF1cGNxkQrQwxgk?=
 =?us-ascii?Q?esqIs+F6KiSkynVTNDSgGPNEhdYBYutG8c1/e//FdD7mL8U/5nM1vQtRV03v?=
 =?us-ascii?Q?9X+Yl6djIA28TmSOwCyE/pFylX59NwA6+fvxCMwMhKMP8jWicUoA9ak/imwQ?=
 =?us-ascii?Q?rnh/EhplcMTOd28C4/6anwrdmPfm1cIuHx6lQBul3mZNUwMFp/2OMY5wEIRn?=
 =?us-ascii?Q?ghBkh4D1rYJbdVmjnieWqUUKXKpE8L2cYQdQFAq4D89d6PS8qOAN2p463oDO?=
 =?us-ascii?Q?ptgaU9UQdASTf/ehGlzgM02TJIJfODEBu9oTVGAssz6ZJyfPvHFHQvyih0+7?=
 =?us-ascii?Q?SPyQNJAoqrcfrklFWKSYBQLTcjZj3LE38bPQV16A9BT+44/QNfilHzioh6p8?=
 =?us-ascii?Q?2QjQtGOtxoU2/msLbNoDiIsXvYFV58Zdj2ZzNv/h118RitYlSbrH/wTd3y2U?=
 =?us-ascii?Q?1M66fG0f9OKDLpWG5hztLs6nCTVKZhxyUACp1fD5FF+fhRnL9pgdsy9Ys3dZ?=
 =?us-ascii?Q?s6Rbtr/sAaTjY5jzh9qKFU+3JM+6Xk72mN8034NDzEu1BU+XMoMAiCDcxdwt?=
 =?us-ascii?Q?Luurl5cq9PeKCe5LINHYhoADEu5CwY7vj5q2CbWigaLpCjTOAcSHLSNeNzsJ?=
 =?us-ascii?Q?RBOZUMgXNxNToe4UOvsjND83SV9SMDOtEVvppmb72zRqFkpj57nQ90jzWutt?=
 =?us-ascii?Q?V8vRxMV6vulpjCt9XJzLp8HZHVX+taipz7TL/S+2hi1N51gjzhCbJ9hTZthP?=
 =?us-ascii?Q?/rlmDvxZRoetsM9KIAK6SPJjg2vGPuxlto3u1ErGbWbmiPuLLCBItIZ4VDDw?=
 =?us-ascii?Q?99zd8IuO5Hq/3pD9O93+u0QMc5wzfAk8XbhVaxnoEEbCcK7cXJfm7lpbeUng?=
 =?us-ascii?Q?SRuI/2EpRgPJPJtZhqk=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 554ee1ed-fe36-4046-f990-08dab5dc7a18
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2022 16:26:17.5998
 (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: Qb3hMsXPVlUknvKxlH81w/nhfBHhOGWW8jMv73JpxNoY8o4YbH5KNdTOr+NyRJu+
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5308
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        SPF_HELO_PASS,SPF_NONE 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 Mon, Oct 24, 2022 at 05:22:24PM +0200, Niklas Schnelle wrote:

> Thanks for the explanation, still would like to grok this a bit more if
> you don't mind. If I do read things correctly synchronize_rcu() should
> run in the conext of the VFIO ioctl in this case and shouldn't block
> anything else in the kernel, correct? At least that's how I understand
> the synchronize_rcu() comments and the fact that e.g.
> net/vmw_vsock/virtio_transport.c:virtio_vsock_remove() also does a
> synchronize_rcu() and can be triggered from user-space too.

Yes, but I wouldn't look in the kernel to understand if things are OK
 
> So we're
> more worried about user-space getting slowed down rather than a Denial-
> of-Service against other kernel tasks.

Yes, functionally it is OK, but for something like vfio with vIOMMU
you could be looking at several domains that have to be detached
sequentially and with grace periods > 1s you can reach multiple
seconds to complete something like a close() system call. Generally it
should be weighed carefully

Jason