svn commit: r291911 - head/sys/dev/iscsi
Steven Hartland
steven at multiplay.co.uk
Mon Dec 7 11:34:00 UTC 2015
On 07/12/2015 11:22, Edward Tomasz Napierała wrote:
> On 1207T0256, Steven Hartland wrote:
>> Author: smh
>> Date: Mon Dec 7 02:56:08 2015
>> New Revision: 291911
>> URL: https://svnweb.freebsd.org/changeset/base/291911
>>
>> Log:
>> Fix panic on shutdown due to iscsi event priority
>>
>> iscsi's shutdown_pre_sync prio was SHUTDOWN_PRI_FIRST which caused it to
>> run before other high priority handlers such as filesystems e.g. ZFS.
>>
>> This meant the iscsi sessions where removed before the ZFS geom consumer
>> was closed, resulting in a panic from g_access calls on debug kernels
>> due to negative acr.
>>
>> Instead use the same as the old iscsi_initiator SHUTDOWN_PRI_DEFAULT-1
>> which allows it to run before dashutdown etc but after filesystems.
> I think this might be backwards. Have you tested the following scenario:
>
> 1. Establish the iSCSI session
> 2. Mount the LUN somewhere
> 3. Make the target not reachable (eg ifconfig down), so that the
> initiator tries to reconnect
> 4. Try to shutdown?
>
> Basically, the point of this code is to disable reconnects when there
> won't be any iscsid(8) instance to handle them. The iscsi_shutdown()
> isn't supposed to remove working iSCSI sessions.
I didn't notice your change in head / stable/10 compared to releng, so
I'm testing further updates now.
Currently shutdown is run too early and actually doesn't actually
terminate any sessions.
My current theory is the issue you tried to fix in 286226 is actually
caused by the iscsi_maintenance_thread preferring reconnect over
terminate, so what you where seeing was the terminate never action for
reconnecting sessions. I'm currently trying to validate that theory now.
If I'm right then the fix should be to revert the majority of 286226 and
move the processing of terminate above reconnect in
iscsi_maintenance_thread.
Regards
Steve
More information about the svn-src-head
mailing list