I've tried digging more and just am still not sure what caused this.

At first I thought perhaps all_lock_classes list had some element not

yet removed as lockdep_free_key_range() iterates over the hash tables

but this doesn't seem to be the case.
I was using SLAB and ran into other strange oops, as the one below,

but after switching to SLUB, after Michael Buesch's suggestion that

one went away... The lockdep segfault is still present, however.
Just not sure what's going on. Any ideas?
----- oops with slab, not reproducible with slub:
mcgrof@pogo:~$ sudo rmmod tg3

mcgrof@pogo:~$ sudo rmmod sr_mod
*** dmesg -c
ACPI: PCI interrupt for device 0000:02:00.0 disabled

BUG: unable to handle kernel paging request at virtual address f88a4a05

printing eip: f88a4a05 *pde = 02000067 *pte = 00000000

Oops: 0000 [#1]

Modules linked in: sr_mod uinput thinkpad_acpi hwmon backlight nvram

ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand

cpufreq_conservative dock arc4 ecb blkcipher cryptomgr crypto_algapi

rc80211_simple ath5k mac80211 cfg80211 pcmcia crc32 snd_hda_intel

snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_oss

ipw2200 snd_seq_midi_event ieee80211 ieee80211_crypt sg ehci_hcd

uhci_hcd yenta_socket rsrc_nonstatic snd_seq snd_timer snd_seq_device

firmware_class cdrom pcmcia_core usbcore evdev rng_core rtc snd

soundcore
Pid: 2908, comm: modprobe Not tainted (2.6.24-rc1 #18)

EIP: 0060:[<f88a4a05>] EFLAGS: 00010086 CPU: 0

EIP is at 0xf88a4a05

EAX: c20b75c8 EBX: c2f86f38 ECX: f88a4a05 EDX: c2f86f38

ESI: c20b75c8 EDI: c2f89c00 EBP: c3897bfc ESP: c3897be0

 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068

Process modprobe (pid: 2908, ti=c3896000 task=c3935150 task.ti=c3896000)

Stack: c01b2afc c2f82d98 c3897bf4 c01ba8b6 c2f86f38 c20b75c8 c2f82c00 c3897c24

       c02186dd c2f86f38 c3897c24 c01b54c0 c20b75c8 00000001 c20b75c8 c2f86f38

       c20b75c8 c3897c30 c01b54ed 00000001 c3897c54 c01b556c 00000001 c3897cd4

Call Trace:

 [<c0104cec>] ...
[ message continues ]

Who is responsible for slab btw?

I mean, someone should be interested in getting this bug fixed. :)

When using slab I see random corruptions. I think related to rmmod, but

I'm not sure. I don't see this with slub.
--

Greetings Michael.

-

Pekka and Christoph do most SLAB work.
-

Hi Michael,
Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions

are caused by someone passing a bad pointer to kfree() or

kmem_cache_free().
                                  Pekka

-

Yeah.
What I also saw was random "one-bit-errors" once and then on rmmod of modules.

I have absolutely no idea how they were caused, though (I read the freeing

codes of the stuff hundreds of times). I don't have any of the oops messages

anymore.

But I do _not_ see this behaviour with slub anymore.
--

Greetings Michael.

-

Hi Michael,
It is possible that the corruption is still there but SLUB doesn't

show it. Have you tried with slub_debug enabled?
We jump to a bogus address 0xf88a4a05 via a function pointer from

scsi_request_fn(). Can you work out the exact file and line for

scsi_request_fn+0x5f (look for "gdb vmlinux" in

Documentation/BUG-HUNTING) please?
                                                   Pekka

-

Hm, I don't really remember. Though, I usually have all almost kernel-hacking

options enabled.
That'd be Luis' task then :)
--

Greetings Michael.

-

slub_debug must be specified on the command line. Alternately switch on

CONFIG_SLUB_DEBUG_ON in the .config to force it to be always on.

-