how to do fc_remote_port_delete correctly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This seems pretty basic, but I'm having trouble with it.

The current libfc code has a private structure called fc_rport_libfc_priv
that gets allocated along with the fc_rport structure.

I'm working on patches that restructure this to be separately allocated,
since we need a the private structure to be around before we can do
fc_remote_port_add().  It's a long story, but my question applies to
any FC driver that wants to allocate its rport private data separately.

How should rport->dd_data be set to NULL before/after calling
fc_rport_delete().

I used to set it to NULL before, but figure it's safer to clear it after
terminate_io has been called.  I did a get_device(&rport->dev) first
to be sure the rport doesn't get freed in the meantime.

However, other threads may be in queuecommand already and already
beyond their call to fc_remote_port_chkready() and will reference dd_data.
Maybe they just aren't allowed do that?

Or maybe dd_data isn't allowed to go NULL until the rport times
out and is getting deleted?

Maybe we need a small private rport data with just enough info for the I/O
that's already in progress, or I can recode the I/O path to not use
dd_data (it's mostly stuff that can be gotten through scsi_host instead).

Or maybe we need to do more in our fc_rport_terminate_io callback
from fc_remote_port_delete() to be sure that all I/O really ceases.
We currently do an exch_mgr_reset(), but perhaps some I/O thread hasn't
allocated an exchange yet.

Ideas?

	Thanks,
	Joe



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux