2002-10-18 01:55:22

by Ed Tomlinson

[permalink] [raw]
Subject: usb storage sddr09

Hi,

In the patch fest in the last couple of days usb storage support for sddr09
has broken. I see the following in the log (2.5.43-mm2):

Oct 17 21:37:07 oscar kernel: SCSI subsystem driver Revision: 1.00
Oct 17 21:37:07 oscar kernel: Initializing USB Mass Storage driver...
Oct 17 21:37:07 oscar kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Oct 17 21:37:07 oscar kernel: Vendor: Sandisk Model: ImageMate SDDR-0 Rev: 0208
Oct 17 21:37:07 oscar kernel: Type: Direct-Access ANSI SCSI revision: 02
Oct 17 21:37:07 oscar kernel: drivers/usb/core/usb.c: registered new driver usb-storage
Oct 17 21:37:07 oscar kernel: USB Mass Storage support registered.

Oct 17 21:37:07 oscar kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
Oct 17 21:37:07 oscar kernel: sda : status = 0, message = 00, host = 7, driver = 00
Oct 17 21:37:07 oscar kernel: sddr09: Found Flash card, ID = 00 00 00 00: Manuf. unknown, 4096 MB
Oct 17 21:37:07 oscar kernel: sda : unsupported sector size 1.
Oct 17 21:37:07 oscar kernel: SCSI device sda: 0 1-byte hdwr sectors (0 MB)
Oct 17 21:37:07 oscar kernel: sda: Write Protect is off

mounting then complains /dev/sda1 is not a valid block device. Also attempting to rmmod
usb-storage gets:

Oct 17 21:53:12 oscar kernel: kernel BUG at drivers/base/core.c:269!
Oct 17 21:53:12 oscar kernel: invalid operand: 0000
Oct 17 21:53:12 oscar kernel: vfat af_packet snd-cs46xx snd-pcm snd-timer snd-rawmidi snd-seq-device snd-ac97-codec snd s
oundcore gameport softdog matroxfb_base matroxfb_g450 matroxfb_DAC1064 g450_pll matroxfb_accel fbcon-cfb32 fbcon-cfb8 fbc
on-cfb24 fbcon-cfb16 matroxfb_misc mga agpgart pppoe pppox ipchains msdos fat sd_mod floppy dummy bsd_comp ppp_generic sl
hc parport_pc lp parport ipip smbfs nls_cp850 nls_cp437 binfmt_aout autofs4 cdrom via-rhine mii tulip crc32 usb-storage s
csi_mod pl2303 usbserial hid
Oct 17 21:53:12 oscar kernel: CPU: 0
Oct 17 21:53:12 oscar kernel: EIP: 0060:[put_device+71/112] Not tainted
Oct 17 21:53:12 oscar kernel: EFLAGS: 00010202
Oct 17 21:53:12 oscar kernel: EIP is at put_device+0x47/0x70
Oct 17 21:53:12 oscar kernel: eax: 00000000 ebx: df39bd64 ecx: df39bdfc edx: c5be0000
Oct 17 21:53:12 oscar kernel: esi: dfacaa98 edi: c5b73000 ebp: dfacaa00 esp: c5be1f2c
Oct 17 21:53:12 oscar kernel: ds: 0068 es: 0068 ss: 0068
Oct 17 21:53:12 oscar kernel: Process rmmod (pid: 1353, threadinfo=c5be0000 task=c857b9c0)
Oct 17 21:53:12 oscar kernel: Stack: 00000000 df39bc00 e0958bb0 df39bd64 dfacac00 e0966000 c5b73000 e0966000
Oct 17 21:53:12 oscar kernel: c03099d0 e096e3d8 c0197f09 c0311980 c031199c c0197f56 e096e3d8 e096e3d8
Oct 17 21:53:12 oscar kernel: e0966000 c01c942c e096e3d8 c02402c0 e096bffb fffffff0 e096963c dfacacc0
Oct 17 21:53:12 oscar kernel: Call Trace:
Oct 17 21:53:12 oscar kernel: [<e0958bb0>] scsi_unregister_host_R98f50472+0x214/0x4e8 [scsi_mod]
Oct 17 21:53:12 oscar kernel: [<e096e3d8>] usb_storage_driver+0x18/0x7c [usb-storage]
Oct 17 21:53:12 oscar kernel: [__remove_driver+41/48] __remove_driver+0x29/0x30
Oct 17 21:53:12 oscar kernel: [remove_driver+70/76] remove_driver+0x46/0x4c
Oct 17 21:53:12 oscar kernel: [<e096e3d8>] usb_storage_driver+0x18/0x7c [usb-storage]
Oct 17 21:53:12 oscar kernel: [<e096e3d8>] usb_storage_driver+0x18/0x7c [usb-storage]
Oct 17 21:53:12 oscar kernel: [usb_deregister+32/40] usb_deregister+0x20/0x28
Oct 17 21:53:12 oscar kernel: [<e096e3d8>] usb_storage_driver+0x18/0x7c [usb-storage]
Oct 17 21:53:12 oscar kernel: [<e096bffb>] __module_usb_device_size+0x4bf/0xcb5 [usb-storage]
Oct 17 21:53:12 oscar kernel: [<e096963c>] usb_stor_exit+0x24/0x86 [usb-storage]
Oct 17 21:53:12 oscar kernel: [free_module+23/192] free_module+0x17/0xc0
Oct 17 21:53:12 oscar kernel: [sys_delete_module+284/628] sys_delete_module+0x11c/0x274
Oct 17 21:53:12 oscar kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Oct 17 21:53:12 oscar kernel:
Oct 17 21:53:12 oscar kernel: Code: 0f 0b 0d 01 69 70 23 c0 8b 83 d0 00 00 00 85 c0 74 06 53 ff
Oct 17 21:53:12 oscar /sbin/hotplug: no runnable /etc/hotplug/block.agent is installed

