linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ubifs: replay: fix high stack usage
@ 2018-11-02 15:39 Arnd Bergmann
  2018-11-02 20:29 ` Richard Weinberger
  0 siblings, 1 reply; 2+ messages in thread
From: Arnd Bergmann @ 2018-11-02 15:39 UTC (permalink / raw)
  To: Richard Weinberger, Artem Bityutskiy, Adrian Hunter
  Cc: Arnd Bergmann, Sascha Hauer, linux-mtd, linux-kernel

Having two shash descriptors on the stack cause a very significant kernel
stack usage that can cross the warning threshold:

fs/ubifs/replay.c: In function 'authenticate_sleb':
fs/ubifs/replay.c:633:1: error: the frame size of 1144 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Normally, gcc optimizes the out, but with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING,
it does not. Splitting the two stack allocations into separate functions
means that they will use the same memory again. In normal configurations
(optimizing for size or performance), those should get inlined and we get
the same behavior as before.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/ubifs/replay.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 75f961c4c044..a08c5b7030ea 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -533,6 +533,28 @@ static int is_last_bud(struct ubifs_info *c, struct ubifs_bud *bud)
 	return data == 0xFFFFFFFF;
 }
 
+/* authenticate_sleb_hash and authenticate_sleb_hmac are split out for stack usage */
+static int authenticate_sleb_hash(struct ubifs_info *c, struct shash_desc *log_hash, u8 *hash)
+{
+	SHASH_DESC_ON_STACK(hash_desc, c->hash_tfm);
+
+	hash_desc->tfm = c->hash_tfm;
+	hash_desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+
+	ubifs_shash_copy_state(c, log_hash, hash_desc);
+	return crypto_shash_final(hash_desc, hash);
+}
+
+static int authenticate_sleb_hmac(struct ubifs_info *c, u8 *hash, u8 *hmac)
+{
+	SHASH_DESC_ON_STACK(hmac_desc, c->hmac_tfm);
+
+	hmac_desc->tfm = c->hmac_tfm;
+	hmac_desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+
+	return crypto_shash_digest(hmac_desc, hash, c->hash_len, hmac);
+}
+
 /**
  * authenticate_sleb - authenticate one scan LEB
  * @c: UBIFS file-system description object
@@ -574,21 +596,12 @@ static int authenticate_sleb(struct ubifs_info *c, struct ubifs_scan_leb *sleb,
 
 		if (snod->type == UBIFS_AUTH_NODE) {
 			struct ubifs_auth_node *auth = snod->node;
-			SHASH_DESC_ON_STACK(hash_desc, c->hash_tfm);
-			SHASH_DESC_ON_STACK(hmac_desc, c->hmac_tfm);
-
-			hash_desc->tfm = c->hash_tfm;
-			hash_desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
 
-			ubifs_shash_copy_state(c, log_hash, hash_desc);
-			err = crypto_shash_final(hash_desc, hash);
+			err = authenticate_sleb_hash(c, log_hash, hash);
 			if (err)
 				goto out;
 
-			hmac_desc->tfm = c->hmac_tfm;
-			hmac_desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
-			err = crypto_shash_digest(hmac_desc, hash, c->hash_len,
-						  hmac);
+			err = authenticate_sleb_hmac(c, hash, hmac);
 			if (err)
 				goto out;
 
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] ubifs: replay: fix high stack usage
  2018-11-02 15:39 [PATCH] ubifs: replay: fix high stack usage Arnd Bergmann
@ 2018-11-02 20:29 ` Richard Weinberger
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Weinberger @ 2018-11-02 20:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Artem Bityutskiy, Adrian Hunter, Sascha Hauer, linux-mtd, linux-kernel

Am Freitag, 2. November 2018, 16:39:24 CET schrieb Arnd Bergmann:
> Having two shash descriptors on the stack cause a very significant kernel
> stack usage that can cross the warning threshold:
> 
> fs/ubifs/replay.c: In function 'authenticate_sleb':
> fs/ubifs/replay.c:633:1: error: the frame size of 1144 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> 
> Normally, gcc optimizes the out, but with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING,
> it does not. Splitting the two stack allocations into separate functions
> means that they will use the same memory again. In normal configurations
> (optimizing for size or performance), those should get inlined and we get
> the same behavior as before.

Thanks for addressing this, applied!

Thanks,
//richard



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-11-02 20:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-02 15:39 [PATCH] ubifs: replay: fix high stack usage Arnd Bergmann
2018-11-02 20:29 ` Richard Weinberger

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