All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Rajat Jain <rajatja@google.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: PCI/AER sysfs files violate the rules of how sysfs works
Date: Fri, 21 Jun 2019 09:29:11 +0200	[thread overview]
Message-ID: <20190621072911.GA21600@kroah.com> (raw)

Hi,

When working on some documentation scripts to show the
Documentation/ABI/ files in an automated way, I ran across this "gem" of
a sysfs file: Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats

In it you describe how the files
/sys/bus/pci/devices/<dev>/aer_dev_correctable and
/sys/bus/pci/devices/<dev>/aer_dev_fatal and
/sys/bus/pci/devices/<dev>/aer_dev_nonfatal
all display a bunch of text on multiple lines.

This violates the "one value per sysfs file" rule, and should never have
been merged as-is :(

Please fix it up to be a lot of individual files if your really need all
of those different values.

Remember, sysfs files should never have to have a parser to read them
other than a simple "what is this single value", and you should NEVER
have fun macros like:

        for (i = 0; i < ARRAY_SIZE(strings_array); i++) {               \
                if (strings_array[i])                                   \
                        str += sprintf(str, "%s %llu\n",                \
                                       strings_array[i], stats[i]);     \
                else if (stats[i])                                      \
                        str += sprintf(str, #stats_array "_bit[%d] %llu\n",\
                                       i, stats[i]);                    \
        }                                                               \
        str += sprintf(str, "TOTAL_%s %llu\n", total_string,            \
                       pdev->aer_stats->total_field);                   \

spit out sysfs information.

Note, I am all for not properly checking the length of the sysfs file
when writing to it, but that is ONLY because you "know" that a single
integer will never overflow anything.  Here you are writing a ton of
different values, with no error checking at all.  So just when I thought
it couldn't be any worse...

Please fix.

thanks,

greg k-h

             reply	other threads:[~2019-06-21  7:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21  7:29 Greg KH [this message]
2019-06-21 14:15 ` PCI/AER sysfs files violate the rules of how sysfs works Bjorn Helgaas
2019-06-21 14:44   ` Greg KH
2019-06-28  0:56   ` Rajat Jain
2019-06-28  8:44     ` Greg KH
     [not found] ` <CACK8Z6GeAheLfmPcYXNnrTn1Rg7C-rndi_YCxiLsePapGCMmzw@mail.gmail.com>
2019-06-21 14:45   ` Greg Kroah-Hartman

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=20190621072911.GA21600@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rajatja@google.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.