Last time I used the device was around 2.5.40 or so - it worked then, but was
much happier if I left a card in the reader during boot.

Ideas?
Ed Tomlinson




2002-10-18 19:29:34

by Andries Brouwer

[permalink] [raw]
Subject: Re: usb storage sddr09

On Thu, Oct 17, 2002 at 09:55:49PM -0400, Ed Tomlinson wrote:

> In the patch fest in the last couple of days usb storage support for sddr09
> has broken. I see the following in the log (2.5.43-mm2):

> Oct 17 21:37:07 oscar kernel: sddr09: Found Flash card, ID = 00 00 00 00: Manuf. unknown, 4096 MB
> Oct 17 21:37:07 oscar kernel: sda : unsupported sector size 1.
> Oct 17 21:37:07 oscar kernel: SCSI device sda: 0 1-byte hdwr sectors (0 MB)

Yes. Reverting the 2.5.43 patch on usb/storage fixes this.

> Also attempting to rmmod usb-storage gets:
>
> Oct 17 21:53:12 oscar kernel: kernel BUG at drivers/base/core.c:269!

Yes. I have seen the patch several times on this list.
See http://marc.theaimsgroup.com/?l=linux-kernel&m=103479992624108&w=2

Andries

2002-10-20 13:56:13

by Ed Tomlinson

[permalink] [raw]
Subject: Re: usb storage sddr09

On October 18, 2002 03:35 pm, Andries Brouwer wrote:
> On Thu, Oct 17, 2002 at 09:55:49PM -0400, Ed Tomlinson wrote:
> > In the patch fest in the last couple of days usb storage support for
> > sddr09 has broken. I see the following in the log (2.5.43-mm2):
> >
> > Oct 17 21:37:07 oscar kernel: sddr09: Found Flash card, ID = 00 00 00 00:
> > Manuf. unknown, 4096 MB Oct 17 21:37:07 oscar kernel: sda : unsupported
> > sector size 1.
> > Oct 17 21:37:07 oscar kernel: SCSI device sda: 0 1-byte hdwr sectors (0
> > MB)
>
> Yes. Reverting the 2.5.43 patch on usb/storage fixes this.
>
> > Also attempting to rmmod usb-storage gets:
> >
> > Oct 17 21:53:12 oscar kernel: kernel BUG at drivers/base/core.c:269!
>
> Yes. I have seen the patch several times on this list.
> See http://marc.theaimsgroup.com/?l=linux-kernel&m=103479992624108&w=2

