On 2023/05/05 3:40, Paul Moore wrote: > On Wed, May 3, 2023 at 10:50 PM Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: >> On 2023/05/04 7:12, Rinat Gadelshin wrote: >>> On 04.05.2023 00:27, Paul Moore wrote: >>>> Can you be more specific about the kernel threads you are seeing, are >>>> you seeing multiple "kauditd" threads? >>>> >>>> % ps -fC kauditd >>>> UID PID PPID C STIME TTY TIME CMD >>>> root 89 2 0 Apr28 ? 00:00:00 [kauditd] >> >> I don't think so. >> >> kernel audit subsystem uses kthread_run() in order to run short-lived kernel >> threads. > > Thanks Tetsuo, I agree that's far more likely. Ever since I took over > shepherding the audit code, all of the thread issues have been around > the main audit queue thread so it's a bit reflexive to assume that is > the case :) >
Since kthread_run(audit_send_list_thread) is called by audit_receive_msg(AUDIT_LIST_RULES) via audit_list_rules_send(), trying to audit fork request via AUDIT_LIST_RULES will cause spams. Maybe something is going wrong with "And such events occurred 1208 times when AUDIT_LIST_RULES is sending." part; let's wait for what printk() says. By the way, why do we need to use kthread_run() for short-lived tasks? Can't we use a dedicated workqueue which would significantly reduce frequency of fork request for AUDIT_LIST_RULES request? -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
