[PATCH] fsck: add --workers option to configure worker threads

[PATCH] fsck: add --workers option to configure worker threads

[Utkal Singh]

Add a --workers=# command-line option to fsck.erofs to allow users
to configure the number of worker threads used during verification.

Parse the value using strtoul() and validate it against UINT_MAX
before storing it in fsckcfg.nr_workers. Return -EINVAL for invalid
inputs (non-numeric characters or out-of-range values).

Signed-off-by: Utkal Singh <singhutkal015@gmail.com>
---
 fsck/main.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/fsck/main.c b/fsck/main.c
index 16cc627..37e21f4 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -4,6 +4,7 @@
  * Author: Daeho Jeong <daehojeong@google.com>
  */
 #include <stdlib.h>
+#include <limits.h>
 #include <getopt.h>
 #include <time.h>
 #include <utime.h>
@@ -42,6 +43,7 @@ struct erofsfsck_cfg {
 	erofs_nid_t nid;
 	const char *inode_path;
 	bool nosbcrc;
+	unsigned int nr_workers;
 };
 static struct erofsfsck_cfg fsckcfg;
 
@@ -64,6 +66,7 @@ static struct option long_options[] = {
 	{"nid", required_argument, 0, 15},
 	{"path", required_argument, 0, 16},
 	{"no-sbcrc", no_argument, 0, 512},
+	{"workers", required_argument, 0, 17},
 	{0, 0, 0, 0},
 };
 
@@ -117,6 +120,7 @@ static void usage(int argc, char **argv)
 		" --nid=#                check or extract from the target inode of nid #\n"
 		" --path=X               check or extract from the target inode of path X\n"
 		" --no-sbcrc             bypass the superblock checksum verification\n"
+		" --workers=#            number of worker threads\n"
 		" --[no-]xattrs          whether to dump extended attributes (default off)\n"
 		"\n"
 		" -a, -A, -y             no-op, for compatibility with fsck of other filesystems\n"
@@ -257,6 +261,15 @@ static int erofsfsck_parse_options_cfg(int argc, char **argv)
 		case 16:
 			fsckcfg.inode_path = optarg;
 			break;
+		case 17: {
+			char *endptr;
+			unsigned long v = strtoul(optarg, &endptr, 0);
+
+			if (*endptr || v > UINT_MAX)
+				return -EINVAL;
+			fsckcfg.nr_workers = v;
+			break;
+		}
 		case 512:
 			fsckcfg.nosbcrc = true;
 			break;
-- 
2.43.0

Re: [PATCH] fsck: add --workers option to configure worker threads

[Nithurshen]

Hi Utkal,

I've run some tests on your patch.

I compiled fsck.erofs locally, generated a test EROFS image, and passed
various valid and invalid inputs to the new --workers flag (positive
integers, hex, trailing garbage, overflow, and negative numbers).

The happy path works perfectly. The *endptr check correctly catches
trailing garbage, and standard overflows are handled well.

I would suggest changes:
There's a hidden edge case with negative numbers (like --workers=-1)
on 32-bit systems. Because strtoul() is used, a negative number wraps
around to ULONG_MAX. On 64-bit machines, this is safely caught by your
v > UINT_MAX check. However, on 32-bit machines, ULONG_MAX equals
UINT_MAX, meaning -1 will bypass the check and attempt to spawn
4.2 billion threads.

Also, when -EINVAL is returned, fsck silently prints the generic help
menu without explaining what went wrong.

Therefore, in case you decide to send a v2 patch,
1. Switch to strtol() instead of strtoul() so you can explicitly catch
   negative numbers or zero (e.g., `if (*endptr || v <= 0 || ...)`).
2. Add an explicit error message (e.g., using erofs_err) before
   returning -EINVAL so the user knows their input was invalid.

These are just my opinion, but follow what the lead maintainers say.

Best,
Nithurshen

Re: [PATCH] fsck: add --workers option to configure worker threads

[Nithurshen]

As you know, currently decompression process in fsck.erofs is currently
strictly single threaded. In fsck/main.c, erofs_verify_inode_data
still processes blocks synchronously via a standard while loop.
Without wiring this flag to the workqueue engine in lib/workqueue.c,
the option doesn't currently change the tool's behavior.

And as you know "Multi-threaded Decompression Support in fsck.erofs"
is actually an official GSoC 2026 project idea and the project will
likely involve a comprehensive design of the parallelized
architecture, landing just the --workers CLI portion now might be
premature or conflict with the eventual design chosen by the GSoC
contributor.

I'd suggest reaching out to the mentors on the list to see if they
want to hold off on this patch until the GSoC project kicks off.
Also, if you do send a v2, switching to strtol() would be safer to
avoid potential -1 wrap-around issues on 32-bit systems.

Best,
Nithurshen

Re: [PATCH] fsck: add --workers option to configure worker threads

[Utkal Singh]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

Hi Nithurshen,

Thanks for testing the patch and for the detailed feedback.

You're right about the strtoul() wrap-around on 32-bit systems — I'll
switch to strtol() and add explicit error reporting in v2.

