From: Ivan Djelic <ivan.djelic@parrot.com>
To: Kees Cook <keescook@chromium.org>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Linux mtd <linux-mtd@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] lib/bch: Remove VLA usage
Date: Thu, 31 May 2018 10:52:21 +0200 [thread overview]
Message-ID: <20180531085221.GA29786@parrot.com> (raw)
In-Reply-To: <20180530212206.GA36883@beast>
On Wed, May 30, 2018 at 02:22:06PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates a fixed size stack array to cover the range needed for
> bch. This was done instead of a preallocation on the SLAB due to
> performance reasons, shown by Ivan Djelic:
>
> little-endian, type sizes: int=4 long=8 longlong=8
> cpu: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz
> calibration: iter=4.9143µs niter=2034 nsamples=200 m=13 t=4
>
> Buffer allocation | Encoding throughput (Mbit/s)
> ---------------------------------------------------
> on-stack, VLA | 3988
> on-stack, fixed | 4494
> kmalloc | 1967
>
> So this change actually improves performance too, it seems.
>
> The resulting stack allocation can get rather large; without
> CONFIG_BCH_CONST_PARAMS, it will allocate 4096 bytes, which
> trips the stack size checking:
>
> lib/bch.c: In function ‘encode_bch’:
> lib/bch.c:261:1: warning: the frame size of 4432 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>
> Even the default case for "allmodconfig" (with CONFIG_BCH_CONST_M=14 and
> CONFIG_BCH_CONST_T=4) would have started throwing a warning:
>
> lib/bch.c: In function ‘encode_bch’:
> lib/bch.c:261:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>
> But this is how large it's always been; it was just hidden from
> the checker because it was a VLA. So the Makefile has been adjusted to
> silence this warning for anything smaller than 4500 bytes, which should
> provide room for normal cases, but still low enough to catch any future
> pathological situations.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> v2: switch to fixed-size stack array
> ---
(...)
> #define BCH_ECC_WORDS(_p) DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
> #define BCH_ECC_BYTES(_p) DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
>
> +#define BCH_ECC_MAX_WORDS DIV_ROUND_UP(BCH_MAX_M * BCH_MAX_T, 32)
> +#define BCH_ECC_MAX_BYTES DIV_ROUND_UP(BCH_MAX_M * BCH_MAX_T, 8)
> +
> #ifndef dbg
> #define dbg(_fmt, args...) do {} while (0)
> #endif
> @@ -187,7 +194,8 @@ void encode_bch(struct bch_control *bch, const uint8_t *data,
> const unsigned int l = BCH_ECC_WORDS(bch)-1;
> unsigned int i, mlen;
> unsigned long m;
> - uint32_t w, r[l+1];
> + uint32_t w, r[BCH_ECC_MAX_WORDS];
> + const size_t r_bytes = BCH_ECC_BYTES(bch);
Here 'r_bytes' is too small, because BCH_ECC_BYTES(bch) != BCH_ECC_WORDS(bch)*sizeof(uint32_t).
It should be:
const size_t r_bytes = BCH_ECC_WORDS(bch)*sizeof(uint32_t);
or an equivalent like:
const size_t r_bytes = (l+1)*sizeof(*bch->ecc_buf);
The rest of the patch seems fine to me.
BR,
--
Ivan
prev parent reply other threads:[~2018-05-31 8:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 21:22 [PATCH v2] lib/bch: Remove VLA usage Kees Cook
2018-05-31 8:52 ` Ivan Djelic [this message]
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=20180531085221.GA29786@parrot.com \
--to=ivan.djelic@parrot.com \
--cc=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.