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: <3cbaf905.ef7.196b82bdcc9.Coremail.00107082@163.com>
Date: Sat, 10 May 2025 11:10:04 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Suren Baghdasaryan" <surenb@...gle.com>
Cc: "Tim Chen" <tim.c.chen@...ux.intel.com>, kent.overstreet@...ux.dev,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH v2 2/2] alloc_tag: keep codetag iterator active between
 read() calls


At 2025-05-10 05:15:43, "Suren Baghdasaryan" <surenb@...gle.com> wrote:
>On Fri, May 9, 2025 at 1:46 PM Suren Baghdasaryan <surenb@...gle.com> wrote:
>>
>> On Fri, May 9, 2025 at 12:46 PM Tim Chen <tim.c.chen@...ux.intel.com> wrote:
>> >
>> > On Fri, 2025-05-09 at 12:36 -0700, Suren Baghdasaryan wrote:
>> > > On Fri, May 9, 2025 at 11:33 AM Tim Chen <tim.c.chen@...ux.intel.com> wrote:
>> > > >
>> > > > On Sat, 2025-05-10 at 01:39 +0800, David Wang wrote:
>> > > > >
>> > > > >
>> > > > > Signed-off-by: David Wang <00107082@....com>
>> > >
>> > > Acked-by: Suren Baghdasaryan <surenb@...gle.com>
>> > >
>> > > > > ---
>> > > > >  lib/alloc_tag.c | 29 ++++++++++-------------------
>> > > > >  1 file changed, 10 insertions(+), 19 deletions(-)
>> > > > >
>> > > > > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>> > > > > index 25ecc1334b67..fdd5887769a6 100644
>> > > > > --- a/lib/alloc_tag.c
>> > > > > +++ b/lib/alloc_tag.c
>> > > > > @@ -45,21 +45,16 @@ struct allocinfo_private {
>> > > > >  static void *allocinfo_start(struct seq_file *m, loff_t *pos)
>> > > > >  {
>> > > > >       struct allocinfo_private *priv;
>> > > > > -     struct codetag *ct;
>> > > > >       loff_t node = *pos;
>> > > > >
>> > > > > -     priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> > > > > -     m->private = priv;
>> > > > > -     if (!priv)
>> > > > > -             return NULL;
>> > > > > -
>> > > > > -     priv->print_header = (node == 0);
>> > > > > +     priv = (struct allocinfo_private *)m->private;
>> > > > >       codetag_lock_module_list(alloc_tag_cttype, true);
>> > > > > -     priv->iter = codetag_get_ct_iter(alloc_tag_cttype);
>> > > > > -     while ((ct = codetag_next_ct(&priv->iter)) != NULL && node)
>> > > > > -             node--;
>> > > > > -
>> > > > > -     return ct ? priv : NULL;
>> > > > > +     if (node == 0) {
>> > > > > +             priv->print_header = true;
>> > > > > +             priv->iter = codetag_get_ct_iter(alloc_tag_cttype);
>> > > > > +             codetag_next_ct(&priv->iter);
>> > > > > +     }
>> > > >
>> > > > Do you need to skip print header when *pos != 0? i.e add
>> > >
>> > > Technically not needed since proc_create_seq_private() allocates
>> > > seq->private using kzalloc(), so the initial value of
>> > > priv->print_header is always false.
>> >
>> > But we'll start with first call to allocinfo_start() with *pos == 0,
>>
>> Usually but not always if we do lseek() to a non-zero position beforehand.
>
>Actually, this change will break the lseek() case. We can't always
>assume that we start reading from *pos == 0. Current patch will fail
>to initialize priv if we start reading with *pos != 0.
>priv->iter should be tracking current position and allocinfo_start()
>should detect a mismatch between *pos and iter->pos and re-walk the
>tags if there was a position change.

seq_file works line by line,  I think even if it support lseek, seq_file would still start with line #0,
since seq_file have on clue the byte size for each line.

I will check the code,  make some tests and update later.


>
>>
>> > then print_header will be initialized to true.
>>
>> After the first call to allocinfo_show() print_header will be reset
>> back to false.
>>
>> > Will there be subsequent calls of allocinfo_start() with *pos !=0,
>> > but priv->print_header stays at 0?
>>
>> Yes, there will be subsequent calls to allocinfo_start() with *pos !=0
>> and priv->print_header=false, which is what we want, right? We want to
>> print the header only at the beginning of the file (node == 0).
>>
>> >
>> > Tim
>> > >
>> > > >
>> > > >         } else {
>> > > >                 priv->print_header = false;
>> > > >         }
>> > > >
>> > > > Tim
>> > > >
>> > > > > +     return priv->iter.ct ? priv : NULL;
>> > > > >  }
>> > > > >
>> > > >
>> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