Re: slab warning: kmem_cache of name 'dm_bufio_buffer' already exists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 8, 2024 at 9:00 AM Vlastimil Babka <vbabka@xxxxxxx> wrote:
>
> On 11/8/24 17:49, Yang Shi wrote:
> > On Wed, Nov 6, 2024 at 3:35 AM Vlastimil Babka <vbabka@xxxxxxx> wrote:
> >>
> >> On 11/6/24 12:19, Mikulas Patocka wrote:
> >> > Hi
> >>
> >> Hi,
> >>
> >> > The commit 4c39529663b93165953ecf9b1a9ea817358dcd06 ("slab: Warn on
> >> > duplicate cache names when DEBUG_VM=y") is causing large number of
> >> > warnings about "dm_bufio_buffer", "dm_bufio_buffer-%u" (and other) device
> >> > mapper caches.
> >>
> >> Hmm wonder why nobody run into this before. We thought the code that would
> >> cause the warning would be all fixed before introducing it, but we missed
> >> some, sorry.
> >
> > Another data point, I also saw such warning when booting 6.12-rcX (rc1
> > and rc6), but from mlx5 driver. I thought it was mlx driver specific
> > issue, it seems not.
>
> Well this particular issue is mlx driver specific.
> The caches it creates (per device?) don't seem to be have specific size or
> anything to that device, so it should be relatively simple to fix.

Aha, thank you. Added mlx driver maintainers.

>
> > [   63.537874] kmem_cache of name 'mlx5_fs_ftes' already exists
> > [   63.546399] WARNING: CPU: 0 PID: 9 at mm/slab_common.c:107
> > __kmem_cache_create_args+0xb4/0x330
> > [   63.557839] Modules linked in: vfat fat mlx5_core(+) dax_hmem
> > cxl_acpi ampere_cspmu cxl_port cxl_core mlxfw psample einj arm_spe_pmu
> > arm_cspmu_module tls pci_hyperv_intf acpi_ipmi acpi_tad ipmi_ssif
> > ipmi_devintf arm_cmn ipmi_msghandler cppc_cpufreq(+) fuse loop
> > nfnetlink zram xfs crct10dif_ce polyval_ce polyval_generic ghash_ce
> > sha3_ce nvme sha512_ce nvme_core sha512_arm64 sbsa_gwdt nvme_auth
> > xgene_hwmon
> > [   63.596473] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G
> >  W          6.12.0-rc6 #80
> > [   63.609156] Tainted: [W]=WARN
> > [   63.614976] Hardware name: ZOLLNER SUNMOONLAKE/SunMoon Lake, BIOS
> > 00.00. 2024-10-30 13:48:02 11/06/2024
> > [   63.624359] Workqueue: events work_for_cpu_fn
> > [   63.631569] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> > [   63.638523] pc : __kmem_cache_create_args+0xb4/0x330
> > [   63.646340] lr : __kmem_cache_create_args+0xb4/0x330
> > [   63.654158] sp : ffff800080d1bc00
> > [   63.660330] x29: ffff800080d1bc00 x28: 0000000000000000 x27: 0000000000000000
> > [   63.670318] x26: 0000000000000000 x25: ffffbf101f234410 x24: 00000000000002d8
> > [   63.677446] x23: 0000000000000000 x22: ffff800080d1bc58 x21: ffffbf101f2344b8
> > [   63.687436] x20: ffffbf0ff94870a8 x19: ffff2001053a1700 x18: 0000000000000014
> > [   63.694563] x17: 00000000a871ae29 x16: ffffbf101c282f18 x15: 000000007773661b
> > [   63.704552] x14: 0000000000000000 x13: 7374736978652079 x12: 646165726c612027
> > [   63.714539] x11: 736574665f73665f x10: 35786c6d2720656d x9 : ffffbf101c1722f0
> > [   63.724531] x8 : ffff800080d1b890 x7 : 0000000000000001 x6 : 0000000000000001
> > [   63.734518] x5 : ffff001f7d803448 x4 : 0000000000000000 x3 : 0000000000000000
> > [   63.741646] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000108e3a440
> > [   63.751634] Call trace:
> > [   63.754072]  __kmem_cache_create_args+0xb4/0x330
> > [   63.761542]  mlx5_fs_core_alloc+0x158/0x1a8 [mlx5_core]
> > [   63.769708]  mlx5_init_once+0x13c/0x520 [mlx5_core]
> > [   63.777528]  mlx5_init_one_devl_locked+0xa8/0x280 [mlx5_core]
> > [   63.786127]  probe_one+0xe0/0x200 [mlx5_core]
> > [   63.790569]  local_pci_probe+0x48/0xc0
> > [   63.794307]  work_for_cpu_fn+0x24/0x40
> > [   63.798044]  process_one_work+0x180/0x430
> > [   63.802042]  worker_thread+0x25c/0x380
> > [   63.805778]  kthread+0xf4/0x108
> > [   63.808907]  ret_from_fork+0x10/0x20
> >
> >>
> >> > I'd like to ask - how to properly fix it?
> >> >
> >> > We create a "dm_bufio_buffer" or "dm_bufio_buffer-%u" cache with every dm
> >> > bufio client. It used to work (and the duplicate caches are merged), but
> >>
> >> Note the merging can be disabled so then it's really several caches with
> >> exactly same name in /proc/slabinfo and inability to create their
> >> sysfs/debugfs directories.
> >>
> >> > now it warns.
> >> >
> >> > Should I append a pointer to the dm_bufio structure to the slab cache name
> >> > to make them different? Or is there any other preferred solution?
> >>
> >> Anything that uniquely identifies the client should be ok, but beware e.g.
> >> device names that can have slashes, see commit a360f311f57a36 (also for the
> >> simplest possible fix that is an incremented number).
> >>
> >> > Note that it is not possible to pre-create the cache "dm_bufio_buffer-%u"
> >> > in the module's init function, because the size of per-buffer auxiliary
> >> > data is not known at this point.
> >>
> >> Looks like some chose to solve this the harder way, see 4d784c042d164f
> >>
> >> > Mikulas
> >> >
> >>
> >>
>





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux