Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #1784193 +++
Description of problem:
Sequential execution of UDAP API Calls - Open/Close ROCE port, breaks after 28 iteration. This indicates that the Close call does not actually release the connection. Tested and observed on IBM Z (s390x). However the connection leak does not seem to be architecture specific and must exist on x86 as well.
Similar test was performed with VERBS API calls using ibv_open_device / ibv_close_device. No error observed with 60 iterations.
Version-Release number of selected component (if applicable):
dapl 2.1.5-2.el7
How reproducible:
UDAPL code fails after 28 open/close iterations
for( int i = 0 ; i < 60 ; i++ )
{
DAT_IA_HANDLE iaHandle = DAT_HANDLE_NULL;
DAT_EVD_HANDLE evdHandle = DAT_HANDLE_NULL;
cout << "open number " << i << endl ;
status = dat_ia_open(gDevName, SVR_EVD_QLEN, &evdHandle, &iaHandle);
if (DAT_SUCCESS != (status = dat_ia_close(iaHandle, DAT_CLOSE_GRACEFUL_FLAG) ))
{
printError("dat_ia_close", status);
return 1;
}
}
./UdaplUtility ofa-v2-roe0
open number 0
open number 1
open number 2
open number 3
...
open number 27
open number 28
open number 29
host1:CMA:747b:a4377720: 3452 us(3452 us): open_hca: rdma_bind ERR No such device. Is enP303p0s0.66 configured as IPoIB?
failure: dat_ia_open 0x120000
Steps to Reproduce:
1. Start the process
2. Open ROCE port via dat_ia_open() call
3. Close ROCE port via dat_ia_close() call
4. Repeat #2 for 60 times
Actual results:
UDAPL code fails after 28 open/close iterations
Expected results:
Since the connection is closed. There should be no limit in how many consecutive open/close can be executed successfully
Additional info: