On Tue, Aug 20, 2024 at 4:51 PM Chris Li chrisl@kernel.org wrote:
On Mon, Aug 19, 2024 at 10:05 PM Andrew Morton akpm@linux-foundation.org wrote:
On Mon, 19 Aug 2024 19:44:25 +0800 Kairui Song ryncsn@gmail.com wrote:
--- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -836,7 +836,7 @@ static unsigned long cluster_alloc_swap_entry(struct swap_info_struct *si, int o goto done;
/* Order 0 stealing from higher order */
for (int o = 1; o < PMD_ORDER; o++) {
for (int o = 1; o < SWAP_NR_ORDERS; o++) { /* * Clusters here have at least one usable slots and can't fail order 0 * allocation, but reclaim may drop si->lock and race with another user.OK, I got that landed in the right place, but...
The definition of `o' within the for statement isn't typical kernel style - I'm surprised we didn't get a warning for this - maybe things have changed when I wasn't looking.
Noted.
I did use the checkpatch.pl and fixed all the warnings before I sent the patch out. The checkpatch.pl script did not complain about this. Sure I can stay away from it. BTW, I did a search on the kernel tree: $ rg 'for (int' | wc -l 970 $ It seems pretty common in the kernel tree now.
Might be off topic from the issue...
I believe this issue it's not an upstream problem nowadays after e8c07082a810 ("Kbuild: move to -std=gnu11"), I did notice a GCC error after backporting these commits to an older kernel which still used c89, but for upstream this should be OK?
Also, this code makes no attempt to honor our "The preferred limit on the length of a single line is 80 columns" objective. There's just no reason for comment blocks to violate this.
I was wondering why the checkpatch.pl did not catch this, is there any config for checkpatch.pl I should apply?
I typically invoke:
./scripts/checkpatch.pl -g HEAD
I found checkpatch.pl stopped checking for 80 columns limit after commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning") 4 years ago. But the 80 column limit seems still preferred?