From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (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 EED9D33F8CF for ; Sat, 10 Jan 2026 11:54:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768046085; cv=none; b=CHIOCChKlLmJk1jtwdjffl9d74211OQW57Lms7Z5cM1SbZa7ZE1jPm6Ft4T/m1DvjdNyZ/hOK2r4OXmPb13VOYAn/DGyJ5UhN8OsWnHrH1p/y+J0e5qlPnyjUL9GrbOIo07ddQQ10af/Zt6kd5tEAAX/f9T9HnSlSRUk4gcpcFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768046085; c=relaxed/simple; bh=byyV7Uq/UIt5DRX4Sue0fK0qyFngHE0bxdzHQ+d5GUM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Gtc+TM/29S8RHALzu0Xai16a9ySPIm98kREyc234PS/st03HrdLdFpU4toltEkexjIbXPbVZ1RkOk5kqMcljuvFWMQVXHosOEjbKvDjVh81heLKliV13Z0CKl/Cpa2aYFYrDmXqDr218+fA7iUORBy/gbp3QYJxB/QI8WrE2OHs= 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=nMFwJ+dV; arc=none smtp.client-ip=115.124.30.111 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="nMFwJ+dV" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1768046071; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=yjQw6WA9ZHNizbRC8ctPJiQ8KE2a/0XoSGIovCMasWU=; b=nMFwJ+dV2YfLWIc+ZF8QwHMv0JvUOZEblbVHU/vDXLCMMxBJKlQwY3Wi6VIb1k0QSid3n1TytBBbDPRVWs00H+U63q9J0EH6+JZWJNhzaGia/GB9OklG6q2QFhFdC+ptiryXFC6uRNhrQOcHGcbK7JHed53glbkZFgNFR2C4gtE= Received: from 30.180.182.138(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WwjqhvG_1768046069 cluster:ay36) by smtp.aliyun-inc.com; Sat, 10 Jan 2026 19:54:30 +0800 Message-ID: Date: Sat, 10 Jan 2026 19:54:29 +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 Cc: 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: <9303721e-5b67-4c66-8369-61c5125b1fb1@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026/1/10 18:48, Amir Goldstein wrote: > On Sat, Jan 10, 2026 at 11:30 AM Gao Xiang wrote: >> >> 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. >> > > Yes. That's what I said. > >>> >>> 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. >> > > This is what the Fixes: tag is for. > Stable kernel maintainers know how to look for those when applying fixes. For stable kernels, Yes. But there could be customized downstream kernels, yet I totally agree with you, "revert + patch with same title" won't be better in any aspect. > >>> >>> 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. >> > > Mistakes happen. > This is built into the process. > This will not be the first time that a fix patch is also a regression. > Sometimes its detected on the same day and sometimes weeks later... I've sent out a delta fix: https://lore.kernel.org/r/20260110114703.3461706-1-hsiangkao@linux.alibaba.com Hopefully it's the end of the disaster. Thanks, Gao Xiang > > Thanks, > Amir.