From: Paul Walmsley <pjw@kernel.org>
To: Josephine Pfeiffer <hi@josie.lol>
Cc: pjw@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro
Date: Sat, 25 Oct 2025 01:15:12 -0600 (MDT) [thread overview]
Message-ID: <ab17be2e-202e-e34e-21f8-c865aff4024f@kernel.org> (raw)
In-Reply-To: <20251019140711.63664-1-hi@josie.lol>
On Sun, 19 Oct 2025, Josephine Pfeiffer wrote:
> On Sat, 18 Oct 2025, Paul Walmsley wrote:
>
> > Hard to accept that it's a performance issue. But I think you're right
> > that generating a newline should be done with seq_puts().
>
> Fair point. I'll drop that from the commit message.
>
> > A better fix would seem to be to just get rid of pt_dump_seq_puts(). It's
> > only used once in arch/riscv.
> >
> > Taking a broader view, both pt_dump_seq_puts() and pt_dump_seq_printf()
> > look completely pointless. Is there any argument for keeping them?
>
> Good question. I investigated the git history and current usage:
>
> The macros were introduced in commit ae5d1cf358a5 ("arm64: dump: Make the
> page table dumping seq_file optional") to support passing NULL for the
> seq_file parameter. This is used by ptdump_check_wx() for CONFIG_DEBUG_WX,
> where the kernel walks page tables to check for writable+executable pages
> without outputting anything to userspace.
>
> All four architectures use this pattern in ptdump_check_wx():
>
> arch/arm64/mm/ptdump.c:341: .seq = NULL,
> arch/arm/mm/dump.c:456: .seq = NULL,
> arch/riscv/mm/ptdump.c:378: .seq = NULL,
> arch/s390/mm/dump_pagetables.c:197: .seq = NULL,
>
> However, you're right that the utility of these macros varies:
>
> Usage of pt_dump_seq_puts():
> - arm64: 1 use
> - ARM: 0 uses
> - riscv: 1 use
> - s390: 3 uses
>
> Note: ARM defines pt_dump_seq_puts() but never uses it - that macro
> could be removed entirely.
>
> Usage of pt_dump_seq_printf():
> - arm64: 6 uses
> - ARM: 7 uses
> - riscv: 6 uses
> - s390: 5 uses
>
> For RISC-V specifically, I agree the single use of pt_dump_seq_puts()
> could be replaced with an inline conditional. For pt_dump_seq_printf(),
> the macro does save some repetition (6 uses vs 1 macro definition).
>
> pt_dump_seq_printf() could also be questioned - removing it means 20+
> inline conditionals across all architectures. I focused on the minimal
> fix, but happy to tackle the larger refactor if preferred.
>
> Would you prefer:
>
> Option A) Remove pt_dump_seq_puts() entirely from riscv and replace the
> single use with:
> if (st->seq)
> seq_puts(st->seq, "\n");
>
> Option B) Keep the macro for consistency with other architectures, but
> fix the bug
>
> I'm happy to send a v2 with either approach. If Option A, I could also
> propose similar cleanups for arm64 (1 use) as a follow-up.
Thanks for investigating further. I just queued your original patch; I
think that's the simplest way forward.
- Paul
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Paul Walmsley <pjw@kernel.org>
To: Josephine Pfeiffer <hi@josie.lol>
Cc: pjw@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro
Date: Sat, 25 Oct 2025 01:15:12 -0600 (MDT) [thread overview]
Message-ID: <ab17be2e-202e-e34e-21f8-c865aff4024f@kernel.org> (raw)
In-Reply-To: <20251019140711.63664-1-hi@josie.lol>
On Sun, 19 Oct 2025, Josephine Pfeiffer wrote:
> On Sat, 18 Oct 2025, Paul Walmsley wrote:
>
> > Hard to accept that it's a performance issue. But I think you're right
> > that generating a newline should be done with seq_puts().
>
> Fair point. I'll drop that from the commit message.
>
> > A better fix would seem to be to just get rid of pt_dump_seq_puts(). It's
> > only used once in arch/riscv.
> >
> > Taking a broader view, both pt_dump_seq_puts() and pt_dump_seq_printf()
> > look completely pointless. Is there any argument for keeping them?
>
> Good question. I investigated the git history and current usage:
>
> The macros were introduced in commit ae5d1cf358a5 ("arm64: dump: Make the
> page table dumping seq_file optional") to support passing NULL for the
> seq_file parameter. This is used by ptdump_check_wx() for CONFIG_DEBUG_WX,
> where the kernel walks page tables to check for writable+executable pages
> without outputting anything to userspace.
>
> All four architectures use this pattern in ptdump_check_wx():
>
> arch/arm64/mm/ptdump.c:341: .seq = NULL,
> arch/arm/mm/dump.c:456: .seq = NULL,
> arch/riscv/mm/ptdump.c:378: .seq = NULL,
> arch/s390/mm/dump_pagetables.c:197: .seq = NULL,
>
> However, you're right that the utility of these macros varies:
>
> Usage of pt_dump_seq_puts():
> - arm64: 1 use
> - ARM: 0 uses
> - riscv: 1 use
> - s390: 3 uses
>
> Note: ARM defines pt_dump_seq_puts() but never uses it - that macro
> could be removed entirely.
>
> Usage of pt_dump_seq_printf():
> - arm64: 6 uses
> - ARM: 7 uses
> - riscv: 6 uses
> - s390: 5 uses
>
> For RISC-V specifically, I agree the single use of pt_dump_seq_puts()
> could be replaced with an inline conditional. For pt_dump_seq_printf(),
> the macro does save some repetition (6 uses vs 1 macro definition).
>
> pt_dump_seq_printf() could also be questioned - removing it means 20+
> inline conditionals across all architectures. I focused on the minimal
> fix, but happy to tackle the larger refactor if preferred.
>
> Would you prefer:
>
> Option A) Remove pt_dump_seq_puts() entirely from riscv and replace the
> single use with:
> if (st->seq)
> seq_puts(st->seq, "\n");
>
> Option B) Keep the macro for consistency with other architectures, but
> fix the bug
>
> I'm happy to send a v2 with either approach. If Option A, I could also
> propose similar cleanups for arm64 (1 use) as a follow-up.
Thanks for investigating further. I just queued your original patch; I
think that's the simplest way forward.
- Paul
next prev parent reply other threads:[~2025-10-25 7:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-18 17:04 [PATCH 3/4] riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro Josephine Pfeiffer
2025-10-18 17:04 ` Josephine Pfeiffer
2025-10-19 0:21 ` Paul Walmsley
2025-10-19 0:21 ` Paul Walmsley
2025-10-19 14:07 ` Josephine Pfeiffer
2025-10-19 14:07 ` Josephine Pfeiffer
2025-10-25 7:15 ` Paul Walmsley [this message]
2025-10-25 7:15 ` Paul Walmsley
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=ab17be2e-202e-e34e-21f8-c865aff4024f@kernel.org \
--to=pjw@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=hi@josie.lol \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/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.