linux-kernel - Re: [PATCH v4] iomap: support tail packing inline read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHpGcMJg5TOhexLdN8HgGoFhB8kbn1FdAD8Z2XEK9C7oHptFwA@mail.gmail.com>
Date:   Wed, 21 Jul 2021 08:43:00 +0200
From:   Andreas Grünbacher <andreas.gruenbacher@...il.com>
To:     Andreas Grünbacher <andreas.gruenbacher@...il.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        linux-erofs@...ts.ozlabs.org,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v4] iomap: support tail packing inline read

Am Mi., 21. Juli 2021 um 04:54 Uhr schrieb Gao Xiang
<hsiangkao@...ux.alibaba.com>:
> Hi Andreas,
>
> On Wed, Jul 21, 2021 at 04:26:47AM +0200, Andreas Grünbacher wrote:
> > Am Mi., 21. Juli 2021 um 02:33 Uhr schrieb Gao Xiang
> > <hsiangkao@...ux.alibaba.com>:
> > > > And since you can only kmap one page at a time, an inline read grabs the
> > > > first part of the data in "page one" and then we have to call
> > > > iomap_begin a second time get a new address so that we can read the rest
> > > > from "page two"?
> > >
> > > Nope, currently EROFS inline data won't cross page like this.
> > >
> > > But in principle, yes, I don't want to limit it to the current
> > > EROFS or gfs2 usage. I think we could make this iomap function
> > > more generally (I mean, I'd like to make the INLINE extent
> > > functionity as general as possible,
> >
> > Nono. Can we please limit this patch what we actually need right now,
> > and worry about extending it later?
>
> Can you elaborate what it will benefit us if we only support one tail
> block for iomap_read_inline_data()? (I mean it has similar LOC changes,
> similar implementation / complexity.) The only concern I think is if
> it causes gfs2 regression, so that is what I'd like to confirm.

iomap_read_inline_data supports one inline page now (i.e., from the
beginning of the file). It seems that you don't need more than one
tail page in EROFS, right?

You were speculating about inline data in the middle of a file. That
sounds like a really, really bad idea to me, and I don't think we
should waste any time on it.

> In contrast, I'd like to avoid iomap_write_begin() tail-packing because
> it's complex and no fs user interests in it for now. So I leave it
> untouched for now.

I have no idea what you mean by that.

> Another concern I really like to convert EROFS to iomap is I'd like to
> support sub-page blocksize for EROFS after converting. I don't want to
> touch iomap inline code again like this since it interacts 2 directories
> thus cause too much coupling.
>
> Thanks,
> Gao Xiang
>
> >
> > > my v1 original approach
> > > in principle can support any inline extent in the middle of
> > > file rather than just tail blocks, but zeroing out post-EOF
> > > needs another iteration) and I don't see it add more code and
> > > complexity.
> >
> > Thanks,
> > Andreas

Andreas