Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C37ECC64ED8 for ; Sat, 25 Feb 2023 00:02:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229536AbjBYACI (ORCPT ); Fri, 24 Feb 2023 19:02:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229513AbjBYAB7 (ORCPT ); Fri, 24 Feb 2023 19:01:59 -0500 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FBFD6A7B0 for ; Fri, 24 Feb 2023 16:01:58 -0800 (PST) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-53852143afcso23797887b3.3 for ; Fri, 24 Feb 2023 16:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YGce1k7vLcc005CSr+hSLKXBF5SLmaJtWY6pcwxKx0Q=; b=wmKV6llXzbyV9ZIrbyej2OunFiU741qhFzyT++YfHdH+wiBtK7OyXKguWCb/kxA5lR DgiV/yoxIJFHFT7HIAGeNE09zKS75YuufpetByYC+zQvHhisK1MF1WcBapNZQL2eZoTE QHiLj96u/q3tU+9/uJa4MeMk3UhGRkOxdXZPb8EDh1xZ3nxCyran5snsFAKmTd/5JtEu FzHlHgHlzZp3XLv5EM9LwJixEhKTFFF1gIvYyhd8N03lSvOiQxUSedhNiJdnX0om6B9S ntCGHIcAFPwdHLJL2q3LRLX9MSEOB3M4l/aQIIHL5vFmWJgiaeGOAcJ+ZKIBu2P0b/sx fnvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YGce1k7vLcc005CSr+hSLKXBF5SLmaJtWY6pcwxKx0Q=; b=1w+qIZMT8wvXGaSiujLCotnrQrL40yucc4SFQyeerO5/jPulHnbitd/obqsp1WhmxW z8l6JVd64klVKw1K0HqDRs9mM1/fv+KMMwuqi2itxTfM737PWPTBYZP0djKFd4miUW+V tg3Do4NOo+vsj0mWP35NcRUfcmMfIvtqfmxlO6xwfmpI1blc9tr/XYkZ/uDQrGeQBp4f 9C4maXwhFeiE92R9s5NVfnVsi9RBXWejw/UEi1Ph008RHX86wBS0Xiqy4Muy561SC9B9 Y2xhLAvXkb5MC4u4zTcuf461TBOTCJ27HFoQVnF2n9PrFXNcN2Nf2P/Gyi4wgrvAOc27 Cr7Q== X-Gm-Message-State: AO0yUKWY2ItCzZ7aDRmNP9hX9AzTzCnPSRCvUkg/TuW+3UCy0e3NIEAU ZSm0MtXxwp8GKc8Z34lGky0kCxDW+9y7sDQE7crloQ== X-Google-Smtp-Source: AK7set99QV/uEaIf43VqawXg5tt6DNfPTfljZt6PYvMnndqiUknRY5fA1wfLo7lx9pLsVMLGPQvxOcTnIyR7ML4cJf4= X-Received: by 2002:a81:af1b:0:b0:533:8080:16ee with SMTP id n27-20020a81af1b000000b00533808016eemr5627579ywh.10.1677283317533; Fri, 24 Feb 2023 16:01:57 -0800 (PST) MIME-Version: 1.0 References: <20230224231430.2948-1-kunyu@nfschina.com> In-Reply-To: From: Linus Walleij Date: Sat, 25 Feb 2023 01:01:46 +0100 Message-ID: Subject: Re: [v2 PATCH] crypto: stm32 - Save and restore between each request To: Herbert Xu Cc: Lionel Debieve , Li kunyu , davem@davemloft.net, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, mcoquelin.stm32@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Herbert, I tested this on the Ux500 and sadly this happens already in probe(): [ 2.802539] stm32-hash a03c2000.hash: dma-maxburst not specified, using 0 [ 2.809342] stm32-hash a03c2000.hash: No IRQ, use polling mode [ 2.815226] stm32-hash a03c2000.hash: DMA mode not available [ 2.821140] stm32-hash a03c2000.hash: will run requests pump with realtime priority [ 2.828815] stm32-hash a03c2000.hash: Algo 0 : 0 failed [ 2.834144] stm32-hash: probe of a03c2000.hash failed with error -22 I don't quite understand why, we never get to the tests... On Fri, Feb 24, 2023 at 6:52 AM Herbert Xu wrote: > v2 fixes potential state clobbering from the disconnect between > hdev->flags and rctx->flags. > > ---8<--- > The Crypto API hashing paradigm requires the hardware state to > be exported between *each* request because multiple unrelated > hashes may be processed concurrently. > > The stm32 hardware is capable of producing the hardware hashing > state but it was only doing it in the export function. This is > not only broken for export as you can't export a kernel pointer > and reimport it, but it also means that concurrent hashing was > fundamentally broken. > > Fix this by moving the saving and restoring of hardware hash > state between each and every hashing request. > > Fixes: 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module") > Reported-by: Li kunyu > Signed-off-by: Herbert Xu I think I understand the direction of the patch but it seems the pm_runtime_* calls get unbalanced since now this is taken in stm32_hash_one_request -> stm32_hash_hw_init() -> pm_runtime_get_sync() But no corresponding pm_runtime_mark_last_busy(hdev->dev); pm_runtime_put_autosuspend(hdev->dev); Exist anymore? You know the semantics better than me, I'm not sure where to put this, I guess where you save the HW state in stm32_hash_update_cpu()? I don't know about the DMA case then though. Yours, Linus Walleij