[SRU X][PATCH 0/1] Fix LP: #1793430 - cachefiles page leak

Daniel Axtens daniel.axtens at canonical.com
Thu Sep 20 05:51:32 UTC 2018


From: Daniel Axtens <dja at axtens.net>

SRU Justification
-----------------

[Description]

In a heavily loaded system where the system pagecache is nearing
memory limits and fscache is enabled, pages can be leaked by fscache
while trying read pages from cachefiles backend. This can happen
because two applications can be reading same page from a single mount,
two threads can be trying to read the backing page at same time. This
results in one of the thread finding that a page for the backing file
or netfs file is already in the radix tree. During the error handling
cachefiles does not cleanup the reference on backing page, leading to
page leak.

[Fix]
The fix is straightforward, to decrement the reference when error is encounterd.

[Testing]
A user has tested the fix using following method for 12+ hrs.

    1) mkdir -p /mnt/nfs ; mount -o vers=3,fsc <server_ip>:/export /mnt/nfs
    2) create 10000 files of 2.8MB in a NFS mount.
    3) start a thread to simulate heavy VM presssure
       (while true ; do echo 3 > /proc/sys/vm/drop_caches ; sleep 1 ; done)&
    4) start multiple parallel reader for data set at same time
       find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
       find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
       find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
       ..
       ..
       find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
       find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
    5) finally check using cat /proc/fs/fscache/stats | grep -i pages ;
       free -h , cat /proc/meminfo and page-types -r -b lru
       to ensure all pages are freed.

[Regression Potential]
Limited to cachefiles.

Kiran Kumar Modukuri (1):
  UBUNTU: SAUCE: cachefiles: Page leaking in
    cachefiles_read_backing_file while vmscan is active

 fs/cachefiles/rdwr.c | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
2.17.1





More information about the kernel-team mailing list