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.

Description of problem:
When use curl to access https web site, the value of dentry in slabtop continue increase and never release, but after I set export NSS_SDB_USE_CACHE=no or export NSS_SDB_USE_CACHE=yes, access https doesn't increase any more

Version-Release number of selected component (if applicable):
nss-3.28.4-4.el6_9
curl-7.19.7-53.el6_9
libcurl-7.19.7-53.el6_9

How reproducible:
Open slabtop on one terminal, then run "curl https://bugzilla.redhat.com/show_bug.cgi?id=1044666" in another terminal, dentry increase and never release

Steps to Reproduce:
Scenario 1
1.run "unset NSS_SDB_USE_CACHE"
2.run "curl https://bugzilla.redhat.com/show_bug.cgi?id=1044666"
Scenario 2
1.run "export NSS_SDB_USE_CACHE=yes"
2.run "curl https://bugzilla.redhat.com/show_bug.cgi?id=1044666"
Scenario 3
1.run "export NSS_SDB_USE_CACHE=no"
2.run "curl https://bugzilla.redhat.com/show_bug.cgi?id=1044666"


Actual results:
for Scenario 1, dentry increase
for Scenario 2, dentry not increase
for Scenario 3, dentry not increase
if you try serveral times for Scenario 1, dentry will be very high.

Expected results:
dentry not increase for all the Scenario.

Additional info:
There are a related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1044666
But seems not totally the same.
And one curl bug: https://curl.haxx.se/mail/tracker-2013-06/0114.html

This mechanism is used by NSS to ensure optimal performance when using the certificate database (that includes the system-wide trust store).
It is used to reliably detect if the storage that contains the certificate database is accessed over network or using a network file-system, or using directly attached storage. Setting the NSS_SDB_USE_CACHE environment variable will disable the autodetection mechanism.

dentry in the kernel memory is considered part of system "cache", and as such, will be freed by kernel automatically as soon as real applications require more memory, but as long as there is free memory available, it will be used instead of freeing the cache

so I don't see any incorrect behaviour in either NSS, curl or kernel that would require fixing

Since this is a RHEL6 bug and the conversation should probably have not been here, I have created a RHEL7 bug where we can track any further incidents and consider whether an alternative algorithm is appropriate for RHEL7:
https://bugzilla.redhat.com/show_bug.cgi?id=1779325

Created attachment 1641805 [details]
patch to remove negative dcache entries post-test

Here's a patch that works for me, it could use review.  Happy to send it to an upstream list if that's appropriate.

Oops sorry, that was supposed to go on bug #1779325