linux-ext4 - Re: [RFC PATCH v3 10/61] e2fsck: optionally configure one pfsck thread

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]

Date:   Mon, 23 Nov 2020 18:16:33 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Saranya Muruganandam <saranyamohan@...gle.com>
Cc:     linux-ext4@...r.kernel.org, adilger.kernel@...ger.ca,
        Li Xi <lixi@....com>, Wang Shilong <wshilong@....com>
Subject: Re: [RFC PATCH v3 10/61] e2fsck: optionally configure one pfsck
 thread

On Wed, Nov 18, 2020 at 07:38:56AM -0800, Saranya Muruganandam wrote:
> From: Li Xi <lixi@....com>
> 
> This patch creates only one thread to do pass1 check. The same
> codes can be used to create multiple threads, but other functions
> need to be modified to get ready for that.
> 
> pfsck support will be enabled with if configured with
> --enable-pfsck option.

This patch should probably be merged with patch #1 ("e2fsck: add -m
option for multithread").  That will make it be *much* easier to
review.

What I'd actually suggest is that we add some multi-threading support
into libext2fs as separate commits, and put them *first* in the patch
series.  They should ideally have their own unit tests so they can be
individually tested, but that way we can also review the library
changes *first* to make sure they make sense, and that way the
reviewer will understand what the library functions are before
reviewing the e2fsck patches.

I'd then also follow that up with a commit which compiles e2fsck with
the pthread library (and we need to make sure that is portable across
different OS's, and that it works when linking both statically and
dynamically), and then follow that up with e2fsck utility functions
that make life easier for the multi-threading changes --- for example,
a thread-safe logging abstraction.

Finally, I'd then add support to enable parallel fsck via a configure
option, with the default controlled by whether or not pthread support
is enabled.  (My main concern will be that there may be some minimal C
libraries which don't have threading support, when e2fsprogs is
compiled in some embedded environment.)

I'm not convinced that it makes sense to have a command-line thread to
enable multi-threading.  What probably makes more sense is to have
extended e2fsck option (using -E multithread, which takes an optional
argument indicating how many threads should be used).  In production,
the default of whether or not multi-threading should be enabled would
be via /etc/e2fsck.conf.

						- Ted