linux-kernel - Re: [PATCH v1] dynamic_debug: add support for logs destination

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: <CAJfuBxytOcUDmPBO7uQ9mMRvpNvzA3tgg_-pSGmdXpjDPe5sNQ@mail.gmail.com>
Date:   Thu, 12 Oct 2023 12:48:28 -0600
From:   jim.cromie@...il.com
To:     Pekka Paalanen <ppaalanen@...il.com>, jim.cromie@...il.com,
        Łukasz Bartosik <lb@...ihalf.com>,
        linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        "wayland-devel@...ts.freedesktop.org" 
        <wayland-devel@...ts.freedesktop.org>,
        Sean Paul <seanpaul@...omium.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v1] dynamic_debug: add support for logs destination

> If you want the kernel to keep separate flight recorders I guess we could
> add that, but I don't think it currently exists for the dyndbg stuff at
> least. Maybe a flight recorder v2 feature, once the basics are in.
>

dyndbg has   +p    writes to syslog
+T  would separately independently write the same to global trace

This would allow  graceful switchover to tracefs,
without removing logging from dmesg, where most folks
(and any monitor tools) would expect it.

Lukas (iiuc) wants to steer each site to just 1 destination.
Or maybe (in addition to +p > syslog) one trace destination,
either global via events, or a separate tracebuf

Im ambivalent, but thinking the smooth rollover from syslog to trace
might be worth having to ease migration / weaning off syslog.

And we have a 4 byte hole in struct _ddebug we could just use.
Unless the align 8 is optional on 32-bits,
I think we're never gonna close the hole anywhere.

is align 8 a generic expression of an architectural simplifying constraint ?
or a need for 1-7 ptr offsets ?

> > That's my idea of it. It is interesting to see how far the requirements
> > can be reasonably realised.
>
> I think aside from the "make it available directly to unpriviledged
> userspace" everything sounds reasonable and doable.
>
> More on the process side of things, I think Jim is very much looking for
> acks and tested-by by people who are interested in better drm logging
> infra. That should help that things are moving in a direction that's
> actually useful, even when it's not yet entirely complete.
>

yes, please.  Now posted at

https://lore.kernel.org/lkml/20231012172137.3286566-1-jim.cromie@gmail.com/T/#t

Lukas, I managed to miss your email in the send phase.
please consider yourself a direct recipient :-)

thanks everyone

> Cheers, Sima
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch