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 582D7C433FE for ; Tue, 22 Nov 2022 22:06:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235131AbiKVWGP convert rfc822-to-8bit (ORCPT ); Tue, 22 Nov 2022 17:06:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234880AbiKVWGM (ORCPT ); Tue, 22 Nov 2022 17:06:12 -0500 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37D7368287 for ; Tue, 22 Nov 2022 14:06:08 -0800 (PST) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-254-sgcAsR24PNu03owwWGE96w-1; Tue, 22 Nov 2022 22:06:05 +0000 X-MC-Unique: sgcAsR24PNu03owwWGE96w-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 22 Nov 2022 22:06:04 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.044; Tue, 22 Nov 2022 22:06:04 +0000 From: David Laight To: 'Dan Williams' , Lukas Wunner CC: "'ira.weiny@intel.com'" , Bjorn Helgaas , Bjorn Helgaas , Gregory Price , Jonathan Cameron , Vishal Verma , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-cxl@vger.kernel.org" , Thomas Gleixner Subject: RE: [PATCH V2] PCI/DOE: Detect on stack work items automatically Thread-Topic: [PATCH V2] PCI/DOE: Detect on stack work items automatically Thread-Index: AQHY+uF8IwLsQKEiakO+LlTXtrnK365EZJiQgAcGD4iAABtQEA== Date: Tue, 22 Nov 2022 22:06:04 +0000 Message-ID: References: <20221118000524.1477383-1-ira.weiny@intel.com> <20221122171309.GA11310@wunner.de> <20221122171406.GC11310@wunner.de> <637d2f98db8b_12cdff29464@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <637d2f98db8b_12cdff29464@dwillia2-xfh.jf.intel.com.notmuch> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Dan Williams > Sent: 22 November 2022 20:23 ... > > > > > Lukas pointed out that object_is_on_stack() is available to detect this > > > > > automatically. > > > > > > > > > > Use object_is_on_stack() to determine the correct init work function to > > > > > call. > > > > > > > > This is all a bit strange. > > > > The 'onstack' flag is needed for the diagnostic check: > > > > is_on_stack = object_is_on_stack(addr); > > > > if (is_on_stack == onstack) > > > > return; > > > > pr_warn(...); > > > > WARN_ON(1); > > > > > > > > So setting the flag to the location of the buffer just subverts the check. > > > > It that is sane there ought to be a proper way to do it. > > > > > > If object_is_on_stack() is sufficient to check whether a struct > > > is on the stack or not, why doesn't __init_work() use it to > > > auto-detect whether to call debug_object_init_on_stack() or > > > debug_object_init()? > > > > > > Forcing developers to use a specific initializer for something > > > that can be auto-detected is akin to treating them like kids > > > and telling them "You didn't say the magic word." > > > > > > What's the point? > > I had this initial reaction as well, but INIT_WORK_ONSTACK() documents > an important detail of the object's lifetime. Here are 2 examples of > functions that would become trickier to read if the kernel did a > global s/INIT_WORK_ONSTACK()/INIT_WORK()/ > > synchronize_rcu_expedited_queue_work() > insert_wq_barrier() > > ...where those take arguments that are known to come from the stack and > be used in async context. I suspect the check was added in response to some code that added on on-stack item and then slept after returning from that function. One option would be to change the diagnostic check to: is_on_stack != !object_is_on_stack(addr) and then pass in 2 so the test always succeeds. But I suspect that won't be liked. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)