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;
From:   John Ogness <john.ogness@linutronix.de>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        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>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH next v2 1/2] printk: avoid and/or handle record truncation
In-Reply-To: <20200930112836.GC29288@alley>
References: <20200930090134.8723-1-john.ogness@linutronix.de> <20200930090134.8723-2-john.ogness@linutronix.de> <20200930094316.GB987@jagdpanzerIV.localdomain> <87imbv1s0d.fsf@jogness.linutronix.de> <20200930112836.GC29288@alley>
Date:   Wed, 30 Sep 2020 13:48:56 +0206
Message-ID: <87ft6z1oe7.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 2020-09-30, Petr Mladek <pmladek@suse.com> wrote:
> Anyway, I see hardcoded limit more like a hack. It limits something
> somewhere so that some other code somewhere else is safe to use.
>
> And printk.c is really bad from this point. It sometimes does not
> check for overflow because it "knows" that the buffers are big
> enough. But it is error prone code, especially when there are more
> limits defined (pure text, prefix, extended prefix). And it
> will be worse if we allow to add more optional information
> into the prefix.

So should I post a v3 where the checks are added? Or should I add
comments where checks would be, explaining why the checks are not
needed?

John Ogness