linux-kernel - Re: [PATCH 1/2] lib/strtox: introduce kstrtoull

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cb6fe9e6-6869-46d5-8826-19ed5b5c439f@suse.com>
Date: Wed, 20 Dec 2023 20:31:09 +1030
From: Qu Wenruo <wqu@...e.com>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-btrfs@...r.kernel.org,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] lib/strtox: introduce kstrtoull_suffix() helper



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

Download attachment "OpenPGP_0xC23D91F3A125FEA8.asc" of type "application/pgp-keys" (6918 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)