On Mon, Mar 03, 2025 at 08:48:09AM +0100, Hannes Reinecke wrote:
> On 2/28/25 11:47, Hannes Reinecke wrote:
> > Hi Sagi,
> >
> > enabling TLS on latest linus tree reliably crashes my system:
> >
> > [ 487.018058] ------------[ cut here ]------------
> > [ 487.024046] WARNING: CPU: 9 PID: 6159 at mm/slub.c:4719
> > free_large_kmalloc+0x15/0xa0
That's:
if (WARN_ON_ONCE(order == 0))
pr_warn_once("object pointer: 0x%p\n", object);
And while the object pointer is obfuscated (hashed pointers), this
wouldn't be helpful in trying to track down the problem. Perhaps
we could make this a VM_WARN_ON_ONCE_FOLIO() so we get the dump_page()?
I'm tempted to believe this is a double-free, but then I'm not sure why
it'd be triggered by this patch.
> > [ 487.296801] kfree+0x234/0x320
> > [ 487.332084] nvmf_connect_admin_queue+0x105/0x1a0 [nvme_fabrics
> > 34d997d53c805aa2fae8e8baee6a736e8da38358]
> > [ 487.332093] nvme_tcp_start_queue+0x18f/0x310 [nvme_tcp
> > 68f6be106f52ac467179f8a0922f02aeb6fa1f1c]
> > [ 487.332102] nvme_tcp_setup_ctrl+0xf8/0x700 [nvme_tcp
> > 68f6be106f52ac467179f8a0922f02aeb6fa1f1c]
> > [ 487.394495] nvme_tcp_create_ctrl+0x2e3/0x4d0 [nvme_tcp
> > 68f6be106f52ac467179f8a0922f02aeb6fa1f1c]
> > [ 487.394503] nvmf_dev_write+0x323/0x3d0 [nvme_fabrics
> > 34d997d53c805aa2fae8e8baee6a736e8da38358]
> > [ 487.394514] vfs_write+0xd9/0x430
> > [ 487.551642] object pointer: 0x00000000346cb6fc
Oh, wait, that's not the crash!
We continue to free the folio. Even though we hit the "can't happen"
case. That's dangerous.
> > [ 489.405197] Oops: general protection fault, probably for non-
> > canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP NOPTI
I think we all recognise that as list poison. I bet this is a double-free.
Or it could be a wild-free. I mean, look at kfree():
folio = virt_to_folio(object);
if (unlikely(!folio_test_slab(folio))) {
free_large_kmalloc(folio, (void *)object);
return;
}
So if you call kfree() on a random pointer, chances are it's not part
of slab, and we jump into the free_large_kmalloc() path.
We have a _lot_ of page types available. We should mark large kmallocs
as such. I'll send a patch to do that.
