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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A39CC43217 for ; Mon, 28 Feb 2022 14:29:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237159AbiB1OaP (ORCPT ); Mon, 28 Feb 2022 09:30:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234612AbiB1OaO (ORCPT ); Mon, 28 Feb 2022 09:30:14 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93E3D205E4; Mon, 28 Feb 2022 06:29:35 -0800 (PST) Date: Mon, 28 Feb 2022 15:29:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1646058573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TjAcEow0NSJUp2vQoMMRWwS/iFJm6prkulbh5r924f0=; b=ZcNtJQXunGmEL5PSjeClPrP4xsd45gSCe3uBzOoxuYxZ53xgvXFYyZQkBz0Osfh3jpMIJk oIkhADqNfyA9wz/7QUZZ0/Ef2S4aO3si7fktSTdOF/5cjCaUU0CYlmZJYxkmlkohzjw68u UvKZXiB7fADlfKE8OfCvJ9XisoyqnxMTO3a1uOjHY9Q+7fCJ98Lt/6+2C1ltmaOSv04Mmj VGMrgtFd1IlbqFvtWWOGRajtuH2V27laHrwU/ND+QOeyeNtxNV8tcZpfU7JuN6iQHtr4VG eC8feetSrqyQh54+rTbMsdtbe99bH++MWfZlT5Ek3zaHqT+x2tClV0nsyu84Yw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1646058573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TjAcEow0NSJUp2vQoMMRWwS/iFJm6prkulbh5r924f0=; b=jdmZCXfZTa3ABN0aVUinhLQmqloInp6t9d9YC+Unk/0fAIcJD6M9EpsfjOEeBJMf7tUk19 x/3oJXhyf8WWdQAA== From: Sebastian Andrzej Siewior To: "Jason A. Donenfeld" Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Peter Zijlstra , Eric Biggers , Theodore Ts'o , Dominik Brodowski Subject: Re: [PATCH v2] random: do crng pre-init loading in worker rather than irq Message-ID: References: <20220224152937.12747-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-02-28 15:17:19 [+0100], Jason A. Donenfeld wrote: > Hey Sebastian, Hi Jason, > On 2/28/22, Sebastian Andrzej Siewior wrote: > > On 2022-02-24 16:29:37 [+0100], Jason A. Donenfeld wrote: > >> Taking spinlocks from IRQ context is problematic for PREEMPT_RT. That > >> is, in part, why we take trylocks instead. But apparently this still > >> trips up various lock dependency analyzers. That seems like a bug in the > >> analyzers that should be fixed, rather than having to change things > >> here. > > > > Could you please post a lockdep report so I can take a look? > > I thought the problem with lockdep was stated by you somewhere in this thread? > https://lore.kernel.org/lkml/YfOqsOiNfURyvFRX@linutronix.de/ > "But even then we need to find a way to move the crng init part > (crng_fast_load()) out of the hard-IRQ." > And Jonathan posted two related (?) splats he ran into. > > I may have gotten that all wrong, in which case, I'll just excise that > part from the commit message. I'm pretty sure you want this patch > either way, right? Oh, that report. So yes, I want that patch ;) In this case the lockdep is right. The thing that it affects only PREEMPT_RT. That trylock is not the thing that lockdep complains about but the spin_lock_irqsave() within invalidate_batched_entropy(). Taking a spinlock_t from IRQ context is problematic for PREEMPT_RT, correct. A spin_try_lock() is also problematic since another spin_lock() invocation would PI-boost the wrong task (the spin_try_lock() is invoked from an IRQ-context so the task on CPU (random task or idle) is not the actual owner). I'm pointing this out because there was also _another_ problem with try_lock from hard-IRQ context which was fixed in the meantime. Would it work for you to update the commit message? Basically I'm fine with the firs sentence but the remaining part is misleading. > Jason Sebastian