On 11/6/20 1:23 AM, Hannes Reinecke wrote: > On 11/5/20 8:15 PM, Mike Christie wrote: >> On 11/5/20 11:27 AM, Muneendra Kumar M wrote: >>> Hi Mike, >>> Thanks for the input. >>> Below are my replies. >>> >>> >>>> Hey sorry for the late reply. I was trying to test some things out but am >>>> not sure if all drivers work the same. >>> >>>> For the code above, what will happen if we have passed that check in the >>>> driver, then the driver does the report del and add sequence? Let's say >>>> it's initially calling the abort callout, and we passed that check, we then >>>> do the >del/add seqeuence, what will happen next? Do the fc drivers return >>>> success or failure for the abort call. What happens for the other callouts >>>> too? >>> >>>> If failure, then the eh escalates and when we call the next callout, and we >>>> hit the check above and will clear it, so we are ok. >>> >>> If success then we would not get a chance to clear it right? >>> [Muneendra]Agreed. So what about clearing the flags in fc_remote_port_del. I >>> think this should address all the concerns? >>> >>>> If this is the case, then I think you need to instead go the route where >>>> you add the eh cmd completion/decide_disposition callout. You would call >>>> it in scmd_eh_abort_handler, scsi_eh_bus_device_reset, etc when we are >>>> deciding if we want to retry/fail the command. >>> [Muneendra]Sorry I didn't get what you are saying could you please elaborate >>> on the same. >>> >>> In this approach you do not need the eh_timed_out changes, since we only >>> seem to care about the port state after the eh callout has completed. >>> [Muneendra]what about setting the SCMD_NORETRIES_ABORT bit? >>> >> >> I don't think you need it. It sounds like we only care about the port state >> when the cmd is completing. For example we have: >> >> 1. the case where the cmd times out, we do aborts/resets, then the >> port state goes into marginal, then the aborts/resets complete. We want to >> fail the cmds without retries. >> >> 2. If the port state is in marginal, the cmd times out, we do the aborts/resets >> and when we are done if the port state is still marginal we want to fail the >> cmd without retries. >> >> 3. If the port state is marginal (or any value), before or after the cmd >> initially times out, but the port state goes back to online, then when the >> aborts/resets complete we want to retry the cmd. >> > Actually, I don't think the third case can (or should) happen. > A transition from marginal to online should always include a link bounce (ie a rport_del/rport_add sequence), which would cancel all outstanding commands anyway. > And if we have the above provision we could clear the flag in rport_del() and everything would be dandy. That is the part I didn't like or I thought could have issues: 1. What if we go back into marginal after the add() but before we have done scsi_eh_flush_done_q? You need the original looping code and some code for del() right? 2. My issue with #1 is why do we want to add code that loops over commands when we only care about the port state and when scsi_eh_flush_done_q and the abort completion code is already looping over them. 3. This is probably a matter of preference, and I can see why people would not like an extra callout. However, I like the idea that we have an eh callout for the transport class that checks if it's even worth it to run the eh code based on the port state and then we have a eh completion callout that can also check the port state and determine if it's ok. If we had a marginal scsi_device state or even a bit then you would not actually need #3. The fc class could just set the device state/bit and we could check that in the eh completion code paths.
