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
Subject: [PATCH 0/3] kstrtox: introduce memparse_safe()
Date: Sat, 23 Dec 2023 20:28:04 +1030 [thread overview]
Message-ID: <cover.1703324146.git.wqu@suse.com> (raw)
Function memparse() lacks error handling:
- If no valid number string at all
In that case @retptr would just be updated and return value would be
zero.
- No overflown detection
This applies to both the number string part, and the suffixes part.
And since we have no way to indicate errors, we can get weird results
like:
"25E" -> 10376293541461622784 (9E)
This is due to the fact that for "E" suffix, there is only 4 bits
left, and 25 with 60 bits left shift would lead to overflow.
(And decision to support for that "E" suffix is already cursed)
So here we introduce a safer version of it: memparse_safe(), and mark
the original one deprecated.
Unfortunately I didn't find a good way to mark it deprecated, as with
recent -Werror changes, '__deprecated' marco does not seem to warn
anymore.
The new helper has the following advantages:
- Better overflow and invalid string detection
The overflow detection is for both the numberic part, and with the
suffix. Thus above "25E" would be rejected correctly.
The invalid string part means if there is no valid number starts at
the buffer, we return -EINVAL.
- Allow caller to select the suffixes, and saner default ones
The new default one would be "KMGTP", without the cursed and overflow
prone "E".
Some older code like setup_elfcorehdr() would benefit from it, if the
code really wants to only allow "KMG" suffixes.
- Keep the old @retptr behavior
So the existing callers can easily migrate to the new one, without the
need to do extra strsep() work.
- Finally test cases
The test case would cover more things other than the existing kstrtox
tests:
* The @retptr behavior
Either for bad cases, which @retptr should not be touched,
or for good cases, the @retptr is properly advanced,
* Return value verification
Make sure we distinguish -EINVAL and -ERANGE correctly.
With the new helper, migrate btrfs to the interface, and since the
@retptr behavior is the same, we won't cause any behavior change.
Qu Wenruo (3):
kstrtox: introduce a safer version of memparse()
kstrtox: add unit tests for memparse_safe()
btrfs: migrate to the newer memparse_safe() helper
fs/btrfs/ioctl.c | 8 +-
fs/btrfs/super.c | 8 ++
fs/btrfs/sysfs.c | 14 ++-
include/linux/kernel.h | 8 +-
include/linux/kstrtox.h | 15 +++
lib/cmdline.c | 5 +-
lib/kstrtox.c | 96 ++++++++++++++++++
lib/test-kstrtox.c | 217 ++++++++++++++++++++++++++++++++++++++++
8 files changed, 364 insertions(+), 7 deletions(-)
--
2.43.0
next reply other threads:[~2023-12-23 9:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-23 9:58 Qu Wenruo [this message]
2023-12-23 9:58 ` [PATCH 1/3] kstrtox: introduce a safer version of memparse() Qu Wenruo
2023-12-27 13:26 ` David Disseldorp
2023-12-27 20:29 ` Qu Wenruo
2023-12-23 9:58 ` [PATCH 2/3] kstrtox: add unit tests for memparse_safe() Qu Wenruo
2023-12-26 6:36 ` kernel test robot
2023-12-26 7:37 ` Qu Wenruo
2024-01-02 1:33 ` Yujie Liu
2024-01-02 2:03 ` Qu Wenruo
2023-12-23 9:58 ` [PATCH 3/3] btrfs: migrate to the newer memparse_safe() helper Qu Wenruo
2023-12-26 4:53 ` kernel test robot
2023-12-26 6:06 ` kernel test robot
2023-12-27 6:27 ` David Disseldorp
2023-12-27 8:26 ` Qu Wenruo
2023-12-27 16:12 ` [PATCH 0/3] kstrtox: introduce memparse_safe() Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2023-12-27 15:00 Alexey Dobriyan
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.1703324146.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=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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