linux-kernel - Re: [PATCH v2 0/4] debugfs: Add simple min/max "files" to debugfs to fix sched debug code.

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: <2023053025-blinks-vexingly-60d3@gregkh>
Date:   Tue, 30 May 2023 21:18:21 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     chris hyser <chris.hyser@...cle.com>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v2 0/4] debugfs: Add simple min/max "files" to debugfs to
 fix sched debug code.

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