Received-SPF: pass (google.com: domain of linux-kernel+bounces-154216-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240422-kgdb_read_refactor-v2-0-ed51f7d145fe@linaro.org> <20240422-kgdb_read_refactor-v2-7-ed51f7d145fe@linaro.org>
In-Reply-To: <20240422-kgdb_read_refactor-v2-7-ed51f7d145fe@linaro.org>
From: Doug Anderson <dianders@chromium.org>
Date: Mon, 22 Apr 2024 16:52:52 -0700
Message-ID: <CAD=FV=XqSmD4WGyBp7Cv1i8X9yjk2gH1y2j_5qzkxtDL+GKv3g@mail.gmail.com>
Subject: Re: [PATCH v2 7/7] kdb: Simplify management of tmpbuffer in kdb_read()
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jason Wessel <jason.wessel@windriver.com>, kgdb-bugreport@lists.sourceforge.net, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Apr 22, 2024 at 9:38=E2=80=AFAM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> The current approach to filling tmpbuffer with completion candidates is
> confusing, with the buffer management being especially hard to reason
> about. That's because it doesn't copy the completion canidate into
> tmpbuffer, instead of copies a whole bunch of other nonsense and then
> runs the completion stearch from the middle of tmpbuffer!
>
> Change this to copy nothing but the completion candidate into tmpbuffer.
>
> Pretty much everything else in this patch is renaming to reflect the
> above change:
>
>     s/p_tmp/tmpbuffer/
>     s/buf_size/sizeof(tmpbuffer)/
>
> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> ---
>  kernel/debug/kdb/kdb_io.c | 40 +++++++++++++++++-----------------------
>  1 file changed, 17 insertions(+), 23 deletions(-)

Definitely an improvement.

Reviewed-by: Douglas Anderson <dianders@chromium.org>


> diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
> index 94a638a9d52fa..640208675c9a8 100644
> --- a/kernel/debug/kdb/kdb_io.c
> +++ b/kernel/debug/kdb/kdb_io.c
> @@ -227,8 +227,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
>         int count;
>         int i;
>         int diag, dtab_count;
> -       int key, buf_size, ret;
> -
> +       int key, ret;
>
>         diag =3D kdbgetintenv("DTABCOUNT", &dtab_count);
>         if (diag)
> @@ -310,21 +309,16 @@ static char *kdb_read(char *buffer, size_t bufsize)
>         case 9: /* Tab */
>                 if (tab < 2)
>                         ++tab;
> -               p_tmp =3D buffer;
> -               while (*p_tmp =3D=3D ' ')
> -                       p_tmp++;
> -               if (p_tmp > cp)
> -                       break;
> -               memcpy(tmpbuffer, p_tmp, cp-p_tmp);
> -               *(tmpbuffer + (cp-p_tmp)) =3D '\0';
> -               p_tmp =3D strrchr(tmpbuffer, ' ');
> -               if (p_tmp)
> -                       ++p_tmp;
> -               else
> -                       p_tmp =3D tmpbuffer;
> -               len =3D strlen(p_tmp);
> -               buf_size =3D sizeof(tmpbuffer) - (p_tmp - tmpbuffer);
> -               count =3D kallsyms_symbol_complete(p_tmp, buf_size);
> +
> +               tmp =3D *cp;
> +               *cp =3D '\0';
> +               p_tmp =3D strrchr(buffer, ' ');
> +               p_tmp =3D (p_tmp ? p_tmp + 1 : buffer);
> +               strscpy(tmpbuffer, p_tmp, sizeof(tmpbuffer));

You're now using strscpy() here. Is that actually important, or are
you just following good practices and being extra paranoid? If it's
actually important, this probably also needs to be CCed to stable,
right? The old code just assumed that it  could copy the whole buffer
into tmpbuffer. I assume that was OK, but it wasn't documented in the
function comments that there was a maximum size that buffer could
be...


-Doug