From: Mike Christie <michaelc@cs.wisc.edu>
To: Jing Huang <huangj@Brocade.COM>
Cc: James.Bottomley@HansenPartnership.com,
Krishna Gudipati <kgudipat@Brocade.COM>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
Ramkumar Vadivelu <rvadivel@Brocade.COM>,
Vinodh Ravindran <vravindr@Brocade.COM>
Subject: Re: [PATCH 1/5] bfa: Brocade BFA FC SCSI driver (bfad)
Date: Mon, 23 Mar 2009 12:17:23 -0500 [thread overview]
Message-ID: <49C7C423.5010202@cs.wisc.edu> (raw)
In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E02B4B4A2@HQ-EXCH-5.corp.brocade.com>
Jing Huang wrote:
>>> +
>>> + im_port->shost->hostdata[0] = (unsigned long)im_port;
>>
>>
>> I think I asked about this before. Why do you just not allocate the
> bfad
>> or im_port in the hostdata? What is the struct hierarchy? Do you have
>> one bfad for the entire HBA/pci_device then have a im_port for each
> port
>> on the hba?
>>
>
> Thanks for review the code again. Yes, we have one bfad for each HBA
> port/pci device, and one im_port (im stands for initiator mode) for each
> scsi_host/vport. We can certainly allocate im_port in scsi_host_alloc()
> as you suggest, but currently we allocate all possible fc4 port
> (initiator/tgt/ipfc) in one function, and it is just more convenient to
> do it in one place.
I think the refcounting is off though. For example in the shutdown case,
if someone is accessing a scsi host sysfs attr, bfad_im_scsi_host_free
would release the drivers refcounts on the scsi_host and free the
im_port, but the sysfs code could still be accessing the im port. The
shost would still be there because the sysfs code took a refcount on
kobject/kref, but the im port is now gone. When you allocate the port
struct in the hostdata with scsi_host_alloc this type of issue is
handled for you.
next prev parent reply other threads:[~2009-03-23 17:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-14 20:03 [PATCH 1/5] bfa: Brocade BFA FC SCSI driver (bfad) Jing Huang
2009-03-14 21:11 ` Sam Ravnborg
2009-03-19 17:19 ` Mike Christie
2009-03-21 23:03 ` Jing Huang
2009-03-23 17:17 ` Mike Christie [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-03-24 0:10 Krishna Gudipati
2009-03-24 11:05 ` Rolf Eike Beer
2009-03-25 19:36 ` Krishna Gudipati
2009-04-02 3:33 Krishna Gudipati
2009-04-02 9:00 ` Rolf Eike Beer
2009-07-20 6:22 Jing Huang
2009-07-20 7:43 ` Sam Ravnborg
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=49C7C423.5010202@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=James.Bottomley@HansenPartnership.com \
--cc=huangj@Brocade.COM \
--cc=kgudipat@Brocade.COM \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rvadivel@Brocade.COM \
--cc=vravindr@Brocade.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