* Re: [PATCH v2 003/110] audit: widen ino fields to u64
From: Paul Moore @ 2026-03-03 16:17 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, James Morris, Serge E. Hallyn, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <add39953250a4a1b2fe2b09deb3373c2a7482b88.camel@kernel.org>
On Tue, Mar 3, 2026 at 11:12 AM Jeff Layton <jlayton@kernel.org> wrote:
> On Tue, 2026-03-03 at 11:03 -0500, Paul Moore wrote:
> > On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <jlayton@kernel.org> wrote:
> > > On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
> > > > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > >
> > > > > inode->i_ino is being widened from unsigned long to u64. The audit
> > > > > subsystem uses unsigned long ino in struct fields, function parameters,
> > > > > and local variables that store inode numbers from arbitrary filesystems.
> > > > > On 32-bit platforms this truncates inode numbers that exceed 32 bits,
> > > > > which will cause incorrect audit log entries and broken watch/mark
> > > > > comparisons.
> > > > >
> > > > > Widen all audit ino fields, parameters, and locals to u64, and update
> > > > > the inode format string from %lu to %llu to match.
> > > > >
> > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > > ---
> > > > > include/linux/audit.h | 2 +-
> > > > > kernel/audit.h | 9 ++++-----
> > > > > kernel/audit_fsnotify.c | 4 ++--
> > > > > kernel/audit_watch.c | 8 ++++----
> > > > > kernel/auditsc.c | 2 +-
> > > > > 5 files changed, 12 insertions(+), 13 deletions(-)
> > > >
> > > > We should also update audit_hash_ino() in kernel/audit.h. It is a
> > > > *very* basic hash function, so I think leaving the function as-is and
> > > > just changing the inode parameter from u32 to u64 should be fine.
> >
> > ...
> >
> > > It doesn't look like changing the argument type will make any material
> > > difference. Given that it should still work without that change, can we
> > > leave this cleanup for you to do in a follow-on patchset?
> >
> > I would prefer if you made the change as part of the patch, mainly to
> > keep a patch record of this being related.
>
> Ok, I'll see about factoring that in.
Thanks.
> > Ideally I'd really like to see kino_t used in the audit code instead
> > of u64, but perhaps that is done in a later patch that I didn't see.
>
> I think I didn't make this clear enough in the cover letter, but kino_t
> is removed at the end of the series. It's just there to support the
> change during the interim.
Ah, gotcha, thanks for the education :)
> If HCH gets his way to do the changes as one big patch, it'll go away
> entirely.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 003/110] audit: widen ino fields to u64
From: Jeff Layton @ 2026-03-03 16:12 UTC (permalink / raw)
To: Paul Moore
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, James Morris, Serge E. Hallyn, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <CAHC9VhTyhnG7-ojnTnVdh_m1x=rKxw9YEH9g7Xp9m4F78aA5cA@mail.gmail.com>
On Tue, 2026-03-03 at 11:03 -0500, Paul Moore wrote:
> On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <jlayton@kernel.org> wrote:
> > On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
> > > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > >
> > > > inode->i_ino is being widened from unsigned long to u64. The audit
> > > > subsystem uses unsigned long ino in struct fields, function parameters,
> > > > and local variables that store inode numbers from arbitrary filesystems.
> > > > On 32-bit platforms this truncates inode numbers that exceed 32 bits,
> > > > which will cause incorrect audit log entries and broken watch/mark
> > > > comparisons.
> > > >
> > > > Widen all audit ino fields, parameters, and locals to u64, and update
> > > > the inode format string from %lu to %llu to match.
> > > >
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > > include/linux/audit.h | 2 +-
> > > > kernel/audit.h | 9 ++++-----
> > > > kernel/audit_fsnotify.c | 4 ++--
> > > > kernel/audit_watch.c | 8 ++++----
> > > > kernel/auditsc.c | 2 +-
> > > > 5 files changed, 12 insertions(+), 13 deletions(-)
> > >
> > > We should also update audit_hash_ino() in kernel/audit.h. It is a
> > > *very* basic hash function, so I think leaving the function as-is and
> > > just changing the inode parameter from u32 to u64 should be fine.
>
> ...
>
> > It doesn't look like changing the argument type will make any material
> > difference. Given that it should still work without that change, can we
> > leave this cleanup for you to do in a follow-on patchset?
>
> I would prefer if you made the change as part of the patch, mainly to
> keep a patch record of this being related.
>
Ok, I'll see about factoring that in.
> Ideally I'd really like to see kino_t used in the audit code instead
> of u64, but perhaps that is done in a later patch that I didn't see.
I think I didn't make this clear enough in the cover letter, but kino_t
is removed at the end of the series. It's just there to support the
change during the interim.
If HCH gets his way to do the changes as one big patch, it'll go away
entirely.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 003/110] audit: widen ino fields to u64
From: Paul Moore @ 2026-03-03 16:03 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, James Morris, Serge E. Hallyn, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <7a0165fe39e82a1effd8cce5c2c4e82d6a42cb3a.camel@kernel.org>
On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <jlayton@kernel.org> wrote:
> On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
> > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > inode->i_ino is being widened from unsigned long to u64. The audit
> > > subsystem uses unsigned long ino in struct fields, function parameters,
> > > and local variables that store inode numbers from arbitrary filesystems.
> > > On 32-bit platforms this truncates inode numbers that exceed 32 bits,
> > > which will cause incorrect audit log entries and broken watch/mark
> > > comparisons.
> > >
> > > Widen all audit ino fields, parameters, and locals to u64, and update
> > > the inode format string from %lu to %llu to match.
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > include/linux/audit.h | 2 +-
> > > kernel/audit.h | 9 ++++-----
> > > kernel/audit_fsnotify.c | 4 ++--
> > > kernel/audit_watch.c | 8 ++++----
> > > kernel/auditsc.c | 2 +-
> > > 5 files changed, 12 insertions(+), 13 deletions(-)
> >
> > We should also update audit_hash_ino() in kernel/audit.h. It is a
> > *very* basic hash function, so I think leaving the function as-is and
> > just changing the inode parameter from u32 to u64 should be fine.
...
> It doesn't look like changing the argument type will make any material
> difference. Given that it should still work without that change, can we
> leave this cleanup for you to do in a follow-on patchset?
I would prefer if you made the change as part of the patch, mainly to
keep a patch record of this being related.
Ideally I'd really like to see kino_t used in the audit code instead
of u64, but perhaps that is done in a later patch that I didn't see.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 15:25 UTC (permalink / raw)
To: Theodore Tso
Cc: Darrick J. Wong, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260303151617.GD6520@macsyma-wired.lan>
On Tue, 2026-03-03 at 10:16 -0500, Theodore Tso wrote:
> On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> >
> > Like I said to Ted, this is just temporary scaffolding for the change.
> > The PRIino macro is removed in the end. Given that, perhaps you can
> > overlook the bikeshed's color in this instance?
>
> I didn't realize that this was going to disappear in the end. That
> makes me feel much better about the change. I'd suggest changing the
> commit description where it claims that we're using something that
> follows the inttypes.h convention and making it clear that this is
> temporary and only to preserve bisectability.
>
> One question though --- are there *really* places that are using
> signed inode numbers and trying to print them? If people are trying
> to use negative inodes to signal an error or some such, the it implies
> that at least for some file systems, an inode number larger than 2**63
> might be problematic. If there is core VFS code that uses a negative
> inode number then this could be a real potential trap.
>
> So are there really code which is doing a printf of 'PRIino "d"'? Or
> was this to allow the use of of 'PRiino "x"'?
>
Mostly it's to allow 'PRIino "x"'. There are a number of places that
(for whatever reason) print the inode number in hex. I don't want to
change those.
There are also some places that print it as a signed value (PRIino
"d"). I suspect most of those are bugs, or just holdovers from a
simpler time when we didn't worry so much about the signedness of inode
numbers. I fixed a few of those in the context of this series, fwiw.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close
From: Steven Rostedt @ 2026-03-03 15:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Vincent Donnefort, Qing Wang, Masami Hiramatsu, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, syzbot+3b5dd2030fe08afdf65d,
linux-mm, Andrew Morton, Vlastimil Babka, David Hildenbrand
In-Reply-To: <71c3a923-dc00-471c-9555-c08d5e135dee@lucifer.local>
On Tue, 3 Mar 2026 10:19:52 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > > Setting VM_IO just to trigger a failure case in madvise() feels like a hack? I
> > > guess it'd do the trick though, but you're not going to be able to reclaim that
> > > memory, and you might get some unexpected behaviour in code paths that assume
> > > VM_IO means it's memory-mapped I/O... (for instance GUP will stop working, if
> > > you need that).
> >
> > Well, we don't reclaim that memory anyway.
>
> OK so maybe not such an issue then! As long as GUP not working with it wouldn't
> break anything?
Yeah, we don't ever use get_user_page() for this memory. It's pretty much
all handled on the kernel side. User space just has it mapped as read only.
The kernel doesn't care what user space does with it.
> > Yeah, right now the accounting gets screwed up as the mappings get out of
> > sync when it is forked.
>
> Ack, is that in a way that could screw up things from a kernel point of view at
> all? Presumably there was some report that triggered this work, like an assert
> fail or something, or a warning?
Yes, it triggered a warning. The start of this thread added a patch to allow
madvise to remove DONTCOPY from this memory without screwing things up
(by adding an open() handler for the vm_operations_struct).
>
> If a user is explicitly going to an ftrace buffer and madvise()'ing it in random
> ways they've only themselves to blame for being so stupid :)
>
> As long as it's not exploitable in some way I don't think that's too much of an
> issue?
>
> It'd be nice to keep the semantics of 'don't copy on fork' if we could, even if
> some crazy users might override it with madvise().
OK, so should we add the VM_IO flag?
>
> Kind of separate from the question, but I mean if it's kernel-allocated memory
> which you're managing separately it should surely be VM_PFNMAP?
OK, I'm a bit confused. What do you mean "managing separately"? You mean
managing the user space side of things? if so then yes.
Hmm, I haven't heard of VM_PFNMAP, can you explain more its use case.
>
> It depends if you want to have a refcounted folio underneath though. If you do
> then yeah don't do that :)
I have no idea what a refcounted folio would do here :-p
>
> In general I'd suggest supporting the fork case if you can, or just let things
> be wrong if a user does something crazy and undoes the VM_DONTCOPY flag.
OK, so don't add these flags and just allow the forking to happen as this
patch does (if they screw it up, it's their problem).
This patch is here:
https://lore.kernel.org/all/20260227025842.1085206-1-wangqing7171@gmail.com/
I mean, we allow two separate tasks to mmap the same buffer, and they will
have the same issues as a fork would have. Thus, I guess the answer is to
apply this patch?
-- Steve
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 15:23 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
Muchun Song, Oscar Salvador, David Hildenbrand, David Howells,
Paulo Alcantara, Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu,
Trond Myklebust, Anna Schumaker, Chuck Lever, NeilBrown,
Olga Kornievskaia, Dai Ngo, Tom Talpey, Steve French,
Ronnie Sahlberg, Shyam Prasad N, Bharath SM, Alexander Aring,
Ryusuke Konishi, Viacheslav Dubeyko, Eric Van Hensbergen,
Latchesar Ionkov, Dominique Martinet, Christian Schoenebeck,
David Sterba, Marc Dionne, Ian Kent, Luis de Bethencourt,
Salah Triki, Tigran A. Aivazian, Ilya Dryomov, Alex Markuze,
Jan Harkes, coda, Nicolas Pitre, Tyler Hicks, Amir Goldstein,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <4d3b9b92da613ad329b822f3f6043fa08f534451.camel@kernel.org>
On Tue, Mar 03, 2026 at 10:14:27AM -0500, Jeff Layton wrote:
> I think we'll be looking at close to a 1000 line patch that touches
> nearly 200 files if go that route. Roughly:
>
> 182 files changed, 910 insertions(+), 912 deletions(-)
That's not actually a lot, especially for a patch that should be
scriped and mechnanical.
I also really don't understand the backport argument. It's not like
you could backport any of the split out patches individually anyway.
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Theodore Tso @ 2026-03-03 15:16 UTC (permalink / raw)
To: Jeff Layton
Cc: Darrick J. Wong, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <33228005140684201de2ca0c157441d3b6a06413.camel@kernel.org>
On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
>
> Like I said to Ted, this is just temporary scaffolding for the change.
> The PRIino macro is removed in the end. Given that, perhaps you can
> overlook the bikeshed's color in this instance?
I didn't realize that this was going to disappear in the end. That
makes me feel much better about the change. I'd suggest changing the
commit description where it claims that we're using something that
follows the inttypes.h convention and making it clear that this is
temporary and only to preserve bisectability.
One question though --- are there *really* places that are using
signed inode numbers and trying to print them? If people are trying
to use negative inodes to signal an error or some such, the it implies
that at least for some file systems, an inode number larger than 2**63
might be problematic. If there is core VFS code that uses a negative
inode number then this could be a real potential trap.
So are there really code which is doing a printf of 'PRIino "d"'? Or
was this to allow the use of of 'PRiino "x"'?
- Ted
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 15:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Paulo Alcantara,
Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Chuck Lever, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Steve French, Ronnie Sahlberg,
Shyam Prasad N, Bharath SM, Alexander Aring, Ryusuke Konishi,
Viacheslav Dubeyko, Eric Van Hensbergen, Latchesar Ionkov,
Dominique Martinet, Christian Schoenebeck, David Sterba,
Marc Dionne, Ian Kent, Luis de Bethencourt, Salah Triki,
Tigran A. Aivazian, Ilya Dryomov, Alex Markuze, Jan Harkes, coda,
Nicolas Pitre, Tyler Hicks, Amir Goldstein,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <aabwflLfe2HcGv7X@infradead.org>
On Tue, 2026-03-03 at 06:30 -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> > On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> > > On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > > > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > > > overlook the bikeshed's color in this instance?
> > > > >
> > > > > So why add it in the first place?
> > > >
> > > > Bisectability. The first version I did of this would have broken the
> > > > ability to bisect properly across these changes. I don't love the
> > > > "churn" here either, but this should be cleanly bisectable.
> > >
> > > What do you need to bisect in format string changes? Splitting
> > > every variable type change outside of the main i_ino out - sure.
> > > But bisecting that "change to u64 in ext4" really broke ext4 and
> > > not "change to u64" is not very useful. Commits should do one
> > > well defined thing. Adding a weird transition layer for a format
> > > thing that just gets dropped is not one well defined thing.
> >
> > In the middle stages of the series, you will get warnings or errors on
> > 32-bit hosts when i_ino's type doesn't match what the format string
> > expects.
> >
> > There are really only three options here:
> >
> > 1/ Do (almost) all of the changes in one giant patch
> >
> > 2/ Accept that the build may break during the interim stages
> >
> > 3/ This series: using a typedef and macro to work around the breakage
> > until the type can be changed, at the expense of some extra churn in
> > the codebase
> >
> > 3 seems like the lesser evil.
>
> No, 1 is by far the least evil. Note that it's not really almost all,
> as all the local variables can easily and sanely be split out. It's
> all of the format strings, and that makes sense. The only "regressions"
> there are incorrect format strings which have good warnings and can
> be fixed easily.
Well, I've done 2 and 3 already. Why not 1? :)
It's not so much the regressions that are a problem here, but the merge
conflicts for anyone wanting to backport later patches that are near
these format changes. Having that change broken up by subsystem makes
it easier to handle that piecemeal later.
I think we'll be looking at close to a 1000 line patch that touches
nearly 200 files if go that route. Roughly:
182 files changed, 910 insertions(+), 912 deletions(-)
There are some tracepoint changes in some of the per-subsystem patches
that will need to be split out, so the count isn't exact, but it'll be
fairly close.
Since Christian will probably end up taking this series, I'd like to
get his opinion before I respin anything.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 15/18] rtla/trace: Fix write loop in trace_event_save_hist()
From: Tomas Glozar @ 2026-03-03 14:51 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Crystal Wood, Ivan Pravdin, Costa Shulyupin,
John Kacur, Haiyong Sun, Tiezhu Yang, Daniel Wagner,
Daniel Bristot de Oliveira,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260115163650.118910-16-wander@redhat.com>
čt 15. 1. 2026 v 18:29 odesílatel Wander Lairson Costa
<wander@redhat.com> napsal:
>
> The write loop in trace_event_save_hist() does not correctly handle
> errors from the write() system call. If write() returns -1, this value
> is added to the loop index, leading to an incorrect memory access on
> the next iteration and potentially an infinite loop. The loop also
> fails to handle EINTR.
>
> Fix the write loop by introducing proper error handling. The return
> value of write() is now stored in a ssize_t variable and checked for
> errors. The loop retries the call if interrupted by a signal and breaks
> on any other error after logging it with strerror().
>
> Additionally, change the index variable type from int to size_t to
> match the type used for buffer sizes and by strlen(), improving type
> safety.
>
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Looks good. Only thing is that it should have a Fixes tag so that it
can be detected by automation (e.g. stable backports - as this is
relatively old code), like this:
Fixes: 761916fd02c2 ("rtla/trace: Save event histogram output to a file")
(on one line, Gmail may truncate that)
Tomas
^ permalink raw reply
* Re: [PATCH] ftrace: Disable preemption in the tracepoint callbacks handling filtered pids
From: Steven Rostedt @ 2026-03-03 14:39 UTC (permalink / raw)
To: Masami Hiramatsu (Google); +Cc: LKML, Linux Trace Kernel, Mathieu Desnoyers
In-Reply-To: <20260303131706.96057f61a48a34c43ce1e396@kernel.org>
On Tue, 3 Mar 2026 13:17:06 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 9928da636c9d..3b3aaf4831e9 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -1039,6 +1039,7 @@ event_filter_pid_sched_process_exit(void *data, struct task_struct *task)
> struct trace_pid_list *pid_list;
> struct trace_array *tr = data;
>
> + guard(preempt)();
> pid_list = rcu_dereference_raw(tr->filtered_pids);
> trace_filter_add_remove_task(pid_list, NULL, task);
>
> @@ -1054,6 +1055,7 @@ event_filter_pid_sched_process_fork(void *data,
> struct trace_pid_list *pid_list;
> struct trace_array *tr = data;
>
> + guard(preempt)();
> pid_list = rcu_dereference_sched(tr->filtered_pids);
> trace_filter_add_remove_task(pid_list, self, task);
>
Yep. I can make them two different patches. Do you want me to take this as
your patch? I'll need a SoB from you then.
-- Steve
^ permalink raw reply
* Re: [PATCH v3 14/18] rtla/timerlat: Simplify RTLA_NO_BPF environment variable check
From: Tomas Glozar @ 2026-03-03 14:38 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Crystal Wood, Ivan Pravdin, Costa Shulyupin,
John Kacur, Tiezhu Yang, Daniel Wagner,
Daniel Bristot de Oliveira,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260115163650.118910-15-wander@redhat.com>
čt 15. 1. 2026 v 18:29 odesílatel Wander Lairson Costa
<wander@redhat.com> napsal:
> - if (getenv("RTLA_NO_BPF") && strncmp(getenv("RTLA_NO_BPF"), "1", 2) == 0) {
> + if (rtla_no_bpf && strcmp(rtla_no_bpf, "1") == 0) {
Another use case for strncmp_static()?
> debug_msg("RTLA_NO_BPF set, disabling BPF\n");
> params->mode = TRACING_MODE_TRACEFS;
> } else if (!tep_find_event_by_name(tool->trace.tep, "osnoise", "timerlat_sample")) {
> --
> 2.52.0
>
Tomas
^ permalink raw reply
* Re: [BUG] WARNING in __perf_event_account_interrupt (kernel/events/core.c:2797)
From: Peter Zijlstra @ 2026-03-03 14:35 UTC (permalink / raw)
To: Zw Tang
Cc: mingo, Arnaldo Carvalho de Melo, namhyung, linux-perf-users,
linux-kernel, linux-trace-kernel, Steven Rostedt,
Masami Hiramatsu
In-Reply-To: <CAPHJ_VLapzvWHz_ot4uvxSJ_Z3ubtCCp=_ZVReh7KAwjxu5uFQ@mail.gmail.com>
On Tue, Mar 03, 2026 at 08:37:54PM +0800, Zw Tang wrote:
> Hi,
>
> I am reporting a WARNING triggered by a syzkaller reproducer on Linux 7.0.0-rc1.
>
> The kernel hits a WARN in perf events interrupt accounting:
>
> WARNING: kernel/events/core.c:2797 at __perf_event_account_interrupt+0x485/0x530
>
> It is triggered from the perf overflow path while closing a perf_event
> fd created for a tracepoint (PERF_TYPE_TRACEPOINT). The call trace
Could you try -rc2, I suspect that commit:
c9bc1753b3cc ("perf: Fix __perf_event_overflow() vs perf_remove_from_context() race")
will have also fixed this.
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 14:30 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
Muchun Song, Oscar Salvador, David Hildenbrand, David Howells,
Paulo Alcantara, Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu,
Trond Myklebust, Anna Schumaker, Chuck Lever, NeilBrown,
Olga Kornievskaia, Dai Ngo, Tom Talpey, Steve French,
Ronnie Sahlberg, Shyam Prasad N, Bharath SM, Alexander Aring,
Ryusuke Konishi, Viacheslav Dubeyko, Eric Van Hensbergen,
Latchesar Ionkov, Dominique Martinet, Christian Schoenebeck,
David Sterba, Marc Dionne, Ian Kent, Luis de Bethencourt,
Salah Triki, Tigran A. Aivazian, Ilya Dryomov, Alex Markuze,
Jan Harkes, coda, Nicolas Pitre, Tyler Hicks, Amir Goldstein,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <1310fc5c09cce52ec00344b936275fe584c88dea.camel@kernel.org>
On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> > On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > > overlook the bikeshed's color in this instance?
> > > >
> > > > So why add it in the first place?
> > >
> > > Bisectability. The first version I did of this would have broken the
> > > ability to bisect properly across these changes. I don't love the
> > > "churn" here either, but this should be cleanly bisectable.
> >
> > What do you need to bisect in format string changes? Splitting
> > every variable type change outside of the main i_ino out - sure.
> > But bisecting that "change to u64 in ext4" really broke ext4 and
> > not "change to u64" is not very useful. Commits should do one
> > well defined thing. Adding a weird transition layer for a format
> > thing that just gets dropped is not one well defined thing.
>
> In the middle stages of the series, you will get warnings or errors on
> 32-bit hosts when i_ino's type doesn't match what the format string
> expects.
>
> There are really only three options here:
>
> 1/ Do (almost) all of the changes in one giant patch
>
> 2/ Accept that the build may break during the interim stages
>
> 3/ This series: using a typedef and macro to work around the breakage
> until the type can be changed, at the expense of some extra churn in
> the codebase
>
> 3 seems like the lesser evil.
No, 1 is by far the least evil. Note that it's not really almost all,
as all the local variables can easily and sanely be split out. It's
all of the format strings, and that makes sense. The only "regressions"
there are incorrect format strings which have good warnings and can
be fixed easily.
^ permalink raw reply
* Re: [PATCH v3 12/18] rtla: Enforce exact match for time unit suffixes
From: Tomas Glozar @ 2026-03-03 14:27 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Crystal Wood, Ivan Pravdin, Costa Shulyupin,
John Kacur, Tiezhu Yang, Daniel Wagner,
Daniel Bristot de Oliveira,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260115163650.118910-13-wander@redhat.com>
čt 15. 1. 2026 v 18:28 odesílatel Wander Lairson Costa
<wander@redhat.com> napsal:
>
> The parse_ns_duration() function currently uses prefix matching for
> detecting time units. This approach is problematic as it silently
> accepts malformed strings such as "100nsx" or "100us_invalid" by
> ignoring the trailing characters, leading to potential configuration
> errors.
>
> Switch to using strcmp() for suffix comparison to enforce exact matches.
> This ensures that the parser strictly validates the time unit and
> rejects any input containing invalid trailing characters, thereby
> improving the robustness of the configuration parsing.
>
Why not use your strncmp_static() helper to protect from overrun?
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> ---
> tools/tracing/rtla/src/utils.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/tracing/rtla/src/utils.c b/tools/tracing/rtla/src/utils.c
> index 486d96e8290fb..b029fe5970c31 100644
> --- a/tools/tracing/rtla/src/utils.c
> +++ b/tools/tracing/rtla/src/utils.c
> @@ -211,15 +211,15 @@ long parse_ns_duration(char *val)
> t = strtol(val, &end, 10);
>
> if (end) {
> - if (!strncmp(end, "ns", 2)) {
> + if (strcmp(end, "ns") == 0) {
> return t;
> - } else if (!strncmp(end, "us", 2)) {
> + } else if (strcmp(end, "us") == 0) {
> t *= 1000;
> return t;
> - } else if (!strncmp(end, "ms", 2)) {
> + } else if (strcmp(end, "ms") == 0) {
> t *= 1000 * 1000;
> return t;
> - } else if (!strncmp(end, "s", 1)) {
> + } else if (strcmp(end, "s") == 0) {
> t *= 1000 * 1000 * 1000;
> return t;
> }
> --
> 2.52.0
>
Tomas
^ permalink raw reply
* Re: [PATCH v4 4/5] mm: rename zone->lock to zone->_lock
From: Dmitry Ilvokhin @ 2026-03-03 14:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Vlastimil Babka (SUSE), David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Zi Yan, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
SeongJae Park
In-Reply-To: <20260302143743.220eed4feb36d7572fe726cc@linux-foundation.org>
On Mon, Mar 02, 2026 at 02:37:43PM -0800, Andrew Morton wrote:
> On Mon, 2 Mar 2026 15:10:03 +0100 "Vlastimil Babka (SUSE)" <vbabka@kernel.org> wrote:
>
> > On 2/27/26 17:00, Dmitry Ilvokhin wrote:
> > > This intentionally breaks direct users of zone->lock at compile time so
> > > all call sites are converted to the zone lock wrappers. Without the
> > > rename, present and future out-of-tree code could continue using
> > > spin_lock(&zone->lock) and bypass the wrappers and tracing
> > > infrastructure.
> > >
> > > No functional change intended.
> > >
> > > Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> > > Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> > > Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> > > Acked-by: SeongJae Park <sj@kernel.org>
> >
> > I see some more instances of 'zone->lock' in comments in
> > include/linux/mmzone.h and under Documentation/ but otherwise LGTM.
> >
>
> I fixed (most of) that in the previous version but my fix was lost.
Thanks for the fixups, Andrew.
I still see a few 'zone->lock' references in Documentation remain on
mm-new. This patch cleans them up, as noted by Vlastimil.
I'm happy to adjust this patch if anything else needs attention.
From 9142d5a8b60038fa424a6033253960682e5a51f4 Mon Sep 17 00:00:00 2001
From: Dmitry Ilvokhin <d@ilvokhin.com>
Date: Tue, 3 Mar 2026 06:13:13 -0800
Subject: [PATCH] mm: fix remaining zone->lock references
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
Documentation/mm/physical_memory.rst | 4 ++--
Documentation/trace/events-kmem.rst | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst
index b76183545e5b..e344f93515b6 100644
--- a/Documentation/mm/physical_memory.rst
+++ b/Documentation/mm/physical_memory.rst
@@ -500,11 +500,11 @@ General
``nr_isolate_pageblock``
Number of isolated pageblocks. It is used to solve incorrect freepage counting
problem due to racy retrieving migratetype of pageblock. Protected by
- ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+ ``zone_lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
``span_seqlock``
The seqlock to protect ``zone_start_pfn`` and ``spanned_pages``. It is a
- seqlock because it has to be read outside of ``zone->lock``, and it is done in
+ seqlock because it has to be read outside of ``zone_lock``, and it is done in
the main allocator path. However, the seqlock is written quite infrequently.
Defined only when ``CONFIG_MEMORY_HOTPLUG`` is enabled.
diff --git a/Documentation/trace/events-kmem.rst b/Documentation/trace/events-kmem.rst
index 68fa75247488..3c20a972de27 100644
--- a/Documentation/trace/events-kmem.rst
+++ b/Documentation/trace/events-kmem.rst
@@ -57,7 +57,7 @@ the per-CPU allocator (high performance) or the buddy allocator.
If pages are allocated directly from the buddy allocator, the
mm_page_alloc_zone_locked event is triggered. This event is important as high
-amounts of activity imply high activity on the zone->lock. Taking this lock
+amounts of activity imply high activity on the zone_lock. Taking this lock
impairs performance by disabling interrupts, dirtying cache lines between
CPUs and serialising many CPUs.
@@ -79,11 +79,11 @@ contention on the lruvec->lru_lock.
mm_page_pcpu_drain page=%p pfn=%lu order=%d cpu=%d migratetype=%d
In front of the page allocator is a per-cpu page allocator. It exists only
-for order-0 pages, reduces contention on the zone->lock and reduces the
+for order-0 pages, reduces contention on the zone_lock and reduces the
amount of writing on struct page.
When a per-CPU list is empty or pages of the wrong type are allocated,
-the zone->lock will be taken once and the per-CPU list refilled. The event
+the zone_lock will be taken once and the per-CPU list refilled. The event
triggered is mm_page_alloc_zone_locked for each page allocated with the
event indicating whether it is for a percpu_refill or not.
@@ -92,7 +92,7 @@ which triggers a mm_page_pcpu_drain event.
The individual nature of the events is so that pages can be tracked
between allocation and freeing. A number of drain or refill pages that occur
-consecutively imply the zone->lock being taken once. Large amounts of per-CPU
+consecutively imply the zone_lock being taken once. Large amounts of per-CPU
refills and drains could imply an imbalance between CPUs where too much work
is being concentrated in one place. It could also indicate that the per-CPU
lists should be a larger size. Finally, large amounts of refills on one CPU
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 14:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Paulo Alcantara,
Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Chuck Lever, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Steve French, Ronnie Sahlberg,
Shyam Prasad N, Bharath SM, Alexander Aring, Ryusuke Konishi,
Viacheslav Dubeyko, Eric Van Hensbergen, Latchesar Ionkov,
Dominique Martinet, Christian Schoenebeck, David Sterba,
Marc Dionne, Ian Kent, Luis de Bethencourt, Salah Triki,
Tigran A. Aivazian, Ilya Dryomov, Alex Markuze, Jan Harkes, coda,
Nicolas Pitre, Tyler Hicks, Amir Goldstein,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <aabpPQxCTweoTp8Z@infradead.org>
On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > overlook the bikeshed's color in this instance?
> > >
> > > So why add it in the first place?
> >
> > Bisectability. The first version I did of this would have broken the
> > ability to bisect properly across these changes. I don't love the
> > "churn" here either, but this should be cleanly bisectable.
>
> What do you need to bisect in format string changes? Splitting
> every variable type change outside of the main i_ino out - sure.
> But bisecting that "change to u64 in ext4" really broke ext4 and
> not "change to u64" is not very useful. Commits should do one
> well defined thing. Adding a weird transition layer for a format
> thing that just gets dropped is not one well defined thing.
In the middle stages of the series, you will get warnings or errors on
32-bit hosts when i_ino's type doesn't match what the format string
expects.
There are really only three options here:
1/ Do (almost) all of the changes in one giant patch
2/ Accept that the build may break during the interim stages
3/ This series: using a typedef and macro to work around the breakage
until the type can be changed, at the expense of some extra churn in
the codebase
3 seems like the lesser evil.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 13:59 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
Muchun Song, Oscar Salvador, David Hildenbrand, David Howells,
Paulo Alcantara, Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu,
Trond Myklebust, Anna Schumaker, Chuck Lever, NeilBrown,
Olga Kornievskaia, Dai Ngo, Tom Talpey, Steve French,
Ronnie Sahlberg, Shyam Prasad N, Bharath SM, Alexander Aring,
Ryusuke Konishi, Viacheslav Dubeyko, Eric Van Hensbergen,
Latchesar Ionkov, Dominique Martinet, Christian Schoenebeck,
David Sterba, Marc Dionne, Ian Kent, Luis de Bethencourt,
Salah Triki, Tigran A. Aivazian, Ilya Dryomov, Alex Markuze,
Jan Harkes, coda, Nicolas Pitre, Tyler Hicks, Amir Goldstein,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <19e4e79a59dcfc4c61c8cf263af345d0d7026fc8.camel@kernel.org>
On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > overlook the bikeshed's color in this instance?
> >
> > So why add it in the first place?
>
> Bisectability. The first version I did of this would have broken the
> ability to bisect properly across these changes. I don't love the
> "churn" here either, but this should be cleanly bisectable.
What do you need to bisect in format string changes? Splitting
every variable type change outside of the main i_ino out - sure.
But bisecting that "change to u64 in ext4" really broke ext4 and
not "change to u64" is not very useful. Commits should do one
well defined thing. Adding a weird transition layer for a format
thing that just gets dropped is not one well defined thing.
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: input: Document hid-over-spi DT schema
From: Rob Herring @ 2026-03-03 13:53 UTC (permalink / raw)
To: Jingyuan Liang
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, linux-input,
linux-doc, linux-kernel, linux-spi, linux-trace-kernel,
devicetree, hbarnor, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <20260303-send-upstream-v1-9-1515ba218f3d@chromium.org>
On Tue, Mar 3, 2026 at 12:14 AM Jingyuan Liang <jingyliang@chromium.org> wrote:
>
> Documentation describes the required and optional properties for
> implementing Device Tree for a Microsoft G6 Touch Digitizer that
> supports HID over SPI Protocol 1.0 specification.
>
> The properties are common to HID over SPI.
>
> Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> ---
> .../devicetree/bindings/input/hid-over-spi.yaml | 153 +++++++++++++++++++++
> 1 file changed, 153 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> new file mode 100644
> index 000000000000..b623629ed9d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> @@ -0,0 +1,153 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HID over SPI Devices
> +
> +maintainers:
> + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> + - Jiri Kosina <jkosina@suse.cz>
> +
> +description: |+
> + HID over SPI provides support for various Human Interface Devices over the
> + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> + or sensors.
> +
> + The specification has been written by Microsoft and is currently available here:
> + https://www.microsoft.com/en-us/download/details.aspx?id=103325
> +
> + If this binding is used, the kernel module spi-hid will handle the communication
> + with the device and the generic hid core layer will handle the protocol.
> +
> +allOf:
> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - microsoft,g6-touch-digitizer
> + - const: hid-over-spi
> + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> + const: hid-over-spi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> + description:
> + GPIO specifier for the digitizer's reset pin (active low). The line must
> + be flagged with GPIO_ACTIVE_LOW.
> +
> + vdd-supply:
> + description:
> + Regulator for the VDD supply voltage.
Is this part of the spec? This won't scale for multiple devices with
different power rails.
> +
> + input-report-header-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Read Approval packet, listing an address of
> + the input report header to be put on the SPI bus. This address has 24
> + bits.
> +
> + input-report-body-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Read Approval packet, listing an address of
> + the input report body to be put on the SPI bus. This address has 24 bits.
> +
> + output-report-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Output Report sent by the host, listing an
> + address where the output report on the SPI bus is to be written to. This
> + address has 24 bits.
> +
> + post-power-on-delay-ms:
> + description:
> + Optional time in ms required by the device after enabling its regulators
> + or powering it on, before it is ready for communication.
Drop. This should be implied by the compatible.
> +
> + minimal-reset-delay-ms:
> + description:
> + Optional minimum amount of time in ms that device needs to be in reset
> + state for the reset to take effect.
Drop. This should be implied by the compatible.
> +
> + read-opcode:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + Value to be used in Read Approval packets. 1 byte.
> +
> + write-opcode:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + Value to be used in Write Approval packets. 1 byte.
Why are these and the address properties above not defined by the
spec? Do they vary for a specific device? If not, then they should be
implied by the compatible.
> +
> + hid-over-spi-flags:
> + $ref: /schemas/types.yaml#/definitions/uint16
> + description:
> + 16 bits.
> + Bits 0-12 - Reserved (must be 0)
> + Bit 13 - SPI Write Mode. Possible values -
> + * 0b0- Writes are carried out in Single-SPI mode
> + * 0b1- Writes are carried out in the Multi-SPI mode specified by bits
> + 14-15
> + Bits 14-15 - Multi-SPI Mode. Possible values -
> + * 0b00- Single SPI
> + * 0b01- Dual SPI
> + * 0b10- Quad SPI
We already have SPI properties to define the bus width for read and write.
> +
> +required:
> + - compatible
> + - interrupts
> + - reset-gpios
> + - vdd-supply
> + - input-report-header-address
> + - input-report-body-address
> + - output-report-address
> + - read-opcode
> + - write-opcode
> + - hid-over-spi-flags
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hid@0 {
> + compatible = "hid-over-spi";
> + reg = <0x0>;
> + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> + vdd-supply = <&pm8350c_l3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_d6_reset_assert &ts_d6_int_bias>;
> + input-report-header-address = <0x1000>;
> + input-report-body-address = <0x1004>;
> + output-report-address = <0x2000>;
> + read-opcode = <0x0b>;
> + write-opcode = <0x02>;
> + hid-over-spi-flags = <0x0000>;
> + post-power-on-delay-ms = <5>;
> + minimal-reset-delay-ms = <5>;
> + };
> + };
> \ No newline at end of file
Fix this.
Rob
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 13:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Paulo Alcantara,
Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Chuck Lever, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Steve French, Ronnie Sahlberg,
Shyam Prasad N, Bharath SM, Alexander Aring, Ryusuke Konishi,
Viacheslav Dubeyko, Eric Van Hensbergen, Latchesar Ionkov,
Dominique Martinet, Christian Schoenebeck, David Sterba,
Marc Dionne, Ian Kent, Luis de Bethencourt, Salah Triki,
Tigran A. Aivazian, Ilya Dryomov, Alex Markuze, Jan Harkes, coda,
Nicolas Pitre, Tyler Hicks, Amir Goldstein,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <aabkBadGzo7IZpSU@infradead.org>
On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > Like I said to Ted, this is just temporary scaffolding for the change.
> > The PRIino macro is removed in the end. Given that, perhaps you can
> > overlook the bikeshed's color in this instance?
>
> So why add it in the first place?
Bisectability. The first version I did of this would have broken the
ability to bisect properly across these changes. I don't love the
"churn" here either, but this should be cleanly bisectable.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 13:37 UTC (permalink / raw)
To: Jeff Layton
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Paulo Alcantara,
Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Chuck Lever, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Steve French, Ronnie Sahlberg,
Shyam Prasad N, Bharath SM, Alexander Aring, Ryusuke Konishi,
Viacheslav Dubeyko, Eric Van Hensbergen, Latchesar Ionkov,
Dominique Martinet, Christian Schoenebeck, David Sterba,
Marc Dionne, Ian Kent, Luis de Bethencourt, Salah Triki,
Tigran A. Aivazian, Ilya Dryomov, Alex Markuze, Jan Harkes, coda,
Nicolas Pitre, Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <33228005140684201de2ca0c157441d3b6a06413.camel@kernel.org>
On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> Like I said to Ted, this is just temporary scaffolding for the change.
> The PRIino macro is removed in the end. Given that, perhaps you can
> overlook the bikeshed's color in this instance?
So why add it in the first place?
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 13:36 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Theodore Tso, Jeff Layton, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Paulo Alcantara,
Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Chuck Lever, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Steve French, Ronnie Sahlberg,
Shyam Prasad N, Bharath SM, Alexander Aring, Ryusuke Konishi,
Viacheslav Dubeyko, Eric Van Hensbergen, Latchesar Ionkov,
Dominique Martinet, Christian Schoenebeck, David Sterba,
Marc Dionne, Ian Kent, Luis de Bethencourt, Salah Triki,
Tigran A. Aivazian, Ilya Dryomov, Alex Markuze, Jan Harkes, coda,
Nicolas Pitre, Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260303042546.GF13868@frogsfrogsfrogs>
On Mon, Mar 02, 2026 at 08:25:46PM -0800, Darrick J. Wong wrote:
> > That being said, the userspace PRIu64, et. al macros are complete
> > format specifiers, not just a length modifier. And I think this
> > results in less ugly format specifiers in our kernel code.
>
> Yeah, I don't like "ino=%" PRIino "u, lolz\n" either. I'd rather have
> the whole format in the PRIino definition -- it /is/ unsigned long
> after all.
Just drop the bloody macro and the pointless micro-splitting of the
change. After this the inode is always 64-bit and we can just use
normal ll specifiers without messing things up.
^ permalink raw reply
* Re: [PATCH v3 05/18] rtla: Replace magic number with MAX_PATH
From: Tomas Glozar @ 2026-03-03 12:46 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Ivan Pravdin, Crystal Wood, Costa Shulyupin,
John Kacur, Tiezhu Yang, Daniel Wagner,
Daniel Bristot de Oliveira,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260115163650.118910-6-wander@redhat.com>
čt 15. 1. 2026 v 18:26 odesílatel Wander Lairson Costa
<wander@redhat.com> napsal:
> --- a/tools/tracing/rtla/src/osnoise.c
> +++ b/tools/tracing/rtla/src/osnoise.c
> @@ -52,7 +52,7 @@ char *osnoise_get_cpus(struct osnoise_context *context)
> int osnoise_set_cpus(struct osnoise_context *context, char *cpus)
> {
> char *orig_cpus = osnoise_get_cpus(context);
> - char buffer[1024];
> + char buffer[MAX_PATH];
Shouldn't this rather be strlen(cpus), a new constant, something like
CPU_STRING_MAX, or a value dynamically computed from nr_cpus? The
buffer is used to store "cpus" concatenated with "\n" to be written to
the osnoise/cpus file, it has nothing to do with MAX_PATH.
The contents of osnoise/cpus can be arbitrarily long [1], if you
specify more than 1040 CPUs - which is theoretically possible, as
CONFIG_NR_CPUs on e.g. Fedora 43 is 8192, although rather unlikely -
it will be truncated.
[1] 17f89102fe23 ("tracing/osnoise: Allow arbitrarily long CPU string")
Tomas
^ permalink raw reply
* [BUG] WARNING in __perf_event_account_interrupt (kernel/events/core.c:2797)
From: Zw Tang @ 2026-03-03 12:37 UTC (permalink / raw)
To: peterz, mingo, Arnaldo Carvalho de Melo, namhyung
Cc: linux-perf-users, linux-kernel, linux-trace-kernel,
Steven Rostedt, Masami Hiramatsu
Hi,
I am reporting a WARNING triggered by a syzkaller reproducer on Linux 7.0.0-rc1.
The kernel hits a WARN in perf events interrupt accounting:
WARNING: kernel/events/core.c:2797 at __perf_event_account_interrupt+0x485/0x530
It is triggered from the perf overflow path while closing a perf_event
fd created for a tracepoint (PERF_TYPE_TRACEPOINT). The call trace
shows:
__perf_event_overflow()
perf_tp_event()
...
__x64_sys_close()
This looks like a potential state inconsistency / reentrancy issue
between tracepoint-perf event handling (overflow/accounting) and event
close/teardown paths, causing __perf_event_account_interrupt() to hit
a WARN_ON.
log:
[ 109.197980] Call Trace:
[ 109.198578] <TASK>
[ 109.199163] __perf_event_overflow+0xb6/0xa00
[ 109.200270] ? perf_tp_event+0x703/0xcd0
[ 109.201256] perf_swevent_overflow+0xac/0x150
[ 109.202321] perf_swevent_event+0x14d/0x2e0
[ 109.203372] perf_tp_event+0x3d8/0xcd0
[ 109.204320] ? __perf_tp_event_target_task+0x540/0x540
[ 109.205578] ? __lock_acquire+0x55a/0x1ef0
[ 109.206595] ? lock_acquire+0x199/0x2f0
[ 109.207556] ? find_held_lock+0x2b/0x80
[ 109.208512] ? __sanitizer_cov_trace_pc+0x1d/0x50
[ 109.209655] ? _perf_event_period+0x1b2/0x240
[ 109.210714] ? perf_event_refresh+0x100/0x100
[ 109.211984] ? __might_fault+0x151/0x190
[ 109.212905] ? __sanitizer_cov_trace_pc+0x1d/0x50
[ 109.214104] ? __sanitizer_cov_trace_pc+0x1d/0x50
[ 109.215238] ? _perf_ioctl+0x147/0x1d40
[ 109.216203] ? perf_trace_run_bpf_submit+0xef/0x180
[ 109.217378] perf_trace_run_bpf_submit+0xef/0x180
[ 109.218542] perf_trace_lock_acquire+0x385/0x590
[ 109.219684] ? lock_release+0xc9/0x2b0
[ 109.220824] ? perf_trace_lock+0x510/0x510
[ 109.221820] ? __mutex_unlock_slowpath+0x157/0x760
[ 109.223132] ? _mutex_trylock_nest_lock+0x370/0x370
[ 109.224302] ? perf_event_ctx_lock_nested+0x89/0x4d0
[ 109.225533] lock_acquire+0xdf/0x2f0
[ 109.226428] ? file_close_fd+0x4d/0x80
[ 109.227390] ? __sanitizer_cov_trace_pc+0x1d/0x50
[ 109.228570] _raw_spin_lock+0x2b/0x40
[ 109.229517] ? file_close_fd+0x4d/0x80
[ 109.230481] file_close_fd+0x4d/0x80
[ 109.231386] __x64_sys_close+0x38/0x120
[ 109.232343] do_syscall_64+0x115/0x650
[ 109.233305] entry_SYSCALL_64_after_hwframe+0x4b/0x53
Reproducer:
C reproducer: https://pastebin.com/raw/GJtNs8JE
console output: https://pastebin.com/raw/zGwk1RhB
kernel config: https://pastebin.com/raw/g6ZhXQ79
Kernel:
git tree: torvalds/linux
commit: 4d349ee5c7782f8b27f6cb550f112c5e26fff38d
kernel version: 7.0.0-rc1
hardware: QEMU Ubuntu 24.10
^ permalink raw reply
* Re: [PATCH v2 016/110] 9p: use PRIino format for i_ino
From: Christian Schoenebeck @ 2026-03-03 11:52 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
David Sterba, Marc Dionne, Ian Kent, Luis de Bethencourt,
Salah Triki, Tigran A. Aivazian, Ilya Dryomov, Alex Markuze,
Jan Harkes, coda, Nicolas Pitre, Tyler Hicks, Amir Goldstein,
Christoph Hellwig, John Paul Adrian Glaubitz, Yangtao Li,
Mikulas Patocka, David Woodhouse, Richard Weinberger,
Dave Kleikamp, Konstantin Komarov, Mark Fasheh, Joel Becker,
Joseph Qi, Mike Marshall, Martin Brandenburg, Miklos Szeredi,
Anders Larsen, Zhihao Cheng, Damien Le Moal, Naohiro Aota,
Johannes Thumshirn, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Fan Wu, Stephen Smalley, Ondrej Mosnacek,
Casey Schaufler, Alex Deucher, Christian König, David Airlie,
Simona Vetter, Sumit Semwal, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, David S. Miller, Jakub Kicinski,
Simon Horman, Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Darrick J. Wong, Martin Schiller, Eric Paris,
Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
In-Reply-To: <20260302-iino-u64-v2-16-e5388800dae0@kernel.org>
On Monday, 2 March 2026 21:24:00 CET Jeff Layton wrote:
> Convert 9p i_ino format strings to use the PRIino format
> macro in preparation for the widening of i_ino via kino_t.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/9p/vfs_addr.c | 4 ++--
> fs/9p/vfs_inode.c | 6 +++---
> fs/9p/vfs_inode_dotl.c | 6 +++---
> 3 files changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
^ permalink raw reply
* Re: [PATCH v2 069/110] 9p: replace PRIino with %llu/%llx format strings
From: Christian Schoenebeck @ 2026-03-03 12:12 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
David Sterba, Marc Dionne, Ian Kent, Luis de Bethencourt,
Salah Triki, Tigran A. Aivazian, Ilya Dryomov, Alex Markuze,
Jan Harkes, coda, Nicolas Pitre, Tyler Hicks, Amir Goldstein,
Christoph Hellwig, John Paul Adrian Glaubitz, Yangtao Li,
Mikulas Patocka, David Woodhouse, Richard Weinberger,
Dave Kleikamp, Konstantin Komarov, Mark Fasheh, Joel Becker,
Joseph Qi, Mike Marshall, Martin Brandenburg, Miklos Szeredi,
Anders Larsen, Zhihao Cheng, Damien Le Moal, Naohiro Aota,
Johannes Thumshirn, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Fan Wu, Stephen Smalley, Ondrej Mosnacek,
Casey Schaufler, Alex Deucher, Christian König, David Airlie,
Simona Vetter, Sumit Semwal, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, David S. Miller, Jakub Kicinski,
Simon Horman, Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Darrick J. Wong, Martin Schiller, Eric Paris,
Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
In-Reply-To: <20260302-iino-u64-v2-69-e5388800dae0@kernel.org>
On Monday, 2 March 2026 21:24:53 CET Jeff Layton wrote:
> Now that i_ino is u64 and the PRIino format macro has been removed,
> replace all uses in 9p with the concrete format strings.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/9p/vfs_addr.c | 4 ++--
> fs/9p/vfs_inode.c | 6 +++---
> fs/9p/vfs_inode_dotl.c | 6 +++---
> 3 files changed, 8 insertions(+), 8 deletions(-)
9p uses the following macro to convert the 9p network protocol's QID path from
u64 (all platforms) to ino_t. The 32-bit path of this macro should be dropped
after this change, as it would unnecessarily truncate the value to 32-bit now
[fs/9p/v9fs_vfs.h]:
#if (BITS_PER_LONG == 32)
#define QID2INO(q) ((ino_t) (((q)->path+2) ^ (((q)->path) >> 32)))
#else
#define QID2INO(q) ((ino_t) ((q)->path+2))
#endif
You are not breaking anything, if you happen to send a v3, that would be nice
to be dropped, otherwise we'll handle that on our end later on:
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
I wonder whether that exceeded Claude's context size, or if that's in line
with the prompt specified by you.
/Christian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox