From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: akpm@linux-foundation.org, Dmitry Antipov <dmantipov@yandex.ru>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kstrtox: delete saturation in case of overflow
Date: Fri, 18 Sep 2026 09:19:44 +0300 [thread overview]
Message-ID: <aqzYAN30fpL7YfB_@ashevche-desk.local> (raw)
In-Reply-To: <a396f2ea-8de8-4eca-a216-ff69bc40fe85@p183>
On Thu, Sep 17, 2026 at 07:17:07PM +0300, Alexey Dobriyan wrote:
> From 161367fd1e8b41e938274923bbb3d26de69f7a7e Mon Sep 17 00:00:00 2001
> From: Alexey Dobriyan <adobriyan@gmail.com>
> Date: Thu, 17 Sep 2026 18:49:18 +0300
> Subject: [PATCH 1/1] kstrtox: delete saturation in case of overflow
Dunno if this is okay to have in the body. I think you need to use some korg
tools to send mails in a better way.
> Partially revert
>
> commit 6e30111dbb4075e3c26c230417b32bc4a1c66831
> lib: fix _parse_integer_limit() to handle overflow
The reference to the commit is standardized:
commit 6e30111dbb40 ("lib: fix _parse_integer_limit() to handle overflow")
> Originally, kstrto* was written in a way to keep simple_strto*()
> functions as is, so that they continue to return incorrect result
> if integer overflow occurs.
>
> Saturation doesn't do anything useful, it just creates second incorrect
> value and potentially breaks simple_strto*() users.
>
> Caller can decide to saturate itself anyway.
>
> Move saturation to memparse() from where the idea came from.
I don't see the use of this saturation, so perhaps we indeed can live without
it as before (note, I haven't checked any POSIX/C standards for the conversions,
dunno if they specify that kind of behaviour).
...
All above assuming that test cases are passed as before.
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2026-09-18 6:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 16:17 Alexey Dobriyan
2026-09-17 21:37 ` Andrew Morton
2026-09-18 6:19 ` Andy Shevchenko [this message]
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=aqzYAN30fpL7YfB_@ashevche-desk.local \
--to=andriy.shevchenko@linux.intel.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dmantipov@yandex.ru \
--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
all inboxes | Powered by JetHome®