Bug 1571183 - when NSS_SDB_USE_CACHE not set, after curl access https, dentry increase but never released
Summary: when NSS_SDB_USE_CACHE not set, after curl access https, dentry increase but ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.9
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: nss-nspr-maint
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1879249 1779325
TreeView+ depends on / blocked
 
Reported: 2018-04-24 09:07 UTC by zhenggu
Modified: 2020-09-15 19:08 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1779325 (view as bug list)
Environment:
Last Closed: 2019-07-03 12:28:50 UTC
Target Upstream Version:


Attachments (Terms of Use)
patch to remove negative dcache entries post-test (3.40 KB, text/plain)
2019-12-03 21:23 UTC, Eric Sandeen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1720479 0 unspecified CLOSED Curl command in Elasticsearch readiness probe bloats dentry cache 2021-02-22 00:41:40 UTC

Description zhenggu 2018-04-24 09:07:03 UTC
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

Comment 7 Hubert Kario 2019-05-23 11:20:03 UTC
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

Comment 20 Dave Wysochanski 2019-12-03 18:47:37 UTC
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

Comment 21 Eric Sandeen 2019-12-03 21:23:07 UTC
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.

Comment 22 Eric Sandeen 2019-12-03 21:23:43 UTC
Oops sorry, that was supposed to go on bug #1779325


Note You need to log in before you can comment on or make changes to this bug.