Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp350319ybi; Fri, 21 Jun 2019 00:30:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqwcnHUV5t0Tv1NncrS2eYNOlF3kcwZGprNlQNYyrcG15hC8fYLhP88aMpsTIRacAv11h5XU X-Received: by 2002:a17:90a:7107:: with SMTP id h7mr4617453pjk.38.1561102200405; Fri, 21 Jun 2019 00:30:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561102200; cv=none; d=google.com; s=arc-20160816; b=BfXcr4/vZ42vZho5vjT5g9hwwJPElwsmmI4DetMZHQ7zS9y9a4JCEni9rp2Sxwe0SY E/kGaZDpKc4thfChS2xLiVZ2IG0wmaFww+J1wT4e3WdWymr+WAnyXDZOFLI4LoGAGA7P nXqPyiPCECNBOZtmuo+PyvfIQER7y8+a0uiB3LrdsngFl1Fq7LfbMulkelyHHp/LWROQ QUBw1GNtTP1aKVLeOuJmlY3knrT8BdQ5LJUrfz8Gfw0plgaOqPq9MEQ4m9Av8w4ZTncV 10isGBKpZ3s8V4ik7/O3PU/YBRUpLfK3JK5NDEzdM7G0T320gXFYMTql+piSEBVUv5uB wlbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature; bh=KWunAFlCxEWhds1SkDjosYr9MuirTCm/rY6FBrtUqBQ=; b=IcCZnKR3wXc/eFHATJUfBLXRgP5ot07LdQELea7h4pJ4BnKrZcu7+5QG8jQtGoLLW6 IvdC/zDlAFWX7VH5SPRntElv5Bu6rMHvtu4EJ4dF7anmI7JqbjsFOeu5cQn80iW4YbyB B493TSm5zPg01OEqgVTA5HsCUwDt8Thaq5HLxmSs2eyfFgBJyWdqf4RWvgS50ZRVYXvc 6GYRETU8YIUKFbztXY/uDgYc0jzB9SUKEj+GvCTQjLYuDlOh5cWhu7P+hWg+n9qksz+N 1xuR8FVfVrWEAJyzPjH32mrBDJpUioOlHhULgoUp4/XUZoWDyxDbNuWW9CEWW0NxiXS2 0BWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=y41jUmAO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si1910125pld.6.2019.06.21.00.29.44; Fri, 21 Jun 2019 00:30:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=y41jUmAO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726241AbfFUH3P (ORCPT + 99 others); Fri, 21 Jun 2019 03:29:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:47998 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726025AbfFUH3O (ORCPT ); Fri, 21 Jun 2019 03:29:14 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 16E9D208C3; Fri, 21 Jun 2019 07:29:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561102153; bh=kPwFEjWK93xycgmBhsOnGfFIY99Nc6Bkb8Tptor+iqs=; h=Date:From:To:Cc:Subject:From; b=y41jUmAOSMnjkujPbnGkQf0zhRwU2Je97kQwG2jtH13S07da1Dmedk5OCCnfN0dsP L3UuM3nclZUdf6qnbGhOaQxa9KMPxh2DDh7B7RbyC0s+yTiG8N6sdeSeTS3f4V1Xrf aakaUfGwqNs+2LbC6oyPvendd31cETNHqhMwZrmo= Date: Fri, 21 Jun 2019 09:29:11 +0200 From: Greg KH To: Rajat Jain Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: PCI/AER sysfs files violate the rules of how sysfs works Message-ID: <20190621072911.GA21600@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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//aer_dev_correctable and /sys/bus/pci/devices//aer_dev_fatal and /sys/bus/pci/devices//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