I had to resurrect old notebook and immediately hit this under 2.6.32:
[ 77.254109] WARNING: at /home/bor/src/linux-git/kernel/lockdep.c:2465
lockdep
_trace_alloc+0x9a/0xa0()
[ 77.254109] Hardware name: PORTEGE 4000
[ 77.254109] Modules linked in: af_packet irnet ppp_generic slhc
ircomm_tty ircomm binfmt_misc dm_mirror dm_region_hash dm_log
dm_round_robin dm_multipath dm_mod loop nvram toshiba cryptomgr aead
pcompress crypto_blkcipher michael_mic crypto_hash crypto_algapi
orinoco_cs orinoco cfg80211 smsc_ircc2 pcmcia irda toshiba_acpi
yenta_socket video i2c_ali1535 backlight rsrc_nonstatic ali_agp
pcmcia_core psmouse output crc_ccitt i2c_core alim1535_wdt rfkill sg
evdev ohci_hcd agpgart usbcore pata_ali libata reiserfs [last unloaded:
scsi_wait_scan]
[ 77.254109] Pid: 2296, comm: wpa_supplicant Not tainted 2.6.32-1avb
#1
[ 77.254109] Call Trace:
[ 77.254109] [<c011f0ad>] warn_slowpath_common+0x6d/0xa0
[ 77.254109] [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0
[ 77.254109] [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0
[ 77.254109] [<c011f0f5>] warn_slowpath_null+0x15/0x20
[ 77.254109] [<c014206a>] lockdep_trace_alloc+0x9a/0xa0
[ 77.254109] [<c018d296>] __kmalloc+0x36/0x130
[ 77.254109] [<dffcb6a8>] ? orinoco_set_key+0x48/0x1c0 [orinoco]
[ 77.254109] [<dffcb6a8>] orinoco_set_key+0x48/0x1c0 [orinoco]
[ 77.254109] [<dffcb9fc>] orinoco_ioctl_set_encodeext+0x1dc/0x2d0
[orinoco]
Moving allocation outside of orinoco_lock is non-trivial (as sometimes
it depends on information from card which itself must be protected).
Until orinoco_lock can be converted from spinlock into mutex, this patch
is the most simple solution.
Andrey Borzenkov wrote:
> On Thursday 10 of December 2009 21:34:53 Dave wrote:
>> Andrey Borzenkov wrote:
>>> I had to resurrect old notebook and immediately hit this under
>>> 2.6.32:
>>>
>>> [ 77.254109] WARNING: at
>>> /home/bor/src/linux-git/kernel/lockdep.c:2465 lockdep
>>> _trace_alloc+0x9a/0xa0()
>>>
>>> Until orinoco_lock can be converted from spinlock into mutex, this
>>> patch is the most simple solution.
>> Thank you Andrey. The patch is correct (though it could clean up the
>> misdirected comment 4 or 5 lines above).
>
> Do you want me to resubmit with this cleanup?
>
>> Is it worth pushing this to stable?
>
> I think yes. Sleeping under spinlock with interrupts disabled is not fun
> even if it is very unlikely.
If I understand it right, we want to cc the patch to [email protected].
So if you could take care of that comment and resubmit with cc (and
something in the title so John can tell we'd like this in 2.6.33 as
well), everyone's happy
<festive>
and Santa distributes the patch to all the good little kernels and
kernelettes
</festive>
Dave.
Andrey Borzenkov wrote:
> I had to resurrect old notebook and immediately hit this under 2.6.32:
>
> [ 77.254109] WARNING: at /home/bor/src/linux-git/kernel/lockdep.c:2465
> lockdep
> _trace_alloc+0x9a/0xa0()
>
> Until orinoco_lock can be converted from spinlock into mutex, this patch
> is the most simple solution.
Thank you Andrey. The patch is correct (though it could clean up the
misdirected comment 4 or 5 lines above).
Is it worth pushing this to stable?
Dave.
On Thursday 10 of December 2009 21:34:53 Dave wrote:
> Andrey Borzenkov wrote:
> > I had to resurrect old notebook and immediately hit this under
> > 2.6.32:
> >
> > [ 77.254109] WARNING: at
> > /home/bor/src/linux-git/kernel/lockdep.c:2465 lockdep
> > _trace_alloc+0x9a/0xa0()
> >
> > Until orinoco_lock can be converted from spinlock into mutex, this
> > patch is the most simple solution.
>
> Thank you Andrey. The patch is correct (though it could clean up the
> misdirected comment 4 or 5 lines above).
>
Do you want me to resubmit with this cleanup?
> Is it worth pushing this to stable?
>
I think yes. Sleeping under spinlock with interrupts disabled is not fun
even if it is very unlikely.
On Monday 14 of December 2009 16:53:35 Dave wrote:
> If I understand it right, we want to cc the patch to
> [email protected]. So if you could take care of that comment and
> resubmit with cc (and something in the title so John can tell we'd
> like this in 2.6.33 as well), everyone's happy
>
New version attached.