public inbox for
 help / color / mirror / Atom feed
From: Tetsuo Handa <>
Subject: Re: [Bug runtime/30831] Systemtap scripts fail to compile on newest linux 6.6 kernels
Date: Fri, 24 Nov 2023 00:16:42 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 ( )
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.
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
( ).
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.

  reply	other threads:[~2023-11-23 15:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07 17:46 [Bug runtime/30831] New: The do_each_thread macro has been removed from " wcohen at redhat dot com
2023-09-07 19:23 ` [Bug runtime/30831] Systemtap scripts fail to compile on " wcohen at redhat dot com
2023-09-08  2:49 ` wcohen at redhat dot com
2023-09-18 13:46 ` wcohen at redhat dot com
2023-09-18 13:51 ` wcohen at redhat dot com
2023-09-27 14:24 ` wcohen at redhat dot com
2023-09-27 20:03 ` wcohen at redhat dot com
2023-11-23 15:16   ` Tetsuo Handa [this message]
2023-12-13 14:47     ` William Cohen
2023-12-17 10:41       ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).