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

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

On January 26, 2016 5:46:25 PM PST, Celelibi <celelibi at gmail.com>
wrote:
>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
Yes, we could expire them, and that probably would make sense once we cross a
certain memory threshold.  The big question is if that would ever actually
happen.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

2016-01-27 3:06 UTC+01:00, H. Peter Anvin <hpa at
zytor.com>:
> On January 26, 2016 5:46:25 PM PST, Celelibi <celelibi at gmail.com>
wrote:
>>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
>
> Yes, we could expire them, and that probably would make sense once we cross
> a certain memory threshold.  The big question is if that would ever
actually
> happen.
I'm not really comfortable about making the assumption that we have a
lot of memory available. I'm far from knowing all the use cases of
syslinux.


Celelibi