From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 644942ECE86 for ; Sat, 10 Jan 2026 10:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768041015; cv=none; b=ganc7tmuJ6lCULIor7uyZYV+luEM0IQjAPzM53dXHdUDq0Xz2qnlpweQpblOstqdLz/rFENn1ITJckYWuNxrwC6wxFe6sMHpBPauG/mj6gAbbDI23XT5GrEvq9GL+77ivCrJ/S1qKgAqyutabPKyCUKRTXmninntzpt1a/szZG0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768041015; c=relaxed/simple; bh=Agk4PbeIapiLvTkKTuFrQMjI4JygwDYQ77NFT4eJ4uY=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=N3XkxL2T6ETQI7Jh5/5RCzovFTSAiAFof3uhZtcwumkQ7xy3Cx1b0TvjKIVty0xgF5INEuoaMynmHrQhcS7LB8UhlD2pWZvHjC1Pk1MKI8dHFXsEYXMO9eS2fTwiLVflNo7wo5Y+nOtei4e9RlKB82QYWuBJAM/QfUkiyf2OO6U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=V7iIH88k; arc=none smtp.client-ip=115.124.30.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="V7iIH88k" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1768041002; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=Aq+A9PyioO73SBRkgOtyvMmH4oU0csKSwRhh/v2cmJs=; b=V7iIH88kE2pb98Am3YzvCXNs3vZmzuvP+lNbVxEoUWed3FTerUmWasa+SK2OPsgtDzFljd+Vdb8zEAEgzEPV0549Vsb2FXRFJXhHAHcGWbUQfbGQpmmgKSxR47QnOcM4tis+MXAEDuPJ46DrxXdmYn6OvylcEN3VasdyAjHGUgw= Received: from 30.180.182.138(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WwjdzhG_1768041001 cluster:ay36) by smtp.aliyun-inc.com; Sat, 10 Jan 2026 18:30:02 +0800 Message-ID: <9303721e-5b67-4c66-8369-61c5125b1fb1@linux.alibaba.com> Date: Sat, 10 Jan 2026 18:30:01 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [GIT PULL] erofs fix for 6.19-rc5 (fix the stupid mistake) To: Amir Goldstein , Linus Torvalds , linux-erofs@lists.ozlabs.org, LKML , Alexander Larsson , Dusty Mabe , Chao Yu , Sheng Yong , Zhiguo Niu , Christian Brauner , Miklos Szeredi , Gao Xiang References: From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Amir, On 2026/1/10 17:50, Amir Goldstein wrote: > On Sat, Jan 10, 2026 at 8:27 AM Gao Xiang wrote: >> >> Hi Linus, >> >> Very sorry I sent an incorrect pull request which used an >> outdated PATCH version (I just manually applied tags on the >> incorrect version, but I didn't realize), I shouldn't make >> the stupid mistake in the beginning. >> >> Someone reminded me the mistake just now. >> >> Could you please apply this pull request, I promise that I >> won't make the similar fault again and I should be blamed. >> >> Thanks, >> Gao Xiang >> >> The following changes since commit 072a7c7cdbea4f91df854ee2bb216256cd619f2a: >> >> erofs: don't bother with s_stack_depth increasing for now (2026-01-10 13:01:15 +0800) >> >> are available in the Git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.19-rc5-fixes-2 >> >> for you to fetch changes up to 0a7468a8de7a2721cc0cce30836726f2a3ac2120: >> >> erofs: don't bother with s_stack_depth increasing for now [real fix] (2026-01-10 15:13:12 +0800) >> >> ---------------------------------------------------------------- >> Changes since last update: >> >> - Revert the incorrect outdated PATCH version >> >> - Apply the correct fix of >> "erofs: don't bother with s_stack_depth increasing for now" >> >> ---------------------------------------------------------------- >> Gao Xiang (2): >> Revert "erofs: don't bother with s_stack_depth increasing for now" >> erofs: don't bother with s_stack_depth increasing for now [real fix] >> > > Gao, > > You merged the wrong patch version by mistake - no real harm done. Sadly, the merged one doesn't work for Android APEX (Sheng actually claimed that PATCH v3 RESEND works instead of PATCH v3 [I'm very sorry for v3 RESEND mark again here] and it was him found that the merged pull request used wrong version and he gave me a private text hours ago), see my explanation below. > > But now that it was merged, for the sake of git history, I think it would > be better to merge a fix patch rather than revert + patch with same title. My concern would be that people could merge incomplete patch chain, but I'm fine to send a fix for the fix, I will do. > > If you merge a fix patch you could properly attribute Report/Review/Tested-by > to Sheng Yong [1]. > > It's true that the merged patch already claims to work for Android APEX, > but it had a braino bug and this is what fix patches are for. Sigh, the merged patch (PATCH v3) actually _breaks_ APEX (it's just like PATCH v1/v2), because: if (erofs_is_fileio_mode(sbi)) { - sb->s_stack_depth = - file_inode(sbi->dif0.file)->i_sb->s_stack_depth + 1; - if (sb->s_stack_depth > FILESYSTEM_MAX_STACK_DEPTH) { - erofs_err(sb, "maximum fs stacking depth exceeded"); + inode = file_inode(sbi->dif0.file); + if ((inode->i_sb->s_op == &erofs_sops && !sb->s_bdev) || Here `!sb->s_bdev` is true for all file-backed mounts all the time, so `!sb->s_bdev` equals to a no-op. + inode->i_sb->s_stack_depth) { I will make a delta patch candidate with his "Reported-by:" and "Tested-by:", I will try to send now. It seems I need to sleep later because my brain is exhaused, and always screwed things up, very very sorry about that. Thanks, Gao Xiang > > Thanks, > Amir. > > [1] https://lore.kernel.org/linux-fsdevel/243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.com/