From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0C18C2D0F9 for ; Tue, 12 May 2020 20:31:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C314D206DD for ; Tue, 12 May 2020 20:31:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731064AbgELUbs (ORCPT ); Tue, 12 May 2020 16:31:48 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:44327 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725987AbgELUbr (ORCPT ); Tue, 12 May 2020 16:31:47 -0400 Received: from mail-qk1-f176.google.com ([209.85.222.176]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Mr9Jw-1imwKd1034-00oBq5; Tue, 12 May 2020 22:31:45 +0200 Received: by mail-qk1-f176.google.com with SMTP id b6so14003341qkh.11; Tue, 12 May 2020 13:31:44 -0700 (PDT) X-Gm-Message-State: AGi0PuYyxWOJrZuTfJ0dn4e/8vq/2feu86nzh6vZHk/Ypi+il7F2e/U6 dY81jpYiNcxCtVQ8feCcnRK71UGrj8SIyarvDgk= X-Google-Smtp-Source: APiQypIKCdaOu3b8S6gkZ0qkFU4jDbgQtG+5bVY9dwPACknqdZumuyRrjNjyLTc7jX4YOm7JuUqqed4oej1b5IUnPE8= X-Received: by 2002:a37:aa82:: with SMTP id t124mr21737354qke.3.1589315503943; Tue, 12 May 2020 13:31:43 -0700 (PDT) MIME-Version: 1.0 References: <20200512144949.4f933eca@canb.auug.org.au> <20200512162205.GI5110@sirena.org.uk> <20200512163632.GA916@sol.localdomain> <20200512170801.GK5110@sirena.org.uk> <20200512200805.GA175421@gmail.com> In-Reply-To: <20200512200805.GA175421@gmail.com> From: Arnd Bergmann Date: Tue, 12 May 2020 22:31:27 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: linux-next: manual merge of the sound-asoc tree with the crypto tree To: Eric Biggers Cc: Mark Brown , Herbert Xu , Stephen Rothwell , Liam Girdwood , Linux Crypto List , Linux Next Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Xo+MHz6hfyQZNbY1lyAhMEsaP9SY2L1bfFoJ4u+BE17weqcjyKP zVAB06kwTkaeHE+JMmUB1Gr9Z0AM/neUjR/rldED9X8b6mSGmDTqbiTUvCbe0x/BzT2ksgF fAfsBs1SdyU6WRx5xsw9YVtdHOQ0iSBQuAmy50gQeWCFvDZep59GOEac8qyWqxBFbLsTc6v YOMtmRpaCh1VW6rdf+Xtw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Eb2/49Fu2C0=:g19ZN4RbD8yATAxsYw5hBr QP1xMoW0s6m2DjnFO8I9dx99StVIfwQoX/gkJYLnptW+D9xJa3rb5BUJoPjsbDlQKNrAuhnjo tLv9aQ7qgiOgFIx5d1zNaU6TsuKnsVOL6F6pAjSmmeLAlSOVoVhm/tv5k+uPov+RucznNeiTh dEIRymZjiUpwKH8ssbebTJvjkUdbJl7M0pdPoeNsyfPid+gT/Ol5R4+ZxOdlOEpPJHZ+5cLz1 yQXgIUZ1FQj4tqAySjxe+jsU2kHiyKCz/byrL0Y3quGTOHFHYU2bTJYT/q665QbgqHR3nFA6x fAwsH2N/+xjmhTey13L4wp9p2M1zBsaeN71unY365T3EV2ojEyiH9hpFVGNngaDQMyMzo1hgD EzRjHjfooISHJLEypxRb+GReUNswuaRNznwrJCzvb9BkQg42UFHM1T1qLUDHzkG8J+rlyuqUw ukOxceIjudICcOg1TyeUOvaIjjegTNaL5tW2qdAB1IqK2V/F7/B1Ij5HurEcaC+p1w59MTxJn Z1FbqQ6gwmCK8PyktDGSdzKseEOu77EH1SgdepfL5CKVfjJXvwBDLv3YteV8temrsPgvHv6WQ D4EV05Xfb82eCICkRUNuPadUsi973mVffFsH9nzgbsOhvO8kRfU3UPGPAjoVNFgq5u2DORyuG /7cBLZ8EZBeADDgAs5i/1BuEWzdNkQO0L6EWGfyRCR5oLUYPb384V00wspjCJ9E4XQKSnNiEM TMF9WmuP9ELEqxBZc3mUj66qIwhE9vWTsO3SyZSBD6J5wteiVxsqO/bI9J75sD1OxvvOdV0ug 4kpmi8NKxVKCy1DLFk1pG4EXuTmlRZXv8uNq563Boru7es4Qzg= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 12, 2020 at 10:08 PM Eric Biggers wrote: > On Tue, May 12, 2020 at 06:08:01PM +0100, Mark Brown wrote: > > For later: if SHASH_DESC_ON_STACK is causing problems, we really ought to find a > better solution, since lots of users are using this macro. A version of > crypto_shash_tfm_digest() that falls back to heap allocation if the descsize is > too large would be possible, but that wouldn't fully solve the problem since > some users do incremental hashing. It's hard to know how many of the users of SHASH_DESC_ON_STACK() are likely to cause problems, as multiple factors are involved: - this one triggered the warning because it was on the stack of a function that got inlined into another that has other large variables. Whether it got inlined makes little difference to the stack usage, but does make a difference to warning about it. - generally the structure is larger than we like it, especially on architectures with 128 byte CRYPTO_MINALIGN like ARM. This actually got worse because of b68a7ec1e9a3 ("crypto: hash - Remove VLA usage"), as the stack usage is now always the maximum of all hashes where it used to be specific to the hash that was actually used and could be smaller - the specific instance in calculate_sha256() feels a bit silly, as this function allocates a tfm and a descriptor, runs the digest and then frees both again. I don't know how common this pattern is, but it seems a higher-level abstraction might be helpful anyway. Arnd