On Tue, Apr 18, 2023 at 5:20 PM Alexander Larsson <alexl@xxxxxxxxxx> wrote:
>
> On Tue, 2023-04-18 at 16:33 +0300, Amir Goldstein wrote:
> > On Tue, Apr 18, 2023 at 3:02 PM Alexander Larsson <alexl@xxxxxxxxxx>
> > wrote:
> > >
> > >
> > > > * fh->uuid to layer.
> > > > @@ -907,7 +907,7 @@ struct dentry *ovl_lookup(struct inode *dir,
> > > > struct dentry *dentry,
> > > >
> > > > if (!d.stop && ovl_numlower(poe)) {
> > > > err = -ENOMEM;
> > > > - stack = ovl_stack_alloc(ofs->numlayer - 1);
> > > > + stack = ovl_stack_alloc(ovl_numlowerlayer(ofs));
> > > > if (!stack)
> > > > goto out_put_upper;
> > > > }
> > >
> > > Again, surely ovl_numlower(poe) is a better size here?
> >
> > Intentional. that is changed in the following patch.
> > (to ovl_numlowerlayer(ofs) + 1)
> > As the commit message says:
> > "Following changes will implement lookup in the data layers."
>
> Still, you might have 10 lower layers in the overlay mount overall, but
> this particular parent may only have 1 lower layer, no? So
> numlower(poe) would be smaller that numlowerlayer(ofs).
Ah, I understand your question.
The answer is that absolute redirect (a.k.a poe = roe) can change
numlower(poe) after the stack was allocated.
There are several "optimizations" that could be done, but they
are useless, because stack is a temporary allocation.
The permanent stack allocation is done at the end of lookup
with ovl_alloc_entry(ctr).
Which means I could have also left it ofs->numlayer - 1
this change ends up being just semantic.
Thanks,
Amir.
