All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Faiyaz Mohammed <faiyazm@codeaurora.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 1/1] mm/slub: fix endless "No data" printing for alloc/free_traces attribute
Date: Thu, 25 Nov 2021 17:13:10 +0100	[thread overview]
Message-ID: <20211125171310.0fd27afa@thinkpad> (raw)
In-Reply-To: <a081d544-41f0-29ab-6d46-1afa382af8be@suse.cz>

On Tue, 23 Nov 2021 15:19:49 +0100
Vlastimil Babka <vbabka@suse.cz> wrote:

> On 11/22/21 21:33, Gerald Schaefer wrote:
> > On Mon, 22 Nov 2021 21:14:00 +0100
> > Gerald Schaefer <gerald.schaefer@linux.ibm.com> wrote:
> > 
> > [...]
> >> 
> >> Thanks. While testing this properly, yet another bug showed up. The idx
> >> in op->show remains 0 in all iterations, so I always see the same line
> >> printed t->count times (or infinitely, ATM). Not sure if this only shows
> >> on s390 due to endianness, but the reason is this:
> >> 
> >>   unsigned int idx = *(unsigned int *)v;
> 
> Uh, good catch. I was actually looking suspiciously at how we cast signed to
> unsigned, but didn't occur to me that shortening together with endiannes is
> the problem.
> 
> >> 
> >> IIUC, void *v is always the same as loff_t *ppos, and therefore idx also
> >> should be *ppos. De-referencing the loff_t * with an unsigned int * only
> >> gives the upper 32 bit half of the 64 bit value, which remains 0.
> >> 
> >> This would be fixed e.g. with
> >> 
> >>   unsigned int idx = (unsigned int) *(loff_t *) v;
> 
> With all this experience I'm now inclined to rather follow more the example
> in Documentation/filesystems/seq_file.rst and don't pass around the pointer
> that we got as ppos in slab_debugfs_start(), and that seq_file.c points to
> m->index.
> 
> In that example an own value is kmalloced:
> 
> loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);
> 
> while we could just make this a field of loc_track?

Yes, following the example sounds good, and it would also make proper use
of *v in op->next, which might make the code more readable. It also looks
like it already does exactly what is needed here, i.e. have a simple
iterator that just counts the lines.

I don't think the iterator needs to be saved in loc_track. IIUC, it is
already passed around like in the example, and can then be simply compared
to t->count, similar to the existing code.

This is what I'm currently testing, and it seems to work fine. Will send
a new patch, if there are no objections:

---
 mm/slub.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index a8626825a829..effb7b8d8f88 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -6052,10 +6052,9 @@ __initcall(slab_sysfs_init);
 #if defined(CONFIG_SLUB_DEBUG) && defined(CONFIG_DEBUG_FS)
 static int slab_debugfs_show(struct seq_file *seq, void *v)
 {
-
-	struct location *l;
-	unsigned int idx = *(unsigned int *)v;
 	struct loc_track *t = seq->private;
+	loff_t idx = *(loff_t *) v;
+	struct location *l;
 
 	if (idx < t->count) {
 		l = &t->loc[idx];
@@ -6099,23 +6098,29 @@ static int slab_debugfs_show(struct seq_file *seq, void *v)
 
 static void slab_debugfs_stop(struct seq_file *seq, void *v)
 {
+	kfree(v);
 }
 
 static void *slab_debugfs_next(struct seq_file *seq, void *v, loff_t *ppos)
 {
 	struct loc_track *t = seq->private;
+	loff_t *idxp = (loff_t *) v;
 
-	v = ppos;
-	++*ppos;
-	if (*ppos <= t->count)
-		return v;
+	*ppos = ++(*idxp);
+	if (*idxp <= t->count)
+		return idxp;
 
 	return NULL;
 }
 
 static void *slab_debugfs_start(struct seq_file *seq, loff_t *ppos)
 {
-	return ppos;
+	loff_t *idxp = kmalloc(sizeof(loff_t), GFP_KERNEL);
+
+	if (!idxp)
+		return NULL;
+	*idxp = *ppos;
+	return idxp;
 }
 
 static const struct seq_operations slab_debugfs_sops = {
-- 
2.32.0


  reply	other threads:[~2021-11-25 16:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 19:39 [RFC PATCH 0/1] mm/slub: endless "No data" printing for alloc/free_traces attribute Gerald Schaefer
2021-11-17 19:39 ` [RFC PATCH 1/1] mm/slub: fix " Gerald Schaefer
2021-11-19 10:41   ` Vlastimil Babka
2021-11-19 19:59     ` Gerald Schaefer
2021-11-22 15:02       ` Vlastimil Babka
2021-11-22 20:14         ` Gerald Schaefer
2021-11-22 20:33           ` Gerald Schaefer
2021-11-23 14:19             ` Vlastimil Babka
2021-11-25 16:13               ` Gerald Schaefer [this message]
2021-11-25 20:12                 ` Gerald Schaefer
2021-11-25 22:00                   ` Vlastimil Babka
2021-11-26 17:11                     ` Gerald Schaefer
2021-11-26 17:18                     ` [PATCH] mm/slub: fix endianness bug for alloc/free_traces attributes Gerald Schaefer
2021-11-29 14:26                       ` Vlastimil Babka
2021-11-19  9:43 ` [RFC PATCH 0/1] mm/slub: endless "No data" printing for alloc/free_traces attribute Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211125171310.0fd27afa@thinkpad \
    --to=gerald.schaefer@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=faiyazm@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.