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: <CAK8Bye+v+fYsN-716vQKJCoTmDQWmTw_Z1ZGD2A=HvuuAApwig@mail.gmail.com>
Date:   Mon, 16 Oct 2023 17:13:16 +0200
From:   Łukasz Bartosik <lb@...ihalf.com>
To:     jim.cromie@...il.com
Cc:     Pekka Paalanen <ppaalanen@...il.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

czw., 12 paź 2023 o 20:48 <jim.cromie@...il.com> napisał(a):
>
> > 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.

I'm glad you brought that up. This means we can leave class_id field
untouched, have separate +T in flags (for consistency)
and dst_id can be easily 8 bits wide.

Also can you point me to the latest version of writing debug logs to
trace events (+T option).
I would like to base trace instances work on that because both are
closely related.

> Unless the align 8 is optional on 32-bits,

I verified with "gcc -g -m32 ..." that the align(8) is honored 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