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 923F9C433EF for ; Tue, 19 Jul 2022 17:21:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238096AbiGSRVs (ORCPT ); Tue, 19 Jul 2022 13:21:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238936AbiGSRVl (ORCPT ); Tue, 19 Jul 2022 13:21:41 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D817E46D8E; Tue, 19 Jul 2022 10:21:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 90B67B81C76; Tue, 19 Jul 2022 17:21:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4080CC341C6; Tue, 19 Jul 2022 17:21:31 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="cK15E3aO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1658251289; 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=+DdIaGBIWAy9ehfPzceJ7R4AOuJB01GP/jeXzjkuNW0=; b=cK15E3aOfaYau/qzxYk1kkloBH9BwEizkRXRjeOPTGsrd1mKfY82Kg1qZdllepCJQ2YA2k fzNWjrS/HIE5R7Py/BIl5qdxvxCsI+Ux9KlI6kAV+efUUjUTirU5j++IWs+BmBjsFNOVnJ v2OhDxkIxgbw1o/2PcJl+mMgqee/XUI= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 27e8b8f4 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 19 Jul 2022 17:21:29 +0000 (UTC) Date: Tue, 19 Jul 2022 19:21:24 +0200 From: "Jason A. Donenfeld" To: Valentin Schneider Cc: Kalle Valo , Herbert Xu , linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, Gregory Erwin , Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , Rui Salvaterra , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Christian Brauner , linux-crypto@vger.kernel.org Subject: Re: [PATCH v8] ath9k: let sleep be interrupted when unregistering hwrng Message-ID: References: <20220629114240.946411-1-Jason@zx2c4.com> <87v8s8ubws.fsf@kernel.org> 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 Hi Valentin, On Tue, Jul 19, 2022 at 04:15:02PM +0100, Valentin Schneider wrote: > On 11/07/22 13:53, Jason A. Donenfeld wrote: > > Hi Valentin, > > > > On 7/11/22, Valentin Schneider wrote: > >> Thanks for the Cc. > >> > >> I'm not hot on the export of wake_up_state(), IMO any wakeup with > >> !(state & TASK_NORMAL) should be reserved to kernel internals. Now, here > >> IIUC the problem is that the patch uses an inline invoking > >> > >> wake_up_state(p, TASK_INTERRUPTIBLE) > >> > >> so this isn't playing with any 'exotic' task state, thus it shouldn't > >> actually need the export. > >> > >> I've been trying to figure out if this could work with just a > >> wake_up_process(), but the sleeping pattern here is not very conforming > >> (cf. 'wait loop' pattern in sched/core.c), AFAICT the signal is used to > >> circumvent that :/ > > > > I don't intend to work on this patch more. If you'd like to ack the > > trivial scheduler change (adding EXPORT_SYMBOL), that'd help, and then > > this can move forward as planned. Otherwise, if you have particular > > opinions about this patch that you want to happen, feel free to pick > > up the patch and send your own revisions (though I don't intend to do > > further review). Alternatively, I'll just send a patch to remove the > > driver entirely. Hopefully you do find this ack-able, though. > > > > I'm not for a blanket wake_up_state() export, however if we *really* need > it then I suppose we could have a wake_up_process_interruptible() exported > and used by __set_notify_signal(). > Thanks for keeping this thread alive. I'll do what you suggest and send a v+1. I think I understand the idea. Let's see how it goes. Jason