From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by sourceware.org (Postfix) with ESMTPS id 060563858C2B for ; Thu, 23 Nov 2023 15:16:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 060563858C2B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=I-love.SAKURA.ne.jp Authentication-Results: sourceware.org; spf=none smtp.mailfrom=I-love.SAKURA.ne.jp ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 060563858C2B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=202.181.97.72 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700752624; cv=none; b=vkdPK7Y3o8/sP/fJOlKWdL7Bk08VUdP2u73W0WCOMckDPhBOI9VQEmI2T/+Q1YsiEb7jYT/yHNIbsJIctFGs8JSZZfERKyEsQpj2EqHclEnkSmPc/Jn0TPGw5kr2YWI0D/kguMUmws7JWgi+2I1eiof2rWJp2WevJpzsiWeG2zs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700752624; c=relaxed/simple; bh=eMV4ZoHBarbS4kLNq8CbwbMG2aqIDPP1JUByoxRCgqM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=u4kom867SYiPZ8DH2nNzPL0M+tj1cLnB1BQcDZgYtELqjWhxKNSGfyu6LEA9Y/vq1GeKHaUZ1aM7YsP74t9cYjttXBdhSlCOQQ7Yf7I1ozOMNuwEZBSfYIWJ3n32pN1jrDnAjQFTaSvVXFSrH0ER7LwBy/YhLn/0J+gm5gF7NUI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fsav115.sakura.ne.jp (fsav115.sakura.ne.jp [27.133.134.242]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 3ANFGklQ052178; Fri, 24 Nov 2023 00:16:46 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav115.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav115.sakura.ne.jp); Fri, 24 Nov 2023 00:16:46 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav115.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 3ANFGkTw052175 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Nov 2023 00:16:46 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Fri, 24 Nov 2023 00:16:42 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Bug runtime/30831] Systemtap scripts fail to compile on newest linux 6.6 kernels Content-Language: en-US To: wcohen@redhat.com References: Cc: systemtap@sourceware.org From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023/09/28 5:03, wcohen at redhat dot com via Systemtap wrote: > commit ca71442b93af61cbd9a1386e24e967373f928eae (HEAD -> master, origin/master, > origin/HEAD) > Author: William Cohen > Date: Wed Sep 27 10:09:11 2023 -0400 > > Eliminate use of kernel's flush_scheduled_work() in systemtap modules > > Kernel git commit 20bdedafd2f63e0ba70991127f9b5c0826ebdb32 turns use > of flush_scheduled_work() into a warning which causes builds of > anything using it to fail because warnings are treated as errors. > Previous users of flush_scheduled_work() in the kernel have been > converted over to use individual workqueues. Systemtap runtime now > does the same. It creates and uses its own workqueue to eliminate the > use of flush_scheduled_work(). That commit does not look correct. systemtap_wq = alloc_workqueue("systemtap-wq", WQ_UNBOUND | WQ_MEM_RECLAIM, 0); if (!systemtap_wq) return !systemtap_wq; causes stap_init_module() to return 1 (i.e. a positive value) when alloc_workqueue() failed. The caller ( https://elixir.bootlin.com/linux/v6.6/source/kernel/module/main.c#L2528 ) emits a warning message but thinks that stap_init_module() succeeded. stap_init_module() should return -ENOMEM when alloc_workqueue() failed. Also, when alloc_workqueue() with WQ_MEM_RECLAIM flag succeeded, alloc_workqueue() allocated a "struct task_struct". Not calling destroy_workqueue(systemtap_wq) leaks that "struct task_struct" and related kernel resources. rc = systemtap_kernel_module_init(); if (rc) return rc; I don't know the content of systemtap_kernel_module_init() emitted by translate.cxx , but it seems to me that destroy_workqueue(systemtap_wq) will not be called. Like https://lkml.kernel.org/r/49925af7-78a8-a3dd-bce6-cfc02e1a9236@I-love.SAKURA.ne.jp says, please be sure to call destroy_workqueue(systemtap_wq) when stap_init_module() returns an error after alloc_workqueue() succeeded. Also, system_wq is created without WQ_MEM_RECLAIM flag ( https://elixir.bootlin.com/linux/v6.6/source/kernel/workqueue.c#L6596 ). If you don't have a reason to create systemtap_wq with WQ_MEM_RECLAIM flag, use of WQ_MEM_RECLAIM flag is a waste of kernel resource.