On 07/01/22(Fri) 10:54, Sebastien Marie wrote:
> Hi,
>
> Debugging some code paths is complex: for example, unveil(2) code is
> involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> spamming printf() for all processes using unveil(2) (a lot of
> processes) instead of just the
> I agree, but the intent is replacing a debugging method with another
> debugging method (hoping it is more useful). The messages showed here
> are the same that the ones which would be shown on the console before
> the diff.
the thing about the kernel messages, is you see the pointers and you
> If this gets added, more care is needed with the messages. For example,
> kernel memory addresses should not be shown because they are privileged
> information.
No kidding. We spent a decade cleaning that up, and don't want to go back
to exposing.
On Fri, Jan 07, 2022 at 11:06:30AM +, Visa Hankala wrote:
> On Fri, Jan 07, 2022 at 10:54:54AM +0100, Sebastien Marie wrote:
> > Debugging some code paths is complex: for example, unveil(2) code is
> > involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> > spamming printf()
On Fri, Jan 07, 2022 at 10:54:54AM +0100, Sebastien Marie wrote:
> Debugging some code paths is complex: for example, unveil(2) code is
> involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> spamming printf() for all processes using unveil(2) (a lot of
> processes) instead of
Hi,
Debugging some code paths is complex: for example, unveil(2) code is
involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
spamming printf() for all processes using unveil(2) (a lot of
processes) instead of just the interested cases I want to follow.
So I cooked the following
