From patchwork Thu Aug 2 04:18:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 952568 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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41gxkx4QJMz9rxx; Thu, 2 Aug 2018 14:19:05 +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 1fl54m-0007OG-CD; Thu, 02 Aug 2018 04:19:00 +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 1fl54k-0007Nd-RU for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:18:58 +0000 Received: from mail-pl0-f69.google.com ([209.85.160.69]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fl54k-0001wV-Fs for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:18:58 +0000 Received: by mail-pl0-f69.google.com with SMTP id h4-v6so506685pll.4 for ; Wed, 01 Aug 2018 21:18:58 -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:subject:date:message-id:in-reply-to :references; bh=bDhHN9AZZTPkgJKih2zLeZdd0ESqbaxPl9IK3MwYDAA=; b=irWW7L5jYxJ2YkhjDJLmsweHJtLAreoD6fMBI3WYX+pmhltdIp6Yu1C94D7N8OKU2B yK7G2Ym02IwuVXbQrl4dubl6NQsi2ggxPys1mc4lsIoFxYm5kHkF+K26FXzEBNLJVg0Q 65RAG88Xi3kMMRDwHROnX5fE4yLnCOm27xS/02bXQZEXWpyzw2AqE29JM9AO9M5niyNh W4eykvAmZJRtY3yLjS6k6SX3MH5ows+7hxe+Eyem/uYb8ohKlkDfBKJoBpP/yeOPAsEn qYtiay4FqE+q5OIOUqpQm2ahKXVfQQu9Zm8DsylhCoVojmmVUURNC4BMkYG8C5LNxs7C yywQ== X-Gm-Message-State: AOUpUlEJ2SakJp5sg22MOX9qRm1peDuTqF7N3yiQw+PWP5zsvpJVq4EG cTofmrcvh1eptiQkOYPKhX4H8wlD8mfMHZq4AMZaa3+P0v5J6mACFbjN+33ztje3tbKPdz1UD1A 7fMhz9+UUcjEoFUBX8NvPZogMa6OHiVnWZz0mw2SZbJXLqlHi X-Received: by 2002:a63:65c2:: with SMTP id z185-v6mr1099346pgb.276.1533183537205; Wed, 01 Aug 2018 21:18:57 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcN2FQcT692A+3C/Wl/Bn0Uggp7wvAeRklhTP1eq77UguLyGvH70vsSCRJ1LUG5AJs7+BTbNQ== X-Received: by 2002:a63:65c2:: with SMTP id z185-v6mr1099342pgb.276.1533183537098; Wed, 01 Aug 2018 21:18:57 -0700 (PDT) Received: from localhost.localdomain (124-171-193-200.dyn.iinet.net.au. [124.171.193.200]) by smtp.gmail.com with ESMTPSA id p73-v6sm952509pfk.186.2018.08.01.21.18.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 21:18:56 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU T][PATCH 1/6] Revert "UBUNTU: SAUCE: CacheFiles: fix a read_waiter/read_copier race" Date: Thu, 2 Aug 2018 14:18:45 +1000 Message-Id: <20180802041850.22961-2-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180802041850.22961-1-daniel.axtens@canonical.com> References: <20180802041850.22961-1-daniel.axtens@canonical.com> 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: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" BugLink: https://bugs.launchpad.net/bugs/1774336 Revert 8aa5f7aa51024cd8e211707bf240689200dfe263 in Trusty. Upstream has taken a different solution, which we're about to apply. Signed-off-by: Daniel Axtens --- fs/cachefiles/rdwr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c index 24617af9f24a..a1210b0322e0 100644 --- a/fs/cachefiles/rdwr.c +++ b/fs/cachefiles/rdwr.c @@ -58,9 +58,9 @@ static int cachefiles_read_waiter(wait_queue_t *wait, unsigned mode, spin_lock(&object->work_lock); list_add_tail(&monitor->op_link, &monitor->op->to_do); - fscache_enqueue_retrieval(monitor->op); spin_unlock(&object->work_lock); + fscache_enqueue_retrieval(monitor->op); return 0; } From patchwork Thu Aug 2 04:18:46 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 952569 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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41gxl03gNYz9s3x; Thu, 2 Aug 2018 14:19:08 +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 1fl54o-0007Pz-Jb; Thu, 02 Aug 2018 04:19:02 +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 1fl54m-0007Oc-SC for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:00 +0000 Received: from mail-pl0-f72.google.com ([209.85.160.72]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fl54m-0001wZ-G5 for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:00 +0000 Received: by mail-pl0-f72.google.com with SMTP id q12-v6so598702pls.13 for ; Wed, 01 Aug 2018 21:19:00 -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:subject:date:message-id:in-reply-to :references; bh=2DUmqACCV8+MnGoNbY0FsedIDF6WIvwZgP+8+ve9IKY=; b=TQaGpF1BPdCBjF7DRXsdxUU7zE3MMZl1XU8mdPCsxH2VxItPV1442rK0lsguqw+LYz 9V0h2sIQ3Xc6b0LhXyZWGbI919kh0W84AteyJp0BN/gdqVsVcAJko7zIyARYy2dgc8Sb 6QE0jx2Wb0HNPXm17KvPsAFRJIC5cQGxW4nZoWiC7W+zjFDCvQrKO63jsy9v1CLD9SgB OkdV/VYJok3rhFWql/X8ek6WEc1ROk7oib11XFQjkr25y/NMivtqSojNnN5ysQjYf1h2 ya0GamiO44hpE8MzmY36u/c+m4iYYBXd/YTa7RqDbSsBqoOi8wjPuTNy1lp8bkDNWtoA 4X/w== X-Gm-Message-State: AOUpUlGUUqepRdBuTcJB/gZqBbWAu2GOoM2FxOQgCcw0l1Qzvd0rWlp3 GfZLAeHPoqeWjVg0CG8EHa5ZQweHLWUW5930bxGilZlutuWrNa103JdgTB0vDZQR2bbXVGJZ8QJ 2qo93ObUcZ8ZI/6ZTqOdLKXqW+JopjrcoflDepBxE4GV0h0NT X-Received: by 2002:a63:4d06:: with SMTP id a6-v6mr1087705pgb.408.1533183539150; Wed, 01 Aug 2018 21:18:59 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfSs6ncEIACHTMlEAR4FULqFdbZBac4EQvpZD2K3IRJJR/2VGXO1ipZH7MvrTecFx8KHQLVbA== X-Received: by 2002:a63:4d06:: with SMTP id a6-v6mr1087699pgb.408.1533183539022; Wed, 01 Aug 2018 21:18:59 -0700 (PDT) Received: from localhost.localdomain (124-171-193-200.dyn.iinet.net.au. [124.171.193.200]) by smtp.gmail.com with ESMTPSA id p73-v6sm952509pfk.186.2018.08.01.21.18.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 21:18:58 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU T][PATCH 2/6] fscache: Allow cancelled operations to be enqueued Date: Thu, 2 Aug 2018 14:18:46 +1000 Message-Id: <20180802041850.22961-3-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180802041850.22961-1-daniel.axtens@canonical.com> References: <20180802041850.22961-1-daniel.axtens@canonical.com> 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: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Kiran Kumar Modukuri BugLink: https://bugs.launchpad.net/bugs/1774336 Alter the state-check assertion in fscache_enqueue_operation() to allow cancelled operations to be given processing time so they can be cleaned up. Also fix a debugging statement that was requiring such operations to have an object assigned. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") Reported-by: Kiran Kumar Modukuri Signed-off-by: David Howells (cherry picked from commit d0eb06afe712b7b103b6361f40a9a0c638524669) Signed-off-by: Daniel Axtens --- fs/fscache/operation.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/fscache/operation.c b/fs/fscache/operation.c index 318071aca217..473c529d604c 100644 --- a/fs/fscache/operation.c +++ b/fs/fscache/operation.c @@ -37,7 +37,8 @@ void fscache_enqueue_operation(struct fscache_operation *op) ASSERT(op->processor != NULL); ASSERT(fscache_object_is_available(op->object)); ASSERTCMP(atomic_read(&op->usage), >, 0); - ASSERTCMP(op->state, ==, FSCACHE_OP_ST_IN_PROGRESS); + ASSERTIFCMP(op->state != FSCACHE_OP_ST_IN_PROGRESS, + op->state, ==, FSCACHE_OP_ST_CANCELLED); fscache_stat(&fscache_n_op_enqueue); switch (op->flags & FSCACHE_OP_TYPE) { @@ -402,7 +403,8 @@ void fscache_put_operation(struct fscache_operation *op) struct fscache_cache *cache; _enter("{OBJ%x OP%x,%d}", - op->object->debug_id, op->debug_id, atomic_read(&op->usage)); + op->object ? op->object->debug_id : 0, + op->debug_id, atomic_read(&op->usage)); ASSERTCMP(atomic_read(&op->usage), >, 0); From patchwork Thu Aug 2 04:18:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 952570 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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41gxl26n7mz9s2g; Thu, 2 Aug 2018 14:19:10 +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 1fl54r-0007Rn-5L; Thu, 02 Aug 2018 04:19:05 +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 1fl54p-0007Q9-5c for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:03 +0000 Received: from mail-pf1-f197.google.com ([209.85.210.197]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fl54o-0001xC-Hn for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:02 +0000 Received: by mail-pf1-f197.google.com with SMTP id v9-v6so660260pfn.6 for ; Wed, 01 Aug 2018 21:19:02 -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:subject:date:message-id:in-reply-to :references; bh=hGpTcfeWJQf8WzlXlKyV9eQmmQE3Hpf7eh227xf44wA=; b=nDcvMyZWv2gFFdf1WnAAifHeRs4hF2juyEEBlrBR/nTEqzSS06gBZZx80M2TuRZoti GR5oG8k1efk344aVmvDGaqyG9YCHY0YTGWDmHpdnhhk5UD0kBdcainVNLPzXWvGZf+1l 8TVGM9bEl2btBQt8EdDzC2gCrwJ+zBxZohKXbJ6VNg7stlzWO36aF/ClN1TJeKXKjRNn pW0gJHe5V4tj1YELZJyBk5yWWrRh4Q6tXcTQpUhFFv+hUeYbbk/xyk6XKeAcDWewukz9 gjZOvuLmMGmtrBs2u+AhKnfkOSODYTnpXuYUY0XJGxbpPYgOShShLw/GZAJYz/WoFwB0 le6A== X-Gm-Message-State: AOUpUlH8/8yZNPh4yLvQaGs21WZQwPJ75RBlfijMhusE0Ck2VSnD8sej YyLbAXMlAqffBv/p72h5Ly8uomgbGZBSsqCd5ir6V/bXpt8BHse9c0R9bk4AY40VbqwTj9wXJys 2iux0g0lsHZaDqQoWOFOzgLD6o5w/cZFrTfn2cWpv0HJem8q2 X-Received: by 2002:a17:902:bf06:: with SMTP id bi6-v6mr976239plb.76.1533183541216; Wed, 01 Aug 2018 21:19:01 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe1lj2+roU+kz1ItYt1MEaZaLubuwBj6hQeWihO5BSJrK5Wkmx3C4fm+Le5WM3GeaeNeaFvNg== X-Received: by 2002:a17:902:bf06:: with SMTP id bi6-v6mr976232plb.76.1533183541040; Wed, 01 Aug 2018 21:19:01 -0700 (PDT) Received: from localhost.localdomain (124-171-193-200.dyn.iinet.net.au. [124.171.193.200]) by smtp.gmail.com with ESMTPSA id p73-v6sm952509pfk.186.2018.08.01.21.18.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 21:19:00 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU T][PATCH 3/6] cachefiles: Fix refcounting bug in backing-file read monitoring Date: Thu, 2 Aug 2018 14:18:47 +1000 Message-Id: <20180802041850.22961-4-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180802041850.22961-1-daniel.axtens@canonical.com> References: <20180802041850.22961-1-daniel.axtens@canonical.com> 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: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Kiran Kumar Modukuri BugLink: https://bugs.launchpad.net/bugs/1774336 cachefiles_read_waiter() has the right to access a 'monitor' object by virtue of being called under the waitqueue lock for one of the pages in its purview. However, it has no ref on that monitor object or on the associated operation. What it is allowed to do is to move the monitor object to the operation's to_do list, but once it drops the work_lock, it's actually no longer permitted to access that object. However, it is trying to enqueue the retrieval operation for processing - but it can only do this via a pointer in the monitor object, something it shouldn't be doing. If it doesn't enqueue the operation, the operation may not get processed. If the order is flipped so that the enqueue is first, then it's possible for the work processor to look at the to_do list before the monitor is enqueued upon it. Fix this by getting a ref on the operation so that we can trust that it will still be there once we've added the monitor to the to_do list and dropped the work_lock. The op can then be enqueued after the lock is dropped. The bug can manifest in one of a couple of ways. The first manifestation looks like: FS-Cache: FS-Cache: Assertion failed FS-Cache: 6 == 5 is false ------------[ cut here ]------------ kernel BUG at fs/fscache/operation.c:494! RIP: 0010:fscache_put_operation+0x1e3/0x1f0 ... fscache_op_work_func+0x26/0x50 process_one_work+0x131/0x290 worker_thread+0x45/0x360 kthread+0xf8/0x130 ? create_worker+0x190/0x190 ? kthread_cancel_work_sync+0x10/0x10 ret_from_fork+0x1f/0x30 This is due to the operation being in the DEAD state (6) rather than INITIALISED, COMPLETE or CANCELLED (5) because it's already passed through fscache_put_operation(). The bug can also manifest like the following: kernel BUG at fs/fscache/operation.c:69! ... [exception RIP: fscache_enqueue_operation+246] ... #7 [ffff883fff083c10] fscache_enqueue_operation at ffffffffa0b793c6 #8 [ffff883fff083c28] cachefiles_read_waiter at ffffffffa0b15a48 #9 [ffff883fff083c48] __wake_up_common at ffffffff810af028 I'm not entirely certain as to which is line 69 in Lei's kernel, so I'm not entirely clear which assertion failed. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") Reported-by: Lei Xue Reported-by: Vegard Nossum Reported-by: Anthony DeRobertis Reported-by: NeilBrown Reported-by: Daniel Axtens Reported-by: Kiran Kumar Modukuri Signed-off-by: David Howells Reviewed-by: Daniel Axtens (cherry picked from commit 934140ab028713a61de8bca58c05332416d037d1) Signed-off-by: Daniel Axtens --- fs/cachefiles/rdwr.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c index a1210b0322e0..725a0e20a913 100644 --- a/fs/cachefiles/rdwr.c +++ b/fs/cachefiles/rdwr.c @@ -27,6 +27,7 @@ static int cachefiles_read_waiter(wait_queue_t *wait, unsigned mode, struct cachefiles_one_read *monitor = container_of(wait, struct cachefiles_one_read, monitor); struct cachefiles_object *object; + struct fscache_retrieval *op = monitor->op; struct wait_bit_key *key = _key; struct page *page = wait->private; @@ -51,16 +52,22 @@ static int cachefiles_read_waiter(wait_queue_t *wait, unsigned mode, list_del(&wait->task_list); /* move onto the action list and queue for FS-Cache thread pool */ - ASSERT(monitor->op); + ASSERT(op); - object = container_of(monitor->op->op.object, - struct cachefiles_object, fscache); + /* We need to temporarily bump the usage count as we don't own a ref + * here otherwise cachefiles_read_copier() may free the op between the + * monitor being enqueued on the op->to_do list and the op getting + * enqueued on the work queue. + */ + fscache_get_retrieval(op); + object = container_of(op->op.object, struct cachefiles_object, fscache); spin_lock(&object->work_lock); - list_add_tail(&monitor->op_link, &monitor->op->to_do); + list_add_tail(&monitor->op_link, &op->to_do); spin_unlock(&object->work_lock); - fscache_enqueue_retrieval(monitor->op); + fscache_enqueue_retrieval(op); + fscache_put_retrieval(op); return 0; } From patchwork Thu Aug 2 04:18:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 952571 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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41gxl652Bfz9s4s; Thu, 2 Aug 2018 14:19:14 +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 1fl54u-0007UG-GX; Thu, 02 Aug 2018 04:19:08 +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 1fl54q-0007RX-Rj for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:04 +0000 Received: from mail-pf1-f199.google.com ([209.85.210.199]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fl54q-0001xG-Fu for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:04 +0000 Received: by mail-pf1-f199.google.com with SMTP id v9-v6so663396pff.4 for ; Wed, 01 Aug 2018 21:19:04 -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:subject:date:message-id:in-reply-to :references; bh=FgQRH5DQyUhr63MqVzh1kOlSYwhvgg6twWAG/10rBWk=; b=DWLu5nQVJ25OyXV7recqGOCkira2+mGEklLCHqHGP/lVAaymSI0xvKlazEN+Vgda8i DBECxRt7/vU1MrlATeO4pIqz7R8CRE1CykaV+oDs/rh2MF8LKG5/yxobYLqG/xTbDz+4 EvxefK3mZVVPlh1cQ/koLmK4WCAdR5uyvd+JoJFCZPpFLSyIPVRbxspZuZPzEcWLdroR BabjeL/WdDLV/knuQcerTP3rLbYdGZAMcTsnmqBHnJbSFvVMo//4/qMyzmunnglUowC3 0qJYNYIRjmnpS+a4+OqmC/yKBDoC0G16/i1RQle5OdEFXNpGiYbyf8KU19w1buO6rwOf JOkQ== X-Gm-Message-State: AOUpUlGs9SwNDbaXEzQXQoty1qjoDQ5Z26JX5QFH4gz+2YiTOOq0PtP7 wmo4rViODTiFaUQzV6y/P+kC5s5xoJjG/XQUoa8P5N32yzI1ML7YTVradvU3SCGxUwBcjbx+uH6 8l4vuB4PiD1K7fpjqY7tDaZv9BEKsz71G08NB0pzGrBhF1Kze X-Received: by 2002:a65:6109:: with SMTP id z9-v6mr1074307pgu.243.1533183543169; Wed, 01 Aug 2018 21:19:03 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeMQ2+TUPhKTJC+RaWmH3Si7+3UjbgcVQ3gcUoXxwzgmnIIG1PvxTtRBlkH655RJJkgbJU8eQ== X-Received: by 2002:a65:6109:: with SMTP id z9-v6mr1074297pgu.243.1533183542970; Wed, 01 Aug 2018 21:19:02 -0700 (PDT) Received: from localhost.localdomain (124-171-193-200.dyn.iinet.net.au. [124.171.193.200]) by smtp.gmail.com with ESMTPSA id p73-v6sm952509pfk.186.2018.08.01.21.19.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 21:19:02 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU T][PATCH 4/6] fscache: Fix reference overput in fscache_attach_object() error handling Date: Thu, 2 Aug 2018 14:18:48 +1000 Message-Id: <20180802041850.22961-5-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180802041850.22961-1-daniel.axtens@canonical.com> References: <20180802041850.22961-1-daniel.axtens@canonical.com> 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: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Kiran Kumar Modukuri BugLink: https://bugs.launchpad.net/bugs/1776277 When a cookie is allocated that causes fscache_object structs to be allocated, those objects are initialised with the cookie pointer, but aren't blessed with a ref on that cookie unless the attachment is successfully completed in fscache_attach_object(). If attachment fails because the parent object was dying or there was a collision, fscache_attach_object() returns without incrementing the cookie counter - but upon failure of this function, the object is released which then puts the cookie, whether or not a ref was taken on the cookie. Fix this by taking a ref on the cookie when it is assigned in fscache_object_init(), even when we're creating a root object. Analysis from Kiran Kumar: This bug has been seen in 4.4.0-124-generic #148-Ubuntu kernel BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776277 fscache cookie ref count updated incorrectly during fscache object allocation resulting in following Oops. kernel BUG at /build/linux-Y09MKI/linux-4.4.0/fs/fscache/internal.h:321! kernel BUG at /build/linux-Y09MKI/linux-4.4.0/fs/fscache/cookie.c:639! [Cause] Two threads are trying to do operate on a cookie and two objects. (1) One thread tries to unmount the filesystem and in process goes over a huge list of objects marking them dead and deleting the objects. cookie->usage is also decremented in following path: nfs_fscache_release_super_cookie -> __fscache_relinquish_cookie ->__fscache_cookie_put ->BUG_ON(atomic_read(&cookie->usage) <= 0); (2) A second thread tries to lookup an object for reading data in following path: fscache_alloc_object 1) cachefiles_alloc_object -> fscache_object_init -> assign cookie, but usage not bumped. 2) fscache_attach_object -> fails in cant_attach_object because the cookie's backing object or cookie's->parent object are going away 3) fscache_put_object -> cachefiles_put_object ->fscache_object_destroy ->fscache_cookie_put ->BUG_ON(atomic_read(&cookie->usage) <= 0); [NOTE from dhowells] It's unclear as to the circumstances in which (2) can take place, given that thread (1) is in nfs_kill_super(), however a conflicting NFS mount with slightly different parameters that creates a different superblock would do it. A backtrace from Kiran seems to show that this is a possibility: kernel BUG at/build/linux-Y09MKI/linux-4.4.0/fs/fscache/cookie.c:639! ... RIP: __fscache_cookie_put+0x3a/0x40 [fscache] Call Trace: __fscache_relinquish_cookie+0x87/0x120 [fscache] nfs_fscache_release_super_cookie+0x2d/0xb0 [nfs] nfs_kill_super+0x29/0x40 [nfs] deactivate_locked_super+0x48/0x80 deactivate_super+0x5c/0x60 cleanup_mnt+0x3f/0x90 __cleanup_mnt+0x12/0x20 task_work_run+0x86/0xb0 exit_to_usermode_loop+0xc2/0xd0 syscall_return_slowpath+0x4e/0x60 int_ret_from_sys_call+0x25/0x9f [Fix] Bump up the cookie usage in fscache_object_init, when it is first being assigned a cookie atomically such that the cookie is added and bumped up if its refcount is not zero. Remove the assignment in fscache_attach_object(). [Testcase] I have run ~100 hours of NFS stress tests and not seen this bug recur. [Regression Potential] - Limited to fscache/cachefiles. Fixes: ccc4fc3d11e9 ("FS-Cache: Implement the cookie management part of the netfs API") Signed-off-by: Kiran Kumar Modukuri Signed-off-by: David Howells (backported from commit f29507ce66701084c39aeb1b0ae71690cbff3554) Signed-off-by: Daniel Axtens --- fs/cachefiles/bind.c | 3 ++- fs/fscache/cache.c | 2 +- fs/fscache/cookie.c | 7 ++++--- fs/fscache/object.c | 1 + 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index 622f4696e484..2a5b374aff9c 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -219,7 +219,8 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) "%s", fsdef->dentry->d_sb->s_id); - fscache_object_init(&fsdef->fscache, NULL, &cache->cache); + fscache_object_init(&fsdef->fscache, &fscache_fsdef_index, + &cache->cache); ret = fscache_add_cache(&cache->cache, &fsdef->fscache, cache->tag); if (ret < 0) diff --git a/fs/fscache/cache.c b/fs/fscache/cache.c index f7cff367db7f..5d5c1987b841 100644 --- a/fs/fscache/cache.c +++ b/fs/fscache/cache.c @@ -220,6 +220,7 @@ int fscache_add_cache(struct fscache_cache *cache, { struct fscache_cache_tag *tag; + ASSERTCMP(ifsdef->cookie, ==, &fscache_fsdef_index); BUG_ON(!cache->ops); BUG_ON(!ifsdef); @@ -248,7 +249,6 @@ int fscache_add_cache(struct fscache_cache *cache, if (!cache->kobj) goto error; - ifsdef->cookie = &fscache_fsdef_index; ifsdef->cache = cache; cache->fsdef = ifsdef; diff --git a/fs/fscache/cookie.c b/fs/fscache/cookie.c index 29d7feb62cf7..269773d7e698 100644 --- a/fs/fscache/cookie.c +++ b/fs/fscache/cookie.c @@ -302,6 +302,7 @@ static int fscache_alloc_object(struct fscache_cache *cache, goto error; } + ASSERTCMP(object->cookie, ==, cookie); fscache_stat(&fscache_n_object_alloc); object->debug_id = atomic_inc_return(&fscache_object_debug_id); @@ -356,6 +357,8 @@ static int fscache_attach_object(struct fscache_cookie *cookie, _enter("{%s},{OBJ%x}", cookie->def->name, object->debug_id); + ASSERTCMP(object->cookie, ==, cookie); + spin_lock(&cookie->lock); /* there may be multiple initial creations of this object, but we only @@ -395,9 +398,7 @@ static int fscache_attach_object(struct fscache_cookie *cookie, spin_unlock(&cache->object_list_lock); } - /* attach to the cookie */ - object->cookie = cookie; - atomic_inc(&cookie->usage); + /* Attach to the cookie. The object already has a ref on it. */ hlist_add_head(&object->cookie_link, &cookie->backing_objects); fscache_objlist_add(object); diff --git a/fs/fscache/object.c b/fs/fscache/object.c index 53d35c504240..0de8ad801acb 100644 --- a/fs/fscache/object.c +++ b/fs/fscache/object.c @@ -313,6 +313,7 @@ void fscache_object_init(struct fscache_object *object, object->store_limit_l = 0; object->cache = cache; object->cookie = cookie; + atomic_inc(&cookie->usage); object->parent = NULL; object->oob_event_mask = 0; From patchwork Thu Aug 2 04:18:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 952572 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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41gxl74CXmz9rxx; Thu, 2 Aug 2018 14:19:15 +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 1fl54v-0007VA-Ln; Thu, 02 Aug 2018 04:19:09 +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 1fl54s-0007T5-P8 for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:06 +0000 Received: from mail-pf1-f197.google.com ([209.85.210.197]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fl54s-0001xK-DW for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:06 +0000 Received: by mail-pf1-f197.google.com with SMTP id s1-v6so628092pfm.22 for ; Wed, 01 Aug 2018 21:19:06 -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:subject:date:message-id:in-reply-to :references; bh=67Bs64B6LHr6seyn1RzXo2/Gj6rst8yYcoKzvQrGwyM=; b=hUAO/ayfXXWXUr3xmKxiemv6g/EBrs51zCwKs+FratyuP+K7R4lBmuLuEeonALoGAs A7EFEaGkjVjrYWpM22GD7PoH4AFzBEXYZ7OwpdSN9pRDFBb/Nvbwe3lecb3KLaK2pWA4 Lw08Fj0dDvukMzJXhWM63sKg/aEZpIzqptIkAH5WvaPov0phcl18NXTnChKPjKaub2zq ePbN+eFBLbpdptp7aOwWTbgudpWoJOUxyq8JW7Wro0Jw27D9T/4chGelFT+Op7nPur0H 9/X1sEC8Kz4y1VqV4SMiLzzEPY2jRODMiyQWh7F9zx9JH7ZGObCk6dJ5Kusq8En/jx3w 3Dgw== X-Gm-Message-State: AOUpUlHESvSpN6A5P9eQ9jPZ04QAtb0xrm4n7xMsW+ThacrCVeS62BJf iytIapmbdjwS30ffQjPlYs3DrfIC4ZX4Eey28uuue/23EMWIAIzMEsidrzq4keXkS55ou8kZLW6 vT2T92QEFo+95M99niE0wCZv1uXOhsb3qRauFCSIh5X1A5uwm X-Received: by 2002:a63:b605:: with SMTP id j5-v6mr1092746pgf.437.1533183545073; Wed, 01 Aug 2018 21:19:05 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfB+dIWKnKBLIL3an1so5vrdHfNruBBkFKJ3h4YCFxBhnhHelc9W2TwZW2cT16Cj4KBL/Qx+A== X-Received: by 2002:a63:b605:: with SMTP id j5-v6mr1092743pgf.437.1533183544943; Wed, 01 Aug 2018 21:19:04 -0700 (PDT) Received: from localhost.localdomain (124-171-193-200.dyn.iinet.net.au. [124.171.193.200]) by smtp.gmail.com with ESMTPSA id p73-v6sm952509pfk.186.2018.08.01.21.19.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 21:19:04 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU T][PATCH 5/6] cachefiles: Fix missing clear of the CACHEFILES_OBJECT_ACTIVE flag Date: Thu, 2 Aug 2018 14:18:49 +1000 Message-Id: <20180802041850.22961-6-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180802041850.22961-1-daniel.axtens@canonical.com> References: <20180802041850.22961-1-daniel.axtens@canonical.com> 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: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Kiran Kumar Modukuri BugLink: https://bugs.launchpad.net/bugs/1776254 In cachefiles_mark_object_active(), the new object is marked active and then we try to add it to the active object tree. If a conflicting object is already present, we want to wait for that to go away. After the wait, we go round again and try to re-mark the object as being active - but it's already marked active from the first time we went through and a BUG is issued. Fix this by clearing the CACHEFILES_OBJECT_ACTIVE flag before we try again. Analysis from Kiran Kumar Modukuri: [Impact] Oops during heavy NFS + FSCache + Cachefiles CacheFiles: Error: Overlong wait for old active object to go away. BUG: unable to handle kernel NULL pointer dereference at 0000000000000002 CacheFiles: Error: Object already active kernel BUG at fs/cachefiles/namei.c:163! [Cause] In a heavily loaded system with big files being read and truncated, an fscache object for a cookie is being dropped and a new object being looked. The new object being looked for has to wait for the old object to go away before the new object is moved to active state. [Fix] Clear the flag 'CACHEFILES_OBJECT_ACTIVE' for the new object when retrying the object lookup. [Testcase] Have run ~100 hours of NFS stress tests and have not seen this bug recur. [Regression Potential] - Limited to fscache/cachefiles. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") Signed-off-by: Kiran Kumar Modukuri Signed-off-by: David Howells (backported from commit 5ce83d4bb7d8e11e8c1c687d09f4b5ae67ef3ce3) Signed-off-by: Daniel Axtens --- fs/cachefiles/namei.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index ca65f39dc8dc..beaa2fd6734f 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -192,6 +192,8 @@ try_again: /* an old object from a previous incarnation is hogging the slot - we * need to wait for it to be destroyed */ wait_for_old_object: + clear_bit(CACHEFILES_OBJECT_ACTIVE, &object->flags); + if (fscache_object_is_live(&object->fscache)) { printk(KERN_ERR "\n"); printk(KERN_ERR "CacheFiles: Error:" @@ -255,7 +257,6 @@ wait_for_old_object: goto try_again; requeue: - clear_bit(CACHEFILES_OBJECT_ACTIVE, &object->flags); cache->cache.ops->put_object(&xobject->fscache); _leave(" = -ETIMEDOUT"); return -ETIMEDOUT; From patchwork Thu Aug 2 04:18:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 952573 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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41gxl84c4Hz9s2g; Thu, 2 Aug 2018 14:19:16 +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 1fl54x-0007WL-1H; Thu, 02 Aug 2018 04:19:11 +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 1fl54v-0007Ug-0v for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:09 +0000 Received: from mail-pg1-f197.google.com ([209.85.215.197]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fl54u-0001xN-JD for kernel-team@lists.canonical.com; Thu, 02 Aug 2018 04:19:08 +0000 Received: by mail-pg1-f197.google.com with SMTP id x2-v6so491975pgp.4 for ; Wed, 01 Aug 2018 21:19:08 -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:subject:date:message-id:in-reply-to :references; bh=He2cjvZmP8crA3lw+QUfX1Y6F1lQehK/41EcfY99030=; b=aLTGb7P/iBlWWkaUifIjmbozqKZf30ytj0grVVQCRtlIiJXNt1edaPiLXLmoIGrBP8 kHyp5qmEBXGDjAw9A5Nt2qZa/769H/D46lD1+kitc3OPTAWxRjFuXbj6usoruiYRN2lT lKNaFUEGgH9zqI4zvsoXKeify9HuQNnZWEzyP4rDoxnfjT1Om5co0ZBBBlOX4eZq8NW1 LpL59Lvbz5HnGGfJ2wsos7eJE3iBNtsL7jdiJJ6evNG66KjqhoU492l94ItNvQNgl+7M /370FWqWLJjnaSb0lljhhx4GlhQSBK7erZgJNgIaPuYnhxDB4cPHcycyOKA8AreJhIZP Zc9Q== X-Gm-Message-State: AOUpUlGHVEIaImQVDl8N1mfo+DNhfvTB4oaP4lBWTHdejiqkV1VMGGdk cNdGYIi0eS+cYOsKMkk4XlrIfEzRjUCOC4UCxh7fLdl9oJyxoOF4OI/Ioty30Koj4rNRr0X1yc6 pVIWhngOEE7/OgwMcSwute+nqHiBLrCmkPzZFp3nS20w2OWYV X-Received: by 2002:a17:902:ab95:: with SMTP id f21-v6mr925138plr.264.1533183547273; Wed, 01 Aug 2018 21:19:07 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdtfaHhnZIU+w9uzPKSVr6WTyNRyfAYnDNcbvOIDVbExWowN+qDqjNyiIM1icijKPJfCHVTGQ== X-Received: by 2002:a17:902:ab95:: with SMTP id f21-v6mr925132plr.264.1533183547139; Wed, 01 Aug 2018 21:19:07 -0700 (PDT) Received: from localhost.localdomain (124-171-193-200.dyn.iinet.net.au. [124.171.193.200]) by smtp.gmail.com with ESMTPSA id p73-v6sm952509pfk.186.2018.08.01.21.19.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 21:19:06 -0700 (PDT) From: Daniel Axtens To: kernel-team@lists.canonical.com Subject: [SRU T][PATCH 6/6] cachefiles: Wait rather than BUG'ing on "Unexpected object collision" Date: Thu, 2 Aug 2018 14:18:50 +1000 Message-Id: <20180802041850.22961-7-daniel.axtens@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180802041850.22961-1-daniel.axtens@canonical.com> References: <20180802041850.22961-1-daniel.axtens@canonical.com> 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: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Kiran Kumar Modukuri BugLink: https://bugs.launchpad.net/bugs/1776254 If we meet a conflicting object that is marked FSCACHE_OBJECT_IS_LIVE in the active object tree, we have been emitting a BUG after logging information about it and the new object. Instead, we should wait for the CACHEFILES_OBJECT_ACTIVE flag to be cleared on the old object (or return an error). The ACTIVE flag should be cleared after it has been removed from the active object tree. A timeout of 60s is used in the wait, so we shouldn't be able to get stuck there. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") Signed-off-by: Kiran Kumar Modukuri Signed-off-by: David Howells (cherry picked from commit c2412ac45a8f8f1cd582723c1a139608694d410d) Signed-off-by: Daniel Axtens --- fs/cachefiles/namei.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index beaa2fd6734f..68c2b2ae0ad6 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -199,7 +199,6 @@ wait_for_old_object: printk(KERN_ERR "CacheFiles: Error:" " Unexpected object collision\n"); cachefiles_printk_object(object, xobject); - BUG(); } atomic_inc(&xobject->usage); write_unlock(&cache->active_lock);