Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 25 Sep 2020 10:15:11 +0200
From:   Petr Mladek <pmladek@suse.com>
To:     Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        John Ogness <john.ogness@linutronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk 3/5] printk: use buffer pool for sprint buffers
Message-ID: <20200925081511.GK29288@alley>
References: <20200922153816.5883-1-john.ogness@linutronix.de>
 <20200922153816.5883-4-john.ogness@linutronix.de>
 <20200923151129.GC6442@alley>
 <20200924054058.GE577@jagdpanzerIV.localdomain>
 <20200924084555.GJ6442@alley>
 <20200924085343.GB541@jagdpanzerIV.localdomain>
 <a3a29f06-9ecc-ae21-c0fe-2f86fe31f780@prevas.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a3a29f06-9ecc-ae21-c0fe-2f86fe31f780@prevas.dk>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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