Received: by 10.223.176.5 with SMTP id f5csp3368581wra; Mon, 29 Jan 2018 12:14:48 -0800 (PST) X-Google-Smtp-Source: AH8x224234CM7TKK7RPpm+PhE5IONCFqzj0LLjETFSl0xdlQl7Vz5V8+cXT7XJJaM8Wh022LXkVY X-Received: by 2002:a17:902:424:: with SMTP id 33-v6mr22530683ple.57.1517256888041; Mon, 29 Jan 2018 12:14:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517256888; cv=none; d=google.com; s=arc-20160816; b=bY/QcBpFawLx/VUA2/i0c97bG+WhzVUXHD7k+hx2CKOaC00O/a+BcK6QLK+LK66Bx5 wgXyTDhTYGB0n+5wO5K8loHlXr5RoTInveVJUTDVzEKueT85OGMNKXSeKdvob/PdeFih RBka/KWtkTusoeJigxocq+Gp990Uc9c1pvDR+1a5rtCx8/Xs4/AyRPrlUSh9h0nsOXDW Cc1SMQ+GmV3U7g0Ak7yNU/e+4qf7SSE4d4ZOPx2aJqpTsxXxhUC32fYCPxVKFOyWa1ng eTrfCX6+S9gZezDWQyeEacVnYsw9GqwdxHvoNCPmyOVkaoLYYZnYpOjAX2HptDaD9yRq VzCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=GZMYHAkLxRVJV1RGPG4Wf8KXHG4jj1dnEaf7/xsti9o=; b=TUneHL03i8SogMyyYHN/ac7wyqj+aHwvFd8nDpbd5ZTaxaoRBAdKY/v91I/jv5IL84 PUGDzx22H54/LBL0+ha5692P5L0RTXxzTnwZSRFCgZKqGw4g7Ro2rHiFd0Mi3ec/CtKl hIVPsZid9TvzbnHhchTavpbfHxe87REB5C/ckbsz23Lcl5+vibz2BYQrxBoK/OEvphjq 1AMK6AmrtM6YcEBlehiOEfEAc89gAWbo1D0kQNWc/yoy2D+Bc5aMLjO0v9SpW2lQSCab xhyAO865s1Y0mor+6VRIUSU74FF3NUd2vWcHujd+tHxfXBSBLZ15GII3CgFEBeit+bxU zWcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g24-v6si9062019plj.50.2018.01.29.12.14.33; Mon, 29 Jan 2018 12:14:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753334AbeA2UNC (ORCPT + 99 others); Mon, 29 Jan 2018 15:13:02 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:36362 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932104AbeA2UM7 (ORCPT ); Mon, 29 Jan 2018 15:12:59 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 21FAD2FD8; Mon, 29 Jan 2018 13:07:45 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , David Sterba Subject: [PATCH 4.14 11/71] Btrfs: fix stale entries in readdir Date: Mon, 29 Jan 2018 13:56:39 +0100 Message-Id: <20180129123828.066888632@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180129123827.271171825@linuxfoundation.org> References: <20180129123827.271171825@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Josef Bacik commit e4fd493c0541d36953f7b9d3bfced67a1321792f upstream. 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. Fixes: 23b5ec74943f ("btrfs: fix readdir deadlock with pagefault") Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/delayed-inode.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -1677,28 +1677,18 @@ void btrfs_readdir_put_delayed_items(str int btrfs_should_delete_dir_index(struct list_head *del_list, u64 index) { - struct btrfs_delayed_item *curr, *next; - int ret; + struct btrfs_delayed_item *curr; + int ret = 0; - if (list_empty(del_list)) - return 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; } /*