[PATCH v2] fscrypt: improve filename encryption and decryption performance

[Yuwen Chen]

On Thu, 3 Jul 2025 22:14:41 -0700, Eric Biggers wrote:
> I'm guessing you have some debugging options enabled in your kconfig.  Usually
> the allocations aren't quite *that* expensive.  That being said, it's always
> been really annoying that they have to be there.

Turn off most of the debugging options and merge these two patches
for memory allocation. The performance test results are as follows:
Before this submission was merged, when creating 10000 files,
the performance test results are as follows:
$ time /data/file_creater 10000
0m10.90s real     0m00.00s user     0m10.69s system

After merge these two patches, the performance is as follows:
$ time /data/file_creater 10000
0m05.32s real     0m00.00s user     0m05.28s system

> Unfortunately, as far as I know, you actually can't just allocate the
> skcipher_request on the stack like that, since the legacy crypto API assumes
> that the request memory is DMA-able.  On-stack requests also might not be
> properly aligned (see
> https://lore.kernel.org/all/CA+55aFxJOzMim_d-O2E2yip8JWo0NdYs_72sNwFKSkTjy8q0Sw@xxxxxxxxxxxxxx/
> -- may be outdated, but I haven't heard otherwise).

Thank you for the reminder. This should be a problem here.
Just, why can SYNC_SKCIPHER_REQUEST_ON_STACK be allocated on
the stack? Is it possible to use ALIGN to achieve alignment?

> The problem is really that the legacy crypto API (crypto_skcipher in this case)
> was never really designed for efficient CPU-based crypto in the first place.
> The correct solution is to add simple library APIs for the algorithms to
> lib/crypto/, then update fscrypt to use that instead of crypto_skcipher.
> I plan to do that, but I'm first focusing on other related things, such as doing
> the same for fsverity.

This sounds very good. For file name decryption, due to the
relatively small amount of data, the cost of interface calls
indeed cannot be ignored. Thank you very much for your guidance.