linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).