From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Kees Cook <keescook@chromium.org>,
qat-linux@intel.com,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Richard Weinberger <richard@nod.at>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
Minchan Kim <minchan@kernel.org>, Nick Terrell <terrelln@fb.com>,
netdev@vger.kernel.org, linux-mtd@lists.infradead.org,
Jakub Kicinski <kuba@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Paolo Abeni <pabeni@redhat.com>,
linuxppc-dev@lists.ozlabs.org, linux-crypto@vger.kernel.org
Subject: Re: [RFC PATCH 05/21] ubifs: Pass worst-case buffer size to compression routines
Date: Tue, 18 Jul 2023 15:38:13 -0700 [thread overview]
Message-ID: <20230718223813.GC1005@sol.localdomain> (raw)
In-Reply-To: <20230718125847.3869700-6-ardb@kernel.org>
On Tue, Jul 18, 2023 at 02:58:31PM +0200, Ard Biesheuvel wrote:
> Currently, the ubifs code allocates a worst case buffer size to
> recompress a data node, but does not pass the size of that buffer to the
> compression code. This means that the compression code will never use
> the additional space, and might fail spuriously due to lack of space.
>
> So let's multiply out_len by WORST_COMPR_FACTOR after allocating the
> buffer. Doing so is guaranteed not to overflow, given that the preceding
> kmalloc_array() call would have failed otherwise.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> fs/ubifs/journal.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
> index dc52ac0f4a345f30..4e5961878f336033 100644
> --- a/fs/ubifs/journal.c
> +++ b/fs/ubifs/journal.c
> @@ -1493,6 +1493,8 @@ static int truncate_data_node(const struct ubifs_info *c, const struct inode *in
> if (!buf)
> return -ENOMEM;
>
> + out_len *= WORST_COMPR_FACTOR;
> +
> dlen = le32_to_cpu(dn->ch.len) - UBIFS_DATA_NODE_SZ;
> data_size = dn_size - UBIFS_DATA_NODE_SZ;
> compr_type = le16_to_cpu(dn->compr_type);
This looks like another case where data that would be expanded by compression
should just be stored uncompressed instead.
In fact, it seems that UBIFS does that already. ubifs_compress() has this:
/*
* If the data compressed only slightly, it is better to leave it
* uncompressed to improve read speed.
*/
if (in_len - *out_len < UBIFS_MIN_COMPRESS_DIFF)
goto no_compr;
So it's unclear why the WORST_COMPR_FACTOR thing is needed at all.
- Eric
next prev parent reply other threads:[~2023-07-18 22:39 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 12:58 [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)" Ard Biesheuvel
2023-07-18 22:32 ` Eric Biggers
2023-07-18 22:54 ` Eric Biggers
2023-07-18 23:06 ` Ard Biesheuvel
2023-07-21 9:10 ` Simon Horman
2023-08-03 9:51 ` Giovanni Cabiddu
2023-08-03 9:59 ` Ard Biesheuvel
2023-08-03 10:29 ` Giovanni Cabiddu
2023-07-18 12:58 ` [RFC PATCH 02/21] crypto: qat - Drop support for allocating destination buffers Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 03/21] crypto: acompress - Drop destination scatterlist allocation feature Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 04/21] net: ipcomp: Migrate to acomp API from deprecated comp API Ard Biesheuvel
2023-07-21 9:11 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 05/21] ubifs: Pass worst-case buffer size to compression routines Ard Biesheuvel
2023-07-18 22:38 ` Eric Biggers [this message]
2023-07-19 8:33 ` Ard Biesheuvel
2023-07-19 14:23 ` Zhihao Cheng
2023-07-19 14:38 ` Ard Biesheuvel
2023-07-20 1:23 ` Zhihao Cheng
2023-07-18 12:58 ` [RFC PATCH 06/21] ubifs: Avoid allocating buffer space unnecessarily Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 07/21] ubifs: Migrate to acomp compression API Ard Biesheuvel
2023-07-21 9:19 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 08/21] zram: " Ard Biesheuvel
2023-07-21 9:22 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 09/21] crypto: nx - Migrate to scomp API Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 10/21] crypto: 842 - drop obsolete 'comp' implementation Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 11/21] crypto: deflate " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 12/21] crypto: lz4 " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 13/21] crypto: lz4hc " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 14/21] crypto: lzo-rle " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 15/21] crypto: lzo " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 16/21] crypto: zstd " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 17/21] crypto: cavium/zip " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 18/21] crypto: compress_null " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 19/21] crypto: remove obsolete 'comp' compression API Ard Biesheuvel
2023-07-21 11:07 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 20/21] crypto: deflate - implement acomp API directly Ard Biesheuvel
2023-07-21 11:12 ` Simon Horman
2023-07-21 11:17 ` Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 21/21] crypto: scompress - Drop the use of per-cpu scratch buffers Ard Biesheuvel
2023-07-28 9:55 ` [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs Herbert Xu
2023-07-28 9:57 ` Ard Biesheuvel
2023-07-28 9:59 ` Herbert Xu
2023-07-28 10:03 ` Ard Biesheuvel
2023-07-28 10:05 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230718223813.GC1005@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=axboe@kernel.dk \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=giovanni.cabiddu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=minchan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qat-linux@intel.com \
--cc=richard@nod.at \
--cc=senozhatsky@chromium.org \
--cc=steffen.klassert@secunet.com \
--cc=terrelln@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).