RE: [PATCH v4 1/3] elf: Allow dlopen of filter object to work [BZ #16272]

[David Kilroy <David dot Kilroy at arm dot com>]

Adhemerval Zanella said:
> 
> On 29/01/2020 08:17, David Kilroy wrote:
> > There are two fixes that are needed to be able to dlopen filter
> > objects. First _dl_map_object_deps cannot assume that map will be at
> > the beginning of l_searchlist.r_list[], as filtees are inserted
> before
> > map. Secondly dl_open_worker needs to ensure that filtees get
> > relocated.
> >
> > In _dl_map_object_deps:
> >
> > * avoiding removing relocation dependencies of map by setting
> >   l_reserved to 0 and otherwise processing the rest of the search
> >   list.
> >
> > * ensure that map remains at the beginning of l_initfini - the list
> >   of things that need initialisation (and destruction). Do this by
> >   splitting the copy up. This may not be required, but matches the
> >   initialization order without dlopen.
> >
> > Modify dl_open_worker to relocate the objects in new->l_inifini.
> > new->l_initfini is constructed in _dl_map_object_deps, and lists the
> > objects that need initialization and destruction. Originally the list
> > of objects in new->l_next are relocated. All of these objects should
> > also be included in new->l_initfini (both lists are populated with
> > dependencies in _dl_map_object_deps). We can't use new->l_prev to
> pick
> > up filtees, as during a recursive dlopen from an interposed malloc
> > call, l->prev can contain objects that are not ready for relocation.
> >
> > Add tests to verify that symbols resolve to the filtee implementation
> > when auxiliary and filter objects are used, both as a normal link and
> > when dlopen'd.
> >
> > Tested by running the testsuite on x86_64.
> 
> LGTM, thanks.
> 
> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>


<snip>
 
> > diff --git a/elf/tst-auxobj-dlopen.c b/elf/tst-auxobj-dlopen.c
> > new file mode 100644
> > index 0000000..7f91bdd
> > --- /dev/null
> > +++ b/elf/tst-auxobj-dlopen.c
> > @@ -0,0 +1,47 @@
> > +/* Test for BZ16272, dlopen'ing an auxiliary filter object.
> 
> Just a nip and tuck: usually bugzilla reports are references as
> BZ#NNNNN.

Thanks for reviewing! Should I resubmit with this fixed? I'd also need
someone to actually apply the changes (assuming no other objections).


FYI I'll be out of office until next week.


Regards,
Dave.