Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp3415868rwa; Tue, 23 Aug 2022 04:31:58 -0700 (PDT) X-Google-Smtp-Source: AA6agR7x3zvtOvebaPAC0kcDUdv/44Hatv+8RwTqjy8/jIKXFbE1lynlZlMNtOEVp24Pov/5dLBd X-Received: by 2002:a17:90b:33c4:b0:1fb:6311:db94 with SMTP id lk4-20020a17090b33c400b001fb6311db94mr2527015pjb.65.1661254196990; Tue, 23 Aug 2022 04:29:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661254196; cv=none; d=google.com; s=arc-20160816; b=S8hy1UHEped0CzmoVZRRSrpKSo1ytR+WHXLTqqyh+l6PLRVxeaqGSd0wvc/ns3MEuQ tJotZsCSNXtVZemtYBNTq2X3FuSHKOLjom1f11ZwRzc/5kQ7EvsgIIAXdM1UbmJIO85h 67nPdgiF1to5fbcVRZgau+h0OtGB2Sz0avP7m6xr9RdYHAUTgnGszQIoguOGDhUVOPtp 4kj/udXdt/NA9mEwurk0yPcvl4+ZUiTuKbBbk5+pJlLOWY7hw5qezYQuHDeG16QFpix7 XTUdayN+Z9N4Tl/ChlW0ddseMioLqJxBb5hI1LnXKrP54tWdJkXWdSNpWzN4yxXJ4Mk6 h/hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=AoUfnrQbS8P2tTPctFlasCtkAE5//rZhXLxLJOzh8hM=; b=WuPiohqwqp1ncE6vo1xG3zNIxLpr5PWOZzR6feALQvlm9plTSckIxGLEqmNsuEVekZ 8bv16ovaWJLQhQDW5P1z4kbjfAoskG+Drrmx6ZMB8f8vXwdv1RUA/ZsrPqPuc3UtbTYi +Bk0UXkKdOaSRcPb/LsRjf8yOzRF5KhB899a5aNFM5KdIAC/oymtRbbt920LKvO+oGEy Km3C+cnTWl9SD5y4J1tUpKVhw+sWfag1O+OIkJfG0GxzS+4SOL/MnaUaVLWrT25Qgw6S aF/mM8ziDTejvhzBcc1ToGEVqf8f61kvnegIakJF4c8iCysc9rgc+HVaNi5um9RvtVkZ aO4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qtBtKD8P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c196-20020a624ecd000000b00536366cfa93si11279251pfb.197.2022.08.23.04.29.45; Tue, 23 Aug 2022 04:29:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qtBtKD8P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353914AbiHWKMS (ORCPT + 99 others); Tue, 23 Aug 2022 06:12:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352252AbiHWKFI (ORCPT ); Tue, 23 Aug 2022 06:05:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DC577CB5E; Tue, 23 Aug 2022 01:51:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 39F516150F; Tue, 23 Aug 2022 08:51:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3ED85C433D6; Tue, 23 Aug 2022 08:51:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1661244712; bh=l1hHllYzgE1Bcw27PDIeyRbRqgXZ1yIg4OE0bNPY3QE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qtBtKD8P56WqTsBtGD9/zPKl9Qx5K/7elZmvcwi5uJmglXefJ+vnsSzX8F/mtpXIQ j5gupnDa7MBHNSCkneFfsFu/qFDU18UK0R2ElYooY7ZBMCmhps9S4jOgR7ljjTZjF9 WFy5yZBFn7x9L4seW5snyy2fBfHe3d1WJ3bqT170= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba Subject: [PATCH 4.14 179/229] btrfs: fix lost error handling when looking up extended ref on log replay Date: Tue, 23 Aug 2022 10:25:40 +0200 Message-Id: <20220823080100.012041778@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220823080053.202747790@linuxfoundation.org> References: <20220823080053.202747790@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Filipe Manana commit 7a6b75b79902e47f46328b57733f2604774fa2d9 upstream. During log replay, when processing inode references, if we get an error when looking up for an extended reference at __add_inode_ref(), we ignore it and proceed, returning success (0) if no other error happens after the lookup. This is obviously wrong because in case an extended reference exists and it encodes some name not in the log, we need to unlink it, otherwise the filesystem state will not match the state it had after the last fsync. So just make __add_inode_ref() return an error it gets from the extended reference lookup. Fixes: f186373fef005c ("btrfs: extended inode refs") CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/tree-log.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -1100,7 +1100,9 @@ again: extref = btrfs_lookup_inode_extref(NULL, root, path, name, namelen, inode_objectid, parent_objectid, 0, 0); - if (!IS_ERR_OR_NULL(extref)) { + if (IS_ERR(extref)) { + return PTR_ERR(extref); + } else if (extref) { u32 item_size; u32 cur_offset = 0; unsigned long base;