redit it "kernel style" bit honggfuzz very
much helped me find this bug (indirectly).
>
> Reported-by: Colin Walters
> Fixes: 431339ba9042 ("staging: erofs: add inode operations")
> Signed-off-by: Gao Xiang
> ---
> v2:
> - sent out a wrong version
On Mon, Sep 9, 2024, at 9:21 AM, Gao Xiang wrote:
>
> It can be bigger.
>
> Like ext4, EROFS supports PAGE_SIZE symlink via page_get_link()
> (non-fastsymlink cases), but mostly consider this as 4KiB though
> regardless of on-disk block sizes.
But symlink targets can't be bigger than PATH_MAX
On Mon, Sep 9, 2024, at 10:14 AM, Gao Xiang wrote:
>
> Not quite sure about hard limitation in EROFS
> runtime, we could define
>
> #define EROFS_SYMLINK_MAXLEN 4096
Not sure that a new define is needed versus just reusing PATH_MAX, but that's
obviously just a style thing that's much more you
On Mon, Sep 9, 2024, at 11:40 AM, Gao Xiang wrote:
>
> Just my personal opinion, my understanding of rubustness
> is stability and security.
>
> But whether to check or not check this, it doesn't crash
> the kernel or deadlock or livelock, so IMHO, it's already
> rubustness.
OK, if you're tell
On Mon, Sep 9, 2024, at 10:18 PM, Gao Xiang wrote:
> I know you ask for an explicit check on symlink i_size, but
> I've explained the current kernel behavior:
>- For symlink i_size < PAGE_SIZE (always >= 4096 on Linux),
> it behaves normally for EROFS Linux implementation;
>
>- For
Hi, today in the composefs[1] project we do checksumming of a "canonicalized"
EROFS (i.e. not written by mkfs.erofs currently[2]), and we hardcode a 4k
blocksize today.
It came up in https://issues.redhat.com/browse/RHEL-63985 that on ppc64le (at
least Fedora derivatives?) use a 64k page size b
On Fri, Dec 6, 2024, at 2:46 PM, Gao Xiang wrote:
> Did you try upstream kernels? It's already supported upstream
> since Linux 6.4.
Sorry, my bad. (It should have occurred to me to check, but this one popped
back up on my radar when I'm trying to do several other things at the same
time).
Any
Patch looks sane to me.
On Wed, Apr 9, 2025, at 2:17 AM, Gao Xiang wrote:
> I think it should be fixed on the kernel side too, yet I rarely look
> after 32-bit platforms due to lack of test environments.
It is relatively easy to run 32 bit containers on a 64bit host, that’s what the
Debian CI
Hey, we're working on shipping composefs in Debian. It runs the tests on 32 bit
(i386), which we don't do upstream.
As part of that, we also run fsck.erofs. It turns out that there must be some
bug in fsck.erofs on i386 because it loops infinitely on the filesystem
generated by this composefs:
