From: "Luck, Tony" <tony.luck@intel.com>
To: Yicong Yang <yangyicong@hisilicon.com>
Cc: viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
David.Laight@aculab.com, linux-fsdevel@vger.kernel.org,
akinobu.mita@gmail.com, linux-kernel@vger.kernel.org,
linuxarm@huawei.com, prime.zeng@huawei.com
Subject: Re: [PATCH v3] libfs: fix error cast of negative value in simple_attr_write()
Date: Thu, 3 Jun 2021 09:09:04 -0700 [thread overview]
Message-ID: <20210603160904.GA983893@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <1605341356-11872-1-git-send-email-yangyicong@hisilicon.com>
On Sat, Nov 14, 2020 at 04:09:16PM +0800, Yicong Yang wrote:
> The attr->set() receive a value of u64, but simple_strtoll() is used
> for doing the conversion. It will lead to the error cast if user inputs
> a negative value.
>
> Use kstrtoull() instead of simple_strtoll() to convert a string got
> from the user to an unsigned value. The former will return '-EINVAL' if
> it gets a negetive value, but the latter can't handle the situation
> correctly. Make 'val' unsigned long long as what kstrtoull() takes, this
> will eliminate the compile warning on no 64-bit architectures.
>
> Fixes: f7b88631a897 ("fs/libfs.c: fix simple_attr_write() on 32bit machines")
> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
> ---
> Change since v1:
> - address the compile warning for non-64 bit platform.
> Change since v2:
> Link: https://lore.kernel.org/linux-fsdevel/1605000324-7428-1-git-send-email-yangyicong@hisilicon.com/
> - make 'val' unsigned long long and mentioned in the commit
> Link: https://lore.kernel.org/linux-fsdevel/1605261369-551-1-git-send-email-yangyicong@hisilicon.com/
Belated error report on this. Some validation team just moved to
v5.10 and found their error injection scripts no longer work.
They have been using:
# echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2
to write the mask value 0xfffffffffffff000 for many years ... but
now writing a negative value (-4096) to this file gives an EINVAL error.
Maybe they've been taking advantage of a bug all this time? The
comment for debugfs_create_x64() says it is for reading/writing
an unsigned value. But when a bug fix breaks user code ... then
we are supposed to ask whether that bug is actually a feature.
If there was a debugfs_create_s64() I might just fix einj.c to
use that ... but there isn't :-(
-Tony
next prev parent reply other threads:[~2021-06-03 16:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 8:09 [PATCH v3] libfs: fix error cast of negative value in simple_attr_write() Yicong Yang
2021-06-03 16:09 ` Luck, Tony [this message]
2021-06-07 9:26 ` Yicong Yang
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=20210603160904.GA983893@agluck-desk2.amr.corp.intel.com \
--to=tony.luck@intel.com \
--cc=David.Laight@aculab.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=prime.zeng@huawei.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yangyicong@hisilicon.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.