On 2024/5/3 12:15, Al Viro wrote:
On Fri, Apr 26, 2024 at 01:32:04PM +0800, Gao Xiang wrote:
Hi Al,
This patch caused some corrupted failure, since
here erofs_read_metabuf() is EROFS_NO_KMAP and
it's no needed to get a maped-address since only
a page reference is needed.
if (IS_ERR(mptr)) {
ret = PTR_ERR(mptr);
erofs_err(sb, "failed to get inline data %d", ret);
@@ -876,7 +876,7 @@ static int z_erofs_pcluster_begin(struct z_erofs_decompress_frontend *fe)
}
get_page(map->buf.page);
WRITE_ONCE(fe->pcl->compressed_bvecs[0].page, map->buf.page);
- fe->pcl->pageofs_in = map->m_pa & ~PAGE_MASK;
+ fe->pcl->pageofs_in = offset_in_page(mptr);
So it's unnecessary to change this line IMHO.
*nod*
thanks for catching that.
BTW, would you mind routing this series through erofs tree
with other erofs patches for -next (as long as this series
isn't twisted with vfs and block stuffs...)? Since I may
need to test more to ensure they don't break anything and
could fix them immediately by hand...
FWIW, my immediate interest here is the first couple of patches.
Yes, the first two patches are fine by me, you could submit
directly.
How about the following variant:
#misc.erofs (the first two commits) is put into never-rebased mode;
you pull it into your tree and do whatever's convenient with the rest.
I merge the same branch into block_device work; that way it doesn't
cause conflicts whatever else happens in our trees.
Are you OK with that? At the moment I have
; git shortlog v6.9-rc2^..misc.erofs
Al Viro (2):
erofs: switch erofs_bread() to passing offset instead of block number
erofs_buf: store address_space instead of inode
Linus Torvalds (1):
Linux 6.9-rc2
IOW, it's those two commits, based at -rc2. I can rebase that to other
starting point if that'd be more convenient for you.
Yeah, thanks for that. I think I will submit two pull requests for
the next cycle, and I will send the second pull request after your
vfs work is landed upstream and it will include the remaining
patches you sent (a bit off this week since we're on holiday here).
Thanks,
Gao Xiang
