Received-SPF: pass (google.com: domain of linux-kernel+bounces-109698-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 21 Mar 2024 07:39:49 +0100
Message-ID: <87v85grsui.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Cc: linux-kernel@vger.kernel.org,
	linux-sound@vger.kernel.org
Subject: Re: Regression: SUnreclaim leak: snd_ctl_ioctl?
In-Reply-To: <1710953751.8yx03664pf.none@localhost>
References: <1710953751.8yx03664pf.none.ref@localhost>
	<1710953751.8yx03664pf.none@localhost>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
Precedence: bulk
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII

On Wed, 20 Mar 2024 18:01:22 +0100,
Alex Xu (Hello71) wrote:
> 
> Hi all,
> 
> In the last few days of running torvalds master kernel, I found that 
> SUnreclaim memory seems to increase indefinitely. slabinfo -r kmalloc-2k 
> says:
> 
> Slabcache: kmalloc-2k       Aliases:  0 Order :  3 Objects: 1272941
> 
> Sizes (bytes)     Slabs              Debug                Memory
> ------------------------------------------------------------------------
> Object :    2048  Total  :  264991   Sanity Checks : On   Total: 8683225088
> SlabObj:    6144  Full   :  264972   Redzoning     : On   Used : 2606983168
> SlabSiz:   32768  Partial:      19   Poisoning     : On   Loss : 6076241920
> Loss   :    4096  CpuSlab:       0   Tracking      : On   Lalig: 5213966336
> Align  :    2048  Objects:       5   Tracing       : Off  Lpadd: 542701568
> 
> kmalloc-2k has no kmem_cache operations
> 
> kmalloc-2k: Kernel object allocation
> -----------------------------------------------------------------------
> 1272283 snd_ctl_ioctl+0x45f/0x6d0 waste=1048361192/824 age=6141/183854/366927 pid=687-33984 cpus=0-1,3-8,10
>         memdup_user+0x21/0x70
>         snd_ctl_ioctl+0x45f/0x6d0
>         __x64_sys_ioctl+0x85/0xa0
>         do_syscall_64+0x3d/0xf0
>         entry_SYSCALL_64_after_hwframe+0x46/0x4e
> 
>     189 acpi_add_single_object+0x38/0x710 waste=119448/632 age=368130/368134/368138 pid=1 cpus=0
> [ ... ]
> 
> kmalloc-2k: Kernel object freeing
> ------------------------------------------------------------------------
>  633587 <not-available> age=4295305473 pid=0 cpus=0
>  382872 rcu_core+0x284/0x540 age=4513/194630/361523 pid=0-21201 cpus=0-11
>         rcu_core+0x284/0x540
>         __do_softirq+0xad/0x1de
> 
>  247690 amdgpu_dm_atomic_commit_tail+0x1721/0x3740 age=6157/199198/366963 pid=163-19507 cpus=0-11
>         amdgpu_dm_atomic_commit_tail+0x1721/0x3740
>         commit_tail+0x8a/0x120
>         process_one_work+0x12b/0x250
>         worker_thread+0x2d9/0x3f0
>         kthread+0xac/0xe0
>         ret_from_fork+0x28/0x40
>         ret_from_fork_asm+0x11/0x20
> 
>    2794 __sk_destruct+0x17a/0x1b0 age=994/147194/368001 pid=0-19414 cpus=0-11
> [ ... ]
> 
> So, if I understand correctly, some memory copied from userspace for 
> snd_ctl_ioctl is not freed correctly. The PIDs were pipewire, 
> wireplumber, and pipewire-pulse, so I restarted those but it didn't 
> resolve the issue.
> 
> Let me know what other information is needed.

Likely the same issue fixed by
  https://lore.kernel.org/r/20240320062722.31325-1-tiwai@suse.de

It'll be included in the next PR for 6.9-rc1.


thanks,

Takashi