Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3331153pxb; Mon, 1 Mar 2021 07:26:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwybMX2Vk8MF4XbCh5FUbGFhEWTVbqKiOQj9LWnk+ysA8YPhj5dv2+SyLf/IoaF3zGfAW66 X-Received: by 2002:a17:906:1352:: with SMTP id x18mr5978815ejb.545.1614612369862; Mon, 01 Mar 2021 07:26:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614612369; cv=none; d=google.com; s=arc-20160816; b=nuwTLiafCx/SKGhb5NEAU/+7/Tu6U0aOa6puhR9luE7KVXc0BTPlB930a0Wc0fU23p UwJvF1y3TrwGC7CohRfYap+hT157kQ+ATPX72Hg7S7GSsQianJbgWdZkrYzVHu5BEACO 1yDB608h19T9UdcTjNgxJT4ADdVMdE+ONFxrv49fLPqf9Tc74CorrNeeQsFkgI6xr7y6 u0uJ+6OpfUnVjjH6kkrUy0f3Bd9dnpSLIfGX9fhvkk+1KsAgAlbpkrMqNTnh3zG4jBAo 07l85JtEFGGWuE3pojDez8X9jg769Wte8Qlu/KyGHFk5JmMeeMr3Xb+WJT/J40aJ5Y2N Asdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:from:user-agent:content-disposition:mime-version :message-id:subject:cc:to:date; bh=30AYJPOAroB8zkXNq9jgw3RQEpGykDPbSkJ7+IR0xNE=; b=SsapUxEpeklPcxJvpEckCb7ZNHKUsEXGnE35VQAqcumGyTqtC3R4Ax87Btzgqzd/Xd jwnKCsjn2gxwKsWG7TV+ZN4djPmvXSDDCMa6uEW2/GScOdq2hXMB4dp/qY80CxlxiTXp PWgpuL3nQy7WEqt98/lOMtAOkLoxnPsA6ayXQgVOmX51iq2YS+7EV+zazgizwQowTtzV Ff71UBUyaPvhKJaUD9t5git3fVA26jQE7YSTxFf5t6yAZx5uXvmfa7FwvBbMmnOZaqpQ zj1wvzdT2sl9pGhWSdM8RAXgMOVHknX8mqQCofprV0txAJfktdL8aNwprGtA/KnU6C+r iBkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n22si11269730edo.214.2021.03.01.07.25.36; Mon, 01 Mar 2021 07:26:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237177AbhCAPX3 (ORCPT + 99 others); Mon, 1 Mar 2021 10:23:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236673AbhCAPXO (ORCPT ); Mon, 1 Mar 2021 10:23:14 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1999BC061756 for ; Mon, 1 Mar 2021 07:22:33 -0800 (PST) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGkNU-0005ir-6h; Mon, 01 Mar 2021 16:22:32 +0100 Received: from sha by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1lGkNT-000394-OS; Mon, 01 Mar 2021 16:22:31 +0100 Date: Mon, 1 Mar 2021 16:22:31 +0100 To: linux-crypto@vger.kernel.org Cc: Horia =?utf-8?Q?Geant=C4=83?= , Aymen Sghaier , kernel@pengutronix.de Subject: CAAM: kernel BUG at drivers/crypto/caam/jr.c:230! Message-ID: <20210301152231.GC5549@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 16:18:25 up 11 days, 18:42, 82 users, load average: 0.02, 0.12, 0.16 User-Agent: Mutt/1.10.1 (2018-07-13) From: Sascha Hauer X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-crypto@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi All, I am on a Layerscape LS1046a using Linux-5.11. The CAAM driver sometimes crashes during the run-time self tests with: > kernel BUG at drivers/crypto/caam/jr.c:247! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in: > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-20210225-3-00039-g434215968816-dirty #12 > Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (C300) board (DT) > pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) > pc : caam_jr_dequeue+0x98/0x57c > lr : caam_jr_dequeue+0x98/0x57c > sp : ffff800010003d50 > x29: ffff800010003d50 x28: ffff8000118d4000 > x27: ffff8000118d4328 x26: 00000000000001f0 > x25: ffff0008022be480 x24: ffff0008022c6410 > x23: 00000000000001f1 x22: ffff8000118d4329 > x21: 0000000000004d80 x20: 00000000000001f1 > x19: 0000000000000001 x18: 0000000000000020 > x17: 0000000000000000 x16: 0000000000000015 > x15: ffff800011690230 x14: 2e2e2e2e2e2e2e2e > x13: 2e2e2e2e2e2e2020 x12: 3030303030303030 > x11: ffff800011700a38 x10: 00000000fffff000 > x9 : ffff8000100ada30 x8 : ffff8000116a8a38 > x7 : 0000000000000001 x6 : 0000000000000000 > x5 : 0000000000000000 x4 : 0000000000000000 > x3 : 00000000ffffffff x2 : 0000000000000000 > x1 : 0000000000000000 x0 : 0000000000001800 > Call trace: > caam_jr_dequeue+0x98/0x57c > tasklet_action_common.constprop.0+0x164/0x18c > tasklet_action+0x44/0x54 > __do_softirq+0x160/0x454 > __irq_exit_rcu+0x164/0x16c > irq_exit+0x1c/0x30 > __handle_domain_irq+0xc0/0x13c > gic_handle_irq+0x5c/0xf0 > el1_irq+0xb4/0x180 > arch_cpu_idle+0x18/0x30 > default_idle_call+0x3c/0x1c0 > do_idle+0x23c/0x274 > cpu_startup_entry+0x34/0x70 > rest_init+0xdc/0xec > arch_call_rest_init+0x1c/0x28 > start_kernel+0x4ac/0x4e4 > Code: 91392021 912c2000 d377d8c6 97f24d96 (d4210000) The driver iterates over the descriptors in the output ring and matches them with the ones it has previously queued. If it doesn't find a matching descriptor it complains with the BUG_ON() seen above. What I see sometimes is that the address in the output ring is 0x0, the job status in this case is 0x40000006 (meaning DECO Invalid KEY command). It seems that the CAAM doesn't write the descriptor address to the output ring at least in some error cases. When we don't have the descriptor address of the failed descriptor we have no way to find it in the list of queued descriptors, thus we also can't find the callback for that descriptor. This looks very unfortunate, anyone else seen this or has an idea what to do about it? I haven't investigated yet which job actually fails and why. Of course that would be my ultimate goal to find that out. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |