linux-kernel - RE: [PATCH 2/2] scsi: fnic: Remove unnecessary spinlock locking and unlocking

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] [day] [month] [year] [list]

Message-ID:
 <SJ0PR11MB5896FD24A1AFD61EE36F549EC3CD2@SJ0PR11MB5896.namprd11.prod.outlook.com>
Date: Thu, 27 Feb 2025 01:16:00 +0000
From: "Karan Tilak Kumar (kartilak)" <kartilak@...co.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
CC: "Sesidhar Baddela (sebaddel)" <sebaddel@...co.com>, "Arulprabhu Ponnusamy
 (arulponn)" <arulponn@...co.com>, "Dhanraj Jhawar (djhawar)"
	<djhawar@...co.com>, "Gian Carlo Boffa (gcboffa)" <gcboffa@...co.com>, "Masa
 Kai (mkai2)" <mkai2@...co.com>, "Satish Kharat (satishkh)"
	<satishkh@...co.com>, "Arun Easi (aeasi)" <aeasi@...co.com>,
	"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>, "martin.petersen@...cle.com"
	<martin.petersen@...cle.com>, "linux-scsi@...r.kernel.org"
	<linux-scsi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] scsi: fnic: Remove unnecessary spinlock locking and
 unlocking

On Tuesday, February 25, 2025 11:32 PM, Dan Carpenter <dan.carpenter@...aro.org> wrote:
>
> On Tue, Feb 25, 2025 at 01:51:46PM -0800, Karan Tilak Kumar wrote:
> > diff --git a/drivers/scsi/fnic/fdls_disc.c b/drivers/scsi/fnic/fdls_disc.c
> > index 8843d9486dbb..6530298733f0 100644
> > --- a/drivers/scsi/fnic/fdls_disc.c
> > +++ b/drivers/scsi/fnic/fdls_disc.c
> > @@ -311,36 +311,30 @@ void fdls_schedule_oxid_free_retry_work(struct work_struct *work)
> >     unsigned long flags;
> >     int idx;
> >
> > -   spin_lock_irqsave(&fnic->fnic_lock, flags);
> > -
> >     for_each_set_bit(idx, oxid_pool->pending_schedule_free, FNIC_OXID_POOL_SZ) {
> >
> >             FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num,
> >                     "Schedule oxid free. oxid idx: %d\n", idx);
> >
> > -           spin_unlock_irqrestore(&fnic->fnic_lock, flags);
> >             reclaim_entry = kzalloc(sizeof(*reclaim_entry), GFP_KERNEL);
> > -           spin_lock_irqsave(&fnic->fnic_lock, flags);
> > -
> >             if (!reclaim_entry) {
> >                     schedule_delayed_work(&oxid_pool->schedule_oxid_free_retry,
> >                             msecs_to_jiffies(SCHEDULE_OXID_FREE_RETRY_TIME));
> > -                   spin_unlock_irqrestore(&fnic->fnic_lock, flags);
> >                     return;
> >             }
> >
> >             if (test_and_clear_bit(idx, oxid_pool->pending_schedule_free)) {
>
> We discussed this earlier and I really should have brought it up then,
> but what is this check about?  We "know" (scare quotes) that it is true
> because we're inside a for_each_set_bit() loop.  I had assumed it was to
> test for race conditions so that's why I put it under the lock.  If the
> locking doesn't matter then we could just do a clear_bit() without doing
> a second test.
>
> regards,
> dan carpenter
>
> >                     reclaim_entry->oxid_idx = idx;
> >                     reclaim_entry->expires = round_jiffies(jiffies + delay_j);
> > +                   spin_lock_irqsave(&fnic->fnic_lock, flags);
> >                     list_add_tail(&reclaim_entry->links, &oxid_pool->oxid_reclaim_list);
> > +                   spin_unlock_irqrestore(&fnic->fnic_lock, flags);
> >                     schedule_delayed_work(&oxid_pool->oxid_reclaim_work, delay_j);
> >             } else {
> >                     /* unlikely scenario, free the allocated memory and continue */
> >                     kfree(reclaim_entry);
> >             }
> >     }
>
> > -
> > -   spin_unlock_irqrestore(&fnic->fnic_lock, flags);
> >  }
> >
> >  static bool fdls_is_oxid_fabric_req(uint16_t oxid)
> > --
> > 2.47.1
>

Thanks for your review and comments, Dan.
You are right; We reviewed it, and locking is only needed to add to the reclaim list.
We can use clear_bit. I'll send out a revised patch for this.

Regards,
Karan (on behalf of the Cisco team)