[Bug 244572] Resources leaked by linux_kpi when resetting RDMA device

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Mar 3 13:40:36 UTC 2020


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244572

            Bug ID: 244572
           Summary: Resources leaked by linux_kpi when resetting RDMA
                    device
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: aboyer at pensando.io

Created attachment 212118
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=212118&action=edit
Proposed patch to linux_file_close()

If an RDMA driver resets itself by posting a NETDEV_UNREGISTER event while a
userspace process has the device open, cleanup will fail and unregister will
hang forever.

(This is admittedly an obscure corner case.)

This is what should happen when the process shuts down:
#2 0xffffffff80e9a4e6 at ib_destroy_qp+0xd6
#3 0xffffffff80e98ab0 at ib_uverbs_cleanup_ucontext+0x1e0
#4 0xffffffff80e9879c at ib_uverbs_close+0x6c
#5 0xffffffff80e45cda at linux_file_close+0x18a

The issue is that the uverbs file will be partially destroyed by the unregister
process, clearing the uverbs file's fops structure. Then, when the userspace
process shuts down, the uverbs file will be closed, but its ->release()
function (ib_uverbs_close() in this case) will not be called.

This leaks whatever RDMA data structures were in use by the process.

To fix the issue, change linux_file_close() to use the file pointer's embedded
f_ops, rather than pulling them from the cdev. This allows cleanup to run even
after the cdev has been destroyed.

The attached patch has been tested on FreeBSD 11.3-RELEASE-p5 and
12.1-RELEASE-p1.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list