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] [day] [month] [year] [list]
Message-ID: <20250528231856.GK4037@twin.jikos.cz>
Date: Thu, 29 May 2025 01:18:56 +0200
From: David Sterba <dsterba@...e.cz>
To: Daniel Vacek <neelx@...e.com>
Cc: dsterba@...e.cz, 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: btrfs_backref_link_edge() cleanup

On Mon, May 19, 2025 at 12:38:14PM +0200, Daniel Vacek wrote:
> On Thu, 15 May 2025 at 16:47, David Sterba <dsterba@...e.cz> wrote:
> >
> > Please write more descriptive subject lines, related to what is being
> > cleaned up, and not just a generic "function() cleanup".
> >
> > On Wed, May 14, 2025 at 03:12:39PM +0200, Daniel Vacek wrote:
> > > This function is always called with the LINK_LOWER argument. Thus we can
> > > simplify it and remove the LINK_LOWER and LINK_UPPER macros.
> > >
> > > The last call with LINK_UPPER was removed with commit
> > > 0097422c0dfe0a ("btrfs: remove clone_backref_node() from relocation")
> >
> > While removing the code is ok, looking to the git history I think
> > there's probably more, related to the node linking. Here it's removing
> > one half (LINK_UPPER).
> 
> I'm not sure what you mean here. I mentioned the commit you suggested.
> Checking the rest of edge linking I don't see how it could be
> trivially simplified further.

The idea is to look around if there's possibly more code to be removed,
not trivially but based on the logic related to the removed code for the
LOWER part. The relocation code is complicated so this is beyond the
cleanup and don't have a specific suggestion, so let's take what we have
now.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