linux-kernel - Re: [PATCH] mm/code_tag: Skip displaying the code

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: <CAJuCfpH-qXf7unhzr7PKY9iX0AcwDrpuKCoigQM+edV=AVYXJg@mail.gmail.com>
Date: Thu, 12 Dec 2024 18:44:34 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Zhenhua Huang <quic_zhenhuah@...cinc.com>
Cc: akpm@...ux-foundation.org, kent.overstreet@...ux.dev, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm/code_tag: Skip displaying the code_tag if it is not called

On Wed, Dec 11, 2024 at 11:50 PM Zhenhua Huang
<quic_zhenhuah@...cinc.com> wrote:
>
> Hi Suren,
>
> On 2024/12/12 15:16, Suren Baghdasaryan wrote:
> > On Wed, Dec 11, 2024 at 12:56 AM Zhenhua Huang
> > <quic_zhenhuah@...cinc.com> wrote:
> >>
> >> /proc/allocinfo is full of callsites which are not called at all.
> >> Let's only output if the callsite actually been invoked.
> >
> > No, I disagree. Allocation that was never invoked is not the same as
> > no allocation at all. How would we know the difference if we filter
>
> But it doesn't affect further display when it is actually called? why we
> need to know the diff here...
>
> The point from me is: up to now, the callsite hasn't been invoked, so it
> can be ignored in the output.. The original output is really huge..

My point is that with this change we lose information which can be
useful. For example if I want to analyze all the places in the kernel
where memory can be potentially allocated, your change would prevent
me from doing that.

>
> > out the empty ones?
> > If you don't want to see all the unused sites, you can filter them in
> > the userspace. I also suspect that for practical purposes you would
> > want to filter small ones (below some threshold) as well.
>
> Yeah, that's the expected way from us as well :)
>
> >
> >>
> >> Signed-off-by: Zhenhua Huang <quic_zhenhuah@...cinc.com>
> >> ---
> >>   lib/alloc_tag.c | 10 ++++++----
> >>   1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> >> index 35f7560a309a..06fb7eb5c0bc 100644
> >> --- a/lib/alloc_tag.c
> >> +++ b/lib/alloc_tag.c
> >> @@ -95,10 +95,12 @@ static void alloc_tag_to_text(struct seq_buf *out, struct codetag *ct)
> >>          struct alloc_tag_counters counter = alloc_tag_read(tag);
> >>          s64 bytes = counter.bytes;
> >>
> >> -       seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls);
> >> -       codetag_to_text(out, ct);
> >> -       seq_buf_putc(out, ' ');
> >> -       seq_buf_putc(out, '\n');
> >> +       if (bytes || counter.calls) {
> >> +               seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls);
> >> +               codetag_to_text(out, ct);
> >> +               seq_buf_putc(out, ' ');
> >> +               seq_buf_putc(out, '\n');
> >> +       }
> >>   }
> >>
> >>   static int allocinfo_show(struct seq_file *m, void *arg)
> >> --
> >> 2.25.1
> >>
>