public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-btrfs@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] lib/strtox: introduce kstrtoull_suffix() helper
Date: Wed, 20 Dec 2023 20:31:09 +1030	[thread overview]
Message-ID: <cb6fe9e6-6869-46d5-8826-19ed5b5c439f@suse.com> (raw)
In-Reply-To: <b3ae8802-b4e0-4542-8fe0-e2d169944ac0@p183>


[-- Attachment #1.1.1: Type: text/plain, Size: 842 bytes --]



On 2023/12/20 20:24, Alexey Dobriyan wrote:
>> Just as mentioned in the comment of memparse(), the simple_stroull()
>> usage can lead to overflow all by itself.
> 
> which is the root cause...
> 
> I don't like one char suffixes. They are easy to integrate but then the
> _real_ suffixes are "MiB", "GiB", etc.
> 
> If you care only about memparse(), then using _parse_integer() can be
> arranged. I don't see why not.

Well, personally speaking I don't think we should even support the 
suffix at all, at least for the only two usage inside btrfs.

But unfortunately I'm not the one to do the final call, and the final 
call is to keep the suffix behavior...

And indeed using _parse_integer() with _parse_interger_fixup_radix() 
would be better, as we don't need to extend the _kstrtoull() code base.

Thanks,
Qu

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7027 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2023-12-20 10:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20  9:54 [PATCH 1/2] lib/strtox: introduce kstrtoull_suffix() helper Alexey Dobriyan
2023-12-20 10:01 ` Qu Wenruo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-12-20 14:24 Andy Shevchenko
2023-12-20 20:38 ` Qu Wenruo
2023-12-21 12:00   ` Andy Shevchenko
2023-12-21 20:37     ` Qu Wenruo
2023-12-21 20:55       ` Andy Shevchenko
2023-12-18 13:44 Andy Shevchenko
2023-12-15  8:39 [PATCH 0/2] lib/kstrtox: " Qu Wenruo
2023-12-15  8:39 ` [PATCH 1/2] lib/strtox: " Qu Wenruo
2023-12-18 12:59   ` David Disseldorp
2023-12-18 19:52     ` Qu Wenruo
2023-12-19  3:17       ` David Disseldorp
2023-12-19 16:42     ` David Laight
2023-12-19 21:17       ` Qu Wenruo
2023-12-20  8:31         ` David Laight
2023-12-20  9:32           ` Qu Wenruo

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=cb6fe9e6-6869-46d5-8826-19ed5b5c439f@suse.com \
    --to=wqu@suse.com \
    --cc=adobriyan@gmail.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 \
    /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