Hello everyone,
Summary:
Kernel Oops caused by multiple access requests to a single scanner
through libusb.
Detailed description:
The following script leads to an kernel oops on my System:
#!/bin/bash
scanimage > test &
scanimage -h
This is because scanimage -h tries to append a list of availlable
scanners to the help output and thus interferes with the first
scanimage process which is initializing the scanner at the same
moment. I am using the kernel 2.6.5 and the usb host controller
ohci-hcd. The kernel is tainted because I am using the loop-aes module
and the mppe patch from pptpclient.sf.net/mppe/ which should not
interfere with the scanning process.
Relevant kernel logs and the output of ksymoops applied to those logs
are attached seperately. Please let me know if you need any further
information.
Btw: After the occurrence of the kernel oops I tried a
# modprobe -r ohci-hcd
After showing some messages which indicated modprobe's effort to
process the command, modprobe hang it even
kill -9 pid
or
killall -9 modprobe
could not stop the process. When rebooting the system stopped during
shut down when it tried to stop alsa (most likely, because it uses
modprobe to unload the alsa related modules at this point).
Best regards,
Elias
On Fri, Apr 23, 2004 at 10:56:17PM +0200, E. Oltmanns wrote:
> Hello everyone,
>
> Summary:
> Kernel Oops caused by multiple access requests to a single scanner
> through libusb.
>
> Detailed description:
> The following script leads to an kernel oops on my System:
> #!/bin/bash
> scanimage > test &
> scanimage -h
>
> This is because scanimage -h tries to append a list of availlable
> scanners to the help output and thus interferes with the first
> scanimage process which is initializing the scanner at the same
> moment.
Heh, then don't do that :)
Accesses by two different processes of the same device through usbfs is
big trouble. Don't do that.
That being said, I have some usbfs locking patches that might help a bit
here that will probably show up in the next -mm release if you want to
see if that helps you out or not.
thanks,
greg k-h
Greg KH wrote:
> On Fri, Apr 23, 2004 at 10:56:17PM +0200, E. Oltmanns wrote:
>
>>Hello everyone,
>>
>>Summary:
>>Kernel Oops caused by multiple access requests to a single scanner
>>through libusb.
>>
>>Detailed description:
>>The following script leads to an kernel oops on my System:
>>#!/bin/bash
>>scanimage > test &
>>scanimage -h
>>
>>This is because scanimage -h tries to append a list of availlable
>>scanners to the help output and thus interferes with the first
>>scanimage process which is initializing the scanner at the same
>>moment.
>
>
> Heh, then don't do that :)
>
> Accesses by two different processes of the same device through usbfs is
> big trouble. Don't do that.
>
> That being said, I have some usbfs locking patches that might help a bit
> here that will probably show up in the next -mm release if you want to
> see if that helps you out or not.
Just in general, if there is anything a non-root user can do to crash
the system, it's probably a kernel bug by definition. It doesn't matter
that's it a stupid thing to do, it might be malicious. And in this case
it might just be user error.
Glad someone is working on locking, bozos and evil-doers abound ;-)
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Mon, Apr 26, 2004 at 01:06:15PM -0400, Bill Davidsen wrote:
>
> Just in general, if there is anything a non-root user can do to crash
> the system, it's probably a kernel bug by definition. It doesn't matter
> that's it a stupid thing to do, it might be malicious. And in this case
> it might just be user error.
But you either have to be root in order to talk to usbfs, or you were
root when you gave a user access to the usbfs node. So either way, a
"normal" user can't even do this.
thanks,
greg k-h
Am Montag, 26. April 2004 21:53 schrieb Greg KH:
> On Mon, Apr 26, 2004 at 01:06:15PM -0400, Bill Davidsen wrote:
> > Just in general, if there is anything a non-root user can do to crash
> > the system, it's probably a kernel bug by definition. It doesn't matter
> > that's it a stupid thing to do, it might be malicious. And in this case
> > it might just be user error.
>
> But you either have to be root in order to talk to usbfs, or you were
> root when you gave a user access to the usbfs node. So either way, a
> "normal" user can't even do this.
Greg,
that's not an answer. It in effect means that usbfs is useless.
Regards
Oliver
On Tue, Apr 27, 2004 at 12:17:34AM +0200, Oliver Neukum wrote:
> Am Montag, 26. April 2004 21:53 schrieb Greg KH:
> > On Mon, Apr 26, 2004 at 01:06:15PM -0400, Bill Davidsen wrote:
> > > Just in general, if there is anything a non-root user can do to crash
> > > the system, it's probably a kernel bug by definition. It doesn't matter
> > > that's it a stupid thing to do, it might be malicious. And in this case
> > > it might just be user error.
> >
> > But you either have to be root in order to talk to usbfs, or you were
> > root when you gave a user access to the usbfs node. So either way, a
> > "normal" user can't even do this.
>
> Greg,
>
> that's not an answer. It in effect means that usbfs is useless.
Particularly in network environtments the lack of locking facilities
is more than just discomfort even if root has the option of (limitted)
user level access control. But even if just local users were allowed
to use usbfs, double access could easily happen by accident, i.e., I
didn't expect
scanimage -h
to list the availlable scanners which caused the failure of usbfs in
my case. In conclusion I dare say that any effort on the development
of locking facilities for usbfs will be most likely appreciated very much.
Regards,
Elias
On Tue, Apr 27, 2004 at 12:17:34AM +0200, Oliver Neukum wrote:
> Am Montag, 26. April 2004 21:53 schrieb Greg KH:
> > On Mon, Apr 26, 2004 at 01:06:15PM -0400, Bill Davidsen wrote:
> > > Just in general, if there is anything a non-root user can do to crash
> > > the system, it's probably a kernel bug by definition. It doesn't matter
> > > that's it a stupid thing to do, it might be malicious. And in this case
> > > it might just be user error.
> >
> > But you either have to be root in order to talk to usbfs, or you were
> > root when you gave a user access to the usbfs node. So either way, a
> > "normal" user can't even do this.
>
> Greg,
>
> that's not an answer. It in effect means that usbfs is useless.
Heh. So the correct answer is:
- don't do that. Talking to the same device through usbfs at
the same time by multiple programs is cause for lots of bad
things to happen to your device, and might possibly cause it
to hang. If you want to allow a user to access a device
through usbfs, make sure you trust them.
Better? :)
thanks,
greg k-h
Am Dienstag, 27. April 2004 00:31 schrieb Greg KH:
> On Tue, Apr 27, 2004 at 12:17:34AM +0200, Oliver Neukum wrote:
> > Am Montag, 26. April 2004 21:53 schrieb Greg KH:
> > > On Mon, Apr 26, 2004 at 01:06:15PM -0400, Bill Davidsen wrote:
> > > > Just in general, if there is anything a non-root user can do to crash
> > > > the system, it's probably a kernel bug by definition. It doesn't
> > > > matter that's it a stupid thing to do, it might be malicious. And in
> > > > this case it might just be user error.
> > >
> > > But you either have to be root in order to talk to usbfs, or you were
> > > root when you gave a user access to the usbfs node. So either way, a
> > > "normal" user can't even do this.
> >
> > Greg,
> >
> > that's not an answer. It in effect means that usbfs is useless.
>
> Heh. So the correct answer is:
> - don't do that. Talking to the same device through usbfs at
> the same time by multiple programs is cause for lots of bad
> things to happen to your device, and might possibly cause it
> to hang. If you want to allow a user to access a device
> through usbfs, make sure you trust them.
>
> Better? :)
But that's not the issue, he got an oops.
No, don't do that means: Reserve usbfs to root.
Crashing a device which access is given to is maybe acceptable. Anything
more clearly is not.
Regards
Oliver
> Heh. So the correct answer is:
> - don't do that. Talking to the same device through usbfs at
> the same time by multiple programs is cause for lots of bad
> things to happen to your device, and might possibly cause it
> to hang. If you want to allow a user to access a device
> through usbfs, make sure you trust them.
If usbfs fails to work when a device is accessed by multiple programs
then that is a bug in usbfs and should be fixed. Hopefully it's already
fixed.
All the best,
Duncan.