netdev - Re: pull-request: mac80211-next 2019-07-31

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 28 Oct 2019 12:38:29 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        John Crispin <john@...ozen.org>
Subject: Re: pull-request: mac80211-next 2019-07-31

On Mon, 2019-10-28 at 12:08 +0100, Johannes Berg wrote:
> On Mon, 2019-10-28 at 11:53 +0100, Arnd Bergmann wrote:
> > > Why do you say 32-bit btw, it should be *bigger* on 64-bit, but I didn't
> > > see this ... hmm.
> > 
> > That is correct. For historic reasons, both the total amount of stack space
> > per thread and the warning limit on 64 bit are twice the amount that we
> > have on 32-bit kernels, so even though the problem is more serious on
> > 64-bit architectures, we do not see a warning about it because we remain
> > well under the warning limit.
> 
> Hmm, but I have:
> 
> CONFIG_FRAME_WARN=1024
> 
> in my compilation

But the compiler decides not to inline it, for whatever reason. Only if
I mark it as __always_inline, does it actually inline it.

But it does seem to merge the storage, if I inline only assoc_success()
I get 888 bytes (after the fix), if I inline also
ieee80211_rx_mgmt_assoc_resp() then I get 904 bytes.

johannes