From patchwork Tue Jan 23 20:17:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10181019 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2CA2D602B7 for ; Tue, 23 Jan 2018 20:17:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1C73C283C9 for ; Tue, 23 Jan 2018 20:17:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 10FC3287C2; Tue, 23 Jan 2018 20:17:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 68A73283C9 for ; Tue, 23 Jan 2018 20:17:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752562AbeAWURJ (ORCPT ); Tue, 23 Jan 2018 15:17:09 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:37119 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752411AbeAWURI (ORCPT ); Tue, 23 Jan 2018 15:17:08 -0500 Received: by mail-qt0-f193.google.com with SMTP id d54so4705341qtd.4 for ; Tue, 23 Jan 2018 12:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=e+s4504qxb7Qtw6ggKoMEAeEZK2QTTAKmpg8fHlMK1k=; b=CM924/UyIO3DF/QUvcNS5u3Qr8iXlD34J17zrHjByIfb9ggk6AilBBmuLhict8d8lo LJ4lKhV/ODjF17dwjUgVKCh53F9YRVEiw0RyvsB1ReqV6Jd/vox2yDEJ9Y9G9+EwiFXr UyhbOFV6RebTUYs/DS5uykqJBfTCWW5zikNSucaSIZgTXBLXpcFMm53JbsfBgylT3kAk Cg5ENjBZgcV5GOQICpUeAiqT8oUOq8SYgH6Qq8rJF5XZV4sSL69Ny2CRU8UPrmgl1f6T Wl8ittXKdPFLWJg/aZHh8w5dejkP7QDN3wIb4KxQpdOW61pCrTxyCndaeP2Gl4Yqk4PP 2Vkg== 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=e+s4504qxb7Qtw6ggKoMEAeEZK2QTTAKmpg8fHlMK1k=; b=du9pM6ir7tJHPFrXgXigSeDOxC7QlJUCRv8hiMxc69q7Vr73IsD9nC4Jn4LtYLuXv8 30He9CZ1Rt4spEMcgZ3BSNFyhUjtSdJu5Fd09ohkE2lttabwBWlOaQM2hjsvoPYTsZy5 5Io2asUvJ2bDNMfB4Sx1vSs5aTKs6RrmT6Nf7ud9v6Ea6uaGi+Mtdizq3zGJqRR/s8RW aGzUFn1L15BOeQJ9XBEMX6xGozjX7zXd5qoqvnqxOU+057YFZFS5j1TRtuOktfL/5ude yTAuFUT4So8iklwIU99etdNPc9xeX51bdg6716VUsrXEclujW6saj9OiUk1Lju9Jyodr 3f4w== X-Gm-Message-State: AKwxytclEPl3iJE7LudA8OxTUK4dxcjBlbDxU+pugXyvK1kO+ccm9hYu uBgUQVmusrTzTC3r+jz8Br3F7g== X-Google-Smtp-Source: AH8x224T/foRlWh3W+DXqmEm0ujDcj7lkjyA+KjTufnon8KB+giWAlbpCsycXIJNLAcj2+stT/0beA== X-Received: by 10.55.121.132 with SMTP id u126mr5101176qkc.29.1516738627863; Tue, 23 Jan 2018 12:17:07 -0800 (PST) Received: from localhost (cpe-2606-A000-4381-1201-225-22FF-FEB3-E51A.dyn6.twc.com. [2606:a000:4381:1201:225:22ff:feb3:e51a]) by smtp.gmail.com with ESMTPSA id p31sm893760qta.77.2018.01.23.12.17.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2018 12:17:07 -0800 (PST) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Cc: Josef Bacik , stable@vger.kernel.org Subject: [PATCH] Btrfs: fix stale entries in readdir Date: Tue, 23 Jan 2018 15:17:05 -0500 Message-Id: <1516738626-23283-1-git-send-email-josef@toxicpanda.com> X-Mailer: git-send-email 2.7.5 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Josef Bacik In fixing the readdir+pagefault deadlock I accidentally introduced a stale entry regression in readdir. If we get close to full for the temporary buffer, and then skip a few delayed deletions, and then try to add another entry that won't fit, we will emit the entries we found and retry. Unfortunately we delete entries from our del_list as we find them, assuming we won't need them. However our pos will be with whatever our last entry was, which could be before the delayed deletions we skipped, so the next search will add the deleted entries back into our readdir buffer. So instead don't delete entries we find in our del_list so we can make sure we always find our delayed deletions. This is a slight perf hit for readdir with lots of pending deletions, but hopefully this isn't a common occurrence. If it is we can revist this and optimize it. cc: stable@vger.kernel.org Fixes: 23b5ec74943f ("btrfs: fix readdir deadlock with pagefault") Signed-off-by: Josef Bacik --- fs/btrfs/delayed-inode.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 1c0bab4080a0..c9f7b13a7847 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -1632,28 +1632,18 @@ void btrfs_readdir_put_delayed_items(struct inode *inode, int btrfs_should_delete_dir_index(struct list_head *del_list, u64 index) { - struct btrfs_delayed_item *curr, *next; - int ret; - - if (list_empty(del_list)) - return 0; + struct btrfs_delayed_item *curr; + int ret = 0; - list_for_each_entry_safe(curr, next, del_list, readdir_list) { + list_for_each_entry(curr, del_list, readdir_list) { if (curr->key.offset > index) break; - - list_del(&curr->readdir_list); - ret = (curr->key.offset == index); - - if (refcount_dec_and_test(&curr->refs)) - kfree(curr); - - if (ret) - return 1; - else - continue; + if (curr->key.offset == index) { + ret = 1; + break; + } } - return 0; + return ret; } /*