From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E7FDC433ED for ; Sun, 25 Apr 2021 10:41:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0416460FEF for ; Sun, 25 Apr 2021 10:41:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229906AbhDYKmS (ORCPT ); Sun, 25 Apr 2021 06:42:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:44668 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229837AbhDYKmS (ORCPT ); Sun, 25 Apr 2021 06:42:18 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C19F76102A; Sun, 25 Apr 2021 10:41:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1619347297; bh=lOqkIL2viNkXqI+r6TPf4aoZZtxysHO+U451S7dnWhg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HwyXaOkGKogBhLucMmI6epTWfh9tstzzceDDE3ETspFcRxx0A6RlkQtq3Kcbc9zr3 lo1W3yxQRjgXd1JVT29dnEpb09YK5oYIEt54yMUS1oUWdBoM7qCBnGE/PGjyx0bNkI 58YpJZKz2ixReRTeJeN+L7tMb3GCjsQ4wJmv75hM= Date: Sun, 25 Apr 2021 12:41:34 +0200 From: Greg KH To: Gao Xiang Cc: stable@vger.kernel.org, yuchao0@huawei.com Subject: Re: FAILED: patch "[PATCH] erofs: fix extended inode could cross boundary" failed to apply to 4.19-stable tree Message-ID: References: <159766792693116@kroah.com> <20200818025546.GA6339@xiangao.remote.csb> <20210425093913.GA3813581@xiangao.remote.csb> <20210425101357.GB3813581@xiangao.remote.csb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210425101357.GB3813581@xiangao.remote.csb> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Sun, Apr 25, 2021 at 06:13:57PM +0800, Gao Xiang wrote: > On Sun, Apr 25, 2021 at 11:51:57AM +0200, Greg KH wrote: > > On Sun, Apr 25, 2021 at 05:39:13PM +0800, Gao Xiang wrote: > > > Hi Greg, > > > > > > On Sun, Apr 25, 2021 at 10:52:22AM +0200, Greg KH wrote: > > > > On Tue, Aug 18, 2020 at 10:55:46AM +0800, Gao Xiang wrote: > > > > > On Mon, Aug 17, 2020 at 02:38:46PM +0200, gregkh@linuxfoundation.org wrote: > > > > > > > > > > > > The patch below does not apply to the 4.19-stable tree. > > > > > > If someone wants it applied there, or to any other stable or longterm > > > > > > tree, then please email the backport, including the original git commit > > > > > > id to . > > > > > > > > > > > > thanks, > > > > > > > > > > > > greg k-h > > > > > > > > > > > > ------------------ original commit in Linus's tree ------------------ > > > > > > > > > > > > From 0dcd3c94e02438f4a571690e26f4ee997524102a Mon Sep 17 00:00:00 2001 > > > > > > From: Gao Xiang > > > > > > Date: Thu, 30 Jul 2020 01:58:01 +0800 > > > > > > Subject: [PATCH] erofs: fix extended inode could cross boundary > > > > > > > > > > > > Each ondisk inode should be aligned with inode slot boundary > > > > > > (32-byte alignment) because of nid calculation formula, so all > > > > > > compact inodes (32 byte) cannot across page boundary. However, > > > > > > extended inode is now 64-byte form, which can across page boundary > > > > > > in principle if the location is specified on purpose, although > > > > > > it's hard to be generated by mkfs due to the allocation policy > > > > > > and rarely used by Android use case now mainly for > 4GiB files. > > > > > > > > > > > > For now, only two fields `i_ctime_nsec` and `i_nlink' couldn't > > > > > > be read from disk properly and cause out-of-bound memory read > > > > > > with random value. > > > > > > > > > > > > Let's fix now. > > > > > > > > > > > > Fixes: 431339ba9042 ("staging: erofs: add inode operations") > > > > > > Cc: # 4.19+ > > > > > > Link: https://lore.kernel.org/r/20200729175801.GA23973@xiangao.remote.csb > > > > > > Reviewed-by: Chao Yu > > > > > > Signed-off-by: Gao Xiang > > > > > > > > > > Yeah, due to code difference, will manually backport this later... > > > > > > > > What ever happened to this backport? Did I miss it somewhere? > > > > > > Thanks for your reminder, since the codebase was cleaned up and 4.19 > > > codebase is somewhat different from the current codebase. > > > > > > Sorry for forgeting it, and I will try to pick it up and send it out soon. > > > > No worries, just ran across this and wanted to make sure that I didn't > > drop it on my end somewhere. > > Nope, that was my fault. :) > > Due to 4.19 erofs staging version was quite an early version (1st upstreaming > version), more non-trivial conflicts occur in this patch. But it needs to be > fixed with careness if users would like to use 4.19 staging erofs and use > extended inode. I'm addressing this now. > > Yet, I've suggested all Android vendors / users use 5.4+ LTS fs/erofs versions, > since in-place decompression has been supported since linux 5.3 which is great > for performance. And the 5.4 erofs codebase is already shipped for many other > SoC vendors with their in-market products. I too would recommend that anyone using erofs use a newer version, but for those stuck on older kernels like 4.19, they don't seem to be able to want to do that. Should we just mark the filesystem as "BROKEN" on the stable 4.19 tree to prevent anyone from using it there? That feels drastic, but it's your call what would work best here. thanks, greg k-h