Re: [PATCH 3/6] be2iscsi: Fix MCCQ posting for Mbx-Cmd after driver initialization is complete

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

 



On 04/03/2014 01:30 PM, Mike Christie wrote:
> On 04/03/2014 12:02 AM, Jayamohan Kallickal wrote:
>>
>>
>> -----Original Message-----
>> From: Mike Christie [mailto:michaelc@xxxxxxxxxxx] 
>> Sent: Thursday, March 27, 2014 5:46 PM
>> To: Jayamohan Kallickal; jbottomley@xxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx
>> Cc: Jayamohan Kallickal; Sony John-N
>> Subject: Re: [PATCH 3/6] be2iscsi: Fix MCCQ posting for Mbx-Cmd after driver initialization is complete
>>
>> On 03/27/2014 09:39 AM, Jayamohan Kallickal wrote:
>>>  Even before probe for function was completed, iSCSI Daemon had 
>>> initiated login  to target while OS was coming up. The targets which 
>>> had node.startup=automatic,  login process was initiated.Since 
>>> function specific initialization was still in  progress this lead to kernel panic.
>>>  The reson was MCCQ was not yet created and login Mbx_Cmd was sent on MCCQ.
>>>  wrb_from_mccq() failed with kernel-panic access.
>>>
>>>  In the fix checking in alloc_mcc_tag() if driver initialization is complete or not.
>>>  Based on the result driver continues or return with an Error.
>>>
>>> Signed-off-by: John Soni Jose <sony.john-n@xxxxxxxxxx>
>>> Signed-off-by: Jayamohan Kallickal <Jayamohan.Kallickal@xxxxxxxxxx>
>>> ---
>>>  drivers/scsi/be2iscsi/be_cmds.c | 8 ++++++++  
>>> drivers/scsi/be2iscsi/be_main.c | 2 ++  
>>> drivers/scsi/be2iscsi/be_main.h | 1 +
>>>  3 files changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/scsi/be2iscsi/be_cmds.c 
>>> b/drivers/scsi/be2iscsi/be_cmds.c index 1432ed5..4cabf5f 100644
>>> --- a/drivers/scsi/be2iscsi/be_cmds.c
>>> +++ b/drivers/scsi/be2iscsi/be_cmds.c
>>> @@ -118,6 +118,14 @@ unsigned int alloc_mcc_tag(struct beiscsi_hba 
>>> *phba)  {
>>>  	unsigned int tag = 0;
>>>  
>>> +
>>> +	if (phba->state & BE_ADAPTER_INIT_PHASE) {
>>> +		beiscsi_log(phba, KERN_ERR,
>>> +			    BEISCSI_LOG_INIT | BEISCSI_LOG_CONFIG,
>>> +			    "BC_%d : Driver Initialization still in progress\n");
>>> +		return tag;
>>> +	}
>>> +
>>
>>> I think normally we do not call scsi_host_add and expose the host until the driver can handle requests from entry points like sysfs and queuecommand.
>>
>>> Can you just move iscsi_host_add from beiscsi_hba_alloc to beiscsi_dev_probe after beiscsi_setup_boot_info is called?
>>
>> Tried moving iscsi_add_host and it did not help the issue where the ep_connect was being called before the probe is completed.
>>
>> Chris Leech has a solution for this and when applied along with this patch works for us.
>>
> 
> Did you test the host add solution with Chris's fix? With your patch and
> Chris's patch __session_create will return error. iscsiadm would then
> retry and eventually the host would be added. With your patch,
> __session_create -> iscsi_sysfs_get_host_no_from_hwinfo would probably
> fail, because iscsid tries to read a host attr and gets a error because
> the host is not yet setup.
> 
> If you move the host add and uses Chris's patch then something similar
> should happen. The host will not even be in sysfs yet, so
> iscsi_sysfs_get_host_no_from_hwinfo will fail. __session_create will
> return error and iscsiadm will retry.
> 
> For what I am suggesting you do not need "if full_init" tests in every
> driver. The host is not added until it is actually setup.
> 

Hey, also the thing about some of the traces in the rh bz is that you
are getting a oops when iscsid reads a sysfs attr

https://bugzilla.redhat.com/show_bug.cgi?id=1081798#c5

That is not a problem with ep_connect being called too soon. That is a
issue with exposing the host before the driver has setup the host. For
that case you should move the host add and that should fix that problem.

For the other problem Chris is fixing where the wrong ep connect cmd is
called and a null host is passed down it seems be2iscsi already catches
that. Chris's patch is still needed so iscsid does the right thing. Just
saying we are mixing different issues.
--
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