All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@redhat.com>
To: Hu Weiwen <sehuww@mail.scut.edu.cn>
Cc: linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH v2] erofs-utils: fix battach on full buffer block
Date: Fri, 22 Jan 2021 20:43:52 +0800	[thread overview]
Message-ID: <20210122124352.GA3105292@xiangao.remote.csb> (raw)
In-Reply-To: <20210121162606.8168-1-sehuww@mail.scut.edu.cn>

Hi Weiwen,

On Fri, Jan 22, 2021 at 12:26:06AM +0800, Hu Weiwen wrote:
> When __erofs_battach() is called on an buffer block of which
> (bb->buffers.off % EROFS_BLKSIZ == 0), `tail_blkaddr' will not be
> updated correctly. This bug can be reproduced by:
> 
> mkdir bug-repo
> head -c 4032 /dev/urandom > bug-repo/1
> head -c 4095 /dev/urandom > bug-repo/2
> head -c 12345 /dev/urandom > bug-repo/3  # arbitrary size
> mkfs.erofs -Eforce-inode-compact bug-repo.erofs.img bug-repo
> 
> Then mount this image and see that file `3' in the image is different
> from `bug-repo/3'.
> 
> This patch fix this by:
> 
> * Don't inline tail-end data in this case, since the tail-end data will
> be in a different block from inode.
> * Correctly handle `battach' in this case.
> 
> Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
> ---
> Hi Xiang,
> 
> I still think send this as a seperate patch would be better. In previous v6
> patch, I have fixed the erofs_mapbh() behaviour so that there should be no
> user-visible bug introduced in that patch. And this patch is almost unrelated
> to that optimization.
> 
> Compared with v1, this version fixes an error when compression is enabled.
> 

I have to say I still don't get the point of the whole description
above and the patch itself honestly. even if (bb->buffers.off %
EROFS_BLKSIZ == 0), the whole block can be used for tail-packing
inline + inode. Assume that you testcase above is the case you
addressed, could you elaborate them in detail?

If the original behavior is no user-visiable, I'm not sure what
issue you'd like to resolve...

Thanks,
Gao Xiang

> Thanks,
> Hu Weiwen


  parent reply	other threads:[~2021-01-22 12:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18 12:39 [PATCH] erofs-utils: fix battach on full buffer block Hu Weiwen
2021-01-18 13:59 ` Gao Xiang
2021-01-18 15:52   ` 胡玮文
2021-01-18 23:28     ` Gao Xiang
2021-01-19  6:02   ` 胡玮文
2021-01-19 15:43     ` Gao Xiang
2021-01-20  4:57       ` 胡玮文
2021-01-20  5:12         ` Gao Xiang
2021-01-21  6:07           ` 胡玮文
2021-01-21  7:22             ` 胡玮文
2021-01-21  9:22             ` Gao Xiang
2021-01-21 16:26           ` [PATCH v2] " Hu Weiwen
2021-01-22  2:31             ` Gao Xiang
2021-01-22 12:43             ` Gao Xiang [this message]
2021-02-14 15:22             ` Gao Xiang via Linux-erofs
2021-02-14 16:00             ` [PATCH v3] erofs-utils: fix battach on full buffer blocks Gao Xiang via Linux-erofs
2021-02-22 15:34               ` Li GuiFu via Linux-erofs

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=20210122124352.GA3105292@xiangao.remote.csb \
    --to=hsiangkao@redhat.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=sehuww@mail.scut.edu.cn \
    /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.