linux-kernel - Re: [PATCH v3 20/20] ext4: simplify calculation of blkoff in ext4_mb_new_blocks

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: <c4ac2156-b773-bc9e-a764-8c3beeeaf3ac@huaweicloud.com>
Date:   Mon, 20 Mar 2023 15:31:55 +0800
From:   Kemeng Shi <shikemeng@...weicloud.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     adilger.kernel@...ger.ca, ojaswin@...ux.ibm.com,
        ritesh.list@...il.com,
        Harshad Shirwadkar <harshadshirwadkar@...il.com>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 20/20] ext4: simplify calculation of blkoff in
 ext4_mb_new_blocks_simple



on 3/17/2023 11:50 PM, Theodore Ts'o wrote:
> On Thu, Mar 16, 2023 at 06:19:40PM +0800, Kemeng Shi wrote:
>> Hi Theodore, thanks for feedback. I will submit another patchset for
>> mballoc and I would like to include this fix if no one else does. As
>> new patches may be conflicted with old ones I submited, I would submit
>> the new patchset after the old ones are fully reviewed and applied
>> if this fix is not in rush. Thanks!
> 
> Hi, I've already taken the your patches into the dev branch; were
> there any changes you were intending to make to your patches?
> 
> If you could submit a separate fix for the bug that I noticed, that
> would be great.
Hi, I was stuck in some urgent work recently and I will do this ASAP and
it should be done in this week.
> Also, if you are interested in doing some more work in mballoc.c, I
> was wondering if you would be interested in adding some Kunit tests
> for mballoc.c.  A simple example Kunit test for ext4 can be found in
> fs/ext4/inode_test.c.  (The convention is to place tests for foo.c in
> foo_test.c.)

> [1] https://docs.kernel.org/dev-tools/kunit/
> 
> In order to add mballoc Kunit tests, we will need to add some "mock"[2]
> functions to simulate what happens when mballoc.c tries reading a
> block bitmap.  My thinking was to have a test provide an array of some
> data structure like this:
> 
> struct test_bitmap {
>        unsigned int	start;
>        unsigned int	len;
> };
> 
> [2] https://en.wikipedia.org/wiki/Mock_object
> 
> ... which indicates the starting block, and the length of a run of
> blocks that are marked as in use, where the list of blocks are sorted
> by starting block number, and where a starting block of ~0 indicates
> the end of the list of block extents.
> We would also need have a set of utility ext4 Kunit functions to
> create "fake" ext4 superblocks and ext4_sb_info structures.
The Kunit tests thing sounds interesting and I would like to this. But
I still need some time to get basic knowledge then I maybe able to discuss
detais. Of couse, anyone is also interesting in this and can make this work
soon is fine.:)
> I was originally thinking that obvious starting Kunit tests would be
> for fs/ext4/hash.c and fs/ext4/extents_status.c, since they require
> the little or no "mocking" support.  However, there are so many
> changes in fs/ext4/mballoc.c, the urgency in having unit tests for it
> is getting more urgent --- since if there is a bug in one of these
> functions, such as the one that I noted in
> ext4_mb_new_blocks_simple(), since it's harder to exhaustively test
> some of these smaller sub-functions in integration tests such as those
> found in xfstests.  Unit tests are the best way to make sure we're
> testing all of the code paths in a complex module such as mballoc.c
Yes, I can't agree more and this may be able to find other exsiting bugs.

-- 
Best wishes
Kemeng Shi