Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5931305rwb; Mon, 14 Nov 2022 11:33:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf7PBF3QSAAE1q8imwZ1SNDIHlAvn1dHHMjslmquZDrzp6aHXVGADU6EG2TLWe4U7u1iDoIC X-Received: by 2002:a62:e806:0:b0:563:8011:e9e4 with SMTP id c6-20020a62e806000000b005638011e9e4mr15228535pfi.76.1668454384418; Mon, 14 Nov 2022 11:33:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668454384; cv=none; d=google.com; s=arc-20160816; b=UIuH8vusKFq9iPOPTQsfhYZntuG5sdjq2tGvFqK9TMTN2d63TxaSznF7zz3ctHg2Nl 93YvnbRpIzA62fD4aj15dZNBMRMY7Dp/VK4v9jI5ihoMtHp4AEWqifX6Jh3+yPNsCndw mnV+S7u4be/uAJ592BOae8LmkmijvFhnFLx+ht0lCkwx7OtIwUgPr0DO9lEsTopWJ0me K/yP3wX1MWfJ83tSlSBMCNRw+yYZdJqKavuKjoU4TVfwxND43J+DCVbmEIEUeAkhrrZY D6irBXU4XPzOjxouU1vRQm27c+5HEKQ2quj5RehTn4Mm2I2H4VzBltpdc3XZK4POeb98 Ufzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=/5Cf7qYpoc6/rZTWg/y10ZBuAju4Ba730yEiDx9zC2I=; b=lPsTg04dm5Pg4Lqs6L/pxzJryJnB8lwWgjvCHqiGn3vJdyM5+QeXQc3SDGl++J8VtP UXa2cySaiX3c9eHzjNk3rcA0197Taz/39Vb0nyEnk5HAIUbDsobl0c6oVdqmRvQ6vdJu ZedmZgrX+Hzjfx2CKe9gVli/ywAAaFA1q/AIQAZXHZl+UKptC7JEAmX7E8MiOG1v0rAr mXQ85VRNfhQuRk8KYyaIpFaAUvXsaEP2N9Sn+kuwR7wDpRGLQbaHhiVkB8Huv5pNN8+h CjZXT22xyojfguJVh2/GjBxb5UGla9kO0MDmNctHj6aHCU+yHi+qwd0gX/GIos8kj8Z+ LXhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f184-20020a636ac1000000b0042b85da3a53si10220992pgc.473.2022.11.14.11.32.51; Mon, 14 Nov 2022 11:33:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237250AbiKNT2X (ORCPT + 89 others); Mon, 14 Nov 2022 14:28:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236454AbiKNT2T (ORCPT ); Mon, 14 Nov 2022 14:28:19 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD0062497A for ; Mon, 14 Nov 2022 11:28:18 -0800 (PST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 6850161377 for ; Mon, 14 Nov 2022 19:28:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0856DC433C1; Mon, 14 Nov 2022 19:28:16 +0000 (UTC) Date: Mon, 14 Nov 2022 14:28:58 -0500 From: Steven Rostedt To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Stephen Boyd , Guenter Roeck , Anna-Maria Gleixner , Andrew Morton , Julia Lawall Subject: Re: [PATCH v6 4/6] timers: Add timer_shutdown_sync() to be called before freeing timers Message-ID: <20221114142858.59682a42@gandalf.local.home> In-Reply-To: <87bkp9s61z.ffs@tglx> References: <20221110064101.429013735@goodmis.org> <20221110064147.343514404@goodmis.org> <875yfitpdu.ffs@tglx> <20221113191518.0a3b29b1@rorschach.local.home> <87sfims7ca.ffs@tglx> <20221114083635.60e23559@gandalf.local.home> <87bkp9s61z.ffs@tglx> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Nov 2022 20:13:28 +0100 Thomas Gleixner wrote: > On Mon, Nov 14 2022 at 08:36, Steven Rostedt wrote: > > On Mon, 14 Nov 2022 01:33:25 +0100 > > Thomas Gleixner wrote: > >> https://lore.kernel.org/all/87v8vjiaih.ffs@tglx/ > >> > > I'm not sure what you mean by that. The idea is that once timer_shutdown() > > is called, we still warn on re-arming the timer. > > That's the whole point. As Linus and I discussed in that thread: > > "That would mean, that we still check the function pointer for NULL > without warning and just return. That would indeed be a good argument > for not having the warning at all." > > and as I demonstrated you on the example of the BT driver which you > "fixed" this is the only sensible way to handle this. I agree that it wasn't a complete fix, but as I mentioned before, I was pulled off before I could do more. > > The warning does not buy us anything, unless you want to go and amend > all the usage sites which trigger it with 'if (mystruct->shutdown)' > conditionals. The rationale for the warning was that it would let us know what drivers need to be fixed for older kernels without the shutdown state. I'm perfectly fine in removing the warning. We may just add it to the field kernels so that we can know if there's any drivers that have issues that we need to look at. > > It's very similar to the work->canceling logic for kthreads that Linus > mentioned in this thread which prevents that the work timer is rearmed > concurrently. The difference is that timer_shutdown() is a final > decision which renders the timer unusable unless it is explicitely > reinitialized. > > But that's mostly a matter of documentation and it has to be made clear > that nothing in a shutdown path which has the BT pattern: > > timer_shutdown(); > destroy_workqueue(); > > relies on the timer being functional after the shutdown point. I'm > pretty sure that the vast majority of such use cases do not care, but > given the size of the driver zoo I'm also sure that you'll find at least > one which depends on the timer working accross teardown. > Agreed. -- Steve