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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Mar 2023 11:50:47 -0400 From: "Theodore Ts'o" <tytso@....edu> To: Kemeng Shi <shikemeng@...weicloud.com> 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 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. 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. 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 Cheers, - Ted
Powered by blists - more mailing lists