Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp186197pxb; Tue, 5 Apr 2022 04:09:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxG6xTgP2uyr8f+7PUkQArRybCR+/iBIgo18qhaL0hyV3r+0BiNtUrf/Uc3Qoef0HrOK6q7 X-Received: by 2002:a17:902:d714:b0:153:a902:e544 with SMTP id w20-20020a170902d71400b00153a902e544mr2873573ply.17.1649156983658; Tue, 05 Apr 2022 04:09:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649156983; cv=none; d=google.com; s=arc-20160816; b=l/bI8HndoyNPhndr00WIX27AsMOkwzcorZqr1S3P6xqpPYaE9yCwpvy+qNZ23c0ODK H+rog6UyENcber3XPEx6bLu1lt82C9t+gyNDrbvOlQKUyDR2bYDFmuPk5BcDzlMw5UtY Z+w53Z0RkIp86VC6lr5cQaZgK6EzxnaKB2POepLXcZzegxeqEKFQMs/20tsPMGTq7SZm YlNqWflB5xoMtXBjcMrjsPAxsmn5KAmIfK5w5AANgfv678kmpV7kqYPrhKjPbVHgB59u CyZ/SWYVuuwwY29B9xETozzUDYcQY2vi7bJD62x+rnks4ihkzCMfYdXaw3hh8AunYheX k7Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0s741zjxNxdppgULWe9R0/zRKs1xe7Q7zVh156iDVKw=; b=ZfreuyVJfYZaL0ns9YWRzcdjQtmayuSF+AP0bDBFJbKo/fSPk00DpZddu7iGh9DHlO 0qayVYCmcutZ3OuTuD/8/XX47rxPQVIPm6/LdCDqigiFpdLs8ojy4Y9WduoRHPKRtybZ b5Rk0SjRfPH9cjDI7DS9WX57jOW7fLbQPjIuYzkwH5Y5Ws/7sAEeeuM7M4I6le9CAf12 hA+LIl9+36EVIL/tyuK51JzeLkKMrvHY3olF6GemfIPfrjCW/1JT7cEzJXs2nq3RsYE8 +Se3R3uOUrAWTuSNcsDItOnc4deVnnTd0CO/9gieR31uOg5U06n29xQtPZOo2l2pkbDL P7ag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="eb/33kP+"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kb11-20020a17090ae7cb00b001bfa5e268ccsi1969963pjb.90.2022.04.05.04.09.13; Tue, 05 Apr 2022 04:09:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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=@gmail.com header.s=20210112 header.b="eb/33kP+"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349643AbiDELKE (ORCPT + 99 others); Tue, 5 Apr 2022 07:10:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353399AbiDEKGG (ORCPT ); Tue, 5 Apr 2022 06:06:06 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEFAFBF94B for ; Tue, 5 Apr 2022 02:54:56 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id h23-20020a17090a051700b001c9c1dd3acbso2108338pjh.3 for ; Tue, 05 Apr 2022 02:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=0s741zjxNxdppgULWe9R0/zRKs1xe7Q7zVh156iDVKw=; b=eb/33kP+s5z5M25fWDG+bkLTISik/2kQBUDJnOqigEe4EjAg6xwfuwS28xjLqTWJCR /sYyWlpHk1l89WHAXBfguoudlza+9V66/hCYePvurC32dljLuSpfXzkxkwu2wxLmiqfl 6usAIkC6jF3uBIU0Qk8OCRMEl2Zyr39aKUSsYop1gpJq+rR43JgED8+v/RXDECPqLmx1 fWwgFs59CE60Q/QqMJzY0aoYvWZD6qCFNTs96ppiq9wGpgQUhecDsX+b34DYnv0QWb+P IYkt8cPhrQsCrwKoTAIAYNDy6t6z5k3WtEYjqS4EFg9zWd3KU3l/d5XLWv/DMUFqkZxY +aig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=0s741zjxNxdppgULWe9R0/zRKs1xe7Q7zVh156iDVKw=; b=ZAQAt9HYaaSRIt2tUla5mJK6dmYYd/G21Kw8UTA7P1n6/6FbZSCirQEHH/2BrVc1tL ewLPF8nRYUIdg262wiG+url+6UVh+KNkC79tMR770mRlniupIGzKwXvocjhwr2kWs/bb v06THYbAxS+CiWg4TK0MDTLQjdjybJZprhfbpB2pq0GeCT7g39HelKWGzQpEw0nM8vh5 1o3pHFdeigCm9iUiZDLjR6uzoMgZ6dUmQdw7NT688yZccKIrZwOaElq+5Q/91hjo6Ami PUqyALVR2mYhiXMGR0s27gJK0kJS1Iq5BVboUMsq2CvWe/cqKEAr2FGTFEu39thEWWTP /OgA== X-Gm-Message-State: AOAM532nnyP08YSeuKXqRKZYHD97J5A2MgP63oK0oYoS4FM2c6ZCPZ5a KxIeK9jWm2cvTVY6G6D0hik= X-Received: by 2002:a17:90b:3ec8:b0:1c6:bf6a:19bc with SMTP id rm8-20020a17090b3ec800b001c6bf6a19bcmr3097126pjb.79.1649152496441; Tue, 05 Apr 2022 02:54:56 -0700 (PDT) Received: from localhost ([2406:7400:63:792d:bde9:ddd5:53e9:ed83]) by smtp.gmail.com with ESMTPSA id mi18-20020a17090b4b5200b001c9a9b60489sm1981575pjb.7.2022.04.05.02.54.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 02:54:56 -0700 (PDT) Date: Tue, 5 Apr 2022 15:24:51 +0530 From: Ritesh Harjani To: anserper@ya.ru Cc: linux-ext4@vger.kernel.org, Andrew Perepechko Subject: Re: [PATCH v3] ext4: truncate during setxattr leads to kernel panic Message-ID: <20220405095451.kx43cdu2ureywgcq@riteshh-domain> References: <20220402084023.1841375-1-anserper@ya.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220402084023.1841375-1-anserper@ya.ru> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,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-ext4@vger.kernel.org On 22/04/02 11:40AM, anserper@ya.ru wrote: > From: Andrew Perepechko > > When changing a large xattr value to a different large xattr value, > the old xattr inode is freed. Truncate during the final iput causes > current transaction restart. Eventually, parent inode bh is marked > dirty and kernel panic happens when jbd2 figures out that this bh > belongs to the committed transaction. > > A possible fix is to call this final iput in a separate thread. > This way, setxattr transactions will never be split into two. > Since the setxattr code adds xattr inodes with nlink=0 into the > orphan list, old xattr inodes will be properly cleaned up in > any case. Ok, I think there is a lot happening in above description. I think part of the problem I am unable to understand it easily is because I haven't spend much time with xattr code. But I think below 2 requests will be good to have - 1. Do we have the call stack for this problem handy. I think it will be good to mention it in the commit message itself. It is sometimes easy to look at the call stack if someone else encounters a similar problem. That also gives more idea about where the problem is occuring. 2. Do we have a easy reproducer for this problem? I think it will be a good addition to fstests given that this adds another context in calling iput on old_ea_inode. > > Signed-off-by: Andrew Perepechko > HPE-bug-id: LUS-10534 ^^^ I think above can be dropped. Any fixes tag instead? -ritesh