linux-kernel - RE: [PATCH rc v4] iommufd/fault: Use a separate spinlock to protect fault->deliver list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276EFF7DF03C91D8F92DB2D8CE72@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 20 Jan 2025 06:08:43 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>
CC: "jgg@...dia.com" <jgg@...dia.com>, "joro@...tes.org" <joro@...tes.org>,
	"will@...nel.org" <will@...nel.org>, "robin.murphy@....com"
	<robin.murphy@....com>, "baolu.lu@...ux.intel.com"
	<baolu.lu@...ux.intel.com>, "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH rc v4] iommufd/fault: Use a separate spinlock to protect
 fault->deliver list

> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Monday, January 20, 2025 2:02 PM
> 
> On Mon, Jan 20, 2025 at 05:37:13AM +0000, Tian, Kevin wrote:
> > > From: Nicolin Chen <nicolinc@...dia.com>
> > > Sent: Saturday, January 18, 2025 3:29 AM
> > >
> > >
> > > Lastly, move the mutex closer to the response in the fault structure,
> > > and update its kdoc accordingly.
> >
> > Then this comment is stale.
> 
> Its position "in the fault structure" is moved though.. :)
> 
> > >
> > > -	/* The lists of outstanding faults protected by below mutex. */
> > > -	struct mutex mutex;
> > > +	spinlock_t lock; /* protects the deliver list */
> > >  	struct list_head deliver;
> > > +	struct mutex mutex; /* serializes response flows */
> > >  	struct xarray response;
> > >
> >
> > And the comment for the mutex should be restored.
> 
> Why? I followed Baolu's suggestion to update that.. The response
> flows are in fops_read/fops_write/auto_response, so I think the
> new comment remains correct?
> 

You are right. Now the patch keeps the original scope for this
mutex which made me consider the lock for both deliver and
response again. But the actual reason is still for response, so
please forget this comment. 😊