On Fri, Feb 23, 2024 at 10:27:35AM -0800, Eric Biggers wrote: > On Fri, Feb 23, 2024 at 02:23:52PM +0100, Andrey Albershteyn wrote: > > On 2024-02-22 21:31:56, Eric Biggers wrote: > > > On Mon, Feb 12, 2024 at 05:58:06PM +0100, Andrey Albershteyn wrote: > > > > fs-verity previously had debug printk but it was removed. This patch > > > > adds trace points to the same places where printk were used (with a > > > > few additional ones). > > > > > > Are all of these actually useful? There's a maintenance cost to adding all of > > > these. > > > > > > > Well, they were useful for me while testing/working on this > > patchset. Especially combining -e xfs -e fsverity was quite good for > > checking correctness and debugging with xfstests tests. They're > > probably could be handy if something breaks. > > > > Or you mean if each of them is useful? The ones which I added to > > signature verification probably aren't as useful as other; my > > intention adding them was to also cover these code paths. > > Well, I'll have to maintain all of these, including reviewing them, keeping them > working as code gets refactored, and fixing any bugs that exist or may get > introduced later in them. They also increase the icache footprint of the code. > I'd like to make sure that it will be worthwhile. The pr_debug messages that I > had put in fs/verity/ originally were slightly useful when writing fs/verity/ > originally, but after that I never really used them. Instead I found they > actually made patching fs/verity/ a bit harder, since I had to make sure to keep > all the pr_debug statements updated as code changed around them. pr_debug is largely useless outside of code development purposes. The value in tracepoints is that they are available for diagnosing problems on production systems and should be thought of as such. Yes, you can also use them to debug development code, but in that environment they are no substitute for custom trace_printk() debug output. However, when you have extensive tracepoints coverage, the amount of custom trace_printk() stuff you need to add to a kernel to debug an issue ends up being limited, because most of the key state and object changes in the code are already covered by tracepoints. > Maybe I am an outlier and other people really do like having these tracepoints > around. But I'd like to see a bit more feedback along those lines first. If we > could keep them to a more minimal set, that would also be helpful. For people who are used to subsystems with extensive tracepoint coverage (like XFS), the lack of tracepoints in all the surrounding code is jarring. It makes the rest of the system feel like a black hole where detailed runtime introspection is almost completely impossible without a *lot* of work. Extensive tracepoints help everyone in the production support and diagnosis chain understand what is going on by providing easy to access runtime introspection for the code. i.e. they provide benefit to far more people than just the one kernel developer who enables pr_debug on the subsystem when developing new code... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
