[PATCH v7 2/2] erofs-utils: lib: add API to iterate dirs in EROFS

Kelvin Zhang zhangkelvin at google.com
Mon Dec 20 11:53:00 AEDT 2021


I don't understand why re-using the context struct(<50 bytes) helps prevent
stack overflow, when the current implementation of erofs_iterate_dir holds
a 4096 bytes buffer on stack. If is erofs_iterate_dir called recursively,
it's probably the char buf[EROFS_BLKSIZ]; who's using up stack space.

On Fri, Dec 17, 2021 at 7:36 PM Gao Xiang <hsiangkao at linux.alibaba.com>
wrote:

> Hi Kelvin,
>
> On Fri, Dec 17, 2021 at 02:54:09PM -0500, Kelvin Zhang wrote:
> > Hi Gao,
> >     I drafted a new patchset on top of the dev branch. Changes since v6:
> >
> >     1. block buffer moved to the heap, due to stack size concerns when
> > iterating recursively
> >     2. Added a "recursive" option to input parameters
> >     3. dname buffers are still on the heap, but allocation is done once
> per
> > directory, instead of once for each directory entry.
> >     4. Added a void* arg which will be forwarded to the callback
> function.
> >
> > I ran scripts/checkpatch.pl . Hopefully this makes your life easier.
> Thanks
> > for the reply!.
> >
> >
>
> Many thanks for your reply! I plan to take the patches in the
> experimental branch.
>
> The reason was written in include/erofs/dir.h:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/include/erofs/dir.h?h=experimenta
>
>  erofs_dir_context can be allocated on heap (in summary, by
>  the caller) and chain together in order to avoid recursion
>  totally later. I think it should benefit Android scenario to
>  avoid stack overflow due to deep level as well.
>
> Also Igor Eisberg sent a patch for a new get_pathname in the
> erofs_dir_context reuse way:
>
> https://lore.kernel.org/linux-erofs/CABjEcnE84FNBgiHFk6Q+V3d-4L-93bUFDkdfN4ftPX19kpC=ww@mail.gmail.com/
>
> I plan to polish and apply them as well.
>
> Thanks,
> Gao Xiang
>


-- 
Sincerely,

Kelvin Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20211219/2b961b40/attachment.htm>


More information about the Linux-erofs mailing list