public inbox for fsverity@lists.linux.dev
 help / color / mirror / Atom feed
* Re: [PATCH v2 2/2] fsverity: add tracepoints
       [not found]   ` <20260121003917.GC12110@quark>
@ 2026-01-24 18:49     ` Eric Biggers
  2026-01-26 11:38       ` Andrey Albershteyn
  2026-01-29 15:02       ` Christian Brauner
  0 siblings, 2 replies; 3+ messages in thread
From: Eric Biggers @ 2026-01-24 18:49 UTC (permalink / raw)
  To: Andrey Albershteyn, Christian Brauner
  Cc: linux-xfs, fstests, djwong, fsverity

[+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?

Thanks,

- Eric

^ 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: 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

end of thread, other threads:[~2026-01-29 15:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20260119165644.2945008-1-aalbersh@kernel.org>
     [not found] ` <20260119165644.2945008-3-aalbersh@kernel.org>
     [not found]   ` <20260121003917.GC12110@quark>
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox