On Thu, Jul 03, 2025 at 11:02:59PM -0700, Eric Biggers wrote: [Can you trim your replies to the usual 73 characters? The long lines make them quite hard to read without first reflowing them]
> The real problem is, once again, the legacy crypto_skcipher API, which > requires > that the source/destination buffers be provided as scatterlists. In Linux, > the > kernel stack can be in the vmalloc area. Thus, the buffers passed to > crypto_skcipher cannot be stack buffers unless the caller actually is aware of > how to turn a vmalloc'ed buffer into a scatterlist, which is hard to do. (See > verity_ahash_update() in drivers/md/dm-verity-target.c for an example.) I don't think setting up a scatterlist for vmalloc data is hard. But it is extra boilerplate code that is rather annoying and adds overhead. > code in the kernel uses is something that would be worth adopting for > now in fname_decrypt(). As I mentioned above, it's hard to do (you > have to go page by page), but it's possible. That would allow > immediately moving generic_ci_match() to use a stack allocation, which > would avoid adding all the complexity of the preallocation that you > have in this patchset. I suspect that all the overhead required for that get close to that of a memory allocation. But I wonder why generic_ci_match is even called that often. Both ext4 and f2fs support hashed lookups, so you should usually only see it called for the main match, plus the occasional hash false positive, which should be rate if the hash works. Yuwen, are you using f2fs in the mode where it does a linear scan on a hash lookup miss? That was added as a workaround for the utf8 code point changes, but is a completely broken idea the defeats hashed lookups and IIRC only was default for a very short time. Note that even with this fixed, using an on-stack allocation would be nice eventually when moving the crypto library API, as it would still avoid the allocation entirely. But caching shouldn't be worth it if the number of generic_ci_match per lookup is just slightly above 1. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
