On Wed, Apr 10, 2019 at 12:27:54PM +0200, Thomas Gleixner wrote: > Struct stack_trace is a sinkhole for input and output parameters which is > largely pointless for most usage sites. In fact if embedded into other data > structures it creates indirections and extra storage overhead for no benefit. > > Looking at all usage sites makes it clear that they just require an > interface which is based on a storage array. That array is either on stack, > global or embedded into some other data structure. > > Some of the stack depot usage sites are outright wrong, but fortunately the > wrongness just causes more stack being used for nothing and does not have > functional impact. > > Another oddity is the inconsistent termination of the stack trace with > ULONG_MAX. It's pointless as the number of entries is what determines the > length of the stored trace. In fact quite some call sites remove the > ULONG_MAX marker afterwards with or without nasty comments about it. Not > all architectures do that and those which do, do it inconsistenly either > conditional on nr_entries == 0 or unconditionally. > > The following series cleans that up by: > > 1) Removing the ULONG_MAX termination in the architecture code > > 2) Removing the ULONG_MAX fixups at the call sites > > 3) Providing plain storage array based interfaces for stacktrace and > stackdepot. > > 4) Cleaning up the mess at the callsites including some related > cleanups. > > 5) Removing the struct stack_trace based interfaces > > This is not changing the struct stack_trace interfaces at the architecture > level, but it removes the exposure to the generic code. > > It's only lightly tested as I'm traveling and access to my test boxes is > limited.
This is indeed a much needed cleanup; thanks for starting this. I didn't spot anything wrong while reading through it, so: Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org>
