* Re: [PATCH v2 2/2] fsverity: add tracepoints
2026-01-24 18:49 ` [PATCH v2 2/2] fsverity: add tracepoints Eric Biggers
@ 2026-01-26 11:38 ` Andrey Albershteyn
2026-01-29 15:02 ` Christian Brauner
1 sibling, 0 replies; 3+ messages in thread
From: Andrey Albershteyn @ 2026-01-26 11:38 UTC (permalink / raw)
To: Eric Biggers
Cc: Andrey Albershteyn, Christian Brauner, linux-xfs, fstests, djwong,
fsverity
On 2026-01-24 10:49:54, Eric Biggers wrote:
> [+Cc fsverity@lists.linux.dev]
ops, wrong autocomplete, thanks!
>
> On Tue, Jan 20, 2026 at 04:39:17PM -0800, Eric Biggers wrote:
> > On Mon, Jan 19, 2026 at 05:56:43PM +0100, Andrey Albershteyn wrote:
> > [...]
> > > + TP_printk("ino %lu data size %llu tree size %llu block size %u levels %u",
> > [...]
> > > + TP_printk("ino %lu levels %d block_size %d tree_size %lld root_hash %s digest %s",
> >
> > Would be nice to make these consistent. 3 of the parameters are the
> > same, but the naming and order differs slightly.
> >
> > [...]
> > > + TP_printk("ino %lu pos %lld merkle_blocksize %u",
> > > + (unsigned long) __entry->ino,
> > > + __entry->data_pos,
> > > + __entry->block_size)
> >
> > Likewise here. So now we have "block size", "block_size", and
> > "merkle_blocksize", all for the same thing.
> >
> > > + TP_printk("ino %lu data_pos %llu hblock_idx %lu level %u hidx %u",
> > > + (unsigned long) __entry->ino,
> >
> > And here's data_pos as a %llu, whereas in the previous tracepoint it's
> > just pos as an %lld.
> >
> > > +TRACE_EVENT(fsverity_verify_merkle_block,
> > > + TP_PROTO(const struct inode *inode, unsigned long index,
> > > + unsigned int level, unsigned int hidx),
> >
> > And the 'index' here is what the previous one calls 'hblock_idx'.
> >
> > I think consistent naming would be helpful for people trying to use
> > these tracepoints.
>
> Andrey, let me know if you're planning to send a new version with the
> naming cleaned up, or if I should do it in a follow-up patch instead.
I will send v2 with renames
--
- Andrey
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH v2 2/2] fsverity: add tracepoints
2026-01-24 18:49 ` [PATCH v2 2/2] fsverity: add tracepoints Eric Biggers
2026-01-26 11:38 ` Andrey Albershteyn
@ 2026-01-29 15:02 ` Christian Brauner
1 sibling, 0 replies; 3+ messages in thread
From: Christian Brauner @ 2026-01-29 15:02 UTC (permalink / raw)
To: Eric Biggers; +Cc: Andrey Albershteyn, linux-xfs, fstests, djwong, fsverity
On Sat, Jan 24, 2026 at 10:49:54AM -0800, Eric Biggers wrote:
> [+Cc fsverity@lists.linux.dev]
>
> On Tue, Jan 20, 2026 at 04:39:17PM -0800, Eric Biggers wrote:
> > On Mon, Jan 19, 2026 at 05:56:43PM +0100, Andrey Albershteyn wrote:
> > [...]
> > > + TP_printk("ino %lu data size %llu tree size %llu block size %u levels %u",
> > [...]
> > > + TP_printk("ino %lu levels %d block_size %d tree_size %lld root_hash %s digest %s",
> >
> > Would be nice to make these consistent. 3 of the parameters are the
> > same, but the naming and order differs slightly.
> >
> > [...]
> > > + TP_printk("ino %lu pos %lld merkle_blocksize %u",
> > > + (unsigned long) __entry->ino,
> > > + __entry->data_pos,
> > > + __entry->block_size)
> >
> > Likewise here. So now we have "block size", "block_size", and
> > "merkle_blocksize", all for the same thing.
> >
> > > + TP_printk("ino %lu data_pos %llu hblock_idx %lu level %u hidx %u",
> > > + (unsigned long) __entry->ino,
> >
> > And here's data_pos as a %llu, whereas in the previous tracepoint it's
> > just pos as an %lld.
> >
> > > +TRACE_EVENT(fsverity_verify_merkle_block,
> > > + TP_PROTO(const struct inode *inode, unsigned long index,
> > > + unsigned int level, unsigned int hidx),
> >
> > And the 'index' here is what the previous one calls 'hblock_idx'.
> >
> > I think consistent naming would be helpful for people trying to use
> > these tracepoints.
>
> Andrey, let me know if you're planning to send a new version with the
> naming cleaned up, or if I should do it in a follow-up patch instead.
>
> Christian, can you let me know if it's okay if I take this series
> through the fsverity tree, or do you want it to go through the VFS tree?
Yeah, I can take them no biggie.
Tracepoints, heh, who would've thought.
^ permalink raw reply [flat|nested] 3+ messages in thread