All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <xiang@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yue Hu <huyue2@coolpad.com>,
	Chen Zhongjin <chenzhongjin@huawei.com>,
	Jeff Layton <jlayton@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	linux-cachefs@redhat.com, Hou Tao <houtao1@huawei.com>,
	linux-erofs@lists.ozlabs.org
Subject: Re: [GIT PULL] erofs updates for 6.2-rc1 (fscache part inclusive)
Date: Mon, 12 Dec 2022 15:01:12 +0800	[thread overview]
Message-ID: <Y5bRuDiEwUAK1si1@debian> (raw)
In-Reply-To: <Y5TB6E77vbpRMhIk@debian>

Hi Linus,

On Sun, Dec 11, 2022 at 01:29:21AM +0800, Gao Xiang wrote:
> Hi Linus,
> 
> Once the merge window opens, could you consider this pull request for
> 6.2-rc1?
> 
> In this cycle, large folios are now enabled in the iomap/fscache mode
> for uncompressed files first.  In order to do that, we've also cleaned
> up better interfaces between erofs and fscache, which are acked by
> fscache/netfs folks and included in this pull request.
> 
> Other than that, there are random fixes around erofs over fscache and
> crafted images by syzbot, minor cleanups and documentation updates.
> 
> Note that there could be a trivial conflict between erofs and vfs
> tree according to linux-next report [1].
> 
> Happy Holidays!
> Gao Xiang
> 
> [1] https://lore.kernel.org/r/20221205092415.56cc6e19@canb.auug.org.au/
> 
> The following changes since commit eb7081409f94a9a8608593d0fb63a1aa3d6f95d8:
> 
>   Linux 6.1-rc6 (2022-11-20 16:02:16 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.2-rc1
> 
> for you to fetch changes up to c505feba4c0d76084e56ec498ce819f02a7043ae:
> 

Sorry for bothering again.

Just having seen v6.2 pull request requirements together with
Linux 6.1 announcement.

Comparing with the latest -next on the last Thursday, there was one-liner
addition on
commit 927e5010ff5b ("erofs: use kmap_local_page() only for erofs_bread()")
as below:

diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c
index 85932086d23f..5b3a793103af 100644
--- a/fs/erofs/inode.c
+++ b/fs/erofs/inode.c
@@ -268,6 +268,7 @@ static int erofs_fill_inode(struct inode *inode)
 	case S_IFDIR:
 		inode->i_op = &erofs_dir_iops;
 		inode->i_fop = &erofs_dir_fops;
+		inode_nohighmem(inode);
 		break;
 	case S_IFLNK:
 		err = erofs_fill_symlink(inode, kaddr, ofs)

since I found erofs_lookup() could break on x86 platform with HIGHMEM
enabled this weekend and I made all dirs inode_nohighmem() and folded
into the original patch since it's no needed to keep dirs in HIGHMEM.
I don't find other strange other than this.

Because there is no -next version on Monday, if you would like to
take all commits in -next you could take
  git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.2-rc1-alt

instead (the top commit is e5293c693d68f705787480159c4cd332c09c5e67.)

In that way I will send another patch to fix the issue above later,
but if it's possible, it'd be better to apply "tags/erofs-for-6.2-rc1"
directly...

The diffstat of tags/erofs-for-6.2-rc1-alt is:

Chen Zhongjin (1):
      erofs: Fix pcluster memleak when its block address is zero

Gao Xiang (5):
      erofs: update documentation
      erofs: clean up cached I/O strategies
      erofs: use kmap_local_page() only for erofs_bread()
      erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails
      erofs: validate the extent length for uncompressed pclusters

Hou Tao (1):
      erofs: check the uniqueness of fsid in shared domain in advance

Jingbo Xu (5):
      erofs: enable large folios for iomap mode
      fscache,cachefiles: add prepare_ondemand_read() callback
      erofs: switch to prepare_ondemand_read() in fscache mode
      erofs: support large folios for fscache mode
      erofs: enable large folios for fscache mode

 Documentation/filesystems/erofs.rst |  38 ++--
 fs/cachefiles/io.c                  |  77 ++++---
 fs/erofs/data.c                     |  10 +-
 fs/erofs/fscache.c                  | 408 ++++++++++++++++--------------------
 fs/erofs/inode.c                    |   1 +
 fs/erofs/internal.h                 |  13 +-
 fs/erofs/super.c                    |   2 +-
 fs/erofs/xattr.c                    |   8 +-
 fs/erofs/zdata.c                    |  80 +++----
 fs/erofs/zmap.c                     |  15 +-
 include/linux/netfs.h               |   8 +
 include/trace/events/cachefiles.h   |  27 +--
 12 files changed, 343 insertions(+), 344 deletions(-)

Thanks,
Gao Xiang

WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <xiang@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-erofs@lists.ozlabs.org, linux-cachefs@redhat.com,
	LKML <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Jeff Layton <jlayton@kernel.org>, Chao Yu <chao@kernel.org>,
	Yue Hu <huyue2@coolpad.com>,
	Jingbo Xu <jefflexu@linux.alibaba.com>,
	Hou Tao <houtao1@huawei.com>,
	Chen Zhongjin <chenzhongjin@huawei.com>,
	Jia Zhu <zhujia.zj@bytedance.com>
Subject: Re: [GIT PULL] erofs updates for 6.2-rc1 (fscache part inclusive)
Date: Mon, 12 Dec 2022 15:01:12 +0800	[thread overview]
Message-ID: <Y5bRuDiEwUAK1si1@debian> (raw)
In-Reply-To: <Y5TB6E77vbpRMhIk@debian>

Hi Linus,

On Sun, Dec 11, 2022 at 01:29:21AM +0800, Gao Xiang wrote:
> Hi Linus,
> 
> Once the merge window opens, could you consider this pull request for
> 6.2-rc1?
> 
> In this cycle, large folios are now enabled in the iomap/fscache mode
> for uncompressed files first.  In order to do that, we've also cleaned
> up better interfaces between erofs and fscache, which are acked by
> fscache/netfs folks and included in this pull request.
> 
> Other than that, there are random fixes around erofs over fscache and
> crafted images by syzbot, minor cleanups and documentation updates.
> 
> Note that there could be a trivial conflict between erofs and vfs
> tree according to linux-next report [1].
> 
> Happy Holidays!
> Gao Xiang
> 
> [1] https://lore.kernel.org/r/20221205092415.56cc6e19@canb.auug.org.au/
> 
> The following changes since commit eb7081409f94a9a8608593d0fb63a1aa3d6f95d8:
> 
>   Linux 6.1-rc6 (2022-11-20 16:02:16 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.2-rc1
> 
> for you to fetch changes up to c505feba4c0d76084e56ec498ce819f02a7043ae:
> 

Sorry for bothering again.

Just having seen v6.2 pull request requirements together with
Linux 6.1 announcement.

Comparing with the latest -next on the last Thursday, there was one-liner
addition on
commit 927e5010ff5b ("erofs: use kmap_local_page() only for erofs_bread()")
as below:

diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c
index 85932086d23f..5b3a793103af 100644
--- a/fs/erofs/inode.c
+++ b/fs/erofs/inode.c
@@ -268,6 +268,7 @@ static int erofs_fill_inode(struct inode *inode)
 	case S_IFDIR:
 		inode->i_op = &erofs_dir_iops;
 		inode->i_fop = &erofs_dir_fops;
+		inode_nohighmem(inode);
 		break;
 	case S_IFLNK:
 		err = erofs_fill_symlink(inode, kaddr, ofs)

since I found erofs_lookup() could break on x86 platform with HIGHMEM
enabled this weekend and I made all dirs inode_nohighmem() and folded
into the original patch since it's no needed to keep dirs in HIGHMEM.
I don't find other strange other than this.

Because there is no -next version on Monday, if you would like to
take all commits in -next you could take
  git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.2-rc1-alt

instead (the top commit is e5293c693d68f705787480159c4cd332c09c5e67.)

In that way I will send another patch to fix the issue above later,
but if it's possible, it'd be better to apply "tags/erofs-for-6.2-rc1"
directly...

The diffstat of tags/erofs-for-6.2-rc1-alt is:

Chen Zhongjin (1):
      erofs: Fix pcluster memleak when its block address is zero

Gao Xiang (5):
      erofs: update documentation
      erofs: clean up cached I/O strategies
      erofs: use kmap_local_page() only for erofs_bread()
      erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails
      erofs: validate the extent length for uncompressed pclusters

Hou Tao (1):
      erofs: check the uniqueness of fsid in shared domain in advance

Jingbo Xu (5):
      erofs: enable large folios for iomap mode
      fscache,cachefiles: add prepare_ondemand_read() callback
      erofs: switch to prepare_ondemand_read() in fscache mode
      erofs: support large folios for fscache mode
      erofs: enable large folios for fscache mode

 Documentation/filesystems/erofs.rst |  38 ++--
 fs/cachefiles/io.c                  |  77 ++++---
 fs/erofs/data.c                     |  10 +-
 fs/erofs/fscache.c                  | 408 ++++++++++++++++--------------------
 fs/erofs/inode.c                    |   1 +
 fs/erofs/internal.h                 |  13 +-
 fs/erofs/super.c                    |   2 +-
 fs/erofs/xattr.c                    |   8 +-
 fs/erofs/zdata.c                    |  80 +++----
 fs/erofs/zmap.c                     |  15 +-
 include/linux/netfs.h               |   8 +
 include/trace/events/cachefiles.h   |  27 +--
 12 files changed, 343 insertions(+), 344 deletions(-)

Thanks,
Gao Xiang

  reply	other threads:[~2022-12-12  7:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-10 17:29 [GIT PULL] erofs updates for 6.2-rc1 (fscache part inclusive) Gao Xiang
2022-12-10 17:29 ` Gao Xiang
2022-12-12  7:01 ` Gao Xiang [this message]
2022-12-12  7:01   ` Gao Xiang
2022-12-13  4:12   ` Linus Torvalds
2022-12-13  4:56     ` Gao Xiang
2022-12-13  4:56       ` Gao Xiang
2022-12-13  5:00 ` pr-tracker-bot
2022-12-13  5:00   ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y5bRuDiEwUAK1si1@debian \
    --to=xiang@kernel.org \
    --cc=chenzhongjin@huawei.com \
    --cc=dhowells@redhat.com \
    --cc=houtao1@huawei.com \
    --cc=huyue2@coolpad.com \
    --cc=jlayton@kernel.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.