Both of these are fixed with 2.4.44

Thanks
Ed Tomlinson

2002-10-20 18:18:39

by Andries Brouwer

[permalink] [raw]
Subject: Container_of considered harmful - was Re: usb storage sddr09

> Both of these are fixed with 2.4.44

Yes, there is progress. Not to say that there are no oopses left,
but with 2.5.44 the oopses are different.

Let me just report one, don't know whether I'll have time to track
what happens.

Insert and remove a usb-storage device while usb-storage
is not loaded. Now load usb-storage. Oops.

The oops is a dereference of fffffff0 in base/bus.c:driver_attach().
I have seen several such oopses lately, various places in the kernel.
The cause here is a NULL pointer that is turned into fffffff0 by
container_of() and then fed to get_device(). And get_device() tests
that it gets a non-NULL pointer, but that does not protect against
fffffff0.

Andries

2002-10-21 04:06:38

by Matthew Dharm

[permalink] [raw]
Subject: Re: [linux-usb-devel] Container_of considered harmful - was Re: usb storage sddr09

Actually, I've seen this one with 2.5.44 and no USB storage devices
attached. Just load usb-storage and it OOPSes.

I haven't been able to find it yet, but I haven't looked as hard as I
could.

Matt

On Sun, Oct 20, 2002 at 08:24:36PM +0200, Andries Brouwer wrote:
> > Both of these are fixed with 2.4.44
>
> Yes, there is progress. Not to say that there are no oopses left,
> but with 2.5.44 the oopses are different.
>
> Let me just report one, don't know whether I'll have time to track
> what happens.
>
> Insert and remove a usb-storage device while usb-storage
> is not loaded. Now load usb-storage. Oops.
>
> The oops is a dereference of fffffff0 in base/bus.c:driver_attach().
> I have seen several such oopses lately, various places in the kernel.
> The cause here is a NULL pointer that is turned into fffffff0 by
> container_of() and then fed to get_device(). And get_device() tests
> that it gets a non-NULL pointer, but that does not protect against
> fffffff0.
>
> Andries
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> [email protected]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver

What, are you one of those Microsoft-bashing Linux freaks?
-- Customer to Greg
User Friendly, 2/10/1999


Attachments:
(No filename) (1.58 kB)
(No filename) (232.00 B)
Download all attachments

2002-10-23 01:39:41

by Kevin O'Connor

[permalink] [raw]
Subject: Re: Container_of considered harmful - was Re: usb storage sddr09

On Sun, Oct 20, 2002 at 08:24:36PM +0200, Andries Brouwer wrote:
> The oops is a dereference of fffffff0 in base/bus.c:driver_attach().
> I have seen several such oopses lately, various places in the kernel.
> The cause here is a NULL pointer that is turned into fffffff0 by
> container_of() and then fed to get_device(). And get_device() tests
> that it gets a non-NULL pointer, but that does not protect against
> fffffff0.

Just as an anecdote - I built a variant of container_of to protect against
cases where NULL can creep in:

#define test_container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__p = (ptr); \
__p ? container_of(__p, type, member) : NULL;})

It calls the real container_of only if 'ptr' is not NULL.

-Kevin

--
------------------------------------------------------------------------
| Kevin O'Connor "BTW, IMHO we need a FAQ for |
| [email protected] 'IMHO', 'FAQ', 'BTW', etc. !" |
------------------------------------------------------------------------