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

[Greg Kurz]

On Fri, 25 May 2018 07:42:53 +0200
Thomas Huth <thuth at redhat.com> wrote:

> 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.
> 

It looks like some memory defragmentation logic already exists but it is
only used during malloc() when the heap is full. Isn't this enough ?

>  Thomas