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

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

On 01/26/16 06:55, Celelibi wrote:
> 
> Do you mean executables should also stay in memory and just get a
> fast-reinitialization when re-running them?
> 
Yes.  I hope that it would make things a lot faster, especially over the
network.  However, it wouldn't really matter in the common case of just
showing a menu and booting from there; now when we have hierarchical menus.
> 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.
Hm.  We could rather easily deal with that by storing the full path of
the module; that way we can distinguish them.
> BTW, can ldlinux.c32 be affected by the PATH directive or another
> configuration option?
Not at the moment, and I don't think it should be.  ldlinux.c32 is very
closely coupled with the bootstrap part of the bootloader itself.

	-hpa

2016-01-26 20:22 UTC+01:00, H. Peter Anvin <hpa at
zytor.com>:
> On 01/26/16 06:55, Celelibi wrote:
>>
>> Do you mean executables should also stay in memory and just get a
>> fast-reinitialization when re-running them?
>>
>
> Yes.  I hope that it would make things a lot faster, especially over the
> network.  However, it wouldn't really matter in the common case of just
> showing a menu and booting from there; now when we have hierarchical menus.
>
>> 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.
>
> Hm.  We could rather easily deal with that by storing the full path of
> the module; that way we can distinguish them.
>
That means modules will accumulate in memory. If we add a way to prune
the least recently used modules when memory is required, that become
quite close to the file system cache I had in mind with the solution
3. ^^ Except it's specialized for modules.

>> BTW, can ldlinux.c32 be affected by the PATH directive or another
>> configuration option?
>
> Not at the moment, and I don't think it should be.  ldlinux.c32 is very
> closely coupled with the bootstrap part of the bootloader itself.
Thanks, that's what I thought.


Celelibi