From: Nicolin Chen <nicolinc@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "jgg@nvidia.com" <jgg@nvidia.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"joro@8bytes.org" <joro@8bytes.org>,
"will@kernel.org" <will@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: Re: [PATCH rc 2/2] iommufd/fault: Use a separate spinlock to protect fault->deliver list
Date: Tue, 14 Jan 2025 21:40:23 -0800 [thread overview]
Message-ID: <Z4dKR4ORF/FcfCSD@Asurada-Nvidia> (raw)
In-Reply-To: <BN9PR11MB52769D7C88B3DBBB4DF3A0028C192@BN9PR11MB5276.namprd11.prod.outlook.com>
On Wed, Jan 15, 2025 at 05:24:44AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > Sent: Wednesday, January 15, 2025 7:29 AM
> >
> > @@ -445,12 +445,38 @@ struct iommufd_fault {
> >
> > /* The lists of outstanding faults protected by below mutex. */
> > struct mutex mutex;
> > + spinlock_t lock; /* protects the deliver list */
> > struct list_head deliver;
> > struct xarray response;
>
> Move 'mutex' together with response then?
Ack.
> >
> > +/* Extract the first node out of the fault->deliver list */
> > +static inline struct iopf_group *
> > +iommufd_fault_deliver_extract(struct iommufd_fault *fault)
>
> Probably simpler be iommufd_fault_fetch()
We have deliver and response two lists. So I think that "deliver"
would be necessary. Yet, I can do "fetch" v.s. "extract".
> > @@ -102,17 +102,19 @@ static void iommufd_auto_response_faults(struct
> > iommufd_hw_pagetable *hwpt,
> > struct iommufd_attach_handle
> > *handle)
> > {
> > struct iommufd_fault *fault = hwpt->fault;
> > - struct iopf_group *group, *next;
> > + struct iopf_group *group;
> > unsigned long index;
> >
> > if (!fault)
> > return;
> >
> > mutex_lock(&fault->mutex);
> > - list_for_each_entry_safe(group, next, &fault->deliver, node) {
> > - if (group->attach_handle != &handle->handle)
> > + for (group = iommufd_fault_deliver_extract(fault); group;
> > + group = iommufd_fault_deliver_extract(fault)) {
>
> while (group = iommufd_fault_fetch(fault)) {
> ...
> }
Ah, right...how didn't I see this lol.
>
> > @@ -266,17 +268,20 @@ static ssize_t iommufd_fault_fops_read(struct file
> > *filep, char __user *buf,
> > return -ESPIPE;
> >
> > mutex_lock(&fault->mutex);
> > - while (!list_empty(&fault->deliver) && count > done) {
> > - group = list_first_entry(&fault->deliver,
> > - struct iopf_group, node);
> > -
> > - if (group->fault_count * fault_size > count - done)
> > + for (group = iommufd_fault_deliver_extract(fault); group;
> > + group = iommufd_fault_deliver_extract(fault)) {
> > + if (done >= count ||
> > + group->fault_count * fault_size > count - done) {
> > + iommufd_fault_deliver_restore(fault, group);
> > break;
> > + }
> >
> > rc = xa_alloc(&fault->response, &group->cookie, group,
> > xa_limit_32b, GFP_KERNEL);
> > - if (rc)
> > + if (rc) {
> > + iommufd_fault_deliver_restore(fault, group);
> > break;
> > + }
>
> The scope of mutex can be reduced to just protect the smaller trunk
> touching fault->response.
Ack.
> Otherwise looks good:
>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Thanks!
Nicolin
next prev parent reply other threads:[~2025-01-15 5:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 23:28 [PATCH rc 0/2] iommufd/fault: Two bug fixes prior to vEVENTQ Nicolin Chen
2025-01-14 23:28 ` [PATCH rc 1/2] iommufd/fault: Destroy response and mutex in iommufd_fault_destroy() Nicolin Chen
2025-01-15 0:54 ` Jason Gunthorpe
2025-01-15 5:17 ` Tian, Kevin
2025-01-15 5:21 ` Baolu Lu
2025-01-14 23:28 ` [PATCH rc 2/2] iommufd/fault: Use a separate spinlock to protect fault->deliver list Nicolin Chen
2025-01-15 5:24 ` Tian, Kevin
2025-01-15 5:40 ` Nicolin Chen [this message]
2025-01-15 5:24 ` Baolu Lu
2025-01-15 5:45 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z4dKR4ORF/FcfCSD@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.