Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220212130410.6901-1-ojeda@kernel.org> <20220212130410.6901-13-ojeda@kernel.org>
 <YgosclY9ebD3t020@smile.fi.intel.com> <dc9054f2-5e2b-0ae2-1022-23421668dd05@rasmusvillemoes.dk>
 <2a7dff8e0efb4142849802357284af51@AcuMS.aculab.com>
In-Reply-To: <2a7dff8e0efb4142849802357284af51@AcuMS.aculab.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Mon, 14 Feb 2022 15:04:47 +0100
Message-ID: <CANiq72mVsvfdyw8=OtSVbZqm43kjnH2+fUg40_j96BkdM0RtVQ@mail.gmail.com>
Subject: Re: [PATCH v4 12/20] vsprintf: add new `%pA` format specifier
To:     David Laight <David.Laight@aculab.com>
Cc:     Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Miguel Ojeda <ojeda@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Gary Guo <gary@garyguo.net>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Wedson Almeida Filho <wedsonaf@google.com>,
        Petr Mladek <pmladek@suse.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Feb 14, 2022 at 12:37 PM David Laight <David.Laight@aculab.com> wrote:
>
> Doesn't that stand a reasonable chance of blowing the kernel stack?
>
> vsnprintf() is likely to be on the 'worst case' stack path anyway.
> Anything vaguely like a recursive call, or anything 'stack expensive'
> inside vsnprintf() stands a real chance of overflowing the stack.

There should be no recursion going on, but stack usage could be a
concern depending on what the formatted types attempt to do (thus we
need to be mindful when implementing `Display`) and what the compiler
could possibly generate on a worst case (Gary, bjorn3 et. al. may want
to give details about this).

Cheers,
Miguel