Regarding the design concern: I agree that landing just the CLI
portion without wiring it to the workqueue may be premature. I'll
hold off on v2 until we hear from Gao Xiang on whether this should
wait for the broader multi-threaded fsck design.

Thanks,
Utkal

On Sun, 22 Mar 2026 at 14:27, Nithurshen <nithurshen.dev@gmail.com> wrote:

> As you know, currently decompression process in fsck.erofs is currently
> strictly single threaded. In fsck/main.c, erofs_verify_inode_data
> still processes blocks synchronously via a standard while loop.
> Without wiring this flag to the workqueue engine in lib/workqueue.c,
> the option doesn't currently change the tool's behavior.
>
> And as you know "Multi-threaded Decompression Support in fsck.erofs"
> is actually an official GSoC 2026 project idea and the project will
> likely involve a comprehensive design of the parallelized
> architecture, landing just the --workers CLI portion now might be
> premature or conflict with the eventual design chosen by the GSoC
> contributor.
>
> I'd suggest reaching out to the mentors on the list to see if they
> want to hold off on this patch until the GSoC project kicks off.
> Also, if you do send a v2, switching to strtol() would be safer to
> avoid potential -1 wrap-around issues on 32-bit systems.
>
> Best,
> Nithurshen
>

[-- Attachment #2: Type: text/html, Size: 1970 bytes --]

Re: [PATCH] fsck: add --workers option to configure worker threads

[Gao Xiang]

On 2026/3/22 17:31, Utkal Singh wrote:
> Hi Nithurshen,
> 
> Thanks for testing the patch and for the detailed feedback.
> 
> You're right about the strtoul() wrap-around on 32-bit systems — I'll
> switch to strtol() and add explicit error reporting in v2.
> 
> Regarding the design concern: I agree that landing just the CLI
> portion without wiring it to the workqueue may be premature. I'll
> hold off on v2 until we hear from Gao Xiang on whether this should
> wait for the broader multi-threaded fsck design.

This patch is simply not needed as an individual patch.

> 
> Thanks,
> Utkal
> 
> On Sun, 22 Mar 2026 at 14:27, Nithurshen <nithurshen.dev@gmail.com> wrote:
> 
>> As you know, currently decompression process in fsck.erofs is currently
>> strictly single threaded. In fsck/main.c, erofs_verify_inode_data
>> still processes blocks synchronously via a standard while loop.
>> Without wiring this flag to the workqueue engine in lib/workqueue.c,
>> the option doesn't currently change the tool's behavior.
>>
>> And as you know "Multi-threaded Decompression Support in fsck.erofs"
>> is actually an official GSoC 2026 project idea and the project will
>> likely involve a comprehensive design of the parallelized
>> architecture, landing just the --workers CLI portion now might be
>> premature or conflict with the eventual design chosen by the GSoC
>> contributor.
>>
>> I'd suggest reaching out to the mentors on the list to see if they
>> want to hold off on this patch until the GSoC project kicks off.
>> Also, if you do send a v2, switching to strtol() would be safer to
>> avoid potential -1 wrap-around issues on 32-bit systems.
>>
>> Best,
>> Nithurshen
>>
> 

Re: [PATCH] fsck: add --workers option to configure worker threads

[Utkal Singh]

Understood. I'll drop this patch and fold the --workers
option into the full MT implementation once the design
is settled. Thanks for the feedback.

Utkal

On Sun, 22 Mar 2026 at 15:18, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2026/3/22 17:31, Utkal Singh wrote:
> > Hi Nithurshen,
> >
> > Thanks for testing the patch and for the detailed feedback.
> >
> > You're right about the strtoul() wrap-around on 32-bit systems — I'll
> > switch to strtol() and add explicit error reporting in v2.
> >
> > Regarding the design concern: I agree that landing just the CLI
> > portion without wiring it to the workqueue may be premature. I'll
> > hold off on v2 until we hear from Gao Xiang on whether this should
> > wait for the broader multi-threaded fsck design.
>
> This patch is simply not needed as an individual patch.
>
> >
> > Thanks,
> > Utkal
> >
> > On Sun, 22 Mar 2026 at 14:27, Nithurshen <nithurshen.dev@gmail.com> wrote:
> >
> >> As you know, currently decompression process in fsck.erofs is currently
> >> strictly single threaded. In fsck/main.c, erofs_verify_inode_data
> >> still processes blocks synchronously via a standard while loop.
> >> Without wiring this flag to the workqueue engine in lib/workqueue.c,
> >> the option doesn't currently change the tool's behavior.
> >>
> >> And as you know "Multi-threaded Decompression Support in fsck.erofs"
> >> is actually an official GSoC 2026 project idea and the project will
> >> likely involve a comprehensive design of the parallelized
> >> architecture, landing just the --workers CLI portion now might be
> >> premature or conflict with the eventual design chosen by the GSoC
> >> contributor.
> >>
> >> I'd suggest reaching out to the mentors on the list to see if they
> >> want to hold off on this patch until the GSoC project kicks off.
> >> Also, if you do send a v2, switching to strtol() would be safer to
> >> avoid potential -1 wrap-around issues on 32-bit systems.
> >>
> >> Best,
> >> Nithurshen
> >>
> >
>