Re: [PATCH v1] RDMA/core: Fix check_flush_dependency splat on addr_wq

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

 



On Fri, Aug 26, 2022 at 07:57:04PM +0000, Chuck Lever III wrote:
> The connect APIs would be a place to start. In the meantime, though...
> 
> Two or three years ago I spent some effort to ensure that closing
> an RDMA connection leaves a client-side RPC/RDMA transport with no
> RDMA resources associated with it. It releases the CQs, QP, and all
> the MRs. That makes initial connect and reconnect both behave exactly
> the same, and guarantees that a reconnect does not get stuck with
> an old CQ that is no longer working or a QP that is in TIMEWAIT.
> 
> However that does mean that substantial resource allocation is
> done on every reconnect.

And if the resource allocations fail then what happens? The storage
ULP retries forever and is effectively deadlocked?

How much allocation can you safely do under GFP_NOIO?

Jason



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux