| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/06/19 20:46 | flow | patch-triage |
2mArgs:null Results: {
"EnableConfigs": [
"RDMA_RXE",
"NVME_RDMA",
"NVME_TARGET_RDMA",
"SUNRPC_XPRT_RDMA",
"CIFS_SMB_DIRECT",
"SMB_SERVER_SMBDIRECT",
"INFINIBAND_SRP",
"INFINIBAND_SRPT",
"INFINIBAND_ISER",
"INFINIBAND_ISERT",
"INFINIBAND_RTRS_CLIENT",
"INFINIBAND_RTRS_SERVER",
"RDS_RDMA",
"INFINIBAND_IPOIB"
],
"FocusSymbols": [
"nvme_rdma_find_get_device",
"nvmet_rdma_find_get_device",
"frwr_query_device",
"rxe_qp_chk_cap",
"rxe_srq_chk_init",
"smbdirect_connection_create_qp",
"rds_ib_cm_fill_conn_param",
"svc_rdma_accept",
"rpcrdma_ep_create"
],
"Reasoning": "The patch changes the types of various RDMA device attributes from `int` to `u32` and updates the corresponding `min()` calls and format strings. It also fixes some potential underflows in connection setup functions. These changes affect the core RDMA logic and various RDMA ULPs (Upper Layer Protocols) which can be tested using the software RDMA driver (RXE). It is worth fuzzing to ensure no regressions or new integer overflow/underflow bugs were introduced.",
"WorthFuzzing": true
} |
| 1/1 | 2026/06/19 20:46 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 3025390b09359e1904d239a1b2741614484be725\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Fri Jun 19 20:46:23 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c\nindex 3d7b6cddd131c4..ee98188e57fb5f 100644\n--- a/drivers/infiniband/core/cq.c\n+++ b/drivers/infiniband/core/cq.c\n@@ -393,8 +393,7 @@ static int ib_alloc_cqs(struct ib_device *dev, unsigned int nr_cqes,\n \t * a reasonable batch size so that we can share CQs between\n \t * multiple users instead of allocating a larger number of CQs.\n \t */\n-\tnr_cqes = min_t(unsigned int, dev-\u003eattrs.max_cqe,\n-\t\t\tmax(nr_cqes, IB_MAX_SHARED_CQ_SZ));\n+\tnr_cqes = min(dev-\u003eattrs.max_cqe, max(nr_cqes, IB_MAX_SHARED_CQ_SZ));\n \tnr_cqs = min_t(unsigned int, dev-\u003enum_comp_vectors, num_online_cpus());\n \tfor (i = 0; i \u003c nr_cqs; i++) {\n \t\tcq = ib_alloc_cq(dev, NULL, nr_cqes, i, poll_ctx);\ndiff --git a/drivers/infiniband/hw/qedr/verbs.c b/drivers/infiniband/hw/qedr/verbs.c\nindex 679aa6f3a63bc5..a85ad01711348e 100644\n--- a/drivers/infiniband/hw/qedr/verbs.c\n+++ b/drivers/infiniband/hw/qedr/verbs.c\n@@ -151,7 +151,7 @@ int qedr_query_device(struct ib_device *ibdev,\n \tattr-\u003emax_qp_init_rd_atom =\n \t 1 \u003c\u003c (fls(qattr-\u003emax_qp_req_rd_atomic_resc) - 1);\n \tattr-\u003emax_qp_rd_atom =\n-\t min(1 \u003c\u003c (fls(qattr-\u003emax_qp_resp_rd_atomic_resc) - 1),\n+\t min(1U \u003c\u003c (fls(qattr-\u003emax_qp_resp_rd_atomic_resc) - 1),\n \t\tattr-\u003emax_qp_init_rd_atom);\n \n \tattr-\u003emax_srq = qattr-\u003emax_srq;\ndiff --git a/drivers/infiniband/sw/rxe/rxe_qp.c b/drivers/infiniband/sw/rxe/rxe_qp.c\nindex f3dff1aea96afc..7a0529a17992c8 100644\n--- a/drivers/infiniband/sw/rxe/rxe_qp.c\n+++ b/drivers/infiniband/sw/rxe/rxe_qp.c\n@@ -67,27 +67,27 @@ static int rxe_qp_chk_cap(struct rxe_dev *rxe, struct ib_qp_cap *cap,\n \t\t\t int has_srq)\n {\n \tif (cap-\u003emax_send_wr \u003e rxe-\u003eattr.max_qp_wr) {\n-\t\trxe_dbg_dev(rxe, \"invalid send wr = %u \u003e %d\\n\",\n-\t\t\t cap-\u003emax_send_wr, rxe-\u003eattr.max_qp_wr);\n+\t\trxe_dbg_dev(rxe, \"invalid send wr = %u \u003e %u\\n\",\n+\t\t\t cap-\u003emax_send_wr, rxe-\u003eattr.max_qp_wr);\n \t\tgoto err1;\n \t}\n \n \tif (cap-\u003emax_send_sge \u003e rxe-\u003eattr.max_send_sge) {\n-\t\trxe_dbg_dev(rxe, \"invalid send sge = %u \u003e %d\\n\",\n-\t\t\t cap-\u003emax_send_sge, rxe-\u003eattr.max_send_sge);\n+\t\trxe_dbg_dev(rxe, \"invalid send sge = %u \u003e %u\\n\",\n+\t\t\t cap-\u003emax_send_sge, rxe-\u003eattr.max_send_sge);\n \t\tgoto err1;\n \t}\n \n \tif (!has_srq) {\n \t\tif (cap-\u003emax_recv_wr \u003e rxe-\u003eattr.max_qp_wr) {\n-\t\t\trxe_dbg_dev(rxe, \"invalid recv wr = %u \u003e %d\\n\",\n-\t\t\t\t cap-\u003emax_recv_wr, rxe-\u003eattr.max_qp_wr);\n+\t\t\trxe_dbg_dev(rxe, \"invalid recv wr = %u \u003e %u\\n\",\n+\t\t\t\t cap-\u003emax_recv_wr, rxe-\u003eattr.max_qp_wr);\n \t\t\tgoto err1;\n \t\t}\n \n \t\tif (cap-\u003emax_recv_sge \u003e rxe-\u003eattr.max_recv_sge) {\n-\t\t\trxe_dbg_dev(rxe, \"invalid recv sge = %u \u003e %d\\n\",\n-\t\t\t\t cap-\u003emax_recv_sge, rxe-\u003eattr.max_recv_sge);\n+\t\t\trxe_dbg_dev(rxe, \"invalid recv sge = %u \u003e %u\\n\",\n+\t\t\t\t cap-\u003emax_recv_sge, rxe-\u003eattr.max_recv_sge);\n \t\t\tgoto err1;\n \t\t}\n \t}\n@@ -537,9 +537,9 @@ int rxe_qp_chk_attr(struct rxe_dev *rxe, struct rxe_qp *qp,\n \n \tif (mask \u0026 IB_QP_MAX_QP_RD_ATOMIC) {\n \t\tif (attr-\u003emax_rd_atomic \u003e rxe-\u003eattr.max_qp_rd_atom) {\n-\t\t\trxe_dbg_qp(qp, \"invalid max_rd_atomic %d \u003e %d\\n\",\n-\t\t\t\t attr-\u003emax_rd_atomic,\n-\t\t\t\t rxe-\u003eattr.max_qp_rd_atom);\n+\t\t\trxe_dbg_qp(qp, \"invalid max_rd_atomic %u \u003e %u\\n\",\n+\t\t\t\t attr-\u003emax_rd_atomic,\n+\t\t\t\t rxe-\u003eattr.max_qp_rd_atom);\n \t\t\tgoto err1;\n \t\t}\n \t}\ndiff --git a/drivers/infiniband/sw/rxe/rxe_srq.c b/drivers/infiniband/sw/rxe/rxe_srq.c\nindex c9a7cd38953d31..74904a6fdf2b21 100644\n--- a/drivers/infiniband/sw/rxe/rxe_srq.c\n+++ b/drivers/infiniband/sw/rxe/rxe_srq.c\n@@ -13,8 +13,8 @@ int rxe_srq_chk_init(struct rxe_dev *rxe, struct ib_srq_init_attr *init)\n \tstruct ib_srq_attr *attr = \u0026init-\u003eattr;\n \n \tif (attr-\u003emax_wr \u003e rxe-\u003eattr.max_srq_wr) {\n-\t\trxe_dbg_dev(rxe, \"max_wr(%d) \u003e max_srq_wr(%d)\\n\",\n-\t\t\tattr-\u003emax_wr, rxe-\u003eattr.max_srq_wr);\n+\t\trxe_dbg_dev(rxe, \"max_wr(%u) \u003e max_srq_wr(%u)\\n\",\n+\t\t\t attr-\u003emax_wr, rxe-\u003eattr.max_srq_wr);\n \t\tgoto err1;\n \t}\n \n@@ -27,8 +27,8 @@ int rxe_srq_chk_init(struct rxe_dev *rxe, struct ib_srq_init_attr *init)\n \t\tattr-\u003emax_wr = RXE_MIN_SRQ_WR;\n \n \tif (attr-\u003emax_sge \u003e rxe-\u003eattr.max_srq_sge) {\n-\t\trxe_dbg_dev(rxe, \"max_sge(%d) \u003e max_srq_sge(%d)\\n\",\n-\t\t\tattr-\u003emax_sge, rxe-\u003eattr.max_srq_sge);\n+\t\trxe_dbg_dev(rxe, \"max_sge(%u) \u003e max_srq_sge(%u)\\n\",\n+\t\t\t attr-\u003emax_sge, rxe-\u003eattr.max_srq_sge);\n \t\tgoto err1;\n \t}\n \n@@ -107,8 +107,8 @@ int rxe_srq_chk_attr(struct rxe_dev *rxe, struct rxe_srq *srq,\n \n \tif (mask \u0026 IB_SRQ_MAX_WR) {\n \t\tif (attr-\u003emax_wr \u003e rxe-\u003eattr.max_srq_wr) {\n-\t\t\trxe_dbg_srq(srq, \"max_wr(%d) \u003e max_srq_wr(%d)\\n\",\n-\t\t\t\tattr-\u003emax_wr, rxe-\u003eattr.max_srq_wr);\n+\t\t\trxe_dbg_srq(srq, \"max_wr(%u) \u003e max_srq_wr(%u)\\n\",\n+\t\t\t\t attr-\u003emax_wr, rxe-\u003eattr.max_srq_wr);\n \t\t\tgoto err1;\n \t\t}\n \n@@ -129,8 +129,8 @@ int rxe_srq_chk_attr(struct rxe_dev *rxe, struct rxe_srq *srq,\n \n \tif (mask \u0026 IB_SRQ_LIMIT) {\n \t\tif (attr-\u003esrq_limit \u003e rxe-\u003eattr.max_srq_wr) {\n-\t\t\trxe_dbg_srq(srq, \"srq_limit(%d) \u003e max_srq_wr(%d)\\n\",\n-\t\t\t\tattr-\u003esrq_limit, rxe-\u003eattr.max_srq_wr);\n+\t\t\trxe_dbg_srq(srq, \"srq_limit(%u) \u003e max_srq_wr(%u)\\n\",\n+\t\t\t\t attr-\u003esrq_limit, rxe-\u003eattr.max_srq_wr);\n \t\t\tgoto err1;\n \t\t}\n \ndiff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c\nindex 57fec88a16290a..ed0592898384d3 100644\n--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c\n+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c\n@@ -1071,8 +1071,7 @@ static struct ib_qp *ipoib_cm_create_tx_qp(struct net_device *dev, struct ipoib_\n \tstruct ib_qp *tx_qp;\n \n \tif (dev-\u003efeatures \u0026 NETIF_F_SG)\n-\t\tattr.cap.max_send_sge = min_t(u32, priv-\u003eca-\u003eattrs.max_send_sge,\n-\t\t\t\t\t MAX_SKB_FRAGS + 1);\n+\t\tattr.cap.max_send_sge = min(priv-\u003eca-\u003eattrs.max_send_sge, MAX_SKB_FRAGS + 1);\n \n \ttx_qp = ib_create_qp(priv-\u003epd, \u0026attr);\n \ttx-\u003emax_send_sge = attr.cap.max_send_sge;\n@@ -1582,7 +1581,8 @@ static void ipoib_cm_create_srq(struct net_device *dev, int max_sge)\n int ipoib_cm_dev_init(struct net_device *dev)\n {\n \tstruct ipoib_dev_priv *priv = ipoib_priv(dev);\n-\tint max_srq_sge, i;\n+\tu32 max_srq_sge;\n+\tint i;\n \tu8 addr;\n \n \tINIT_LIST_HEAD(\u0026priv-\u003ecm.passive_ids);\n@@ -1600,9 +1600,9 @@ int ipoib_cm_dev_init(struct net_device *dev)\n \n \tskb_queue_head_init(\u0026priv-\u003ecm.skb_queue);\n \n-\tipoib_dbg(priv, \"max_srq_sge=%d\\n\", priv-\u003eca-\u003eattrs.max_srq_sge);\n+\tipoib_dbg(priv, \"max_srq_sge=%u\\n\", priv-\u003eca-\u003eattrs.max_srq_sge);\n \n-\tmax_srq_sge = min_t(int, IPOIB_CM_RX_SG, priv-\u003eca-\u003eattrs.max_srq_sge);\n+\tmax_srq_sge = min(priv-\u003eca-\u003eattrs.max_srq_sge, IPOIB_CM_RX_SG);\n \tipoib_cm_create_srq(dev, max_srq_sge);\n \tif (ipoib_cm_has_srq(dev)) {\n \t\tpriv-\u003ecm.max_cm_mtu = max_srq_sge * PAGE_SIZE - 0x10;\ndiff --git a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c\nindex 3ed1ea566690dd..2490696a1aabc8 100644\n--- a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c\n+++ b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c\n@@ -147,8 +147,7 @@ int ipoib_transport_dev_init(struct net_device *dev, struct ib_device *ca)\n \t\t.cap = {\n \t\t\t.max_send_wr = ipoib_sendq_size,\n \t\t\t.max_recv_wr = ipoib_recvq_size,\n-\t\t\t.max_send_sge = min_t(u32, priv-\u003eca-\u003eattrs.max_send_sge,\n-\t\t\t\t\t MAX_SKB_FRAGS + 1),\n+\t\t\t.max_send_sge = min(priv-\u003eca-\u003eattrs.max_send_sge, MAX_SKB_FRAGS + 1),\n \t\t\t.max_recv_sge = IPOIB_UD_RX_SG\n \t\t},\n \t\t.sq_sig_type = IB_SIGNAL_ALL_WR,\ndiff --git a/drivers/infiniband/ulp/iser/iser_verbs.c b/drivers/infiniband/ulp/iser/iser_verbs.c\nindex f03b3bb3c0c4c1..55fe68e5b8375e 100644\n--- a/drivers/infiniband/ulp/iser/iser_verbs.c\n+++ b/drivers/infiniband/ulp/iser/iser_verbs.c\n@@ -244,8 +244,7 @@ static int iser_create_ib_conn_res(struct ib_conn *ib_conn)\n \t\tmax_send_wr = ISER_QP_SIG_MAX_REQ_DTOS + 1;\n \telse\n \t\tmax_send_wr = ISER_QP_MAX_REQ_DTOS + 1;\n-\tmax_send_wr = min_t(unsigned int, max_send_wr,\n-\t\t\t (unsigned int)ib_dev-\u003eattrs.max_qp_wr);\n+\tmax_send_wr = min(max_send_wr, ib_dev-\u003eattrs.max_qp_wr);\n \n \tcq_size = max_send_wr + ISER_QP_MAX_RECV_DTOS;\n \tib_conn-\u003ecq = ib_cq_pool_get(ib_dev, cq_size, -1, IB_POLL_SOFTIRQ);\n@@ -589,7 +588,7 @@ static void iser_route_handler(struct rdma_cm_id *cma_id)\n \t\tgoto failure;\n \n \tmemset(\u0026conn_param, 0, sizeof conn_param);\n-\tconn_param.responder_resources = ib_dev-\u003eattrs.max_qp_rd_atom;\n+\tconn_param.responder_resources = min(ib_dev-\u003eattrs.max_qp_rd_atom, U8_MAX);\n \tconn_param.initiator_depth = 1;\n \tconn_param.retry_count = 7;\n \tconn_param.rnr_retry_count = 6;\ndiff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c\nindex 1015a51f750af4..4691845bf815f9 100644\n--- a/drivers/infiniband/ulp/isert/ib_isert.c\n+++ b/drivers/infiniband/ulp/isert/ib_isert.c\n@@ -214,9 +214,9 @@ isert_create_device_ib_res(struct isert_device *device)\n \tstruct ib_device *ib_dev = device-\u003eib_device;\n \tint ret;\n \n-\tisert_dbg(\"devattr-\u003emax_send_sge: %d devattr-\u003emax_recv_sge %d\\n\",\n+\tisert_dbg(\"devattr-\u003emax_send_sge: %u devattr-\u003emax_recv_sge %u\\n\",\n \t\t ib_dev-\u003eattrs.max_send_sge, ib_dev-\u003eattrs.max_recv_sge);\n-\tisert_dbg(\"devattr-\u003emax_sge_rd: %d\\n\", ib_dev-\u003eattrs.max_sge_rd);\n+\tisert_dbg(\"devattr-\u003emax_sge_rd: %u\\n\", ib_dev-\u003eattrs.max_sge_rd);\n \n \tdevice-\u003epd = ib_alloc_pd(ib_dev, 0);\n \tif (IS_ERR(device-\u003epd)) {\n@@ -381,8 +381,7 @@ isert_set_nego_params(struct isert_conn *isert_conn,\n \tstruct ib_device_attr *attr = \u0026isert_conn-\u003edevice-\u003eib_device-\u003eattrs;\n \n \t/* Set max inflight RDMA READ requests */\n-\tisert_conn-\u003einitiator_depth = min_t(u8, param-\u003einitiator_depth,\n-\t\t\t\tattr-\u003emax_qp_init_rd_atom);\n+\tisert_conn-\u003einitiator_depth = min(param-\u003einitiator_depth, attr-\u003emax_qp_init_rd_atom);\n \tisert_dbg(\"Using initiator_depth: %u\\n\", isert_conn-\u003einitiator_depth);\n \n \tif (param-\u003eprivate_data) {\ndiff --git a/drivers/infiniband/ulp/rtrs/rtrs-clt.c b/drivers/infiniband/ulp/rtrs/rtrs-clt.c\nindex e351552733df23..80b08697f96b59 100644\n--- a/drivers/infiniband/ulp/rtrs/rtrs-clt.c\n+++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.c\n@@ -1681,8 +1681,7 @@ static int create_con_cq_qp(struct rtrs_clt_con *con)\n \t\t * + 2 for drain and heartbeat\n \t\t * in case qp gets into error state.\n \t\t */\n-\t\tmax_send_wr =\n-\t\t\tmin_t(int, wr_limit, SERVICE_CON_QUEUE_DEPTH * 2 + 2);\n+\t\tmax_send_wr = min(wr_limit, SERVICE_CON_QUEUE_DEPTH * 2 + 2);\n \t\tmax_recv_wr = max_send_wr;\n \t} else {\n \t\t/*\n@@ -1698,11 +1697,9 @@ static int create_con_cq_qp(struct rtrs_clt_con *con)\n \t\twr_limit = clt_path-\u003es.dev-\u003eib_dev-\u003eattrs.max_qp_wr;\n \t\t/* Shared between connections */\n \t\tclt_path-\u003es.dev_ref++;\n-\t\tmax_send_wr = min_t(int, wr_limit,\n-\t\t\t /* QD * (REQ + RSP + FR REGS or INVS) + drain */\n-\t\t\t clt_path-\u003equeue_depth * 4 + 1);\n-\t\tmax_recv_wr = min_t(int, wr_limit,\n-\t\t\t clt_path-\u003equeue_depth * 3 + 1);\n+\t\t/* QD * (REQ + RSP + FR REGS or INVS) + drain */\n+\t\tmax_send_wr = min(wr_limit, clt_path-\u003equeue_depth * 4 + 1);\n+\t\tmax_recv_wr = min(wr_limit, clt_path-\u003equeue_depth * 3 + 1);\n \t\tmax_send_sge = 2;\n \t}\n \tatomic_set(\u0026con-\u003ec.sq_wr_avail, max_send_wr);\ndiff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c\nindex 6482ad859bd108..f5a6890235bcc4 100644\n--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c\n+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c\n@@ -1731,21 +1731,16 @@ static int create_con(struct rtrs_srv_path *srv_path,\n \t\t * All receive and all send (each requiring invalidate)\n \t\t * + 2 for drain and heartbeat\n \t\t */\n-\t\tmax_send_wr = min_t(int, wr_limit,\n-\t\t\t\t SERVICE_CON_QUEUE_DEPTH * 2 + 2);\n+\t\tmax_send_wr = min(wr_limit, SERVICE_CON_QUEUE_DEPTH * 2 + 2);\n \t\tmax_recv_wr = max_send_wr;\n \t\ts-\u003esignal_interval = min_not_zero(srv-\u003equeue_depth,\n \t\t\t\t\t\t (size_t)SERVICE_CON_QUEUE_DEPTH);\n \t} else {\n \t\t/* when always_invlaidate enalbed, we need linv+rinv+mr+imm */\n \t\tif (always_invalidate)\n-\t\t\tmax_send_wr =\n-\t\t\t\tmin_t(int, wr_limit,\n-\t\t\t\t srv-\u003equeue_depth * (1 + 4) + 1);\n+\t\t\tmax_send_wr = min(wr_limit, srv-\u003equeue_depth * (1 + 4) + 1);\n \t\telse\n-\t\t\tmax_send_wr =\n-\t\t\t\tmin_t(int, wr_limit,\n-\t\t\t\t srv-\u003equeue_depth * (1 + 2) + 1);\n+\t\t\tmax_send_wr = min(wr_limit, srv-\u003equeue_depth * (1 + 2) + 1);\n \n \t\tmax_recv_wr = srv-\u003equeue_depth + 1;\n \t}\ndiff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c\nindex acbd787de265b5..0caebbc2810ff3 100644\n--- a/drivers/infiniband/ulp/srp/ib_srp.c\n+++ b/drivers/infiniband/ulp/srp/ib_srp.c\n@@ -557,7 +557,7 @@ static int srp_create_ch_ib(struct srp_rdma_ch *ch)\n \tinit_attr-\u003ecap.max_send_wr = m * target-\u003equeue_size;\n \tinit_attr-\u003ecap.max_recv_wr = target-\u003equeue_size + 1;\n \tinit_attr-\u003ecap.max_recv_sge = 1;\n-\tinit_attr-\u003ecap.max_send_sge = min(SRP_MAX_SGE, attr-\u003emax_send_sge);\n+\tinit_attr-\u003ecap.max_send_sge = min(attr-\u003emax_send_sge, SRP_MAX_SGE);\n \tinit_attr-\u003esq_sig_type = IB_SIGNAL_REQ_WR;\n \tinit_attr-\u003eqp_type = IB_QPT_RC;\n \tinit_attr-\u003esend_cq = send_cq;\ndiff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c\nindex 9aec5d80117f1f..a4e4feba4a0253 100644\n--- a/drivers/infiniband/ulp/srpt/ib_srpt.c\n+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c\n@@ -77,8 +77,8 @@ module_param(srp_max_req_size, int, 0444);\n MODULE_PARM_DESC(srp_max_req_size,\n \t\t \"Maximum size of SRP request messages in bytes.\");\n \n-static int srpt_srq_size = DEFAULT_SRPT_SRQ_SIZE;\n-module_param(srpt_srq_size, int, 0444);\n+static unsigned int srpt_srq_size = DEFAULT_SRPT_SRQ_SIZE;\n+module_param(srpt_srq_size, uint, 0444);\n MODULE_PARM_DESC(srpt_srq_size,\n \t\t \"Shared receive queue (SRQ) size.\");\n \n@@ -405,8 +405,7 @@ static void srpt_get_ioc(struct srpt_port *sport, u32 slot,\n \tif (sdev-\u003euse_srq)\n \t\tsend_queue_depth = sdev-\u003esrq_size;\n \telse\n-\t\tsend_queue_depth = min(MAX_SRPT_RQ_SIZE,\n-\t\t\t\t sdev-\u003edevice-\u003eattrs.max_qp_wr);\n+\t\tsend_queue_depth = min(sdev-\u003edevice-\u003eattrs.max_qp_wr, MAX_SRPT_RQ_SIZE);\n \n \tmemset(iocp, 0, sizeof(*iocp));\n \tstrcpy(iocp-\u003eid_string, SRPT_ID_STRING);\n@@ -1850,7 +1849,7 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)\n \tstruct srpt_port *sport = ch-\u003esport;\n \tstruct srpt_device *sdev = sport-\u003esdev;\n \tconst struct ib_device_attr *attrs = \u0026sdev-\u003edevice-\u003eattrs;\n-\tint sq_size = sport-\u003eport_attrib.srp_sq_size;\n+\tu32 sq_size = sport-\u003eport_attrib.srp_sq_size;\n \tint i, ret;\n \n \tWARN_ON(ch-\u003erq_size \u003c 1);\n@@ -1911,13 +1910,13 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)\n \t\tbool retry = sq_size \u003e MIN_SRPT_SQ_SIZE;\n \n \t\tif (retry) {\n-\t\t\tpr_debug(\"failed to create queue pair with sq_size = %d (%d) - retrying\\n\",\n+\t\t\tpr_debug(\"failed to create queue pair with sq_size = %u (%d) - retrying\\n\",\n \t\t\t\t sq_size, ret);\n \t\t\tib_cq_pool_put(ch-\u003ecq, ch-\u003ecq_size);\n \t\t\tsq_size = max(sq_size / 2, MIN_SRPT_SQ_SIZE);\n \t\t\tgoto retry;\n \t\t} else {\n-\t\t\tpr_err(\"failed to create queue pair with sq_size = %d (%d)\\n\",\n+\t\t\tpr_err(\"failed to create queue pair with sq_size = %u (%d)\\n\",\n \t\t\t sq_size, ret);\n \t\t\tgoto err_destroy_cq;\n \t\t}\n@@ -1925,7 +1924,7 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)\n \n \tatomic_set(\u0026ch-\u003esq_wr_avail, qp_init-\u003ecap.max_send_wr);\n \n-\tpr_debug(\"%s: max_cqe= %d max_sge= %d sq_size = %d ch= %p\\n\",\n+\tpr_debug(\"%s: max_cqe= %d max_sge= %d sq_size = %u ch= %p\\n\",\n \t\t __func__, ch-\u003ecq-\u003ecqe, qp_init-\u003ecap.max_send_sge,\n \t\t qp_init-\u003ecap.max_send_wr, ch);\n \n@@ -2298,7 +2297,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,\n \t * depth to avoid that the initiator driver has to report QUEUE_FULL\n \t * to the SCSI mid-layer.\n \t */\n-\tch-\u003erq_size = min(MAX_SRPT_RQ_SIZE, sdev-\u003edevice-\u003eattrs.max_qp_wr);\n+\tch-\u003erq_size = min(sdev-\u003edevice-\u003eattrs.max_qp_wr, MAX_SRPT_RQ_SIZE);\n \tspin_lock_init(\u0026ch-\u003espinlock);\n \tch-\u003estate = CH_CONNECTING;\n \tINIT_LIST_HEAD(\u0026ch-\u003ecmd_wait_list);\n@@ -3136,7 +3135,7 @@ static int srpt_alloc_srq(struct srpt_device *sdev)\n \t\treturn PTR_ERR(srq);\n \t}\n \n-\tpr_debug(\"create SRQ #wr= %d max_allow=%d dev= %s\\n\", sdev-\u003esrq_size,\n+\tpr_debug(\"create SRQ #wr= %d max_allow=%u dev= %s\\n\", sdev-\u003esrq_size,\n \t\t sdev-\u003edevice-\u003eattrs.max_srq_wr, dev_name(\u0026device-\u003edev));\n \n \tsdev-\u003ereq_buf_cache = srpt_cache_get(srp_max_req_size);\n@@ -3951,7 +3950,7 @@ static int __init srpt_init_module(void)\n \n \tif (srpt_srq_size \u003c MIN_SRPT_SRQ_SIZE\n \t || srpt_srq_size \u003e MAX_SRPT_SRQ_SIZE) {\n-\t\tpr_err(\"invalid value %d for kernel module parameter srpt_srq_size -- must be in the range [%d..%d].\\n\",\n+\t\tpr_err(\"invalid value %u for kernel module parameter srpt_srq_size -- must be in the range [%d..%d].\\n\",\n \t\t srpt_srq_size, MIN_SRPT_SRQ_SIZE, MAX_SRPT_SRQ_SIZE);\n \t\tgoto out;\n \t}\ndiff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c\nindex 6909e354279427..56cd228af1d57a 100644\n--- a/drivers/nvme/host/rdma.c\n+++ b/drivers/nvme/host/rdma.c\n@@ -394,8 +394,10 @@ nvme_rdma_find_get_device(struct rdma_cm_id *cm_id)\n \t\tgoto out_free_pd;\n \t}\n \n-\tndev-\u003enum_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,\n-\t\t\t\t\tndev-\u003edev-\u003eattrs.max_send_sge - 1);\n+\tndev-\u003enum_inline_segments = ndev-\u003edev-\u003eattrs.max_send_sge;\n+\tif (ndev-\u003enum_inline_segments)\n+\t\tndev-\u003enum_inline_segments--;\n+\tndev-\u003enum_inline_segments = min(ndev-\u003enum_inline_segments, NVME_RDMA_MAX_INLINE_SEGMENTS);\n \tlist_add(\u0026ndev-\u003eentry, \u0026device_list);\n out_unlock:\n \tmutex_unlock(\u0026device_list_mutex);\n@@ -1847,7 +1849,7 @@ static int nvme_rdma_route_resolved(struct nvme_rdma_queue *queue)\n \tparam.qp_num = queue-\u003eqp-\u003eqp_num;\n \tparam.flow_control = 1;\n \n-\tparam.responder_resources = queue-\u003edevice-\u003edev-\u003eattrs.max_qp_rd_atom;\n+\tparam.responder_resources = min(queue-\u003edevice-\u003edev-\u003eattrs.max_qp_rd_atom, U8_MAX);\n \t/* maximum retry count */\n \tparam.retry_count = 7;\n \tparam.rnr_retry_count = 7;\ndiff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c\nindex ac26f4f774c4de..1c332d66222a0b 100644\n--- a/drivers/nvme/target/rdma.c\n+++ b/drivers/nvme/target/rdma.c\n@@ -152,7 +152,7 @@ static const struct kernel_param_ops srq_size_ops = {\n \t.get = param_get_int,\n };\n \n-static int nvmet_rdma_srq_size = 1024;\n+static unsigned int nvmet_rdma_srq_size = 1024;\n module_param_cb(srq_size, \u0026srq_size_ops, \u0026nvmet_rdma_srq_size, 0644);\n MODULE_PARM_DESC(srq_size, \"set Shared Receive Queue (SRQ) size, should \u003e= 256 (default: 1024)\");\n \n@@ -1197,7 +1197,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)\n \tstruct nvmet_port *nport = port-\u003enport;\n \tstruct nvmet_rdma_device *ndev;\n \tint inline_page_count;\n-\tint inline_sge_count;\n+\tu32 inline_sge_count;\n \tint ret;\n \n \tmutex_lock(\u0026device_list_mutex);\n@@ -1213,7 +1213,9 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)\n \n \tinline_page_count = num_pages(nport-\u003einline_data_size);\n \tinline_sge_count = max(cm_id-\u003edevice-\u003eattrs.max_sge_rd,\n-\t\t\t\tcm_id-\u003edevice-\u003eattrs.max_recv_sge) - 1;\n+\t\t\t\tcm_id-\u003edevice-\u003eattrs.max_recv_sge);\n+\tif (inline_sge_count)\n+\t\tinline_sge_count--;\n \tif (inline_page_count \u003e inline_sge_count) {\n \t\tpr_warn(\"inline_data_size %d cannot be supported by device %s. Reducing to %lu.\\n\",\n \t\t\tnport-\u003einline_data_size, cm_id-\u003edevice-\u003ename,\n@@ -1553,8 +1555,9 @@ static int nvmet_rdma_cm_accept(struct rdma_cm_id *cm_id,\n \n \tparam.rnr_retry_count = 7;\n \tparam.flow_control = 1;\n-\tparam.initiator_depth = min_t(u8, p-\u003einitiator_depth,\n-\t\tqueue-\u003edev-\u003edevice-\u003eattrs.max_qp_init_rd_atom);\n+\tparam.initiator_depth = min3(p-\u003einitiator_depth,\n+\t\t\t\t queue-\u003edev-\u003edevice-\u003eattrs.max_qp_init_rd_atom,\n+\t\t\t\t U8_MAX);\n \tparam.private_data = \u0026priv;\n \tparam.private_data_len = sizeof(priv);\n \tpriv.recfmt = cpu_to_le16(NVME_RDMA_CM_FMT_1_0);\ndiff --git a/fs/smb/smbdirect/accept.c b/fs/smb/smbdirect/accept.c\nindex 5297400058385e..44b681a2072536 100644\n--- a/fs/smb/smbdirect/accept.c\n+++ b/fs/smb/smbdirect/accept.c\n@@ -32,8 +32,9 @@ int smbdirect_accept_connect_request(struct smbdirect_socket *sc,\n \t/*\n \t * First set what the we as server are able to support\n \t */\n-\tsp-\u003einitiator_depth = min_t(u8, sp-\u003einitiator_depth,\n-\t\t\t\t sc-\u003eib.dev-\u003eattrs.max_qp_rd_atom);\n+\tsp-\u003einitiator_depth = min3(sp-\u003einitiator_depth,\n+\t\t\t\t sc-\u003eib.dev-\u003eattrs.max_qp_rd_atom,\n+\t\t\t\t U8_MAX);\n \n \tpeer_initiator_depth = param-\u003einitiator_depth;\n \tpeer_responder_resources = param-\u003eresponder_resources;\ndiff --git a/fs/smb/smbdirect/connect.c b/fs/smb/smbdirect/connect.c\nindex cd726b399afecb..34a3e72c38fbba 100644\n--- a/fs/smb/smbdirect/connect.c\n+++ b/fs/smb/smbdirect/connect.c\n@@ -182,8 +182,9 @@ static int smbdirect_connect_rdma_connect(struct smbdirect_socket *sc)\n \tif (sc-\u003eib.dev-\u003eattrs.kernel_cap_flags \u0026 IBK_SG_GAPS_REG)\n \t\tsc-\u003emr_io.type = IB_MR_TYPE_SG_GAPS;\n \n-\tsp-\u003eresponder_resources = min_t(u8, sp-\u003eresponder_resources,\n-\t\t\t\t\tsc-\u003eib.dev-\u003eattrs.max_qp_rd_atom);\n+\tsp-\u003eresponder_resources = min3(sp-\u003eresponder_resources,\n+\t\t\t\t sc-\u003eib.dev-\u003eattrs.max_qp_rd_atom,\n+\t\t\t\t U8_MAX);\n \tsmbdirect_log_rdma_mr(sc, SMBDIRECT_LOG_INFO,\n \t\t\"responder_resources=%d\\n\",\n \t\tsp-\u003eresponder_resources);\ndiff --git a/fs/smb/smbdirect/connection.c b/fs/smb/smbdirect/connection.c\nindex 8adf580975344b..690acb84e1b591 100644\n--- a/fs/smb/smbdirect/connection.c\n+++ b/fs/smb/smbdirect/connection.c\n@@ -287,7 +287,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)\n \t qp_cap.max_send_wr \u003e sc-\u003eib.dev-\u003eattrs.max_qp_wr) {\n \t\tpr_err(\"Possible CQE overrun: max_send_wr %d\\n\",\n \t\t qp_cap.max_send_wr);\n-\t\tpr_err(\"device %.*s reporting max_cqe %d max_qp_wr %d\\n\",\n+\t\tpr_err(\"device %.*s reporting max_cqe %u max_qp_wr %u\\n\",\n \t\t IB_DEVICE_NAME_MAX,\n \t\t sc-\u003eib.dev-\u003ename,\n \t\t sc-\u003eib.dev-\u003eattrs.max_cqe,\n@@ -302,7 +302,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)\n \t max_send_wr \u003e= sc-\u003eib.dev-\u003eattrs.max_qp_wr)) {\n \t\tpr_err(\"Possible CQE overrun: rdma_send_wr %d + max_send_wr %d = %d\\n\",\n \t\t rdma_send_wr, qp_cap.max_send_wr, max_send_wr);\n-\t\tpr_err(\"device %.*s reporting max_cqe %d max_qp_wr %d\\n\",\n+\t\tpr_err(\"device %.*s reporting max_cqe %u max_qp_wr %u\\n\",\n \t\t IB_DEVICE_NAME_MAX,\n \t\t sc-\u003eib.dev-\u003ename,\n \t\t sc-\u003eib.dev-\u003eattrs.max_cqe,\n@@ -316,7 +316,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)\n \t qp_cap.max_recv_wr \u003e sc-\u003eib.dev-\u003eattrs.max_qp_wr) {\n \t\tpr_err(\"Possible CQE overrun: max_recv_wr %d\\n\",\n \t\t qp_cap.max_recv_wr);\n-\t\tpr_err(\"device %.*s reporting max_cqe %d max_qp_wr %d\\n\",\n+\t\tpr_err(\"device %.*s reporting max_cqe %u max_qp_wr %u\\n\",\n \t\t IB_DEVICE_NAME_MAX,\n \t\t sc-\u003eib.dev-\u003ename,\n \t\t sc-\u003eib.dev-\u003eattrs.max_cqe,\n@@ -328,7 +328,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)\n \n \tif (qp_cap.max_send_sge \u003e sc-\u003eib.dev-\u003eattrs.max_send_sge ||\n \t qp_cap.max_recv_sge \u003e sc-\u003eib.dev-\u003eattrs.max_recv_sge) {\n-\t\tpr_err(\"device %.*s max_send_sge/max_recv_sge = %d/%d too small\\n\",\n+\t\tpr_err(\"device %.*s max_send_sge/max_recv_sge = %u/%u too small\\n\",\n \t\t IB_DEVICE_NAME_MAX,\n \t\t sc-\u003eib.dev-\u003ename,\n \t\t sc-\u003eib.dev-\u003eattrs.max_send_sge,\ndiff --git a/include/linux/sunrpc/svc_rdma.h b/include/linux/sunrpc/svc_rdma.h\nindex df6e08aaad5709..217f000be5d6e2 100644\n--- a/include/linux/sunrpc/svc_rdma.h\n+++ b/include/linux/sunrpc/svc_rdma.h\n@@ -78,8 +78,8 @@ struct svcxprt_rdma {\n \tstruct rdma_cm_id *sc_cm_id;\t\t/* RDMA connection id */\n \tstruct list_head sc_accept_q;\t/* Conn. waiting accept */\n \tstruct rpcrdma_notification sc_rn;\t/* removal notification */\n-\tint\t\t sc_ord;\t\t/* RDMA read limit */\n-\tint sc_max_send_sges;\n+\tu32\t\t sc_ord;\t\t/* RDMA read limit */\n+\tunsigned int sc_max_send_sges;\n \tbool\t\t sc_snd_w_inv;\t/* OK to use Send With Invalidate */\n \n \tatomic_t sc_sq_avail;\t/* SQEs ready to be consumed */\ndiff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h\nindex 9dd76f489a0ba4..b8b221b5f56473 100644\n--- a/include/rdma/ib_verbs.h\n+++ b/include/rdma/ib_verbs.h\n@@ -406,36 +406,36 @@ struct ib_device_attr {\n \tu32\t\t\tvendor_id;\n \tu32\t\t\tvendor_part_id;\n \tu32\t\t\thw_ver;\n-\tint\t\t\tmax_qp;\n-\tint\t\t\tmax_qp_wr;\n+\tu32\t\t\tmax_qp;\n+\tu32\t\t\tmax_qp_wr;\n \tu64\t\t\tdevice_cap_flags;\n \tu64\t\t\tkernel_cap_flags;\n-\tint\t\t\tmax_send_sge;\n-\tint\t\t\tmax_recv_sge;\n-\tint\t\t\tmax_sge_rd;\n-\tint\t\t\tmax_cq;\n-\tint\t\t\tmax_cqe;\n-\tint\t\t\tmax_mr;\n-\tint\t\t\tmax_pd;\n-\tint\t\t\tmax_qp_rd_atom;\n-\tint\t\t\tmax_ee_rd_atom;\n-\tint\t\t\tmax_res_rd_atom;\n-\tint\t\t\tmax_qp_init_rd_atom;\n-\tint\t\t\tmax_ee_init_rd_atom;\n+\tu32\t\t\tmax_send_sge;\n+\tu32\t\t\tmax_recv_sge;\n+\tu32\t\t\tmax_sge_rd;\n+\tu32\t\t\tmax_cq;\n+\tu32\t\t\tmax_cqe;\n+\tu32\t\t\tmax_mr;\n+\tu32\t\t\tmax_pd;\n+\tu32\t\t\tmax_qp_rd_atom;\n+\tu32\t\t\tmax_ee_rd_atom;\n+\tu32\t\t\tmax_res_rd_atom;\n+\tu32\t\t\tmax_qp_init_rd_atom;\n+\tu32\t\t\tmax_ee_init_rd_atom;\n \tenum ib_atomic_cap\tatomic_cap;\n \tenum ib_atomic_cap\tmasked_atomic_cap;\n-\tint\t\t\tmax_ee;\n-\tint\t\t\tmax_rdd;\n-\tint\t\t\tmax_mw;\n-\tint\t\t\tmax_raw_ipv6_qp;\n-\tint\t\t\tmax_raw_ethy_qp;\n-\tint\t\t\tmax_mcast_grp;\n-\tint\t\t\tmax_mcast_qp_attach;\n-\tint\t\t\tmax_total_mcast_qp_attach;\n-\tint\t\t\tmax_ah;\n+\tu32\t\t\tmax_ee;\n+\tu32\t\t\tmax_rdd;\n+\tu32\t\t\tmax_mw;\n+\tu32\t\t\tmax_raw_ipv6_qp;\n+\tu32\t\t\tmax_raw_ethy_qp;\n+\tu32\t\t\tmax_mcast_grp;\n+\tu32\t\t\tmax_mcast_qp_attach;\n+\tu32\t\t\tmax_total_mcast_qp_attach;\n+\tu32\t\t\tmax_ah;\n \tint\t\t\tmax_srq;\n-\tint\t\t\tmax_srq_wr;\n-\tint\t\t\tmax_srq_sge;\n+\tu32\t\t\tmax_srq_wr;\n+\tu32\t\t\tmax_srq_sge;\n \tunsigned int\t\tmax_fast_reg_page_list_len;\n \tunsigned int\t\tmax_pi_fast_reg_page_list_len;\n \tu16\t\t\tmax_pkeys;\ndiff --git a/net/rds/ib.c b/net/rds/ib.c\nindex 39f87272e071bf..c62684d4259c4f 100644\n--- a/net/rds/ib.c\n+++ b/net/rds/ib.c\n@@ -162,12 +162,12 @@ static int rds_ib_add_one(struct ib_device *device)\n \t\t IB_ODP_SUPPORT_READ);\n \n \trds_ibdev-\u003emax_1m_mrs = device-\u003eattrs.max_mr ?\n-\t\tmin_t(unsigned int, (device-\u003eattrs.max_mr / 2),\n-\t\t rds_ib_mr_1m_pool_size) : rds_ib_mr_1m_pool_size;\n+\t\tmin(device-\u003eattrs.max_mr / 2,\n+\t\t rds_ib_mr_1m_pool_size) : rds_ib_mr_1m_pool_size;\n \n \trds_ibdev-\u003emax_8k_mrs = device-\u003eattrs.max_mr ?\n-\t\tmin_t(unsigned int, ((device-\u003eattrs.max_mr / 2) * RDS_MR_8K_SCALE),\n-\t\t rds_ib_mr_8k_pool_size) : rds_ib_mr_8k_pool_size;\n+\t\tmin((device-\u003eattrs.max_mr / 2) * RDS_MR_8K_SCALE,\n+\t\t rds_ib_mr_8k_pool_size) : rds_ib_mr_8k_pool_size;\n \n \trds_ibdev-\u003emax_initiator_depth = device-\u003eattrs.max_qp_init_rd_atom;\n \trds_ibdev-\u003emax_responder_resources = device-\u003eattrs.max_qp_rd_atom;\n@@ -204,7 +204,7 @@ static int rds_ib_add_one(struct ib_device *device)\n \t\tgoto put_dev;\n \t}\n \n-\trdsdebug(\"RDS/IB: max_mr = %d, max_wrs = %d, max_sge = %d, max_1m_mrs = %d, max_8k_mrs = %d\\n\",\n+\trdsdebug(\"RDS/IB: max_mr = %u, max_wrs = %d, max_sge = %d, max_1m_mrs = %d, max_8k_mrs = %d\\n\",\n \t\t device-\u003eattrs.max_mr, rds_ibdev-\u003emax_wrs, rds_ibdev-\u003emax_sge,\n \t\t rds_ibdev-\u003emax_1m_mrs, rds_ibdev-\u003emax_8k_mrs);\n \ndiff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c\nindex 5667f0173b47f2..17e587c3007663 100644\n--- a/net/rds/ib_cm.c\n+++ b/net/rds/ib_cm.c\n@@ -173,11 +173,11 @@ static void rds_ib_cm_fill_conn_param(struct rds_connection *conn,\n \n \tmemset(conn_param, 0, sizeof(struct rdma_conn_param));\n \n-\tconn_param-\u003eresponder_resources =\n-\t\tmin_t(u32, rds_ibdev-\u003emax_responder_resources, max_responder_resources);\n-\tconn_param-\u003einitiator_depth =\n-\t\tmin_t(u32, rds_ibdev-\u003emax_initiator_depth, max_initiator_depth);\n-\tconn_param-\u003eretry_count = min_t(unsigned int, rds_ib_retry_count, 7);\n+\tconn_param-\u003eresponder_resources = min3(rds_ibdev-\u003emax_responder_resources,\n+\t\t\t\t\t max_responder_resources, U8_MAX);\n+\tconn_param-\u003einitiator_depth = min3(rds_ibdev-\u003emax_initiator_depth,\n+\t\t\t\t\t max_initiator_depth, U8_MAX);\n+\tconn_param-\u003eretry_count = min(rds_ib_retry_count, 7U);\n \tconn_param-\u003ernr_retry_count = 7;\n \n \tif (dp) {\ndiff --git a/net/sunrpc/xprtrdma/frwr_ops.c b/net/sunrpc/xprtrdma/frwr_ops.c\nindex 7f79a0a2601e65..b2e437afe09daa 100644\n--- a/net/sunrpc/xprtrdma/frwr_ops.c\n+++ b/net/sunrpc/xprtrdma/frwr_ops.c\n@@ -172,8 +172,9 @@ int frwr_mr_init(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr *mr)\n int frwr_query_device(struct rpcrdma_ep *ep, const struct ib_device *device)\n {\n \tconst struct ib_device_attr *attrs = \u0026device-\u003eattrs;\n-\tint max_qp_wr, depth, delta;\n \tunsigned int max_sge;\n+\tu32 max_qp_wr;\n+\tint depth, delta;\n \n \tif (!(attrs-\u003edevice_cap_flags \u0026 IB_DEVICE_MEM_MGT_EXTENSIONS) ||\n \t attrs-\u003emax_fast_reg_page_list_len == 0) {\n@@ -229,10 +230,10 @@ int frwr_query_device(struct rpcrdma_ep *ep, const struct ib_device *device)\n \t}\n \n \tmax_qp_wr = attrs-\u003emax_qp_wr;\n+\tif (max_qp_wr \u003c RPCRDMA_BACKWARD_WRS + 1 + RPCRDMA_MIN_SLOT_TABLE)\n+\t\treturn -ENOMEM;\n \tmax_qp_wr -= RPCRDMA_BACKWARD_WRS;\n \tmax_qp_wr -= 1;\n-\tif (max_qp_wr \u003c RPCRDMA_MIN_SLOT_TABLE)\n-\t\treturn -ENOMEM;\n \tif (ep-\u003ere_max_requests \u003e max_qp_wr)\n \t\tep-\u003ere_max_requests = max_qp_wr;\n \tep-\u003ere_attr.cap.max_send_wr = ep-\u003ere_max_requests * depth;\ndiff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c\nindex f18bc60d9f4ffa..c768cda2e5444a 100644\n--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c\n+++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c\n@@ -544,8 +544,7 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt *xprt)\n \tset_bit(RDMAXPRT_CONN_PENDING, \u0026newxprt-\u003esc_flags);\n \tmemset(\u0026conn_param, 0, sizeof conn_param);\n \tconn_param.responder_resources = 0;\n-\tconn_param.initiator_depth = min_t(int, newxprt-\u003esc_ord,\n-\t\t\t\t\t dev-\u003eattrs.max_qp_init_rd_atom);\n+\tconn_param.initiator_depth = min(newxprt-\u003esc_ord, dev-\u003eattrs.max_qp_init_rd_atom);\n \tif (!conn_param.initiator_depth) {\n \t\tret = -EINVAL;\n \t\ttrace_svcrdma_initdepth_err(newxprt, ret);\n@@ -570,7 +569,7 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt *xprt)\n \t\tdprintk(\" local address : %pIS:%u\\n\", sap, rpc_get_port(sap));\n \t\tsap = (struct sockaddr *)\u0026newxprt-\u003esc_cm_id-\u003eroute.addr.dst_addr;\n \t\tdprintk(\" remote address : %pIS:%u\\n\", sap, rpc_get_port(sap));\n-\t\tdprintk(\" max_sge : %d\\n\", newxprt-\u003esc_max_send_sges);\n+\t\tdprintk(\" max_sge : %u\\n\", newxprt-\u003esc_max_send_sges);\n \t\tdprintk(\" sq_depth : %d\\n\", newxprt-\u003esc_sq_depth);\n \t\tdprintk(\" rdma_rw_ctxs : %d\\n\", ctxts);\n \t\tdprintk(\" max_requests : %d\\n\", newxprt-\u003esc_max_requests);\ndiff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c\nindex aecf9c0a153f36..8ed9da6d2d2f77 100644\n--- a/net/sunrpc/xprtrdma/verbs.c\n+++ b/net/sunrpc/xprtrdma/verbs.c\n@@ -453,7 +453,7 @@ static int rpcrdma_ep_create(struct rpcrdma_xprt *r_xprt)\n \t/* Client offers RDMA Read but does not initiate */\n \tep-\u003ere_remote_cma.initiator_depth = 0;\n \tep-\u003ere_remote_cma.responder_resources =\n-\t\tmin_t(int, U8_MAX, device-\u003eattrs.max_qp_rd_atom);\n+\t\tmin(device-\u003eattrs.max_qp_rd_atom, U8_MAX);\n \n \t/* Limit transport retries so client can detect server\n \t * GID changes quickly. RPC layer handles re-establishing\n"
} |
| 2/1 | 2026/06/19 20:46 | agent | patch-evaluator |
2mModel:gemini-3.1-pro-preview Args: null Results: {
"EnableConfigs": [
"RDMA_RXE",
"NVME_RDMA",
"NVME_TARGET_RDMA",
"SUNRPC_XPRT_RDMA",
"CIFS_SMB_DIRECT",
"SMB_SERVER_SMBDIRECT",
"INFINIBAND_SRP",
"INFINIBAND_SRPT",
"INFINIBAND_ISER",
"INFINIBAND_ISERT",
"INFINIBAND_RTRS_CLIENT",
"INFINIBAND_RTRS_SERVER",
"RDS_RDMA",
"INFINIBAND_IPOIB"
],
"FocusSymbols": [
"nvme_rdma_find_get_device",
"nvmet_rdma_find_get_device",
"frwr_query_device",
"rxe_qp_chk_cap",
"rxe_srq_chk_init",
"smbdirect_connection_create_qp",
"rds_ib_cm_fill_conn_param",
"svc_rdma_accept",
"rpcrdma_ep_create"
],
"Reasoning": "The patch changes the types of various RDMA device attributes from `int` to `u32` and updates the corresponding `min()` calls and format strings. It also fixes some potential underflows in connection setup functions. These changes affect the core RDMA logic and various RDMA ULPs (Upper Layer Protocols) which can be tested using the software RDMA driver (RXE). It is worth fuzzing to ensure no regressions or new integer overflow/underflow bugs were introduced.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer. Your job is to review a provided patch series and determine if it makes functional changes to the kernel that should be fuzzed. IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively use your code access tools to examine the actual source code and confirm any assumptions. Return WorthFuzzing=false if the patch only contains: - Modifications to Documentation/, Kconfig files, or code comments. - Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints. - Changes to numeric constants or macros that do not functionally alter execution flow. - Code paths that are impossible to reach in virtualized environments like GCE or QEMU, even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim). If it modifies reachable core kernel logic, drivers, or architectures, use your code search tools to verify the code can be executed, then return WorthFuzzing=true. When returning WorthFuzzing=true, you MUST ALSO: 1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols. Avoid listing generic hot-path functions to prevent skewed test distributions. 2. Identify any specific CONFIG_ options required to properly test this new/modified feature. Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions. Do not list too generic configs (we already have them enabled). Only list those that specifically cover the modified code. List them in the EnableConfigs output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4"). Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: For your convenience, here is the diff of the changes:
commit 3025390b09359e1904d239a1b2741614484be725
Author: syz-cluster <triage@syzkaller.com>
Date: Fri Jun 19 20:46:23 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
index 3d7b6cddd131c4..ee98188e57fb5f 100644
--- a/drivers/infiniband/core/cq.c
+++ b/drivers/infiniband/core/cq.c
@@ -393,8 +393,7 @@ static int ib_alloc_cqs(struct ib_device *dev, unsigned int nr_cqes,
* a reasonable batch size so that we can share CQs between
* multiple users instead of allocating a larger number of CQs.
*/
- nr_cqes = min_t(unsigned int, dev->attrs.max_cqe,
- max(nr_cqes, IB_MAX_SHARED_CQ_SZ));
+ nr_cqes = min(dev->attrs.max_cqe, max(nr_cqes, IB_MAX_SHARED_CQ_SZ));
nr_cqs = min_t(unsigned int, dev->num_comp_vectors, num_online_cpus());
for (i = 0; i < nr_cqs; i++) {
cq = ib_alloc_cq(dev, NULL, nr_cqes, i, poll_ctx);
diff --git a/drivers/infiniband/hw/qedr/verbs.c b/drivers/infiniband/hw/qedr/verbs.c
index 679aa6f3a63bc5..a85ad01711348e 100644
--- a/drivers/infiniband/hw/qedr/verbs.c
+++ b/drivers/infiniband/hw/qedr/verbs.c
@@ -151,7 +151,7 @@ int qedr_query_device(struct ib_device *ibdev,
attr->max_qp_init_rd_atom =
1 << (fls(qattr->max_qp_req_rd_atomic_resc) - 1);
attr->max_qp_rd_atom =
- min(1 << (fls(qattr->max_qp_resp_rd_atomic_resc) - 1),
+ min(1U << (fls(qattr->max_qp_resp_rd_atomic_resc) - 1),
attr->max_qp_init_rd_atom);
attr->max_srq = qattr->max_srq;
diff --git a/drivers/infiniband/sw/rxe/rxe_qp.c b/drivers/infiniband/sw/rxe/rxe_qp.c
index f3dff1aea96afc..7a0529a17992c8 100644
--- a/drivers/infiniband/sw/rxe/rxe_qp.c
+++ b/drivers/infiniband/sw/rxe/rxe_qp.c
@@ -67,27 +67,27 @@ static int rxe_qp_chk_cap(struct rxe_dev *rxe, struct ib_qp_cap *cap,
int has_srq)
{
if (cap->max_send_wr > rxe->attr.max_qp_wr) {
- rxe_dbg_dev(rxe, "invalid send wr = %u > %d\n",
- cap->max_send_wr, rxe->attr.max_qp_wr);
+ rxe_dbg_dev(rxe, "invalid send wr = %u > %u\n",
+ cap->max_send_wr, rxe->attr.max_qp_wr);
goto err1;
}
if (cap->max_send_sge > rxe->attr.max_send_sge) {
- rxe_dbg_dev(rxe, "invalid send sge = %u > %d\n",
- cap->max_send_sge, rxe->attr.max_send_sge);
+ rxe_dbg_dev(rxe, "invalid send sge = %u > %u\n",
+ cap->max_send_sge, rxe->attr.max_send_sge);
goto err1;
}
if (!has_srq) {
if (cap->max_recv_wr > rxe->attr.max_qp_wr) {
- rxe_dbg_dev(rxe, "invalid recv wr = %u > %d\n",
- cap->max_recv_wr, rxe->attr.max_qp_wr);
+ rxe_dbg_dev(rxe, "invalid recv wr = %u > %u\n",
+ cap->max_recv_wr, rxe->attr.max_qp_wr);
goto err1;
}
if (cap->max_recv_sge > rxe->attr.max_recv_sge) {
- rxe_dbg_dev(rxe, "invalid recv sge = %u > %d\n",
- cap->max_recv_sge, rxe->attr.max_recv_sge);
+ rxe_dbg_dev(rxe, "invalid recv sge = %u > %u\n",
+ cap->max_recv_sge, rxe->attr.max_recv_sge);
goto err1;
}
}
@@ -537,9 +537,9 @@ int rxe_qp_chk_attr(struct rxe_dev *rxe, struct rxe_qp *qp,
if (mask & IB_QP_MAX_QP_RD_ATOMIC) {
if (attr->max_rd_atomic > rxe->attr.max_qp_rd_atom) {
- rxe_dbg_qp(qp, "invalid max_rd_atomic %d > %d\n",
- attr->max_rd_atomic,
- rxe->attr.max_qp_rd_atom);
+ rxe_dbg_qp(qp, "invalid max_rd_atomic %u > %u\n",
+ attr->max_rd_atomic,
+ rxe->attr.max_qp_rd_atom);
goto err1;
}
}
diff --git a/drivers/infiniband/sw/rxe/rxe_srq.c b/drivers/infiniband/sw/rxe/rxe_srq.c
index c9a7cd38953d31..74904a6fdf2b21 100644
--- a/drivers/infiniband/sw/rxe/rxe_srq.c
+++ b/drivers/infiniband/sw/rxe/rxe_srq.c
@@ -13,8 +13,8 @@ int rxe_srq_chk_init(struct rxe_dev *rxe, struct ib_srq_init_attr *init)
struct ib_srq_attr *attr = &init->attr;
if (attr->max_wr > rxe->attr.max_srq_wr) {
- rxe_dbg_dev(rxe, "max_wr(%d) > max_srq_wr(%d)\n",
- attr->max_wr, rxe->attr.max_srq_wr);
+ rxe_dbg_dev(rxe, "max_wr(%u) > max_srq_wr(%u)\n",
+ attr->max_wr, rxe->attr.max_srq_wr);
goto err1;
}
@@ -27,8 +27,8 @@ int rxe_srq_chk_init(struct rxe_dev *rxe, struct ib_srq_init_attr *init)
attr->max_wr = RXE_MIN_SRQ_WR;
if (attr->max_sge > rxe->attr.max_srq_sge) {
- rxe_dbg_dev(rxe, "max_sge(%d) > max_srq_sge(%d)\n",
- attr->max_sge, rxe->attr.max_srq_sge);
+ rxe_dbg_dev(rxe, "max_sge(%u) > max_srq_sge(%u)\n",
+ attr->max_sge, rxe->attr.max_srq_sge);
goto err1;
}
@@ -107,8 +107,8 @@ int rxe_srq_chk_attr(struct rxe_dev *rxe, struct rxe_srq *srq,
if (mask & IB_SRQ_MAX_WR) {
if (attr->max_wr > rxe->attr.max_srq_wr) {
- rxe_dbg_srq(srq, "max_wr(%d) > max_srq_wr(%d)\n",
- attr->max_wr, rxe->attr.max_srq_wr);
+ rxe_dbg_srq(srq, "max_wr(%u) > max_srq_wr(%u)\n",
+ attr->max_wr, rxe->attr.max_srq_wr);
goto err1;
}
@@ -129,8 +129,8 @@ int rxe_srq_chk_attr(struct rxe_dev *rxe, struct rxe_srq *srq,
if (mask & IB_SRQ_LIMIT) {
if (attr->srq_limit > rxe->attr.max_srq_wr) {
- rxe_dbg_srq(srq, "srq_limit(%d) > max_srq_wr(%d)\n",
- attr->srq_limit, rxe->attr.max_srq_wr);
+ rxe_dbg_srq(srq, "srq_limit(%u) > max_srq_wr(%u)\n",
+ attr->srq_limit, rxe->attr.max_srq_wr);
goto err1;
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 57fec88a16290a..ed0592898384d3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1071,8 +1071,7 @@ static struct ib_qp *ipoib_cm_create_tx_qp(struct net_device *dev, struct ipoib_
struct ib_qp *tx_qp;
if (dev->features & NETIF_F_SG)
- attr.cap.max_send_sge = min_t(u32, priv->ca->attrs.max_send_sge,
- MAX_SKB_FRAGS + 1);
+ attr.cap.max_send_sge = min(priv->ca->attrs.max_send_sge, MAX_SKB_FRAGS + 1);
tx_qp = ib_create_qp(priv->pd, &attr);
tx->max_send_sge = attr.cap.max_send_sge;
@@ -1582,7 +1581,8 @@ static void ipoib_cm_create_srq(struct net_device *dev, int max_sge)
int ipoib_cm_dev_init(struct net_device *dev)
{
struct ipoib_dev_priv *priv = ipoib_priv(dev);
- int max_srq_sge, i;
+ u32 max_srq_sge;
+ int i;
u8 addr;
INIT_LIST_HEAD(&priv->cm.passive_ids);
@@ -1600,9 +1600,9 @@ int ipoib_cm_dev_init(struct net_device *dev)
skb_queue_head_init(&priv->cm.skb_queue);
- ipoib_dbg(priv, "max_srq_sge=%d\n", priv->ca->attrs.max_srq_sge);
+ ipoib_dbg(priv, "max_srq_sge=%u\n", priv->ca->attrs.max_srq_sge);
- max_srq_sge = min_t(int, IPOIB_CM_RX_SG, priv->ca->attrs.max_srq_sge);
+ max_srq_sge = min(priv->ca->attrs.max_srq_sge, IPOIB_CM_RX_SG);
ipoib_cm_create_srq(dev, max_srq_sge);
if (ipoib_cm_has_srq(dev)) {
priv->cm.max_cm_mtu = max_srq_sge * PAGE_SIZE - 0x10;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
index 3ed1ea566690dd..2490696a1aabc8 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
@@ -147,8 +147,7 @@ int ipoib_transport_dev_init(struct net_device *dev, struct ib_device *ca)
.cap = {
.max_send_wr = ipoib_sendq_size,
.max_recv_wr = ipoib_recvq_size,
- .max_send_sge = min_t(u32, priv->ca->attrs.max_send_sge,
- MAX_SKB_FRAGS + 1),
+ .max_send_sge = min(priv->ca->attrs.max_send_sge, MAX_SKB_FRAGS + 1),
.max_recv_sge = IPOIB_UD_RX_SG
},
.sq_sig_type = IB_SIGNAL_ALL_WR,
diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c b/drivers/infiniband/ulp/iser/iser_verbs.c
index f03b3bb3c0c4c1..55fe68e5b8375e 100644
--- a/drivers/infiniband/ulp/iser/iser_verbs.c
+++ b/drivers/infiniband/ulp/iser/iser_verbs.c
@@ -244,8 +244,7 @@ static int iser_create_ib_conn_res(struct ib_conn *ib_conn)
max_send_wr = ISER_QP_SIG_MAX_REQ_DTOS + 1;
else
max_send_wr = ISER_QP_MAX_REQ_DTOS + 1;
- max_send_wr = min_t(unsigned int, max_send_wr,
- (unsigned int)ib_dev->attrs.max_qp_wr);
+ max_send_wr = min(max_send_wr, ib_dev->attrs.max_qp_wr);
cq_size = max_send_wr + ISER_QP_MAX_RECV_DTOS;
ib_conn->cq = ib_cq_pool_get(ib_dev, cq_size, -1, IB_POLL_SOFTIRQ);
@@ -589,7 +588,7 @@ static void iser_route_handler(struct rdma_cm_id *cma_id)
goto failure;
memset(&conn_param, 0, sizeof conn_param);
- conn_param.responder_resources = ib_dev->attrs.max_qp_rd_atom;
+ conn_param.responder_resources = min(ib_dev->attrs.max_qp_rd_atom, U8_MAX);
conn_param.initiator_depth = 1;
conn_param.retry_count = 7;
conn_param.rnr_retry_count = 6;
diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c
index 1015a51f750af4..4691845bf815f9 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -214,9 +214,9 @@ isert_create_device_ib_res(struct isert_device *device)
struct ib_device *ib_dev = device->ib_device;
int ret;
- isert_dbg("devattr->max_send_sge: %d devattr->max_recv_sge %d\n",
+ isert_dbg("devattr->max_send_sge: %u devattr->max_recv_sge %u\n",
ib_dev->attrs.max_send_sge, ib_dev->attrs.max_recv_sge);
- isert_dbg("devattr->max_sge_rd: %d\n", ib_dev->attrs.max_sge_rd);
+ isert_dbg("devattr->max_sge_rd: %u\n", ib_dev->attrs.max_sge_rd);
device->pd = ib_alloc_pd(ib_dev, 0);
if (IS_ERR(device->pd)) {
@@ -381,8 +381,7 @@ isert_set_nego_params(struct isert_conn *isert_conn,
struct ib_device_attr *attr = &isert_conn->device->ib_device->attrs;
/* Set max inflight RDMA READ requests */
- isert_conn->initiator_depth = min_t(u8, param->initiator_depth,
- attr->max_qp_init_rd_atom);
+ isert_conn->initiator_depth = min(param->initiator_depth, attr->max_qp_init_rd_atom);
isert_dbg("Using initiator_depth: %u\n", isert_conn->initiator_depth);
if (param->private_data) {
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-clt.c b/drivers/infiniband/ulp/rtrs/rtrs-clt.c
index e351552733df23..80b08697f96b59 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-clt.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.c
@@ -1681,8 +1681,7 @@ static int create_con_cq_qp(struct rtrs_clt_con *con)
* + 2 for drain and heartbeat
* in case qp gets into error state.
*/
- max_send_wr =
- min_t(int, wr_limit, SERVICE_CON_QUEUE_DEPTH * 2 + 2);
+ max_send_wr = min(wr_limit, SERVICE_CON_QUEUE_DEPTH * 2 + 2);
max_recv_wr = max_send_wr;
} else {
/*
@@ -1698,11 +1697,9 @@ static int create_con_cq_qp(struct rtrs_clt_con *con)
wr_limit = clt_path->s.dev->ib_dev->attrs.max_qp_wr;
/* Shared between connections */
clt_path->s.dev_ref++;
- max_send_wr = min_t(int, wr_limit,
- /* QD * (REQ + RSP + FR REGS or INVS) + drain */
- clt_path->queue_depth * 4 + 1);
- max_recv_wr = min_t(int, wr_limit,
- clt_path->queue_depth * 3 + 1);
+ /* QD * (REQ + RSP + FR REGS or INVS) + drain */
+ max_send_wr = min(wr_limit, clt_path->queue_depth * 4 + 1);
+ max_recv_wr = min(wr_limit, clt_path->queue_depth * 3 + 1);
max_send_sge = 2;
}
atomic_set(&con->c.sq_wr_avail, max_send_wr);
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 6482ad859bd108..f5a6890235bcc4 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1731,21 +1731,16 @@ static int create_con(struct rtrs_srv_path *srv_path,
* All receive and all send (each requiring invalidate)
* + 2 for drain and heartbeat
*/
- max_send_wr = min_t(int, wr_limit,
- SERVICE_CON_QUEUE_DEPTH * 2 + 2);
+ max_send_wr = min(wr_limit, SERVICE_CON_QUEUE_DEPTH * 2 + 2);
max_recv_wr = max_send_wr;
s->signal_interval = min_not_zero(srv->queue_depth,
(size_t)SERVICE_CON_QUEUE_DEPTH);
} else {
/* when always_invlaidate enalbed, we need linv+rinv+mr+imm */
if (always_invalidate)
- max_send_wr =
- min_t(int, wr_limit,
- srv->queue_depth * (1 + 4) + 1);
+ max_send_wr = min(wr_limit, srv->queue_depth * (1 + 4) + 1);
else
- max_send_wr =
- min_t(int, wr_limit,
- srv->queue_depth * (1 + 2) + 1);
+ max_send_wr = min(wr_limit, srv->queue_depth * (1 + 2) + 1);
max_recv_wr = srv->queue_depth + 1;
}
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index acbd787de265b5..0caebbc2810ff3 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -557,7 +557,7 @@ static int srp_create_ch_ib(struct srp_rdma_ch *ch)
init_attr->cap.max_send_wr = m * target->queue_size;
init_attr->cap.max_recv_wr = target->queue_size + 1;
init_attr->cap.max_recv_sge = 1;
- init_attr->cap.max_send_sge = min(SRP_MAX_SGE, attr->max_send_sge);
+ init_attr->cap.max_send_sge = min(attr->max_send_sge, SRP_MAX_SGE);
init_attr->sq_sig_type = IB_SIGNAL_REQ_WR;
init_attr->qp_type = IB_QPT_RC;
init_attr->send_cq = send_cq;
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 9aec5d80117f1f..a4e4feba4a0253 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -77,8 +77,8 @@ module_param(srp_max_req_size, int, 0444);
MODULE_PARM_DESC(srp_max_req_size,
"Maximum size of SRP request messages in bytes.");
-static int srpt_srq_size = DEFAULT_SRPT_SRQ_SIZE;
-module_param(srpt_srq_size, int, 0444);
+static unsigned int srpt_srq_size = DEFAULT_SRPT_SRQ_SIZE;
+module_param(srpt_srq_size, uint, 0444);
MODULE_PARM_DESC(srpt_srq_size,
"Shared receive queue (SRQ) size.");
@@ -405,8 +405,7 @@ static void srpt_get_ioc(struct srpt_port *sport, u32 slot,
if (sdev->use_srq)
send_queue_depth = sdev->srq_size;
else
- send_queue_depth = min(MAX_SRPT_RQ_SIZE,
- sdev->device->attrs.max_qp_wr);
+ send_queue_depth = min(sdev->device->attrs.max_qp_wr, MAX_SRPT_RQ_SIZE);
memset(iocp, 0, sizeof(*iocp));
strcpy(iocp->id_string, SRPT_ID_STRING);
@@ -1850,7 +1849,7 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
struct srpt_port *sport = ch->sport;
struct srpt_device *sdev = sport->sdev;
const struct ib_device_attr *attrs = &sdev->device->attrs;
- int sq_size = sport->port_attrib.srp_sq_size;
+ u32 sq_size = sport->port_attrib.srp_sq_size;
int i, ret;
WARN_ON(ch->rq_size < 1);
@@ -1911,13 +1910,13 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
bool retry = sq_size > MIN_SRPT_SQ_SIZE;
if (retry) {
- pr_debug("failed to create queue pair with sq_size = %d (%d) - retrying\n",
+ pr_debug("failed to create queue pair with sq_size = %u (%d) - retrying\n",
sq_size, ret);
ib_cq_pool_put(ch->cq, ch->cq_size);
sq_size = max(sq_size / 2, MIN_SRPT_SQ_SIZE);
goto retry;
} else {
- pr_err("failed to create queue pair with sq_size = %d (%d)\n",
+ pr_err("failed to create queue pair with sq_size = %u (%d)\n",
sq_size, ret);
goto err_destroy_cq;
}
@@ -1925,7 +1924,7 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
atomic_set(&ch->sq_wr_avail, qp_init->cap.max_send_wr);
- pr_debug("%s: max_cqe= %d max_sge= %d sq_size = %d ch= %p\n",
+ pr_debug("%s: max_cqe= %d max_sge= %d sq_size = %u ch= %p\n",
__func__, ch->cq->cqe, qp_init->cap.max_send_sge,
qp_init->cap.max_send_wr, ch);
@@ -2298,7 +2297,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
* depth to avoid that the initiator driver has to report QUEUE_FULL
* to the SCSI mid-layer.
*/
- ch->rq_size = min(MAX_SRPT_RQ_SIZE, sdev->device->attrs.max_qp_wr);
+ ch->rq_size = min(sdev->device->attrs.max_qp_wr, MAX_SRPT_RQ_SIZE);
spin_lock_init(&ch->spinlock);
ch->state = CH_CONNECTING;
INIT_LIST_HEAD(&ch->cmd_wait_list);
@@ -3136,7 +3135,7 @@ static int srpt_alloc_srq(struct srpt_device *sdev)
return PTR_ERR(srq);
}
- pr_debug("create SRQ #wr= %d max_allow=%d dev= %s\n", sdev->srq_size,
+ pr_debug("create SRQ #wr= %d max_allow=%u dev= %s\n", sdev->srq_size,
sdev->device->attrs.max_srq_wr, dev_name(&device->dev));
sdev->req_buf_cache = srpt_cache_get(srp_max_req_size);
@@ -3951,7 +3950,7 @@ static int __init srpt_init_module(void)
if (srpt_srq_size < MIN_SRPT_SRQ_SIZE
|| srpt_srq_size > MAX_SRPT_SRQ_SIZE) {
- pr_err("invalid value %d for kernel module parameter srpt_srq_size -- must be in the range [%d..%d].\n",
+ pr_err("invalid value %u for kernel module parameter srpt_srq_size -- must be in the range [%d..%d].\n",
srpt_srq_size, MIN_SRPT_SRQ_SIZE, MAX_SRPT_SRQ_SIZE);
goto out;
}
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 6909e354279427..56cd228af1d57a 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -394,8 +394,10 @@ nvme_rdma_find_get_device(struct rdma_cm_id *cm_id)
goto out_free_pd;
}
- ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
- ndev->dev->attrs.max_send_sge - 1);
+ ndev->num_inline_segments = ndev->dev->attrs.max_send_sge;
+ if (ndev->num_inline_segments)
+ ndev->num_inline_segments--;
+ ndev->num_inline_segments = min(ndev->num_inline_segments, NVME_RDMA_MAX_INLINE_SEGMENTS);
list_add(&ndev->entry, &device_list);
out_unlock:
mutex_unlock(&device_list_mutex);
@@ -1847,7 +1849,7 @@ static int nvme_rdma_route_resolved(struct nvme_rdma_queue *queue)
param.qp_num = queue->qp->qp_num;
param.flow_control = 1;
- param.responder_resources = queue->device->dev->attrs.max_qp_rd_atom;
+ param.responder_resources = min(queue->device->dev->attrs.max_qp_rd_atom, U8_MAX);
/* maximum retry count */
param.retry_count = 7;
param.rnr_retry_count = 7;
diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index ac26f4f774c4de..1c332d66222a0b 100644
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@ -152,7 +152,7 @@ static const struct kernel_param_ops srq_size_ops = {
.get = param_get_int,
};
-static int nvmet_rdma_srq_size = 1024;
+static unsigned int nvmet_rdma_srq_size = 1024;
module_param_cb(srq_size, &srq_size_ops, &nvmet_rdma_srq_size, 0644);
MODULE_PARM_DESC(srq_size, "set Shared Receive Queue (SRQ) size, should >= 256 (default: 1024)");
@@ -1197,7 +1197,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
struct nvmet_port *nport = port->nport;
struct nvmet_rdma_device *ndev;
int inline_page_count;
- int inline_sge_count;
+ u32 inline_sge_count;
int ret;
mutex_lock(&device_list_mutex);
@@ -1213,7 +1213,9 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
inline_page_count = num_pages(nport->inline_data_size);
inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
- cm_id->device->attrs.max_recv_sge) - 1;
+ cm_id->device->attrs.max_recv_sge);
+ if (inline_sge_count)
+ inline_sge_count--;
if (inline_page_count > inline_sge_count) {
pr_warn("inline_data_size %d cannot be supported by device %s. Reducing to %lu.\n",
nport->inline_data_size, cm_id->device->name,
@@ -1553,8 +1555,9 @@ static int nvmet_rdma_cm_accept(struct rdma_cm_id *cm_id,
param.rnr_retry_count = 7;
param.flow_control = 1;
- param.initiator_depth = min_t(u8, p->initiator_depth,
- queue->dev->device->attrs.max_qp_init_rd_atom);
+ param.initiator_depth = min3(p->initiator_depth,
+ queue->dev->device->attrs.max_qp_init_rd_atom,
+ U8_MAX);
param.private_data = &priv;
param.private_data_len = sizeof(priv);
priv.recfmt = cpu_to_le16(NVME_RDMA_CM_FMT_1_0);
diff --git a/fs/smb/smbdirect/accept.c b/fs/smb/smbdirect/accept.c
index 5297400058385e..44b681a2072536 100644
--- a/fs/smb/smbdirect/accept.c
+++ b/fs/smb/smbdirect/accept.c
@@ -32,8 +32,9 @@ int smbdirect_accept_connect_request(struct smbdirect_socket *sc,
/*
* First set what the we as server are able to support
*/
- sp->initiator_depth = min_t(u8, sp->initiator_depth,
- sc->ib.dev->attrs.max_qp_rd_atom);
+ sp->initiator_depth = min3(sp->initiator_depth,
+ sc->ib.dev->attrs.max_qp_rd_atom,
+ U8_MAX);
peer_initiator_depth = param->initiator_depth;
peer_responder_resources = param->responder_resources;
diff --git a/fs/smb/smbdirect/connect.c b/fs/smb/smbdirect/connect.c
index cd726b399afecb..34a3e72c38fbba 100644
--- a/fs/smb/smbdirect/connect.c
+++ b/fs/smb/smbdirect/connect.c
@@ -182,8 +182,9 @@ static int smbdirect_connect_rdma_connect(struct smbdirect_socket *sc)
if (sc->ib.dev->attrs.kernel_cap_flags & IBK_SG_GAPS_REG)
sc->mr_io.type = IB_MR_TYPE_SG_GAPS;
- sp->responder_resources = min_t(u8, sp->responder_resources,
- sc->ib.dev->attrs.max_qp_rd_atom);
+ sp->responder_resources = min3(sp->responder_resources,
+ sc->ib.dev->attrs.max_qp_rd_atom,
+ U8_MAX);
smbdirect_log_rdma_mr(sc, SMBDIRECT_LOG_INFO,
"responder_resources=%d\n",
sp->responder_resources);
diff --git a/fs/smb/smbdirect/connection.c b/fs/smb/smbdirect/connection.c
index 8adf580975344b..690acb84e1b591 100644
--- a/fs/smb/smbdirect/connection.c
+++ b/fs/smb/smbdirect/connection.c
@@ -287,7 +287,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)
qp_cap.max_send_wr > sc->ib.dev->attrs.max_qp_wr) {
pr_err("Possible CQE overrun: max_send_wr %d\n",
qp_cap.max_send_wr);
- pr_err("device %.*s reporting max_cqe %d max_qp_wr %d\n",
+ pr_err("device %.*s reporting max_cqe %u max_qp_wr %u\n",
IB_DEVICE_NAME_MAX,
sc->ib.dev->name,
sc->ib.dev->attrs.max_cqe,
@@ -302,7 +302,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)
max_send_wr >= sc->ib.dev->attrs.max_qp_wr)) {
pr_err("Possible CQE overrun: rdma_send_wr %d + max_send_wr %d = %d\n",
rdma_send_wr, qp_cap.max_send_wr, max_send_wr);
- pr_err("device %.*s reporting max_cqe %d max_qp_wr %d\n",
+ pr_err("device %.*s reporting max_cqe %u max_qp_wr %u\n",
IB_DEVICE_NAME_MAX,
sc->ib.dev->name,
sc->ib.dev->attrs.max_cqe,
@@ -316,7 +316,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)
qp_cap.max_recv_wr > sc->ib.dev->attrs.max_qp_wr) {
pr_err("Possible CQE overrun: max_recv_wr %d\n",
qp_cap.max_recv_wr);
- pr_err("device %.*s reporting max_cqe %d max_qp_wr %d\n",
+ pr_err("device %.*s reporting max_cqe %u max_qp_wr %u\n",
IB_DEVICE_NAME_MAX,
sc->ib.dev->name,
sc->ib.dev->attrs.max_cqe,
@@ -328,7 +328,7 @@ int smbdirect_connection_create_qp(struct smbdirect_socket *sc)
if (qp_cap.max_send_sge > sc->ib.dev->attrs.max_send_sge ||
qp_cap.max_recv_sge > sc->ib.dev->attrs.max_recv_sge) {
- pr_err("device %.*s max_send_sge/max_recv_sge = %d/%d too small\n",
+ pr_err("device %.*s max_send_sge/max_recv_sge = %u/%u too small\n",
IB_DEVICE_NAME_MAX,
sc->ib.dev->name,
sc->ib.dev->attrs.max_send_sge,
diff --git a/include/linux/sunrpc/svc_rdma.h b/include/linux/sunrpc/svc_rdma.h
index df6e08aaad5709..217f000be5d6e2 100644
--- a/include/linux/sunrpc/svc_rdma.h
+++ b/include/linux/sunrpc/svc_rdma.h
@@ -78,8 +78,8 @@ struct svcxprt_rdma {
struct rdma_cm_id *sc_cm_id; /* RDMA connection id */
struct list_head sc_accept_q; /* Conn. waiting accept */
struct rpcrdma_notification sc_rn; /* removal notification */
- int sc_ord; /* RDMA read limit */
- int sc_max_send_sges;
+ u32 sc_ord; /* RDMA read limit */
+ unsigned int sc_max_send_sges;
bool sc_snd_w_inv; /* OK to use Send With Invalidate */
atomic_t sc_sq_avail; /* SQEs ready to be consumed */
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 9dd76f489a0ba4..b8b221b5f56473 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -406,36 +406,36 @@ struct ib_device_attr {
u32 vendor_id;
u32 vendor_part_id;
u32 hw_ver;
- int max_qp;
- int max_qp_wr;
+ u32 max_qp;
+ u32 max_qp_wr;
u64 device_cap_flags;
u64 kernel_cap_flags;
- int max_send_sge;
- int max_recv_sge;
- int max_sge_rd;
- int max_cq;
- int max_cqe;
- int max_mr;
- int max_pd;
- int max_qp_rd_atom;
- int max_ee_rd_atom;
- int max_res_rd_atom;
- int max_qp_init_rd_atom;
- int max_ee_init_rd_atom;
+ u32 max_send_sge;
+ u32 max_recv_sge;
+ u32 max_sge_rd;
+ u32 max_cq;
+ u32 max_cqe;
+ u32 max_mr;
+ u32 max_pd;
+ u32 max_qp_rd_atom;
+ u32 max_ee_rd_atom;
+ u32 max_res_rd_atom;
+ u32 max_qp_init_rd_atom;
+ u32 max_ee_init_rd_atom;
enum ib_atomic_cap atomic_cap;
enum ib_atomic_cap masked_atomic_cap;
- int max_ee;
- int max_rdd;
- int max_mw;
- int max_raw_ipv6_qp;
- int max_raw_ethy_qp;
- int max_mcast_grp;
- int max_mcast_qp_attach;
- int max_total_mcast_qp_attach;
- int max_ah;
+ u32 max_ee;
+ u32 max_rdd;
+ u32 max_mw;
+ u32 max_raw_ipv6_qp;
+ u32 max_raw_ethy_qp;
+ u32 max_mcast_grp;
+ u32 max_mcast_qp_attach;
+ u32 max_total_mcast_qp_attach;
+ u32 max_ah;
int max_srq;
- int max_srq_wr;
- int max_srq_sge;
+ u32 max_srq_wr;
+ u32 max_srq_sge;
unsigned int max_fast_reg_page_list_len;
unsigned int max_pi_fast_reg_page_list_len;
u16 max_pkeys;
diff --git a/net/rds/ib.c b/net/rds/ib.c
index 39f87272e071bf..c62684d4259c4f 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -162,12 +162,12 @@ static int rds_ib_add_one(struct ib_device *device)
IB_ODP_SUPPORT_READ);
rds_ibdev->max_1m_mrs = device->attrs.max_mr ?
- min_t(unsigned int, (device->attrs.max_mr / 2),
- rds_ib_mr_1m_pool_size) : rds_ib_mr_1m_pool_size;
+ min(device->attrs.max_mr / 2,
+ rds_ib_mr_1m_pool_size) : rds_ib_mr_1m_pool_size;
rds_ibdev->max_8k_mrs = device->attrs.max_mr ?
- min_t(unsigned int, ((device->attrs.max_mr / 2) * RDS_MR_8K_SCALE),
- rds_ib_mr_8k_pool_size) : rds_ib_mr_8k_pool_size;
+ min((device->attrs.max_mr / 2) * RDS_MR_8K_SCALE,
+ rds_ib_mr_8k_pool_size) : rds_ib_mr_8k_pool_size;
rds_ibdev->max_initiator_depth = device->attrs.max_qp_init_rd_atom;
rds_ibdev->max_responder_resources = device->attrs.max_qp_rd_atom;
@@ -204,7 +204,7 @@ static int rds_ib_add_one(struct ib_device *device)
goto put_dev;
}
- rdsdebug("RDS/IB: max_mr = %d, max_wrs = %d, max_sge = %d, max_1m_mrs = %d, max_8k_mrs = %d\n",
+ rdsdebug("RDS/IB: max_mr = %u, max_wrs = %d, max_sge = %d, max_1m_mrs = %d, max_8k_mrs = %d\n",
device->attrs.max_mr, rds_ibdev->max_wrs, rds_ibdev->max_sge,
rds_ibdev->max_1m_mrs, rds_ibdev->max_8k_mrs);
diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index 5667f0173b47f2..17e587c3007663 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -173,11 +173,11 @@ static void rds_ib_cm_fill_conn_param(struct rds_connection *conn,
memset(conn_param, 0, sizeof(struct rdma_conn_param));
- conn_param->responder_resources =
- min_t(u32, rds_ibdev->max_responder_resources, max_responder_resources);
- conn_param->initiator_depth =
- min_t(u32, rds_ibdev->max_initiator_depth, max_initiator_depth);
- conn_param->retry_count = min_t(unsigned int, rds_ib_retry_count, 7);
+ conn_param->responder_resources = min3(rds_ibdev->max_responder_resources,
+ max_responder_resources, U8_MAX);
+ conn_param->initiator_depth = min3(rds_ibdev->max_initiator_depth,
+ max_initiator_depth, U8_MAX);
+ conn_param->retry_count = min(rds_ib_retry_count, 7U);
conn_param->rnr_retry_count = 7;
if (dp) {
diff --git a/net/sunrpc/xprtrdma/frwr_ops.c b/net/sunrpc/xprtrdma/frwr_ops.c
index 7f79a0a2601e65..b2e437afe09daa 100644
--- a/net/sunrpc/xprtrdma/frwr_ops.c
+++ b/net/sunrpc/xprtrdma/frwr_ops.c
@@ -172,8 +172,9 @@ int frwr_mr_init(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr *mr)
int frwr_query_device(struct rpcrdma_ep *ep, const struct ib_device *device)
{
const struct ib_device_attr *attrs = &device->attrs;
- int max_qp_wr, depth, delta;
unsigned int max_sge;
+ u32 max_qp_wr;
+ int depth, delta;
if (!(attrs->device_cap_flags & IB_DEVICE_MEM_MGT_EXTENSIONS) ||
attrs->max_fast_reg_page_list_len == 0) {
@@ -229,10 +230,10 @@ int frwr_query_device(struct rpcrdma_ep *ep, const struct ib_device *device)
}
max_qp_wr = attrs->max_qp_wr;
+ if (max_qp_wr < RPCRDMA_BACKWARD_WRS + 1 + RPCRDMA_MIN_SLOT_TABLE)
+ return -ENOMEM;
max_qp_wr -= RPCRDMA_BACKWARD_WRS;
max_qp_wr -= 1;
- if (max_qp_wr < RPCRDMA_MIN_SLOT_TABLE)
- return -ENOMEM;
if (ep->re_max_requests > max_qp_wr)
ep->re_max_requests = max_qp_wr;
ep->re_attr.cap.max_send_wr = ep->re_max_requests * depth;
diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
index f18bc60d9f4ffa..c768cda2e5444a 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
@@ -544,8 +544,7 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt *xprt)
set_bit(RDMAXPRT_CONN_PENDING, &newxprt->sc_flags);
memset(&conn_param, 0, sizeof conn_param);
conn_param.responder_resources = 0;
- conn_param.initiator_depth = min_t(int, newxprt->sc_ord,
- dev->attrs.max_qp_init_rd_atom);
+ conn_param.initiator_depth = min(newxprt->sc_ord, dev->attrs.max_qp_init_rd_atom);
if (!conn_param.initiator_depth) {
ret = -EINVAL;
trace_svcrdma_initdepth_err(newxprt, ret);
@@ -570,7 +569,7 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt *xprt)
dprintk(" local address : %pIS:%u\n", sap, rpc_get_port(sap));
sap = (struct sockaddr *)&newxprt->sc_cm_id->route.addr.dst_addr;
dprintk(" remote address : %pIS:%u\n", sap, rpc_get_port(sap));
- dprintk(" max_sge : %d\n", newxprt->sc_max_send_sges);
+ dprintk(" max_sge : %u\n", newxprt->sc_max_send_sges);
dprintk(" sq_depth : %d\n", newxprt->sc_sq_depth);
dprintk(" rdma_rw_ctxs : %d\n", ctxts);
dprintk(" max_requests : %d\n", newxprt->sc_max_requests);
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index aecf9c0a153f36..8ed9da6d2d2f77 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -453,7 +453,7 @@ static int rpcrdma_ep_create(struct rpcrdma_xprt *r_xprt)
/* Client offers RDMA Read but does not initiate */
ep->re_remote_cma.initiator_depth = 0;
ep->re_remote_cma.responder_resources =
- min_t(int, U8_MAX, device->attrs.max_qp_rd_atom);
+ min(device->attrs.max_qp_rd_atom, U8_MAX);
/* Limit transport retries so client can detect server
* GID changes quickly. RPC layer handles re-establishing
|
| 3/2 | 2026/06/19 20:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 16105 output: 47 thoughts: 1291 Thoughts: **RDMA Subsystem Type Refactoring & Underflow Fixes - Worth Fuzzing?** Okay, so I'm looking at this patch and it's making some pretty significant type changes in the RDMA/InfiniBand subsystem. Specifically, a lot of fields in `struct ib_device_attr` are going from `int` to `u32`, which seems like a good move for consistency. We're also seeing the usual updates to use `min()` instead of `min_t()` and the associated format string updates (`%d` to `%u`). Standard stuff. But wait, is this just refactoring, or are there functional implications that warrant fuzzing? Let's dig in. It's essentially a type change and underflow prevention, but the details are important. Looking at the diff, it seems that there are two places where there are meaningful changes: In `nvme_rdma_find_get_device` and `nvmet_rdma_find_get_device`, there's a correction to prevent underflow if `max_send_sge` is 0, which is important. Additionally, in `frwr_query_device`, the change prevents an underflow in `max_qp_wr` that could have resulted in errors. This patch touches a lot of RDMA code: the core, RXE, NVMe over Fabrics (RDMA), SRP, SRPT, iSER, iSERT, SMB Direct, RPC RDMA, and RDS. A lot of connections could be affected by this patch. The prompt says to return "WorthFuzzing=false" if it only contains numeric constant or macro changes. This is mostly a type change with some underflow checks. However, there are some changes in `nvme_rdma_find_get_device`, `nvmet_rdma_find_get_device`, and `frwr_query_device` functions and thus, are worth considering. Let's see: `nvme_rdma_find_get_device` and `nvmet_rdma_find_get_device` are connection establishment functions within the NVMe-oF context, and `frwr_query_device` is called during RPC RDMA transport setup. Can we fuzz them effectively? Syzkaller has some NVMe-oF and RDMA support (particularly RXE). These functions are reachable. "If it modifies reachable core kernel logic, drivers, or architectures, use your code search tools to verify the code can be executed, then return WorthFuzzing=true." RXE is software RDMA and can be executed. NVMe-oF over RDMA can run with RXE. And RPC RDMA can run with RXE. Based on that, I'm thinking about these functions: - `nvme_rdma_find_get_device` - `nvmet_rdma_find_get_device` - `frwr_query_device` - `rxe_qp_chk_cap` - `rxe_qp_chk_attr` - `rxe_srq_chk_init` - `rxe_srq_chk_attr` I'll verify these functions exist and are reachable, and then consider this patch definitely worth fuzzing. |
| 4/2 | 2026/06/19 20:46 | tool | grepper |
0mError:no matches Args: {
"Expression": "^(static )?(int|void|struct [a-zA-Z0-9_]+ \\*) nvme_rdma_find_get_device"
}Results: {
"error": "no matches"
} |
| 5/2 | 2026/06/19 20:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 18166 output: 25 thoughts: 28 Thoughts: Okay, here's my summary, presented as a stream of thought: **Debugging the NVMe-RDMA Code** Alright, something isn't quite right with this `grep` expression. It's just not giving me what I need. Perhaps I've been too broad in my search terms. I need to be more precise, more targeted. Let's narrow this down and be specific: I'll focus on the core function, the one that's giving me the most trouble. Forget the initial broad approach, let's just grep directly for the name of that critical function: `nvme_rdma_find_get_device`. That should cut through the noise and give me a laser-focused view of its use. This should be a much more efficient way to drill down to the problem. |
| 6/2 | 2026/06/19 20:46 | tool | grepper |
0mArgs:{
"Expression": "nvme_rdma_find_get_device"
}Results: {
"Output": "drivers/nvme/host/rdma.c=366=static struct nvme_rdma_device *\ndrivers/nvme/host/rdma.c:367:nvme_rdma_find_get_device(struct rdma_cm_id *cm_id)\ndrivers/nvme/host/rdma.c-368-{\n--\ndrivers/nvme/host/rdma.c=491=static int nvme_rdma_create_queue_ib(struct nvme_rdma_queue *queue)\n--\ndrivers/nvme/host/rdma.c-497-\ndrivers/nvme/host/rdma.c:498:\tqueue-\u003edevice = nvme_rdma_find_get_device(queue-\u003ecm_id);\ndrivers/nvme/host/rdma.c-499-\tif (!queue-\u003edevice) {\n"
} |
| 7/2 | 2026/06/19 20:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 18616 output: 25 thoughts: 48 Thoughts: Here's my thought process, summarized as you requested: **Navigating the NVMe/RDMA Codebase** Alright, so I need to understand how NVMe over RDMA devices are discovered. I remember seeing `nvme_rdma_find_get_device` in the kernel source before. Let me see... yes, that's right, it's located in `drivers/nvme/host/rdma.c`. That's the starting point. Now, to understand the broader context, I need to see where that function is used and how it interacts with the NVMe-oF target side. I bet there is a `nvmet_rdma_find_get_device` that will be relevant. I should check that as the next step. |
| 8/2 | 2026/06/19 20:46 | tool | grepper |
0mArgs:{
"Expression": "nvmet_rdma_find_get_device"
}Results: {
"Output": "drivers/nvme/target/rdma.c=1193=static struct nvmet_rdma_device *\ndrivers/nvme/target/rdma.c:1194:nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)\ndrivers/nvme/target/rdma.c-1195-{\n--\ndrivers/nvme/target/rdma.c=1573=static int nvmet_rdma_queue_connect(struct rdma_cm_id *cm_id,\n--\ndrivers/nvme/target/rdma.c-1579-\ndrivers/nvme/target/rdma.c:1580:\tndev = nvmet_rdma_find_get_device(cm_id);\ndrivers/nvme/target/rdma.c-1581-\tif (!ndev) {\n"
} |
| 9/2 | 2026/06/19 20:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 19081 output: 20 thoughts: 12 Thoughts: Here's my take on the thought process, as if it were my own: **Analyzing `frwr_query_device`** Okay, time to dive into `frwr_query_device`. Let's see what's happening under the hood. I need to understand its functionality and where it fits within the larger architecture. I'm going to start by tracing its dependencies and see what other modules or functions it interacts with. Are there any potential bottlenecks or areas for optimization here? I'm particularly interested in how it handles error conditions and edge cases; robustness is always a key consideration, especially in this domain. What kind of data is this function querying, and how is that data used downstream? Are there any opportunities to leverage caching or pre-computed values to improve performance? This warrants a deep investigation. Let's start with a systematic code review and identify any potential areas of concern. |
| 10/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "frwr_query_device"
}Results: {
"Output": "net/sunrpc/xprtrdma/frwr_ops.c=122=int frwr_mr_init(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr *mr)\n--\nnet/sunrpc/xprtrdma/frwr_ops.c-155-/**\nnet/sunrpc/xprtrdma/frwr_ops.c:156: * frwr_query_device - Prepare a transport for use with FRWR\nnet/sunrpc/xprtrdma/frwr_ops.c-157- * @ep: endpoint to fill in\n--\nnet/sunrpc/xprtrdma/frwr_ops.c-171- */\nnet/sunrpc/xprtrdma/frwr_ops.c:172:int frwr_query_device(struct rpcrdma_ep *ep, const struct ib_device *device)\nnet/sunrpc/xprtrdma/frwr_ops.c-173-{\n--\nnet/sunrpc/xprtrdma/verbs.c=378=static int rpcrdma_ep_create(struct rpcrdma_xprt *r_xprt)\n--\nnet/sunrpc/xprtrdma/verbs.c-404-\tep-\u003ere_inline_recv = xprt_rdma_max_inline_read;\nnet/sunrpc/xprtrdma/verbs.c:405:\trc = frwr_query_device(ep, device);\nnet/sunrpc/xprtrdma/verbs.c-406-\tif (rc)\n--\nnet/sunrpc/xprtrdma/xprt_rdma.h=551=void frwr_reset(struct rpcrdma_req *req);\nnet/sunrpc/xprtrdma/xprt_rdma.h:552:int frwr_query_device(struct rpcrdma_ep *ep, const struct ib_device *device);\nnet/sunrpc/xprtrdma/xprt_rdma.h-553-int frwr_mr_init(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr *mr);\n"
} |
| 11/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 19868 output: 22 thoughts: 14 Thoughts: Okay, let's dive into this. Here's how I'd approach summarizing the "Thoughts" based on my expertise: **Checking `rxe_qp_chk_cap`** Alright, so the first thing that pops into my head is `rxe_qp_chk_cap`. I see this as a potential point of interest. Immediately, I'm thinking about the implications – this likely refers to a function or routine within the RXE (RDMA over Converged Ethernet) context that's responsible for checking the capabilities or constraints of a Queue Pair (QP). Given my experience, I'm already formulating questions: What aspects of the QP are we checking? Is this related to resource limits, protocol restrictions, or hardware support? Is this checking the QP state? The size, number of WQEs, any other feature bits? The specific context here is important as different capabilities are checked at different times. If I know the context, and the other code, I can give a much richer answer. From this starting point, I'd want to understand where this function fits into the overall RXE stack, what triggers its execution, and what the consequences of its return values are. That would give me some insight on what's going on. |
| 12/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "rxe_qp_chk_cap"
}Results: {
"Output": "drivers/infiniband/sw/rxe/rxe_qp.c=37=static inline void rxe_reclassify_send_socket(struct socket *sock)\n--\ndrivers/infiniband/sw/rxe/rxe_qp.c-65-\ndrivers/infiniband/sw/rxe/rxe_qp.c:66:static int rxe_qp_chk_cap(struct rxe_dev *rxe, struct ib_qp_cap *cap,\ndrivers/infiniband/sw/rxe/rxe_qp.c-67-\t\t\t int has_srq)\n--\ndrivers/infiniband/sw/rxe/rxe_qp.c=107=int rxe_qp_chk_init(struct rxe_dev *rxe, struct ib_qp_init_attr *init)\n--\ndrivers/infiniband/sw/rxe/rxe_qp.c-127-\ndrivers/infiniband/sw/rxe/rxe_qp.c:128:\tif (rxe_qp_chk_cap(rxe, cap, !!init-\u003esrq))\ndrivers/infiniband/sw/rxe/rxe_qp.c-129-\t\tgoto err1;\n--\ndrivers/infiniband/sw/rxe/rxe_qp.c=487=int rxe_qp_chk_attr(struct rxe_dev *rxe, struct rxe_qp *qp,\n--\ndrivers/infiniband/sw/rxe/rxe_qp.c-496-\ndrivers/infiniband/sw/rxe/rxe_qp.c:497:\tif (mask \u0026 IB_QP_CAP \u0026\u0026 rxe_qp_chk_cap(rxe, \u0026attr-\u003ecap, !!qp-\u003esrq))\ndrivers/infiniband/sw/rxe/rxe_qp.c-498-\t\tgoto err1;\n"
} |
| 13/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 20651 output: 20 thoughts: 233 Thoughts: **Patch Analysis for Virtualized Environments** Okay, so this patch is definitely something I need to look at more closely. It impacts functional logic accessible within virtualized environments because we're dealing with RXE, which is, of course, a software RDMA driver. That raises a flag. I see the changes are *primarily* type adjustments, which is generally less concerning, but they also address potential underflow issues or logic errors linked to `max_send_sge` and `max_qp_wr`. Hmm. The next question, naturally, is whether fuzzing is warranted here. Given that it touches reachable core kernel logic and drivers, the answer is a resounding *yes*. Absolutely, fuzzing is required. This has the potential for significant impact, even with the type-related changes. Now, let's identify all the relevant configurations. For RXE, that's straightforward: `RDMA_RXE`. Then we have NVMe-oF RDMA, which requires `NVME_RDMA` and `NVME_TARGET_RDMA`. RPC RDMA needs `SUNRPC_XPRT_RDMA` and `SVC_RDMA`. SMB Direct is controlled by `CIFS_SMB_DIRECT`, and SRP/SRPT involves `INFINIBAND_SRP` and `INFINIBAND_SRPT`. For iSER/iSERT it's `INFINIBAND_ISER` and `INFINIBAND_ISERT`. Finally, RDS uses `RDS` and `RDS_RDMA`. Alright, time to go and check the Kconfig files and see what more I can find. |
| 14/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "config RDMA_RXE"
}Results: {
"Output": "drivers/infiniband/sw/rxe/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/sw/rxe/Kconfig:2:config RDMA_RXE\ndrivers/infiniband/sw/rxe/Kconfig-3-\ttristate \"Software RDMA over Ethernet (RoCE) driver\"\n"
} |
| 15/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 21345 output: 20 thoughts: 11 Thoughts: Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert: **NVME_RDMA Deep Dive** Alright, time to focus. First things first: `NVME_RDMA`. Got to get my head back in that space. Let's see... what's my initial mental checklist? Latency, bandwidth, fabric considerations... the usual suspects. I need to refresh the key concepts, the critical design decisions behind it. Was there a specific use case or paper that I was thinking about earlier today? Right, need to ensure everything's clear on my mind before diving into the core of the problems. Okay, time to bring up the relevant papers and start connecting the dots. |
| 16/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "config NVME_RDMA"
}Results: {
"Output": "drivers/nvme/host/Kconfig=47=config NVME_FABRICS\n--\ndrivers/nvme/host/Kconfig-51-\ndrivers/nvme/host/Kconfig:52:config NVME_RDMA\ndrivers/nvme/host/Kconfig-53-\ttristate \"NVM Express over Fabrics RDMA host driver\"\n"
} |
| 17/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 21629 output: 22 thoughts: 13 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person: **Navigating the NVMe Over Fabrics Landscape** Alright, time to dive in. My immediate thought? Let's zero in on the `NVME_TARGET_RDMA` aspect of this. I need to refresh my mental model of that specific configuration. I'm already thinking about its nuances compared to other fabric transports – specifically, how it handles the direct memory access implications. Are we talking full RDMA semantics, or a more nuanced approach? What are the implications for the target's resource management and its interaction with the host's RDMA verbs? I'm anticipating potential performance bottlenecks in the network or host-side protocol processing, and `NVME_TARGET_RDMA` is the key piece of that puzzle. It's time to refresh my understanding of the relevant RFCs and any recent performance reports related to this configuration. I need to make sure I have a solid grip on the specific RDMA implementation being used and its impact on end-to-end latency. |
| 18/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "config NVME_TARGET_RDMA"
}Results: {
"Output": "drivers/nvme/target/Kconfig=41=config NVME_TARGET_LOOP\n--\ndrivers/nvme/target/Kconfig-51-\ndrivers/nvme/target/Kconfig:52:config NVME_TARGET_RDMA\ndrivers/nvme/target/Kconfig-53-\ttristate \"NVMe over Fabrics RDMA target support\"\n"
} |
| 19/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 21991 output: 24 thoughts: 22 Thoughts: Here's a summary of my immediate thought process: **RDMA Transport Configuration Check** Okay, so I need to quickly zero in on the RDMA aspects of this. My first thought is to dive right into checking the core configurations related to Remote Direct Memory Access in this context. Specifically, I'm going to look for the presence and settings of `SUNRPC_XPRT_RDMA` and `SVC_RDMA`. These are the keys to understanding how the transport layer is set up and if RDMA is properly enabled and configured on the server-side. |
| 20/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "config SUNRPC_XPRT_RDMA"
}Results: {
"Output": "net/sunrpc/Kconfig=104=config SUNRPC_DEBUG_TRACE\n--\nnet/sunrpc/Kconfig-117-\nnet/sunrpc/Kconfig:118:config SUNRPC_XPRT_RDMA\nnet/sunrpc/Kconfig-119-\ttristate \"RPC-over-RDMA transport\"\n"
} |
| 21/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 22253 output: 22 thoughts: 0 |
| 22/2 | 2026/06/19 20:47 | tool | grepper |
0mError:no matches Args: {
"Expression": "config SUNRPC_SVC_RDMA"
}Results: {
"error": "no matches"
} |
| 23/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 22289 output: 22 thoughts: 18 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Investigating `svc_rdma_transport.c` Configuration** Okay, hold on a second. I need to get my bearings here. I'm deep in the weeds with `svc_rdma_transport.c`, and I've hit a mental roadblock. Specifically, I need to understand the configuration parameters that are driving this module. It's a critical piece, obviously, but I'm getting a mental blank on the options available. I know there are several tuning parameters in this area. I need to refresh my memory and check what's set up in our particular environment. I’m thinking there is a tuning problem or configuration issue so I need to know where I am with the settings. I need to know the defaults as well. I need to find the right configuration and how it affects the transport. Right. Back to the documentation... |
| 24/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "svc_rdma_transport\\.o"
}Results: {
"Output": "net/sunrpc/xprtrdma/Makefile=4=rpcrdma-y := transport.o rpc_rdma.o verbs.o frwr_ops.o ib_client.o \\\nnet/sunrpc/xprtrdma/Makefile:5:\tsvc_rdma.o svc_rdma_backchannel.o svc_rdma_transport.o \\\nnet/sunrpc/xprtrdma/Makefile-6-\tsvc_rdma_sendto.o svc_rdma_recvfrom.o svc_rdma_rw.o \\\n"
} |
| 25/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 22670 output: 19 thoughts: 21 Thoughts: Okay, here's my summarized thought process, presented as if I'm analyzing this code myself: **Tracing the Source: rpcrdma-y & the Makefile** Right, so this appears to be originating from `rpcrdma-y`. That instantly tells me a few things, mostly related to RDMA, potentially related to remote procedure calls over RDMA. My immediate reaction is to check the `Makefile`. That's where I'm going to find the build rules, dependencies, and likely the crucial compilation flags or linker settings associated with this component. The `Makefile` is the Rosetta Stone for understanding how this `rpcrdma-y` module fits into the bigger picture. It's the logical next step to unraveling the purpose and implementation. |
| 26/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "rpcrdma-y"
}Results: {
"Output": "net/sunrpc/xprtrdma/Makefile=2=obj-$(CONFIG_SUNRPC_XPRT_RDMA) += rpcrdma.o\nnet/sunrpc/xprtrdma/Makefile-3-\nnet/sunrpc/xprtrdma/Makefile:4:rpcrdma-y := transport.o rpc_rdma.o verbs.o frwr_ops.o ib_client.o \\\nnet/sunrpc/xprtrdma/Makefile-5-\tsvc_rdma.o svc_rdma_backchannel.o svc_rdma_transport.o \\\n"
} |
| 27/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23024 output: 21 thoughts: 28 Thoughts: Okay, here's my take on those thoughts, framed as my own reasoning: **Initial Assessment of RDMA and CIFS** Alright, so we're looking at network protocols, and my initial thought is that `SUNRPC_XPRT_RDMA` likely covers the RDMA aspect effectively. That's a solid starting point. However, we're not just looking at RDMA, so, before I get too invested in that area, it's worth cross-referencing this thinking against the other protocol mentioned. My next move is to verify that `CIFS_SMB_DIRECT` is the right protocol. |
| 28/2 | 2026/06/19 20:47 | tool | grepper |
0mArgs:{
"Expression": "config CIFS_SMB_DIRECT"
}Results: {
"Output": "fs/smb/client/Kconfig=179=if CIFS\nfs/smb/client/Kconfig-180-\nfs/smb/client/Kconfig:181:config CIFS_SMB_DIRECT\nfs/smb/client/Kconfig-182-\tbool \"SMB Direct support\"\n"
} |
| 29/2 | 2026/06/19 20:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23295 output: 18 thoughts: 26 Thoughts: Here's my thought process, summarized as you requested: **Navigating the SMB Direct Accept Function** Okay, the problem seems to be originating within `fs/smb/smbdirect/accept.c`. That's where I need to focus my attention. Before I dive too deep into the code itself, I should take a step back and get a handle on the build environment. I need to understand how this specific file is compiled and linked. Therefore, the very first thing I'll do is check the `Makefile` associated with this directory. Understanding the build process will illuminate dependencies, compiler flags, and any relevant preprocessor definitions that might impact the behavior I'm seeing. Getting the build context is crucial before I even start reading the C code. It'll give me a clearer picture of how this function fits into the overall SMB Direct infrastructure. |
| 30/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "smbdirect/"
}Results: {
"Output": "MAINTAINERS=24769=F:\tfs/smb/client/smbdirect.*\nMAINTAINERS:24770:F:\tfs/smb/smbdirect/\nMAINTAINERS-24771-F:\tfs/smb/server/transport_rdma.*\n--\nfs/smb/Kconfig=6=source \"fs/smb/server/Kconfig\"\nfs/smb/Kconfig:7:source \"fs/smb/smbdirect/Kconfig\"\nfs/smb/Kconfig-8-\n--\nfs/smb/Makefile=3=obj-$(CONFIG_SMBFS)\t\t+= common/\nfs/smb/Makefile:4:obj-$(CONFIG_SMBDIRECT)\t\t+= smbdirect/\nfs/smb/Makefile-5-obj-$(CONFIG_CIFS)\t\t+= client/\n"
} |
| 31/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23738 output: 17 thoughts: 7 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person: **Reflecting on `CONFIG_SMBDIRECT`** Alright, so the prompt just threw out `CONFIG_SMBDIRECT`. That immediately makes me start thinking about RDMA, specifically InfiniBand or RoCE, and its application within the SMB protocol. We're talking about bypassing the traditional TCP/IP stack to provide low-latency, high-bandwidth file sharing, which is pretty exciting. I'm mentally parsing the implications: increased CPU offload, potentially lower latency bottlenecks on highly loaded systems. I'm also considering the hardware requirements - are we dealing with dedicated RDMA NICs, specific network fabric dependencies, and what about the kernel support? The potential performance benefits are there, but the complexity increases proportionally. The memory model implications are front and center as well – how are they handling the direct memory access and protection with the application? I would be asking if the kernel has the appropriate modules built in or even included. I wonder how the security model integrates with the RDMA capabilities and if the security layers and integrity are fully supported. I also want to know the current status: Is it still a highly-specialized niche implementation, or is it reaching a point of broader adoption in mainstream storage solutions? What's the state of the art when it comes to interoperability with different SMB dialects and versions? I imagine there's a trade-off between performance gain and feature compatibility. Let's see how this plays out. |
| 32/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config SMBDIRECT"
}Results: {
"Output": "fs/smb/smbdirect/Kconfig-4-\nfs/smb/smbdirect/Kconfig:5:config SMBDIRECT\nfs/smb/smbdirect/Kconfig-6-\tdef_tristate n\n"
} |
| 33/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 24149 output: 20 thoughts: 20 Thoughts: Here's my take on those thoughts: **Evaluating InfiniBand SRP and SRPT Configurations** Okay, so I'm thinking, let's just make sure we've looked at the current setup for `INFINIBAND_SRP` and `INFINIBAND_SRPT`. I want to get a good sense of the configuration and ensure nothing obvious is missed. This check is crucial for performance and stability, given the critical role of SRP and SRPT within the InfiniBand environment. This should be a quick diagnostic step, but important to do methodically. |
| 34/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config INFINIBAND_SRP"
}Results: {
"Output": "drivers/infiniband/ulp/srp/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/ulp/srp/Kconfig:2:config INFINIBAND_SRP\ndrivers/infiniband/ulp/srp/Kconfig-3-\ttristate \"InfiniBand SCSI RDMA Protocol\"\n--\ndrivers/infiniband/ulp/srpt/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/ulp/srpt/Kconfig:2:config INFINIBAND_SRPT\ndrivers/infiniband/ulp/srpt/Kconfig-3-\ttristate \"InfiniBand SCSI RDMA Protocol target support\"\n"
} |
| 35/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 24497 output: 20 thoughts: 20 Thoughts: Here's my thought process, as if I were considering this: **Investigating Infiniband iSER Configuration** Okay, so I need to quickly determine the status or relevance of these Infiniband-related variables. First, I'll need to check the configurations for both `INFINIBAND_ISER` and `INFINIBAND_ISERT`. I'm going to assume this is related to iSER (iSCSI Extensions for RDMA) because of the naming convention, but I need to confirm the specific function each one handles within the broader Infiniband ecosystem. I'll need to dig into the documentation, or maybe look at some example configurations. Hopefully, the naming is intuitive, and their purpose and relation will be self-evident. Ideally, I can see exactly what setting these variables impacts within the iSER stack to ensure that it's correctly configured or that I can identify a problem. |
| 36/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config INFINIBAND_ISER"
}Results: {
"Output": "drivers/infiniband/ulp/iser/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/ulp/iser/Kconfig:2:config INFINIBAND_ISER\ndrivers/infiniband/ulp/iser/Kconfig-3-\ttristate \"iSCSI Extensions for RDMA (iSER)\"\n--\ndrivers/infiniband/ulp/isert/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/ulp/isert/Kconfig:2:config INFINIBAND_ISERT\ndrivers/infiniband/ulp/isert/Kconfig-3-\ttristate \"iSCSI Extensions for RDMA (iSER) target support\"\n"
} |
| 37/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 24917 output: 21 thoughts: 25 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Examining Infiniband Router Client and Server Configuration** Alright, let's dive right in and dissect what's going on with the `INFINIBAND_RTRS_CLIENT` and `INFINIBAND_RTRS_SERVER` settings. My initial thought process is to quickly confirm the state of these variables. Depending on their configuration, we can begin to troubleshoot issues with Infiniband routing. They are fundamental in determining the functional relationship between the connected devices. Essentially, are they active, inactive, what are the current values? Are they correctly configured relative to each other? The relationship between client and server will become critical if there is any traffic flow problems. Knowing the values gives a solid foundation. These variables, in the context of routing, immediately trigger questions around whether they are properly defined, if there are any conflicts, and if they align with the expected communication model. I'll need to know the context of the larger setup to understand any specific issues, but these variables are a great starting point for analyzing routing configuration. |
| 38/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config INFINIBAND_RTRS"
}Results: {
"Output": "drivers/infiniband/ulp/rtrs/Kconfig-2-\ndrivers/infiniband/ulp/rtrs/Kconfig:3:config INFINIBAND_RTRS\ndrivers/infiniband/ulp/rtrs/Kconfig-4-\ttristate\n--\ndrivers/infiniband/ulp/rtrs/Kconfig-6-\ndrivers/infiniband/ulp/rtrs/Kconfig:7:config INFINIBAND_RTRS_CLIENT\ndrivers/infiniband/ulp/rtrs/Kconfig-8-\ttristate \"RTRS client module\"\n--\ndrivers/infiniband/ulp/rtrs/Kconfig-17-\ndrivers/infiniband/ulp/rtrs/Kconfig:18:config INFINIBAND_RTRS_SERVER\ndrivers/infiniband/ulp/rtrs/Kconfig-19-\ttristate \"RTRS server module\"\n"
} |
| 39/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25423 output: 19 thoughts: 10 Thoughts: Okay, here's my interpretation of that thought process, assuming I'm the expert: **Investigating RDMA within RDS** Alright, the mental gears are starting to turn. "RDS_RDMA"... that's the trigger. My first instinct is to zero in on this. I need to refresh my understanding of how RDMA interacts within the context of Remote Direct Memory Access (RDMA) and Relational Database Service (RDS). I need to check the current status, and start my investigation from there. Let's see what we can find. |
| 40/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config RDS_RDMA"
}Results: {
"Output": "net/rds/Kconfig=3=config RDS\n--\nnet/rds/Kconfig-9-\nnet/rds/Kconfig:10:config RDS_RDMA\nnet/rds/Kconfig-11-\ttristate \"RDS over Infiniband\"\n"
} |
| 41/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25643 output: 21 thoughts: 12 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Investigating the `INFINIBAND_IPOIB` Variable** Right, let's dive into this `INFINIBAND_IPOIB` thing. My initial thought is to immediately consider its context. We're obviously dealing with InfiniBand, and the presence of "IPOIB" suggests we're talking about IP over IB. This is usually the area of potential performance tuning/configuration, or debugging for IB fabric behavior. My mind immediately flashes to scenarios like: is this setting a driver flag, an environmental variable, or a kernel parameter? What level of the stack is it impacting? And from there, what might be its effects on, say, throughput, latency, or even overall system stability? I'm already anticipating questions about network interface configuration and potential conflicts with other network setups, perhaps even with things like `rdma_cm`. I need to assess what it does to the default behavior. Is this setting being used to enable, disable, or modify some aspect of IPOIB? Is it a general setting, or specific to a certain vendor's implementation, or possibly the linux kernel? I need to figure out what it's *doing* before I can understand its impact. |
| 42/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config INFINIBAND_IPOIB"
}Results: {
"Output": "drivers/infiniband/ulp/ipoib/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/ulp/ipoib/Kconfig:2:config INFINIBAND_IPOIB\ndrivers/infiniband/ulp/ipoib/Kconfig-3-\ttristate \"IP-over-InfiniBand\"\n--\ndrivers/infiniband/ulp/ipoib/Kconfig-11-\ndrivers/infiniband/ulp/ipoib/Kconfig:12:config INFINIBAND_IPOIB_CM\ndrivers/infiniband/ulp/ipoib/Kconfig-13-\tbool \"IP-over-InfiniBand Connected Mode support\"\n--\ndrivers/infiniband/ulp/ipoib/Kconfig-26-\ndrivers/infiniband/ulp/ipoib/Kconfig:27:config INFINIBAND_IPOIB_DEBUG\ndrivers/infiniband/ulp/ipoib/Kconfig-28-\tbool \"IP-over-InfiniBand debugging\" if EXPERT\n--\ndrivers/infiniband/ulp/ipoib/Kconfig-41-\ndrivers/infiniband/ulp/ipoib/Kconfig:42:config INFINIBAND_IPOIB_DEBUG_DATA\ndrivers/infiniband/ulp/ipoib/Kconfig-43-\tbool \"IP-over-InfiniBand data path debugging\"\n"
} |
| 43/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26289 output: 17 thoughts: 139 Thoughts: **Examining the RDMA Configurations** Alright, let's take a look at these RDMA-related configurations. I see a pretty comprehensive list here: `RDMA_RXE`, `NVME_RDMA`, `NVME_TARGET_RDMA`, `SUNRPC_XPRT_RDMA`, `SMBDIRECT`, `INFINIBAND_SRP`, `INFINIBAND_SRPT`, `INFINIBAND_ISER`, `INFINIBAND_ISERT`, `INFINIBAND_RTRS_CLIENT`, `INFINIBAND_RTRS_SERVER`, `RDS_RDMA`, and `INFINIBAND_IPOIB`. Seems like the kernel developers have been keeping busy! Hang on a second… isn't `SMBDIRECT` a hidden config? That rings a bell. Gotta double-check that. Let me quickly go look in `fs/smb/smbdirect/Kconfig` to confirm and refresh my memory on the dependencies and purpose. |
| 44/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config SMBDIRECT"
}Results: {
"Output": "fs/smb/smbdirect/Kconfig-4-\nfs/smb/smbdirect/Kconfig:5:config SMBDIRECT\nfs/smb/smbdirect/Kconfig-6-\tdef_tristate n\n"
} |
| 45/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26718 output: 17 thoughts: 18 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Analyzing the Function Definition** Okay, so I see a function definition here: `def_tristate n`. The immediate question is, where is `def_tristate` being invoked from? Its signature alone doesn't give me much context, so I need to trace back the call chain to understand its purpose within the larger system. This implies that there is some external factor at play which is selecting this. I need to figure out what that trigger is, and what possible outcomes are at play here. Without that understanding, I'm just looking at a syntactic snippet. Its selection indicates that there's a specific logic path being chosen, and I need to figure out the conditions that lead to its execution. |
| 46/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "select SMBDIRECT"
}Results: {
"Output": "fs/smb/client/Kconfig=181=config CIFS_SMB_DIRECT\n--\nfs/smb/client/Kconfig-184-\tdepends on CIFS=m || INFINIBAND=y\nfs/smb/client/Kconfig:185:\tselect SMBDIRECT\nfs/smb/client/Kconfig-186-\thelp\n--\nfs/smb/server/Kconfig=48=config SMB_SERVER_SMBDIRECT\n--\nfs/smb/server/Kconfig-51-\tdepends on SMB_SERVER=m || INFINIBAND=y\nfs/smb/server/Kconfig:52:\tselect SMBDIRECT\nfs/smb/server/Kconfig-53-\tdefault n\n"
} |
| 47/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 27108 output: 22 thoughts: 46 Thoughts: Okay, here's my take on those thoughts, framed as my own: **Enabling SMB Direct and RDMA for Optimal Performance** Alright, let's get down to brass tacks. Based on my understanding of the architecture, I need to focus on enabling `CIFS_SMB_DIRECT` and `SMB_SERVER_SMBDIRECT` first and foremost. These are the key settings to unlock the performance benefits of SMB Direct and Remote Direct Memory Access (RDMA). That's the baseline, the foundation. Now, let's pivot to the hardware. I need to specifically confirm this is possible with the `QEDR` (QLogic FastLinQ 4xxxx Core Module) I'm working with. This will be the deciding factor if I can make use of SMB Direct. |
| 48/2 | 2026/06/19 20:48 | tool | grepper |
0mArgs:{
"Expression": "config INFINIBAND_QEDR"
}Results: {
"Output": "drivers/infiniband/hw/qedr/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/hw/qedr/Kconfig:2:config INFINIBAND_QEDR\ndrivers/infiniband/hw/qedr/Kconfig-3-\ttristate \"QLogic RoCE driver\"\n"
} |
| 49/2 | 2026/06/19 20:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 27442 output: 360 thoughts: 1102 Thoughts: **RDMA Attribute Type Change and Fuzzing Strategy** Okay, so I'm thinking about this patch. First off, QEDR is a hardware driver, right? So, it's not relevant here since we're focused on a virtualized environment. RXE is our software RDMA solution, so that's the angle we need to take. No need to get bogged down in QEDR. Alright, let's look at the functions impacted. Initially, I had a pretty exhaustive list, but that's going to be too much for testing. Time to hone in on the important ones. I need a representative set of functions that are directly modified and are not frequently accessed "hot paths" so that they can be fuzzed without impacting the system in an impactful manner. I've got a slightly more manageable list now: `nvme_rdma_find_get_device`, `nvmet_rdma_find_get_device`, `frwr_query_device`, `rxe_qp_chk_cap`, `rxe_srq_chk_init`, `smbdirect_connection_create_qp`, `rds_ib_cm_fill_conn_param`, `svc_rdma_accept`, and `rpcrdma_ep_create`. These all seem reasonable. We're looking at connection setup, EP creation, QP/SRQ creation, so not usually in the hot path. Perfect. Now, as far as configs go, besides the `RDMA_RXE`, we have a bunch more. I'll need to go through all of them (`NVME_RDMA`, `NVME_TARGET_RDMA`, `SUNRPC_XPRT_RDMA`, `CIFS_SMB_DIRECT`, `SMB_SERVER_SMBDIRECT`, `INFINIBAND_SRP`, `INFINIBAND_SRPT`, `INFINIBAND_ISER`, `INFINIBAND_ISERT`, `INFINIBAND_RTRS_CLIENT`, `INFINIBAND_RTRS_SERVER`, `RDS_RDMA`, `INFINIBAND_IPOIB`) to ensure the changes are correctly handled. Just confirming `RDMA_RXE` is sufficient for software RDMA - yes, we are good. Just in case, I also made note of `RDMA_SIW`, but we're focusing on RXE here. Okay, let's recap my reasoning. This patch is changing integer types from `int` to `u32` for RDMA device attributes, also updating `min()` calls and format strings. There are fixes for potential underflows in some crucial functions: `nvme_rdma_find_get_device`, `nvmet_rdma_find_get_device`, and `frwr_query_device`. These changes touch the core RDMA logic and multiple ULPs which can be tested in our environment using the RXE software RDMA driver. This means we'll need fuzzing to make sure no regressions or any new integer overflow/underflow bugs have been introduced by these changes. Now I think I have a clear plan. Time to produce a concise summary. |
| 50/2 | 2026/06/19 20:49 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"RDMA_RXE",
"NVME_RDMA",
"NVME_TARGET_RDMA",
"SUNRPC_XPRT_RDMA",
"CIFS_SMB_DIRECT",
"SMB_SERVER_SMBDIRECT",
"INFINIBAND_SRP",
"INFINIBAND_SRPT",
"INFINIBAND_ISER",
"INFINIBAND_ISERT",
"INFINIBAND_RTRS_CLIENT",
"INFINIBAND_RTRS_SERVER",
"RDS_RDMA",
"INFINIBAND_IPOIB"
],
"FocusSymbols": [
"nvme_rdma_find_get_device",
"nvmet_rdma_find_get_device",
"frwr_query_device",
"rxe_qp_chk_cap",
"rxe_srq_chk_init",
"smbdirect_connection_create_qp",
"rds_ib_cm_fill_conn_param",
"svc_rdma_accept",
"rpcrdma_ep_create"
],
"Reasoning": "The patch changes the types of various RDMA device attributes from `int` to `u32` and updates the corresponding `min()` calls and format strings. It also fixes some potential underflows in connection setup functions. These changes affect the core RDMA logic and various RDMA ULPs (Upper Layer Protocols) which can be tested using the software RDMA driver (RXE). It is worth fuzzing to ensure no regressions or new integer overflow/underflow bugs were introduced.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"RDMA_RXE",
"NVME_RDMA",
"NVME_TARGET_RDMA",
"SUNRPC_XPRT_RDMA",
"CIFS_SMB_DIRECT",
"SMB_SERVER_SMBDIRECT",
"INFINIBAND_SRP",
"INFINIBAND_SRPT",
"INFINIBAND_ISER",
"INFINIBAND_ISERT",
"INFINIBAND_RTRS_CLIENT",
"INFINIBAND_RTRS_SERVER",
"RDS_RDMA",
"INFINIBAND_IPOIB"
],
"FocusSymbols": [
"nvme_rdma_find_get_device",
"nvmet_rdma_find_get_device",
"frwr_query_device",
"rxe_qp_chk_cap",
"rxe_srq_chk_init",
"smbdirect_connection_create_qp",
"rds_ib_cm_fill_conn_param",
"svc_rdma_accept",
"rpcrdma_ep_create"
],
"Reasoning": "The patch changes the types of various RDMA device attributes from `int` to `u32` and updates the corresponding `min()` calls and format strings. It also fixes some potential underflows in connection setup functions. These changes affect the core RDMA logic and various RDMA ULPs (Upper Layer Protocols) which can be tested using the software RDMA driver (RXE). It is worth fuzzing to ensure no regressions or new integer overflow/underflow bugs were introduced.",
"WorthFuzzing": true
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|