All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, christophe.jaillet@wanadoo.fr,
	andriy.shevchenko@linux.intel.com, David.Laight@ACULAB.COM
Subject: Re: [PATCH v2 1/4] kstrtox: always skip the leading "0x" even if no more valid chars
Date: Wed, 3 Jan 2024 01:16:22 +1100	[thread overview]
Message-ID: <20240103011622.144d62d0@echidna> (raw)
In-Reply-To: <f905131c211685efa59dfa43ffb3a619a283f914.1704168510.git.wqu@suse.com>

On Tue,  2 Jan 2024 14:42:11 +1030, Qu Wenruo wrote:

> Currently the invalid string "0x" (only hex prefix, no valid chars
> followed) would make _parse_integer_fixup_radix() to treat it as octal.
> 
> This is due to the fact that the function would only auto-detect hex if
> and only if there is any valid hex char after "0x".
> Or it would only go octal instead.
> 
> Thankfully this won't affect our unit test, as "0x" would still be
> treated as failure.
> Since we treat the result as octal, the result value would be 0, leaving
> "x" as the tailing char and still fail kstrtox() functions.
> 
> But for the incoming memparse_safe(), the remaining string would still
> be consumed by the caller, and we need to properly treat "0x" as an
> invalid string.
> 
> So this patch would make _parse_integer_fixup_radix() to forcefully go
> hex no matter if there is any valid char following.
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  lib/kstrtox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
> index d586e6af5e5a..41c9a499bbf3 100644
> --- a/lib/kstrtox.c
> +++ b/lib/kstrtox.c
> @@ -27,7 +27,7 @@ const char *_parse_integer_fixup_radix(const char *s, unsigned int *base)
>  {
>  	if (*base == 0) {
>  		if (s[0] == '0') {
> -			if (_tolower(s[1]) == 'x' && isxdigit(s[2]))
> +			if (_tolower(s[1]) == 'x')
>  				*base = 16;
>  			else
>  				*base = 8;

There's a copy of this function in arch/x86/boot/string.c which should
probably remain consistent (or be removed). Aside from that, this looks
good to me:
Reviewed-by: David Disseldorp <ddiss@suse.de>

  reply	other threads:[~2024-01-02 14:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02  4:12 [PATCH v2 0/4] kstrtox: introduce memparse_safe() Qu Wenruo
2024-01-02  4:12 ` [PATCH v2 1/4] kstrtox: always skip the leading "0x" even if no more valid chars Qu Wenruo
2024-01-02 14:16   ` David Disseldorp [this message]
2024-01-02  4:12 ` [PATCH v2 2/4] kstrtox: introduce a safer version of memparse() Qu Wenruo
2024-01-02 14:19   ` David Disseldorp
2024-01-02  4:12 ` [PATCH v2 3/4] kstrtox: add unit tests for memparse_safe() Qu Wenruo
2024-01-02 13:23   ` Geert Uytterhoeven
2024-01-02 20:55     ` Qu Wenruo
2024-01-03  9:27       ` Geert Uytterhoeven
2024-01-03  9:45         ` Qu Wenruo
2024-01-02 14:17   ` David Disseldorp
2024-01-03 22:45     ` Qu Wenruo
2024-01-02  4:12 ` [PATCH v2 4/4] btrfs: migrate to the newer memparse_safe() helper Qu Wenruo
2024-01-02 14:24   ` David Disseldorp
2024-01-02 17:10 ` [PATCH v2 0/4] kstrtox: introduce memparse_safe() David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240103011622.144d62d0@echidna \
    --to=ddiss@suse.de \
    --cc=David.Laight@ACULAB.COM \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.