linux-kernel - Re: [PATCH for-next] scsi: Implement host state statistics

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]

Date:   Wed, 15 Mar 2023 07:48:58 -0400
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "Seymour, Shane M" <shane.seymour@....com>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH for-next] scsi: Implement host state statistics

On Wed, 2023-03-15 at 07:36 +0100, Greg KH wrote:
> On Wed, Mar 15, 2023 at 06:08:19AM +0000, Seymour, Shane M wrote:
> > The following patch implements host state statistics via sysfs. The
> > intent is to allow user space to see the state changes and be able
> > to report when a host changes state. The files do not separate out
> > the time spent into each state but only into three:
> 
> Why does userspace care about these things at all?

This is the most important question: Why are times spent in various
states and transition counts important?  Is this some kind of
predictive failure system, or is it simply logging? If it's logging,
wouldn't you get better information if we output state changes as they
occur then they'd appear as timestamped entries in the syslog from
which all these statistics could be deduced?

>   What tool needs them and what can userspace do with the
> information?
> > 
[...]
> > A (GPLv2) program called hostmond will be released in a few months
> > that will monitor these interfaces and report (local host only via
> > syslog(3C)) when hosts change state.
> 
> We kind of need to see this before the kernel changes can be accepted
> for obvious reasons, what is preventing that from happening now?

I don't think that's a requirement.  The whole point of sysfs is it's
user readable, so we don't need a tool to make use of its entries.  On
the other hand if this tool can help elucidate the use case for these
statistics, then publishing it now would be useful to help everyone
else understand why this is useful.

James