linux-kernel - Re: [PATCH] btrfs: remove extent buffer's redundant `len` member field

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPjX3FfJqH9ErubwMkWfjYTZr6f0vFfShu=JghxHqZ4aVbNK3g@mail.gmail.com>
Date: Wed, 30 Apr 2025 14:53:42 +0200
From: Daniel Vacek <neelx@...e.com>
To: Filipe Manana <fdmanana@...nel.org>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>, 
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: remove extent buffer's redundant `len` member field

On Wed, 30 Apr 2025 at 14:34, Filipe Manana <fdmanana@...nel.org> wrote:
>
> On Wed, Apr 30, 2025 at 1:06 PM Daniel Vacek <neelx@...e.com> wrote:
> >
> > On Wed, 30 Apr 2025 at 12:26, Filipe Manana <fdmanana@...nel.org> wrote:
> > >
> > > On Wed, Apr 30, 2025 at 9:50 AM Daniel Vacek <neelx@...e.com> wrote:
> > > >
> > > > On Wed, 30 Apr 2025 at 10:34, Filipe Manana <fdmanana@...nel.org> wrote:
> > > > >
> > > > > On Wed, Apr 30, 2025 at 9:26 AM Daniel Vacek <neelx@...e.com> wrote:
> > > > > >
> > > > > > On Wed, 30 Apr 2025 at 10:06, Filipe Manana <fdmanana@...nel.org> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 29, 2025 at 4:19 PM Daniel Vacek <neelx@...e.com> wrote:
> > > > > > > >
> > > > > > > > Even super block nowadays uses nodesize for eb->len. This is since commits
> > > > > > > >
> > > > > > > > 551561c34663 ("btrfs: don't pass nodesize to __alloc_extent_buffer()")
> > > > > > > > da17066c4047 ("btrfs: pull node/sector/stripe sizes out of root and into fs_info")
> > > > > > > > ce3e69847e3e ("btrfs: sink parameter len to alloc_extent_buffer")
> > > > > > > > a83fffb75d09 ("btrfs: sink blocksize parameter to btrfs_find_create_tree_block")
> > > > > > > >
> > > > > > > > With these the eb->len is not really useful anymore. Let's use the nodesize
> > > > > > > > directly where applicable.
> > > > > > > >
> > > > > > > > Signed-off-by: Daniel Vacek <neelx@...e.com>
> > > > > > > > ---
> > > > > > > > [RFC]
> > > > > > > >  * Shall the eb_len() helper better be called eb_nodesize()? Or even rather
> > > > > > > >    opencoded and not used at all?
> > ...
> > > > > > > > +static inline u32 eb_len(const struct extent_buffer *eb)
> > > > > > > > +{
> > > > > > > > +       return eb->fs_info->nodesize;
> > > > > > > > +}
> > > > > > >
> > > > > > > Please always add a "btrfs_" prefix to the name of exported functions.
> > > > > >
> > > > > > It's static inline, not exported. But I'm happy just opencoding it
> > > > > > instead. Thanks.
> > > > >
> > > > > Exported in the sense that it's in a header and visible to any C files
> > > > > that include it, not in the sense of being exported with
> > > > > EXPORT_SYMBOL_GPL() for example.
> > > > > This is our coding style convention:
> > > > >
> > > > > https://btrfs.readthedocs.io/en/latest/dev/Development-notes.html#function-declarations
> > > > >
> > > > > static functions inside a C file can omit the prefix.
> > > >
> > > > Nah, thanks again. I was not aware of that. Will keep it in mind.
> > > >
> > > > Still, it doesn't make sense to me to be honest. I mean specifically
> > > > with this example. The header file is also private to btrfs, no public
> > > > API. Personally I wouldn't differentiate if it's a source or a header
> > > > file. The code can be freely moved around. And with the prefix the
> > > > code would end up more bloated and less readable, IMO. But let's not
> > > > start any flamewars here.
> > >
> > > I'd disagree about less readability. Reading code that calls a
> > > function with the btrfs prefix makes it clear it's a btrfs specific
> > > function.
> > > Looking at ext4 and xfs, functions declared or defined in their
> > > headers have a "ext4_", "ext_" or "xfs_" prefix.
> >
> > I see. Makes sense.
> > Does this also apply to preprocessor macros? I don't see them
> > mentioned in the development notes.
> > I'm asking as I did consider using a macro which would look a bit
> > cleaner perhaps, just one line instead of four. But it would also miss
> > the type checking.
> > So I guess the naming convention should also apply to macros, right?
> >
> > Finally quickly checking I see a lot of functions like eg.
> > free_extent_buffer(), free_extent_buffer_stale() and many others
> > violating the rule. I guess we should also clean up and rename them,
> > right?
>
> Haven't you seen patchsets from me in the last few weeks renaming
> functions from extent-io-tree.h and extent_map.h?

Yeah, I noticed and I like them. That's great stuff. I think we're
moving in the right direction.

> You'll see examples of where the prefix is missing, and this happens
> for very old code, we rename things from time to time.
> In those two cases I was motivated due to the need to add more
> functions soon, or having added some new ones not long ago, to make
> everything consistent in those headers/modules by making sure all have
> the "btrfs_" prefix.