From: Greg KH <gregkh@linuxfoundation.org>
To: chris hyser <chris.hyser@oracle.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v2 0/4] debugfs: Add simple min/max "files" to debugfs to fix sched debug code.
Date: Tue, 30 May 2023 21:18:21 +0100 [thread overview]
Message-ID: <2023053025-blinks-vexingly-60d3@gregkh> (raw)
In-Reply-To: <20230530194012.44411-1-chris.hyser@oracle.com>
On Tue, May 30, 2023 at 03:40:08PM -0400, chris hyser wrote:
> v2:
> Apologies. I sent this the first time without including lkml.
>
> v1:
> This originally started as an attempt to solve a divide by zero issue in sched
> debug code that was introduced when a sysctl value with non-zero checking was
> moved to a simple u32 debugfs file. In looking at ways to solve this, it was
> mentioned I should look at providing general debugfs files with min/max
> checking.
>
> One problem was that a check for greater than zero for say a u8 succeeds for a
> number like 256 (but stores a zero anyway) as the upper bits that don't fit into
> storage are silently dropped. Therefore values greater than the storage capacity
> must also fail. Getting an error when what the user wrote is not what was
> actually stored, seems like a useful requirement for the other simple files and
> so I moved the check into there.
>
> To enable easy testing, a test module and test script are provided which can
> validate the new functions as well as check the new limits on the older
> functions. This was stuck under selftests, but it is not currently tied into the
> testing infrastructure.
This is a lot of new infrastructure for a single debugfs file that you
could just check for in the file write callback instead.
I'm all for cool new features, but wow, this seems like major overkill.
Are you _SURE_ you need it all?
thanks,
greg k-h
next prev parent reply other threads:[~2023-05-30 20:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 19:40 [PATCH v2 0/4] debugfs: Add simple min/max "files" to debugfs to fix sched debug code chris hyser
2023-05-30 19:40 ` [PATCH 1/4] debugfs: return EINVAL if write to unsigned simple files exceed storage chris hyser
2023-05-30 20:14 ` Greg KH
2023-05-30 21:20 ` chris hyser
2023-05-30 19:40 ` [PATCH 2/4] debugfs: Provide min/max checking for simple u8, u16, u32, u64 debugfs files chris hyser
2023-05-30 19:40 ` [PATCH 3/4] debugfs: provide testing for the min/max simple debug files chris hyser
2023-05-30 19:40 ` [PATCH 4/4] sched/numa: Fix divide by zero for sysctl_numa_balancing_scan_size chris hyser
2023-05-30 20:18 ` Greg KH [this message]
2023-05-30 21:41 ` [PATCH v2 0/4] debugfs: Add simple min/max "files" to debugfs to fix sched debug code chris hyser
2023-05-30 22:24 ` chris hyser
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=2023053025-blinks-vexingly-60d3@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=chris.hyser@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@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