From patchwork Thu Sep 20 05:51:32 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 972143 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42G5TL4rkKz9sBW; Thu, 20 Sep 2018 15:51:50 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1g2rsO-0006wf-0y; Thu, 20 Sep 2018 05:51:44 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1g2rsM-0006wN-0l for kernel-team@lists.canonical.com; Thu, 20 Sep 2018 05:51:42 +0000 Received: from mail-qk1-f199.google.com ([209.85.222.199]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1g2rsL-0002tt-NX for kernel-team@lists.canonical.com; Thu, 20 Sep 2018 05:51:41 +0000 Received: by mail-qk1-f199.google.com with SMTP id x204-v6so5938433qka.6 for ; Wed, 19 Sep 2018 22:51:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Tx4EiYxJEPV98iEd4q0J3XpCFxP6hj6QYixXHUVe6JI=; b=k0pU1jUkbYyC9pNwZM39difES+TVG3WoeU//51h3kICY0Ez+lEyIwPOR2NsSPVdnRA PY3SveTrHoVGHykk5XGxifrNJVp1C7T1wfmfqaMrmsAioCkrhnl2+u34HWYOAfgUEsNX ITuoGNdeeR+UQA12fCEJwCdK3s8Kfml8H+OapwcQgqSQTybY7NjVPAi3sodvPxzDZBJb PRnTnk4aX0L+oBbds9yMDoWx2sqI2pxL3EKO/q9laxvYtvjs43Fks9rSXwOHlJZAAtF/ 8ADC9okgtl1U1ON1CWIpDkK2KDs1EhvZyaxKxaoFlfkua3l7rlpxCaad8JjWk/rrX5GQ CBLA== X-Gm-Message-State: APzg51BSjrx6XHxbKo6hCTMLhcR2j8eQdUG5xncIOhHVdOkjVVQBomQH MuT5SBnZs9s5y4TcoQ9ZD1T5S+CfW00LcZWcraBenrXUDVK3uBsOu/aVhFgitz0V/Y7zeVnbn2T p67yS4seCrDhS1OpaCrGKnNKFHP1PpNoq/DoxGLx8g4wJkx1w X-Received: by 2002:aed:2ae1:: with SMTP id t88-v6mr26387184qtd.279.1537422700677; Wed, 19 Sep 2018 22:51:40 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZXullVhwe0K8+jB70fRlE88HNx+st3lnksXVbbZKzN4J6fQzpOmdpLoUI/hIBNs8IVkU70Sg== X-Received: by 2002:aed:2ae1:: with SMTP id t88-v6mr26387177qtd.279.1537422700532; Wed, 19 Sep 2018 22:51:40 -0700 (PDT) Received: from linkitivity.iinet.net.au ([2001:67c:1562:8007::aac:4356]) by smtp.gmail.com with ESMTPSA id e29-v6sm17119530qte.47.2018.09.19.22.51.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 22:51:39 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU X][PATCH 0/1] Fix LP: #1793430 - cachefiles page leak Date: Thu, 20 Sep 2018 15:51:32 +1000 Message-Id: <20180920055133.3402-1-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kiran.modukuri@gmail.com MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Daniel Axtens 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 :/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(+)