In the old days, RDS used FMR (Fast Memory Registration) to register
IB MRs to be used by RDMA. A newer and better verbs based
registration/de-registration method called FRWR (Fast Registration
Work Request) was added to RDS by commit 1659185fb4d0 ("RDS: IB:
Support Fastreg MR (FRMR) memory registration mode") in 2016.

Detection and enablement of FRWR was done in commit 2cb2912d6563
("RDS: IB: add Fastreg MR (FRMR) detection support"). But said commit
added an extern bool prefer_frmr, which was not used by said commit -
nor used by later commits. Hence, remove it.

Fixes: 2cb2912d6563 ("RDS: IB: add Fastreg MR (FRMR) detection support")
Cc: stable@vger.kernel.org
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

	v1 -> v2:
	      * Added commit message
	      * Added Cc: stable@vger.kernel.org
---
 net/rds/ib_mr.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/rds/ib_mr.h b/net/rds/ib_mr.h
index ea5e9aee4959e..5884de8c6f45b 100644
--- a/net/rds/ib_mr.h
+++ b/net/rds/ib_mr.h
@@ -108,7 +108,6 @@ struct rds_ib_mr_pool {
 };
 
 extern struct workqueue_struct *rds_ib_mr_wq;
-extern bool prefer_frmr;
 
 struct rds_ib_mr_pool *rds_ib_create_mr_pool(struct rds_ib_device *rds_dev,
 					     int npages);
-- 
2.43.5

On Thu,  4 Sep 2025 13:53:43 +0200 Håkon Bugge wrote:
> Fixes: 2cb2912d6563 ("RDS: IB: add Fastreg MR (FRMR) detection support")
> Cc: stable@vger.kernel.org

Fixes: and cc: stable is for bug fixes which we care about so deeply we
want them backported ASAP. Why do you think removing an unused
declaration qualifies as such :\
-- 
pw-bot: cr

Hi Jakub,


> On 4 Sep 2025, at 15:55, Jakub Kicinski <kuba@kernel.org> wrote:
> 
> On Thu,  4 Sep 2025 13:53:43 +0200 Håkon Bugge wrote:
>> Fixes: 2cb2912d6563 ("RDS: IB: add Fastreg MR (FRMR) detection support")
>> Cc: stable@vger.kernel.org
> 
> Fixes: and cc: stable is for bug fixes which we care about so deeply we
> want them backported ASAP. Why do you think removing an unused
> declaration qualifies as such :\

Sorry if I have mis-interpreted the collateral. From [1], I quote:

"A Fixes: tag indicates that the patch fixes an issue in a previous commit." As such, it is an "issue" and I reference the offending commit.

As to "Cc: stable", you're quite right. My bad. You want a v3 or are you (and stable) able to handle it?



Thxs, Håkon




[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

On Thu, 4 Sep 2025 14:22:02 +0000 Haakon Bugge wrote:
> Sorry if I have mis-interpreted the collateral. From [1], I quote:
> 
> "A Fixes: tag indicates that the patch fixes an issue in a previous
> commit." As such, it is an "issue" and I reference the offending
> commit.

You're not the first one to misinterpret it, I guess we should fix the
doc :$

> As to "Cc: stable", you're quite right. My bad. You want a v3 or are
> you (and stable) able to handle it?

Please repost this one without the extra tags, and if you want it to go
via netdev the subject tag should be net-next in this case (it will end
up in 6.18)

On Thu, Sep 04, 2025 at 07:33:43AM -0700, Jakub Kicinski wrote:
> On Thu, 4 Sep 2025 14:22:02 +0000 Haakon Bugge wrote:
> > Sorry if I have mis-interpreted the collateral. From [1], I quote:
> > 
> > "A Fixes: tag indicates that the patch fixes an issue in a previous
> > commit." As such, it is an "issue" and I reference the offending
> > commit.
> 
> You're not the first one to misinterpret it, I guess we should fix the
> doc :$

+1

FTR, a fix implies a bug. And a good rule of thumb that a bug
is something broken that is user-visible. E.g. a system panic.

> 
> > As to "Cc: stable", you're quite right. My bad. You want a v3 or are
> > you (and stable) able to handle it?
> 
> Please repost this one without the extra tags, and if you want it to go
> via netdev the subject tag should be net-next in this case (it will end
> up in 6.18)