public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: 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,
	ddiss@suse.de, geert@linux-m68k.org, rdunlap@infradead.org
Subject: [PATCH v4 0/4] kstrtox: introduce memparse_safe()
Date: Fri,  5 Jan 2024 13:04:58 +1030	[thread overview]
Message-ID: <cover.1704422015.git.wqu@suse.com> (raw)

[CHANGELOG]
v4:
- Extra test cases for supported but not enabled suffixes

- Comments update for memparse_safe() function

v3:
- Fix the 32bit pointer pattern in the test case
  The old pointer pattern for 32 bit systems is in fact 40 bits,
  which would still lead to sparse warning.
  The newer pattern is using UINTPTR_MAX to trim the pattern, then
  converted to a pointer, which should not cause any trimmed bits and
  make sparse happy.

v2:
- Make _parse_integer_fixup_radix() to always treat "0x" as hex
  This is to make sure invalid strings like "0x" or "0xG" to fail
  as expected for memparse_safe().
  Or they would only parse the first 0, then leaving "x" for caller
  to handle.

- Update the test case to include above failure cases
  This including:
  * "0x", just hex prefix without any suffix/follow up chars
  * "0xK", just hex prefix and a stray suffix
  * "0xY", hex prefix with an invalid char

- Fix a bug in btrfs' conversion to memparse_safe()
  Where I forgot to delete the old memparse() line.

- Fix a compiler warning on m68K
  On that platform, a pointer (32 bits) is smaller than unsigned long long
  (64 bits), which can cause static checker to warn.


Qu Wenruo (4):
  kstrtox: always skip the leading "0x" even if no more valid chars
  kstrtox: introduce a safer version of memparse()
  kstrtox: add unit tests for memparse_safe()
  btrfs: migrate to the newer memparse_safe() helper

 arch/x86/boot/string.c  |   2 +-
 fs/btrfs/ioctl.c        |   6 +-
 fs/btrfs/super.c        |   9 +-
 fs/btrfs/sysfs.c        |  14 ++-
 include/linux/kernel.h  |   8 +-
 include/linux/kstrtox.h |  15 +++
 lib/cmdline.c           |   4 +-
 lib/kstrtox.c           | 101 ++++++++++++++++-
 lib/test-kstrtox.c      | 244 ++++++++++++++++++++++++++++++++++++++++
 9 files changed, 394 insertions(+), 9 deletions(-)

-- 
2.43.0


             reply	other threads:[~2024-01-05  2:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05  2:34 Qu Wenruo [this message]
2024-01-05  2:34 ` [PATCH v4 1/4] kstrtox: always skip the leading "0x" even if no more valid chars Qu Wenruo
2024-01-05  2:35 ` [PATCH v4 2/4] kstrtox: introduce a safer version of memparse() Qu Wenruo
2024-01-15  4:27   ` Randy Dunlap
2024-01-15  5:27     ` Qu Wenruo
2024-01-18 17:52       ` Randy Dunlap
2024-01-05  2:35 ` [PATCH v4 3/4] kstrtox: add unit tests for memparse_safe() Qu Wenruo
2024-01-05  2:35 ` [PATCH v4 4/4] btrfs: migrate to the newer memparse_safe() helper Qu Wenruo
2024-01-05 19:04   ` David Sterba
2024-01-06 14:35 ` [PATCH v4 0/4] kstrtox: introduce memparse_safe() Andy Shevchenko

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=cover.1704422015.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=ddiss@suse.de \
    --cc=geert@linux-m68k.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox