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: <6cdaf5a4-0043-5cde-9b48-06fb7c1fd9e2@maine.edu>
Date: Wed, 5 Feb 2025 10:06:55 -0500 (EST)
From: Vince Weaver <vincent.weaver@...ne.edu>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc: Vince Weaver <vincent.weaver@...ne.edu>, Ian Rogers <irogers@...gle.com>, 
    Stephane Eranian <eranian@...gle.com>, 
    "Liang, Kan" <kan.liang@...ux.intel.com>, 
    Alexander Shishkin <alexander.shishkin@...ux.intel.com>, 
    linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
    Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
    Arnaldo Carvalho de Melo <acme@...nel.org>, 
    Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>, 
    Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH] perf/core: move all of the pmu devices into their own
 location

On Wed, 5 Feb 2025, Greg Kroah-Hartman wrote:

> On Tue, Feb 04, 2025 at 08:21:17PM -0500, Vince Weaver wrote:
> > 
> > it doesn't matter if it's a one line change, your proposed change breaks 
> > userspace.
> 
> It breaks broken userspace :)

no, it breaks working code that's been working for 15 years, apparently on 
some whim by you.

I thought we didn't break userspace.

> > I thought the rule was Linux didn't break userspace.
> > Has that changed recently?
> 
> No, which is why I am working to fix these tools so that it will not be
> broken.

that... is some impressive doublethink.

> > libpfm4/PAPI are widely used and deployed and in some cases possibly 
> > statically linked into other projects.  It will take years for the change 
> > to filter out to all users.
> 
> Great, as it is easy to get this type of fix into the stable kernels,
> and then fix these tools, by the time those old systems eventually
> update to a newer kernel version, it should "just work".

no, that is the worst case scenario.  PAPI is installed on older systems, 
often custom non-vendor packages.  So if you get this into stable then 
these older RHEL systems the kernel will be updated suddenly breaking the 
users with no warning.

Even if we manage to get a change into libpfm4 and PAPI it will probably 
be months before the next stable release, and again people tend not to 
upgrade PAPI releases that often.


> I'm fixing up the bug where all of these devices accidentally got dumped
> into the root of the device tree in the system.

is this a "bug" or just you shuffling around files for no reason?

> Again, /sys/devices/ is NEVER guaranteed to have specific placement,
> that's the whole point of sysfs in the first place.  We can, and do,
> move devices around in there all the time (even every other boot), it's
> just that some tools accidentally didn't realize this and now need to be
> fixed.

great.  Slap a note about this happening in the appropriate "deprecated" 
file with a timeline of 5 years out or whatever, and then when that comes 
around then send your patch.

Vince Weaver
vincent.weaver@...ne.edu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