Thanks for the review. I have prepared a four-patch v8 based on net-next commit 05b5019b01fb, with the following dispositions.
On Wed, 14 Oct 2026 08:15:58 +0000, [email protected] wrote: > The commit message says the effective limit is enforced on every request. > Should the in-tree producers be switched to that same limit? Fixed in v8 patch 4. The admission path, GDMA queue-region size check and RDMA MR builder share min(negotiated TX limit, allocated SQ stride). RDMA CREATE and ADD_PAGES batches are sized from that budget, with header-plus-one-page checks before subtraction. The RX allocation stride is not rewritten, since RX indexing still depends on it. The GDMA queue-region helper retains its existing single-request rejection contract; only the existing RDMA MR path performs multi-message chunking. > This closes an existing hole. Could it be split into a separate fix with a > Fixes: tag, so stable trees pick it up? Agreed: checking the device-supplied doorbell also hardens the initial establishment, not just a rebuilt channel. The v8 commit message now says so explicitly. I am not labeling the whole dynamic-depth feature patch as a standalone stable fix. A minimal backport of initial doorbell validation/failure reporting belongs in a separately qualified net/stable follow-up; that routing work is deferred rather than dismissed. > No dynamic-depth capability bit exists in the tree. The only DYNAMIC flag in > include/net/mana/gdma.h is GDMA_DRV_CAP_FLAG_1_DYNAMIC_IRQ_ALLOC_SUPPORT. > Also, "from v5" won't mean anything once this is in git history. Fixed in the v8 commit message. The references to a goto-heavy 'v5' and a nonexistent proposed capability bit are removed. The message explains the actual initial-report negotiation and driver-version ordering. Revision-to-revision notes belong in the cover/changelog, not as unexplained history in the commit. > Should the EQ test be part of the rebuild, so a failure there also falls > back to bootstrap? With the parent commit, the same PF would have run on a > tested depth-one channel. Recovery retries would also go through the same > rebuild again. Fixed in v8 patch 4. Candidate functional testing is now inside the bounded rebuild decision, and fresh bootstrap fallback is also tested before publication. A failed candidate is not reused without acknowledged teardown, fallback is attempted at most once, and its own error is returned. The prior live timeout budget is restored before fallback so a failed candidate's one-millisecond reduction does not poison the retry; zero cancellation is never revived. > This isn't a bug, but is this comment accurate? mana_hwc_destroy_queues() > is also reached during runtime teardown: Fixed both comments. Queue destruction now states that setup is private while runtime teardown has unpublished the channel and drained senders. Partial initialization cleanup is assigned to the setup path rather than only mana_hwc_create_channel(). > A later mana_gd_send_request() on that retained channel would compute > req_limit = min(0, ...) = 0 here. It would then return -EMSGSIZE and log > an unratelimited dev_err() on every attempt. Before this patch it returned > -ENODEV, because channel_up is false. Fixed in v8 patch 4. The size preflight is performed before admission or caller-state publication, but a stopped channel takes -ENODEV precedence under the resource lock. A retained never-prepared context with zero negotiated limits therefore does not produce a bogus -EMSGSIZE or its size-error log. > Wouldn't wait_for_completion_timeout() run the full 60 seconds and return > -ETIMEDOUT, instead of failing fast with -EPROTO? On the rebuild path this > can happen at each establish stage. Fixed in v8 patch 4. Invalid doorbell metadata latches -EPROTO and completes the initialization wait immediately; it does not depend on INIT_DONE or another EQ re-arm. Establishment resets the latch for its new generation and checks it before publishing the CQ table. Later apparently valid events cannot erase an already-recorded fatal initialization error. Regards, Wei
