linux-kernel - Re: [PATCH RFC -next 01/26] md/md-bitmap: introduce struct bitmap

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: <20240813085806.00006ec3@linux.intel.com>
Date: Tue, 13 Aug 2024 08:58:54 +0200
From: Mariusz Tkaczyk <mariusz.tkaczyk@...ux.intel.com>
To: Yu Kuai <yukuai1@...weicloud.com>
Cc: song@...nel.org, linux-kernel@...r.kernel.org,
 linux-raid@...r.kernel.org, yukuai3@...wei.com, yi.zhang@...wei.com,
 yangerkun@...wei.com
Subject: Re: [PATCH RFC -next 01/26] md/md-bitmap: introduce struct
 bitmap_operations

On Sat, 10 Aug 2024 10:08:29 +0800
Yu Kuai <yukuai1@...weicloud.com> wrote:

> From: Yu Kuai <yukuai3@...wei.com>
> 
> The structure is empty for now, and will be used in later patches to
> merge in bitmap operations, prepare to implement a new lock free
> bitmap in the fulture.

HI Kuai,

typo: future

I think that as "later" you meant next patches in this patchset, right? If yes,
Please you "next" instead.

At this point bringing "lock free implementation in the future" looks like
totally unnecessary. It may happen or may not. Eventually, You can mention it in
cover letter. What we have now is the most important.

This is just a code rework. The main goal of this (as you mentioned in second
patch):

"So that the implementation won't be exposed, and it'll be possible
to invent a new bitmap by replacing bitmap_operations."

but please mention that you are not going to implement second mechanism to not
confuse reader. You need it to improve code maintainability mainly I think.

I would mention something about common "struct _ops" pattern (the special
structure to keep related operations together) that it is going to follow now.

For me, this one can be easy merged with the patch 2, so we will got struct +
usage in one patch.

Anyway, LGTM.

Thanks,
Mariusz