[BUG]: smbfs bug in 2.5.58-mm1

From: Martin Josefsson (gandalf@wlug.westbo.se)
Date: Thu Feb 13 2003 - 13:26:56 EST

Hi Urban,

You seem to be the one to mail this stuff to.

Just came across an smbfs bug in 2.5.58-mm1 compiled with slab-debugging
but without preempt which I've been running for a while.

I was playing an mp3 from a samba server and suddenly the music stopped,
I tried pinging the server and it responded, then I tried stopping the
playback in xmms and then pressing play again. At first nothing happened
but after a few seconds xmms died and I got this in my kernel-log (the
machine appears to still be stable, writing this mail on it):

I'm not sure when these two messages appeared, but they seem related to
the crash and they weren't there when I ran dmesg a few hours earlier.

smb_get_length: Invalid NBT packet, code=96
smb_add_request: request [d023664c, mid=1802201963] timed out!
------------[ cut here ]------------
kernel BUG at mm/slab.c:1632!
invalid operand: 0000
CPU: 0
EIP: 0060:[<c01332d3>] Not tainted
EFLAGS: 00010202
EIP is at cache_alloc_debugcheck_after+0xc3/0xe0
eax: 00000001 ebx: d0236648 ecx: 00000000 edx: 000000f4
esi: ebd8d9c4 edi: 000001d0 ebp: 00000000 esp: c4e77c00
ds: 007b es: 007b ss: 0068
Process xmms (pid: 15113, threadinfo=c4e76000 task=c4c28100)
Stack: ebd8d9c4 d0236648 00000058 ebd8d9c4 00000246 c01323a6 ebd8d9c4 000001d0
       d0236648 e81b7bdc 00000000 00001000 eeadbeaa ebd8d9c4 000001d0 6b6b6b6b
       d0236658 00000000 00000000 c4c28100 e81b7bdc fffffff4 00000042 eeadbf60
Call Trace:
 [<c01323a6>] kmem_cache_alloc+0x56/0x80
 [<eeadbeaa>] smb_do_alloc_request+0x2a/0x11524180 [smbfs]
 [<eeadbf60>] smb_alloc_request+0x30/0x115240d0 [smbfs]
 [<eead445f>] smb_proc_open+0x3f/0x1152bbe0 [smbfs]
 [<eead3e73>] smb_request_ok+0x33/0x1152c1c0 [smbfs]
 [<eead4650>] smb_open+0xf0/0x1152baa0 [smbfs]
 [<eeadadbb>] smb_readpage_sync+0x8b/0x115252d0 [smbfs]
 [<eeadaed5>] smb_readpage+0x25/0x11525150 [smbfs]
 [<c0130c91>] read_pages+0xe1/0x130
 [<c013112c>] __do_page_cache_readahead+0xbc/0x110
 [<c0130d23>] do_page_cache_readahead+0x43/0x50
 [<c0130e7e>] page_cache_readahead+0x14e/0x190
 [<c012beeb>] do_generic_mapping_read+0xbb/0x3c0
 [<c012c230>] file_read_actor+0x0/0xf0
 [<c012c4f4>] __generic_file_aio_read+0x1d4/0x210
 [<c012c230>] file_read_actor+0x0/0xf0
 [<c012c63e>] generic_file_read+0x8e/0xb0
 [<c010abe5>] do_IRQ+0xc5/0xd0
 [<c0109570>] common_interrupt+0x18/0x20
 [<c01159ab>] do_schedule+0x17b/0x2b0
 [<eeadb240>] smb_file_read+0x80/0x11524e40 [smbfs]
 [<c014525e>] vfs_read+0xbe/0x130
 [<c01454fe>] sys_read+0x3e/0x60
 [<c0109403>] syscall_call+0x7/0xb

Code: 0f 0b 60 06 8f b6 25 c0 8b 46 34 e9 54 ff ff ff 8d b6 00 00

mm/slab.c :
(line 1632 marked with ^^^^^^)
(slab-debugging is enabled)

static inline void *
cache_alloc_debugcheck_after(kmem_cache_t *cachep,
                        unsigned long flags, void *objp)
        if (!objp)
                return objp;
        if (cachep->flags & SLAB_POISON)
                if (check_poison_obj(cachep, objp))
        if (cachep->flags & SLAB_RED_ZONE) {
                /* Set alloc red-zone, and check old one. */
                if (xchg((unsigned long *)objp, RED_ACTIVE) !=
                        slab_error(cachep, "memory before object was "
                if (xchg((unsigned long *)(objp+cachep->objsize -
                          BYTES_PER_WORD), RED_ACTIVE) != RED_INACTIVE)
                        slab_error(cachep, "memory after object was "
                objp += BYTES_PER_WORD;
        if (cachep->ctor && cachep->flags & SLAB_POISON) {
                unsigned long ctor_flags = SLAB_CTOR_CONSTRUCTOR;

                if (!flags & __GFP_WAIT)
                        ctor_flags |= SLAB_CTOR_ATOMIC;

                cachep->ctor(objp, cachep, ctor_flags);
        return objp;

I'm not sure how to reproduce this so I hope you know what might be
going on :)


Never argue with an idiot. They drag you down to their level, then beat you with experience. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:48 EST