linux-kernel - Re: [PATCH 07/11] btrfs: move to fn pointers for get/put workspaces

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6f9b4be7-0ce8-bd62-c90d-f3f537528b7a@suse.com>
Date:   Tue, 29 Jan 2019 10:22:34 +0200
From:   Nikolay Borisov <nborisov@...e.com>
To:     Dennis Zhou <dennis@...nel.org>, David Sterba <dsterba@...e.com>,
        Josef Bacik <josef@...icpanda.com>, Chris Mason <clm@...com>,
        Omar Sandoval <osandov@...ndov.com>,
        Nick Terrell <terrelln@...com>
Cc:     kernel-team@...com, linux-btrfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/11] btrfs: move to fn pointers for get/put workspaces

On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> The previous patch added generic helpers for get_workspace() and
> put_workspace(). Now, we can migrate ownership of the workspace_manager
> to be in the compression type code as the compression code itself
> doesn't care beyond being able to get a workspace. The init/cleanup
> and get/put methods are abstracted so each compression algorithm can
> decide how they want to manage their workspaces.
> 
> Signed-off-by: Dennis Zhou <dennis@...nel.org>

TBH I can't really see the value in this patch. IMO it doesn't make the
code more readable, on the contrary, you create algorithm-specific
wrappers over the generic function, where the sole specialization is in
the arguments passed to the generic functions. You introduce 4 more
function pointers and this affects performance negatively (albeit can't
say to what extent) due to spectre mitigations (retpolines).

I also read the follow up patches with the hopes of seeing how the code
becomes cleaner to no avail. At this point I'm really not in favor of
this particular patch.