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:   Fri, 21 Oct 2022 10:36:31 -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: <Y1KgX8EwH8T+FgWC@nvidia.com>
References: <20221018145132.998866-1-schnelle@linux.ibm.com>
 <20221018145132.998866-4-schnelle@linux.ibm.com>
 <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>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <68d91d7a5aadbd46dc34470eccd6b86a84c9e47b.camel@linux.ibm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?phgGFgHXAikTxmYVSV5qH+OvHTn8iDSt1Rfnn6Z6usTfngadE1xyI/HGD0cm?=
 =?us-ascii?Q?0zgB0da3TxLzr4A2yURAbdxc41fnZ1dFdMmXt1rRtlGM/4YuqSybeDPKUJFd?=
 =?us-ascii?Q?DXWJfwLSSeMYxBTNuLHl+746wipq6TzeOi32RMdjL/pXtfx/AfyxAvR9hTKG?=
 =?us-ascii?Q?C8zib9fcfyfhbCJnCk1cglnUIps2MwL1fMrBZ5Gsx6SgZSFGyGYij6ox1FA2?=
 =?us-ascii?Q?/+Ln7s1yWBBo5dYaMHy48PHpTiZG4ZyJ3i+fMdazFAZNL5Lea4oa7blrdHt6?=
 =?us-ascii?Q?RvODbuO3sqtnAzi6uFdmmYV10bcePFHRQnVGTLuXKDyiympD2IK3lKRWvmrV?=
 =?us-ascii?Q?iqGU/i4LoOSihAjiWEOsOt2ol4kaaomBcCQWNf0erulbnLnr6JjgW/6QUIIB?=
 =?us-ascii?Q?RrVWHcuBz432dq1tmbYi+oeIR4HPi1VeQeySKm0NiWnoOT1unvsfVk4v4byk?=
 =?us-ascii?Q?b+3oEZlH0Z0bsPj9Ad0JcBXyK6dXlAKFVC1JVSvwNN3olvhYACsEVVluk2Z8?=
 =?us-ascii?Q?mwvARGHp7pdwlJ1kV1VmG6U3PoiiK+r/X1uoW5W7LpbXiTm4dngmuY1AQsSf?=
 =?us-ascii?Q?35vUWN7QymmCMXve7Gix+yz0REb5Xso4FNYET/0fXLP+6H4p6wzaj3wk/jIe?=
 =?us-ascii?Q?ULLWmpPWUWxx0mqqXknLk49cmU9R7mr9YahMxo4YqBLh4im1IZsLydRDe/QU?=
 =?us-ascii?Q?fBIhmXLCzItKmVNy7psRbkdjTP6bfY7OSQeXLeULYWqJODDLrIuZmdfI0gEs?=
 =?us-ascii?Q?LvSuwcJZenChyxbutwKeMutjR8M16hGUbK8vifJfj5Yt4nSDw4BM9ERhVgH9?=
 =?us-ascii?Q?GaQ32PjOHWFp9lm7/rjVyQgf/fGz6lXX9DpoFP/TMph2WJR+Z0D5Gt5VhSbF?=
 =?us-ascii?Q?+594qrBSknBS7Vb9palA0RnRr0ueG7zBPKLEnzotb56CoWcWm/6oVhdXLB+6?=
 =?us-ascii?Q?VW60mO6l08/Z/0Q3pCjeibYJQu9NQjux/wl/xApmCSIgSCeM2fde8hs8YqkE?=
 =?us-ascii?Q?Wzc1rLeCgqBidtEDD7BpFhOQnsqDfgQA7/43mZ2OH2iCmTBqwtlaMLn4pS6H?=
 =?us-ascii?Q?jZYkhYTNZaF290Jmkca1fNeMuQ/iuqucipoQHGqnYpnY51S6/AUThekGfk9G?=
 =?us-ascii?Q?ImPVwPXzxLz0YXjqh/EAXZW6YQAI6s0XTf/I1tOL98ex+XPENK4Nh1c6TQxY?=
 =?us-ascii?Q?3axiB+80ndCxvbGd1ibhiUMtHfm1CO7b9F6TR1fVsCGnmfXQeScwlZO8wsg4?=
 =?us-ascii?Q?UMb6YfjaVLzPk3LT2fRi1+FlXhL2p7h4LD4Uq55RszJNNcy+gdNJfC7py+DE?=
 =?us-ascii?Q?/I9QyC30CpIlly+BGVrRbWdn0dRmZNah/hP6o3ABDkEe10MEm4juEGH+Hhr5?=
 =?us-ascii?Q?s9oWch/f7ZhpxeQJNY2KdM1K2AZzf37o457Jcvie1D9P40UbdivI5hqRelIu?=
 =?us-ascii?Q?ZqWtygGtT66TkRXG3TE4TxYGlqZXQkGvPRmYHVJ9sccI9n6UNctCItKhCuZW?=
 =?us-ascii?Q?9+va3HsENPV+AkeLZ1CEvoTyRiombFmQ6cKSPE3RXkmHXbrpJkcdYCDd9Xcm?=
 =?us-ascii?Q?Pju4R5iVm5Xchhb7gCs=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f64f4b1-61e5-4dab-d04e-08dab369440b
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2022 13:36:32.2471
 (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: w2TVtWNjPrBmvb6Lk9OUBMb4BgKHvF4NOvvaB02Yit0I3IB7vwpm3qJjWXD7c88y
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB5507
X-Spam-Status: No, score=-1.4 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,
        URIBL_BLOCKED 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 Fri, Oct 21, 2022 at 02:08:02PM +0200, Niklas Schnelle wrote:
> On Thu, 2022-10-20 at 08:05 -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 20, 2022 at 10:51:10AM +0200, Niklas Schnelle wrote:
> > 
> > > Ok that makes sense thanks for the explanation. So yes my assessment is
> > > still that in this situation the IOTLB flush is architected to return
> > > an error that we can ignore. Not the most elegant I admit but at least
> > > it's simple. Alternatively I guess we could use call_rcu() to do the
> > > zpci_unregister_ioat() but I'm not sure how to then make sure that a
> > > subsequent zpci_register_ioat() only happens after that without adding
> > > too much more logic.
> > 
> > This won't work either as the domain could have been freed before the
> > call_rcu() happens, the domain needs to be detached synchronously
> > 
> > Jason
> 
> Yeah right, that is basically the same issue I was thinking of for a
> subsequent zpci_register_ioat(). What about the obvious one. Just call
> synchronize_rcu() before zpci_unregister_ioat()?

Ah, it can be done, but be prepared to wait >> 1s for synchronize_rcu
to complete in some cases.

What you have seems like it could be OK, just deal with the ugly racy
failure

Jason