Syslinux - Jan 2016 - [PATCH 2/2] core: Fix stack overflow when reloading config

2016-01-25 12:28 UTC+01:00, H. Peter Anvin <hpa at
zytor.com>:
> On January 22, 2016 3:59:09 AM PST, Celelibi <celelibi at gmail.com>
wrote:
>>2016-01-22 3:37 UTC+01:00, H. Peter Anvin <hpa at zytor.com>:
>>> On 01/21/16 18:33, Celelibi wrote:
>>>>
>>>> BTW, this code is due to Matt Flemming with commit 3a316db1
(later
>>>> modified). The commit log say this:
>>>>     ldlinux: Loading a config file should cause
re-initialisation
>>>>
>>>>     There are a number of initialisation steps that need to be
>>performed
>>>>     *every* time a config file is loaded. Reload ldlinux.c32 so
that
>>we
>>>>     can re-initialise the environment whenever a new config
file is
>>>>     loaded. This involves unloading all the modules that have
been
>>loaded
>>>>     since ldlinux.c32. Luckily the list of loaded modules is
sorted
>>by
>>>>     load order, which means it's trivial to "pop"
them from the
>>front of
>>>>     the list.
>>>>
>>>
>>> Yes, it is the easy way to initialize.  Part of me wonders if we
>>should
>>> keep a copy of the data section and just wipe it out.
>>>
>>> 	-hpa
>>
>>I see 3 ways of handling this.
>>1) Have some specific code in ldlinux.c32 that handles
>>reinitialization.
>>2) Have some specific cache for the COM32 modules and load them only
>>once for the lifetime of the whole boot loader.
>>3) Put a file system cache that would also benefit to other files.
>>
>>I would tend to prefer the third way, but I don't know how much work
>>it would be or if it would integrate well in the current design.
>>
>>
>>Celelibi
>
> #2 is really easy; we just need to keep a copy of the unmodified data
> section.  The only risk with this approach is running out of memory, but I
> think that risk is minor.
Do you suggest to do this only for ldlinux.c32?

If we keep a copy only of the data section, we will only be able to
use it when we know we reload the module. So it will only apply to
ldlinux.c32. While most modules could benefit from this as the new
config file will probably reload the same menu and libraries.


Celelibi

On 01/25/16 10:51, Celelibi wrote:
> 
> Do you suggest to do this only for ldlinux.c32?
> 
> If we keep a copy only of the data section, we will only be able to
> use it when we know we reload the module. So it will only apply to
> ldlinux.c32. While most modules could benefit from this as the new
> config file will probably reload the same menu and libraries.
> 
Libraries shouldn't need it; they can simply stay in memory.  For
executables one could do such initialization before invoking the entry
point.

	-hpa

2016-01-25 21:03 UTC+01:00, H. Peter Anvin <hpa at
zytor.com>:
> On 01/25/16 10:51, Celelibi wrote:
>>
>> Do you suggest to do this only for ldlinux.c32?
>>
>> If we keep a copy only of the data section, we will only be able to
>> use it when we know we reload the module. So it will only apply to
>> ldlinux.c32. While most modules could benefit from this as the new
>> config file will probably reload the same menu and libraries.
>>
>
> Libraries shouldn't need it; they can simply stay in memory.  For
> executables one could do such initialization before invoking the entry
> point.
>
> 	-hpa
Do you mean executables should also stay in memory and just get a
fast-reinitialization when re-running them?

However, unless we do something more heavy-weight, when a config file
is loaded, I guess all modules will have to be unloaded anyway since
the search path can be changed by the new config file and other
modules with the same name can be loaded.

BTW, can ldlinux.c32 be affected by the PATH directive or another
configuration option?


Celelibi