[SLOF] [PATCH v2 07/11] libnet: Wire up pxelinux.cfg network booting

[Thomas Huth]

On 25.05.2018 07:27, Alexey Kardashevskiy wrote:
> On 25/5/18 2:42 pm, Thomas Huth wrote:
>> On 25.05.2018 04:44, Alexey Kardashevskiy wrote:
>>> On 25/5/18 12:39 am, Thomas Huth wrote:
>>>> On 24.05.2018 11:01, Alexey Kardashevskiy wrote:
>> [...]
>>>>>  And why static?
>>>>
>>>> Allocating big buffers on the stack is always critical within paflof,
>>>> we've seen more than enough buffer overruns in the past already. But I
>>>> could malloc() the buffer instead if you prefer that.
>>>
>>> It is just 2KB, is it still too much for slof? And when it is static - this
>>> space is always taken even if pxelinux is not used so malloc seems
>>> appropriate here.
>>
>> Yeah, stack size is very, very sensitive, since a lot of code is calling
>> engine() recursively, and this uses quite some bit of stack space each
>> time. See commits 8c41240bc4e9, 271fd45605c11, baa834884c90, ... for
>> example.
>>
>> So I'll try to switch to malloc here instead.
> 
> 
> May be then embed cfgbuf/cfgsize into "lkia" so it is obvious lkia's
> entries point into this cfgbuf?
> 
> struct pxe_cfg {
>     struct {
>         const char *label;
>         const char *kernel;
>         const char *initrd;
>         const char *append;
>     } lkia[MAX_LKIA_ENTRIES];
>     unsigned entries;
>     unsigned default;
>     char buf[CFG_BUF_SIZE];
> };
> 
> and malloc/free that?

No, I'd like to keep the buffer and lkia handling separate (since
that'll fit the handling in the s390-ccw bios better).

Just let me add a proper comment in the code that the buffer needs to
remain valid for the lkia pointers, then I think it should be fine.

>> PS:
>> By the way, something for our TODO lists: We really should add some
>> logic to the libc free() function to merge freed memory blocks again if
>> possible...
> 
> Do you have any measurements of how much loose on this?

No. Since we scarcely used malloc and free in the SLOF code in the past,
this also was never an issue. But if we now add more and more code that
uses malloc + free, we should keep this in mind and be prepared to face
out-of-memory problems one day due to the memory fragmentation here.

 Thomas