From: Behan Webster <behanw@converseincode.com>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: "Joe Perches" <joe@perches.com>,
linville@tuxdriver.com, johannes@sipsolutions.net,
davem@davemloft.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dwmw2@infradead.org, pageexec@freemail.hu,
"Jan-Simon Möller" <dl9pf@gmx.de>,
"Vinícius Tinti" <viniciustinti@gmail.com>,
"Mark Charlebois" <charlebm@gmail.com>
Subject: Re: [PATCH v2] mac80211: LLVMLinux: Remove VLAIS usage from mac80211
Date: Sat, 08 Mar 2014 13:36:40 -0800 [thread overview]
Message-ID: <531B8D68.7020801@converseincode.com> (raw)
In-Reply-To: <20140308145309.GA1615@redhat.com>
On 03/08/14 06:53, Stanislaw Gruszka wrote:
> On Fri, Mar 07, 2014 at 06:15:43PM -0800, Behan Webster wrote:
>> On 03/07/14 17:56, Joe Perches wrote:
>>> On Fri, 2014-03-07 at 17:26 -0800, behanw@converseincode.com wrote:
>>>> From: Jan-Simon Möller <dl9pf@gmx.de>
>>>>
>>>> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
>>>> compliant equivalent. This is the original VLAIS struct.
>>> []
>>>> diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
>>> []
>>>> @@ -23,12 +23,14 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
>>>> u8 *data, size_t data_len, u8 *mic)
>>>> {
>>>> struct scatterlist assoc, pt, ct[2];
>>>> - struct {
>>>> - struct aead_request req;
>>>> - u8 priv[crypto_aead_reqsize(tfm)];
>>>> - } aead_req;
>>>> - memset(&aead_req, 0, sizeof(aead_req));
>>>> + char aead_req_data[sizeof(struct aead_request) +
>>>> + crypto_aead_reqsize(tfm) +
>>>> + CRYPTO_MINALIGN] CRYPTO_MINALIGN_ATTR;
>>> Can this be a too large amount of stack?
>>>
>>> Is crypto_aead_reqsize() limited to < ~1k?
>>>
>>> Perhaps it'd be better to use kzalloc for this
>>> or another reserved pool
>> No more stack being used than with the the original code. The stack
>> memory use is identical.
> Could you explain that? It looks like aead_req_data can be bigger than
> original struct aead_req up to CRYPTO_MINALIGN bytes. IOW adding
> CRYPTO_MINALIGN to size seems unneeded as aead_request->__ctx alignment
> requirement should by assured by proper sizeof(struct aead_request).
True, possibly a few more bytes. Nothing significant. However, I will
fix this too.
> Besides, why not add VLAIS feature to llvm instead of fixing all
> programs that use it?
You aren't the first to ask this (I certainly get asked this regularly). :)
VLAIS is specifically disallowed by the C89, C99, and later C standards.
VLAIS is also not an officially documented feature of gcc (It is a side
effect from the support of other languages supported by the gcc
toolchain). The LLVM project won't add VLAIS support for these reasons,
and because it would unnecessarily complicate their compiler
architecture with almost no appreciable gain.
VLAIS is only used in a handful of places in the kernel (almost
exclusively in crypto related code), so changing it in the kernel not
only is easier, but also makes the kernel code C99 (and beyond)
compliant. Being standards compliant is important not only for clang,
but also for newer versions of gcc (though not yet in the case of VLAIS).
VLAIS should not be confused with Variable Length Arrays (VLA) and
flexible members (undefined or zero length arrays at the end of a non
embedded struct) which are both explicitly in the C standards and
supported by both gcc and clang.
Behan
--
Behan Webster
behanw@converseincode.com
next prev parent reply other threads:[~2014-03-08 21:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 19:52 [PATCH] mac80211: LLVMLinux: Remove VLAIS usage from mac80211 behanw
2014-03-07 7:24 ` Johannes Berg
2014-03-08 1:26 ` [PATCH v2] " behanw
[not found] ` <1394241960-1764-1-git-send-email-behanw-k/hB3zQhLwledRVtV/plodBPR1lH4CV8@public.gmane.org>
2014-03-08 1:56 ` Joe Perches
2014-03-08 2:15 ` Behan Webster
[not found] ` <531A7D4F.7090303-k/hB3zQhLwledRVtV/plodBPR1lH4CV8@public.gmane.org>
2014-03-08 2:27 ` Joe Perches
2014-03-08 20:17 ` Behan Webster
2014-03-08 14:53 ` Stanislaw Gruszka
2014-03-08 21:36 ` Behan Webster [this message]
2014-03-08 20:29 ` Sergei Antonov
2014-03-08 20:42 ` Behan Webster
2014-03-08 22:01 ` PaX Team
2014-03-08 23:00 ` Sergei Antonov
[not found] ` <CABikg9x+Z95bHcDc6iu5hBvRNO-ibM8-34_qA+OA_FjB52SPMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-08 23:41 ` Jan-Simon Möller
2014-03-09 1:58 ` Behan Webster
2014-03-19 3:32 ` [PATCH v3] " behanw
2014-03-19 13:51 ` Johannes Berg
2014-03-19 14:25 ` Behan Webster
[not found] ` <1395237113.4142.5.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2014-03-21 6:39 ` [PATCH v4] " behanw-k/hB3zQhLwledRVtV/plodBPR1lH4CV8
2014-03-21 11:59 ` Johannes Berg
2014-03-19 14:09 ` [PATCH v3] " David Laight
2014-03-09 0:01 ` [PATCH v2] " David Miller
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=531B8D68.7020801@converseincode.com \
--to=behanw@converseincode.com \
--cc=charlebm@gmail.com \
--cc=davem@davemloft.net \
--cc=dl9pf@gmx.de \
--cc=dwmw2@infradead.org \
--cc=joe@perches.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=pageexec@freemail.hu \
--cc=sgruszka@redhat.com \
--cc=viniciustinti@gmail.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).