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.
>
next prev parent 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