linux-kernel - Re: [PATCH v3 7/9] uio: add Xilinx user clock monitor support

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] [day] [month] [year] [list]

Message-ID: <D3T2KBEU0DMW.QA7Y6MLTQ3Y3@protonmail.com>
Date: Fri, 30 Aug 2024 07:31:42 +0000
From: Harry Austen <hpausten@...tonmail.com>
To: Stephen Boyd <sboyd@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Michael Turquette <mturquette@...libre.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Michal Simek <michal.simek@....com>, Shubhrajyoti Datta <shubhrajyoti.datta@....com>, Dave Ertman <david.m.ertman@...el.com>, Ira Weiny <ira.weiny@...el.com>, linux-clk@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 7/9] uio: add Xilinx user clock monitor support

On Thu Aug 29, 2024 at 7:17 PM BST, Stephen Boyd wrote:
> Quoting Greg Kroah-Hartman (2024-08-28 00:10:46)
> > On Tue, Aug 27, 2024 at 04:40:52PM -0700, Stephen Boyd wrote:
> > > Quoting Harry Austen (2024-08-27 12:08:52)
> > > > On Mon Aug 26, 2024 at 2:11 PM BST, Greg Kroah-Hartman wrote:
> > > > > Why do you want a UIO api for a clock device?  What userspace code is
> > > > > going to access the hardware this way?  Why not use the normal
> > > > > kernel/user apis instead?
> > > >
> > > > I was just trying to provide userspace access to these _unexpected_ clock
> > > > status event indications (clock stopped, underrun, overrun or glitched) and UIO
> >
> > That is going to be a brand-new user/kernel api that isn't documented
> > anywhere and will be unique to this one device.  Please don't do that.
> >
> > > Maybe unexpected events can be indicated through the EDAC subsystem,
> > > except that is usually about memory or cache errors, not device driver
> > > issues.
> >
> > If you all need a new way to report issues like this to userspace, then
> > let's create the correct api for it, don't require userspace to mmap a
> > random device and expect to poke around in it safely to get the
> > information.
> >
> > Odds are that mmap will change with the next version of this device,
> > right?
>
> Agreed. I'm wondering if we don't even need to invent anything new
> though and can simply use devcoredump. Harry?

I am not familiar with devcoredump, so will experiment with it for the user
clock monitor support. Thanks for the suggestion! In the mean time, I think it
might make more sense to split out the other _tidyup_ patches into a separate
patchset, so that can be merged separately first. Will do that next.

Thanks for the review!
Harry