mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Calvin Owens <calvinowens@fb.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Nagalakshmi Nandigama <nagalakshmi.nandigama@avagotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@avagotech.com>,
	Sreekanth Reddy <sreekanth.reddy@avagotech.com>,
	Abhijit Mahajan <abhijit.mahajan@avagotech.com>,
	<MPT-FusionLinux.pdl@avagotech.com>, <linux-scsi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [PATCH 2/6] Refactor code to use new sas_device refcount
Date: Sat, 11 Jul 2015 21:15:29 -0700	[thread overview]
Message-ID: <20150712041529.GA4066426@mail.thefacebook.com> (raw)
In-Reply-To: <20150703153803.GB4472@infradead.org>

On Friday 07/03 at 08:38 -0700, Christoph Hellwig wrote:
> >  
> > +struct _sas_device *
> > +mpt2sas_scsih_sas_device_get_by_sas_address_nolock(struct MPT2SAS_ADAPTER *ioc,
> > +    u64 sas_address)
> 
> Any chance to use a shorter name for this function? E.g.
> __mpt2sas_get_sdev_by_addr ?

Will do.

> > +{
> > +	struct _sas_device *sas_device;
> > +
> > +	BUG_ON(!spin_is_locked(&ioc->sas_device_lock));
> 
> This will blow on UP builds.  Please use assert_spin_locked or
> lockdep_assert_held instead.  And don't ask me which of the two,
> that's a mystery I don't understand myself either.

Will do.

> >  struct _sas_device *
> > -mpt2sas_scsih_sas_device_find_by_sas_address(struct MPT2SAS_ADAPTER *ioc,
> > +mpt2sas_scsih_sas_device_get_by_sas_address(struct MPT2SAS_ADAPTER *ioc,
> >      u64 sas_address)
> >  {
> 
> > +static struct _sas_device *
> > +_scsih_sas_device_get_by_handle_nolock(struct MPT2SAS_ADAPTER *ioc, u16 handle)
> 
> >  static struct _sas_device *
> > -_scsih_sas_device_find_by_handle(struct MPT2SAS_ADAPTER *ioc, u16 handle)
> > +_scsih_sas_device_get_by_handle(struct MPT2SAS_ADAPTER *ioc, u16 handle)
> 
> Same comments about the function names as above.
> 
> > +	struct _sas_device *sas_device;
> > +
> > +	BUG_ON(!spin_is_locked(&ioc->sas_device_lock));
> 
> Same comment about the right assert helpers as above.
> 
> > @@ -594,9 +634,15 @@ _scsih_sas_device_remove(struct MPT2SAS_ADAPTER *ioc,
> >  	if (!sas_device)
> >  		return;
> >  
> > +	/*
> > +	 * The lock serializes access to the list, but we still need to verify
> > +	 * that nobody removed the entry while we were waiting on the lock.
> > +	 */
> >  	spin_lock_irqsave(&ioc->sas_device_lock, flags);
> > -	list_del(&sas_device->list);
> > -	kfree(sas_device);
> > +	if (!list_empty(&sas_device->list)) {
> > +		list_del_init(&sas_device->list);
> > +		sas_device_put(sas_device);
> > +	}
> >  	spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
> 
> This looks odd to me.  Normally you'd have the lock from the list
> iteration that finds the device.  From looking at the code it seems
> like this only called from probe failure paths, though.  It seems like
> for this case the device simplify shouldn't be added until the probe
> succeeds and this function should go away?

There's a horrible maze of dependencies on things being on the lists
while being added that make this impossible: I spent some time trying
to get this to work, but I always end up with no drives. :(

(The path through _scsih_probe_sas() seems not to care)

I was hopeful your suggestion below about putting the sas_device
pointer in ->hostdata would eliminate the need for all the find_by_X()
lookups, but some won't go away.

> > @@ -1208,12 +1256,15 @@ _scsih_change_queue_depth(struct scsi_device *sdev, int qdepth)
> >  		goto not_sata;
> >  	if ((sas_target_priv_data->flags & MPT_TARGET_FLAGS_VOLUME))
> >  		goto not_sata;
> > +
> >  	spin_lock_irqsave(&ioc->sas_device_lock, flags);
> > -	sas_device = mpt2sas_scsih_sas_device_find_by_sas_address(ioc,
> > +	sas_device = mpt2sas_scsih_sas_device_get_by_sas_address_nolock(ioc,
> >  	   sas_device_priv_data->sas_target->sas_address);
> > -	if (sas_device && sas_device->device_info &
> > -	    MPI2_SAS_DEVICE_INFO_SATA_DEVICE)
> > +	if (sas_device && sas_device->device_info
> > +			& MPI2_SAS_DEVICE_INFO_SATA_DEVICE) {
> >  		max_depth = MPT2SAS_SATA_QUEUE_DEPTH;
> > +		sas_device_put(sas_device);
> > +	}
> 
> Please store a pointer to the sas_device in struct scsi_target ->hostdata
> in _scsih_target_alloc and avoid the need for this and other runtime
> lookups where we have a scsi_device or scsi_target structure available.

Will do.

> > @@ -1324,13 +1377,15 @@ _scsih_target_destroy(struct scsi_target *starget)
> >  
> >  	spin_lock_irqsave(&ioc->sas_device_lock, flags);
> >  	rphy = dev_to_rphy(starget->dev.parent);
> > -	sas_device = mpt2sas_scsih_sas_device_find_by_sas_address(ioc,
> > +	sas_device = mpt2sas_scsih_sas_device_get_by_sas_address_nolock(ioc,
> >  	   rphy->identify.sas_address);
> >  	if (sas_device && (sas_device->starget == starget) &&
> >  	    (sas_device->id == starget->id) &&
> >  	    (sas_device->channel == starget->channel))
> >  		sas_device->starget = NULL;
> >  
> > +	if (sas_device)
> > +		sas_device_put(sas_device);
> >  	spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
> 
> .. like this one.
> 
> >   out:
> > @@ -1386,7 +1441,7 @@ _scsih_slave_alloc(struct scsi_device *sdev)
> >  
> >  	if (!(sas_target_priv_data->flags & MPT_TARGET_FLAGS_VOLUME)) {
> >  		spin_lock_irqsave(&ioc->sas_device_lock, flags);
> > -		sas_device = mpt2sas_scsih_sas_device_find_by_sas_address(ioc,
> > +		sas_device = mpt2sas_scsih_sas_device_get_by_sas_address_nolock(ioc,
> >  				sas_target_priv_data->sas_address);
> >  		if (sas_device && (sas_device->starget == NULL)) {
> >  			sdev_printk(KERN_INFO, sdev,
> 
> .. or this one ..
> 
> > @@ -1428,10 +1487,13 @@ _scsih_slave_destroy(struct scsi_device *sdev)
> >  
> >  	if (!(sas_target_priv_data->flags & MPT_TARGET_FLAGS_VOLUME)) {
> >  		spin_lock_irqsave(&ioc->sas_device_lock, flags);
> > -		sas_device = mpt2sas_scsih_sas_device_find_by_sas_address(ioc,
> > +		sas_device = mpt2sas_scsih_sas_device_get_by_sas_address_nolock(ioc,
> >  		   sas_target_priv_data->sas_address);
> >  		if (sas_device && !sas_target_priv_data->num_luns)
> >  			sas_device->starget = NULL;
> > +
> > +		if (sas_device)
> > +			sas_device_put(sas_device);
> >  		spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
> 
> .. and this, and many more.
> 

  reply	other threads:[~2015-07-12  4:16 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04 15:05 [PATCH] mpt2sas: mpt3sas: Fix memory corruption during initialization Sreekanth Reddy
2015-05-05 15:35 ` Tomas Henzl
2015-05-12  9:38   ` Sreekanth Reddy
2015-05-06 18:48 ` Calvin Owens
2015-05-15  3:41   ` [PATCH 0/6] Fixes for memory corruption in mpt2sas Calvin Owens
2015-05-15  3:41     ` [PATCH 1/6] Add refcount to sas_device struct Calvin Owens
2015-05-15  3:41     ` [PATCH 2/6] Refactor code to use new sas_device refcount Calvin Owens
2015-05-15  3:41     ` [PATCH 3/6] Fix unsafe sas_device_list usage Calvin Owens
2015-05-15  3:42     ` [PATCH 4/6] Add refcount to fw_event_work struct Calvin Owens
2015-05-15  3:42     ` [PATCH 5/6] Refactor code to use new fw_event refcount Calvin Owens
2015-05-15  3:42     ` [PATCH 6/6] Fix unsafe fw_event_list usage Calvin Owens
2015-06-09  3:50     ` [RESEND][PATCH 0/6] Fixes for memory corruption in mpt2sas Calvin Owens
2015-06-09  3:50       ` [PATCH 1/6] Add refcount to sas_device struct Calvin Owens
2015-07-03 15:24         ` Christoph Hellwig
2015-06-09  3:50       ` [PATCH 2/6] Refactor code to use new sas_device refcount Calvin Owens
2015-07-03 15:38         ` Christoph Hellwig
2015-07-12  4:15           ` Calvin Owens [this message]
2015-06-09  3:50       ` [PATCH 3/6] Fix unsafe sas_device_list usage Calvin Owens
2015-07-03 16:03         ` Christoph Hellwig
2015-06-09  3:50       ` [PATCH 4/6] Add refcount to fw_event_work struct Calvin Owens
2015-07-03 15:38         ` Christoph Hellwig
2015-06-09  3:50       ` [PATCH 5/6] Refactor code to use new fw_event refcount Calvin Owens
2015-07-03 16:00         ` Christoph Hellwig
2015-07-12  4:13           ` Calvin Owens
2015-06-09  3:50       ` [PATCH 6/6] Fix unsafe fw_event_list usage Calvin Owens
2015-07-03 16:02         ` Christoph Hellwig
2015-07-12  4:20           ` Calvin Owens
2015-07-02 20:15       ` [RESEND][PATCH 0/6] Fixes for memory corruption in mpt2sas Bart Van Assche
2015-07-12  4:24       ` [PATCH 0/2 v2] " Calvin Owens
2015-07-12  4:24         ` [PATCH 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list usage Calvin Owens
2015-07-13  6:52           ` Christoph Hellwig
2015-07-21  7:06             ` Calvin Owens
2015-07-13 15:05           ` Joe Lawrence
2015-07-21  7:04             ` Calvin Owens
2015-07-16 14:57           ` Sreekanth Reddy
2015-07-21  7:03             ` Calvin Owens
2015-07-12  4:24         ` [PATCH 2/2] mpt2sas: Refcount fw_events " Calvin Owens
2015-07-13  6:52           ` Christoph Hellwig
2015-08-01  5:02         ` [PATCH v3 0/2] Fixes for memory corruption in mpt2sas Calvin Owens
2015-08-01  5:02           ` [PATCH v3 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list usage Calvin Owens
2015-08-10 13:15             ` Sreekanth Reddy
2015-08-14  1:43               ` Calvin Owens
2015-08-01  5:02           ` [PATCH v3 2/2] mpt2sas: Refcount fw_events " Calvin Owens
2015-08-14  1:48           ` [PATCH v4 0/2] Fixes for memory corruption in mpt2sas Calvin Owens
2015-08-14  1:48             ` [PATCH v4 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list usage Calvin Owens
2015-08-14  1:48               ` [PATCH v4 2/2] mpt2sas: Refcount fw_events " Calvin Owens
2015-08-25 21:06                 ` Nicholas A. Bellinger
2015-09-04 14:35                 ` Sreekanth Reddy
2015-08-25 21:03               ` [PATCH v4 1/2] mpt2sas: Refcount sas_device objects " Nicholas A. Bellinger
2015-09-04 14:34               ` Sreekanth Reddy
2015-08-25 21:21             ` [PATCH v4 0/2] Fixes for memory corruption in mpt2sas Nicholas A. Bellinger
2015-07-02 19:22     ` [PATCH 0/6] " Jens Axboe

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=20150712041529.GA4066426@mail.thefacebook.com \
    --to=calvinowens@fb.com \
    --cc=MPT-FusionLinux.pdl@avagotech.com \
    --cc=abhijit.mahajan@avagotech.com \
    --cc=hch@infradead.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nagalakshmi.nandigama@avagotech.com \
    --cc=praveen.krishnamoorthy@avagotech.com \
    --cc=sreekanth.reddy@avagotech.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome