On Thu 2020-09-24 11:49:06, Rasmus Villemoes wrote: > On 24/09/2020 10.53, Sergey Senozhatsky wrote: > > On (20/09/24 10:45), Petr Mladek wrote: > >> On Thu 2020-09-24 14:40:58, Sergey Senozhatsky wrote: > >>> On (20/09/23 17:11), Petr Mladek wrote: > >>>> > >>>> AFAIK, there is one catch. We need to use va_copy() around > >>>> the 1st call because va_format can be proceed only once. > >>>> > >>> > >>> Current printk() should be good enough for reporting, say, "Kernel > >>> stack overflow" errors. Is extra pressure that va_copy() adds something > >>> that we need to consider? > >> > >> The thing is that vsprintf() traverses the arguments using va_arg(). > >> It modifies internal values so that the next va_arg() will read > >> the next value. > > > > Yes, I understand the purpose of va_copy(). I'm asking if we are > > always on the safe side doing va_copy for every printk (+ potential > > recursive va_copy-s). > > va_copy doesn't really add any extra stack use worth talking about. When > ABI says all arguments are passed on stack, va_list is just a pointer > into the arguments, and va_copy merely copies that pointer. When some > arguments are passed in register, the function prologue sets up a > "register save area" where those registers are stashed, and va_list then > contains two pointers: one to the reg save area, one to the place in the > stack where the rest of the arguments are, plus a bit of control > information on how many of the register arguments have been consumed so > far (and that control info is the only reason one must "reset" a > va_list, or rather use a copy that was made before consumption started). > In either case, an extra va_list doesn't cost more than 24 bytes or so > of stack - even if printk() was called with 100 arguments, those > 90-100ish arguments are only stored once on the stack.
Thanks a lot for the detailed information. It is good to know that va_copy() does not cost that much. Best Regards, Petr
