scsi: qla2xxx: Fix N2N and NVMe connect retry failure
FC-NVMe target discovery failed when initiator wwpn < target wwpn in an N2N
(Direct Attach) config, where the driver was stuck on FCP PRLI mode and
failed to retry with NVMe PRLI.
Driver was using a shorter timeout waiting for PLOGI from the peer in
point-to-point configurations. Some devices takes some time (~4 seconds) to
initiate the PLOGI. This peer initiating PLOGI is when the peer has a
higher P-WWN.
When transitioning from loop to N2N, stale NPort ID is not
re-assigned. Stale ID can collide with remote device. This patch will
re-assign NPort ID on N2N is detected.
For N2N, fc_port struct is created during report id acquisition. At
later time, the loop resync (fabric, n2n, loop) would trigger the rest
of the login using the created fc_port struct. The loop resync logic
can trigger another fc_port allocation if the 1st allocation was not
able to execute. This patch prevents the 2nd allocation trigger.
Signed-off-by: Bruce Allan <email address hidden>
Signed-off-by: Tony Nguyen <email address hidden>
Tested-by: Andrew Bowers <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit 195fb97766da1b41b4d49bccc37e13603bcb49cc)
Signed-off-by: Michael Reed <email address hidden>
Acked-by: Krzysztof Kozlowski <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.
Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub
<CPU A, t0>: Executing: __netif_receive_skb() ->__netif_receive_skb_core()
-> arp_rcv() -> arp_process().arp_process() calls __neigh_lookup() which
takes a reference on neighbour entry 'n'.
Moves further along, arp_process() and calls neigh_update()->
__neigh_update(). Neighbour entry is unlocked just before a call to
neigh_update_gc_list.
This unlocking paves way for another thread that may take a reference on
the same and mark it dead and remove it from gc_list.
<CPU B, t1> - neigh_flush_dev() is under execution and calls
neigh_mark_dead(n) marking the neighbour entry 'n' as dead. Also n will be
removed from gc_list.
Moves further along neigh_flush_dev() and calls
neigh_cleanup_and_release(n), but since reference count increased in t1,
'n' couldn't be destroyed.
<CPU A, t3>- Code hits neigh_update_gc_list, with neighbour entry
set as dead.
<CPU A, t4> - arp_process() finally calls neigh_release(n), destroying
the neighbour entry and we have a destroyed ntry still part of gc_list.
Fixes: eb4e8fac00d1("neighbour: Prevent a dead entry from updating gc_list")
Signed-off-by: Chinmay Agarwal <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
