Hi,
this should avoid memory allocations.
For iso-URBs GFP_ATOMIC might hurt,
yet it's necessary if holding a spinlock around
usb_submit_urb() is legal.
The second replacement changes nothing.
Within an irqsave spinlock, it's always ATOMIC anyway.
Regards
Oliver
--- usb-
Hi,
this avoids deadlocks with submitting URBs with storage and
with spinlocks held.
Regards
Oliver
--- usb-ohci.c.alt Sat Dec 1 20:41:47 2001
+++ usb-ohci.c Wed Dec 12 03:14:49 2001
@@ -614,7 +614,7 @@
/* allocate the private part of the URB */
u
Hi,
as we have discussed there's a problem with devices
that need their firmware reloaded on resume.
If they are used for paging out, memory allocation can
deadlock. Therefore the simple solution of running a shell
script on resume won't work.
The recent discussion has convinced me that this pro
Am Mittwoch, 12. Dezember 2001 01:57 schrieb Alan Cox:
> > > NFS uses GFP_NOFS as appropriate so should always do the right thing
> > > itself.
> >
> > What about the physical network io path ?
>
> Thats using GFP_NOIO/GFP_ATOMIC already.
Not true for usbnet.c.
I haven't checked the serial driver
Am Mittwoch, 12. Dezember 2001 01:50 schrieb Alan Cox:
> > The arch maintainers will have to fix the odd drivers.
> > Basically the submit_urb() codepath must use only GFP_ATOMIC.
>
> submit_urb and submit_urb_atomic() ?
If we are going to change the api, then why not introduce a further
paramete
On Wed, Dec 12, 2001, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> could somebody tell me why usb_control_msg() uses the
> p-forms of the endianness conversions ?
The p forms do it from a pointer. However, creating a reference and then
derefencing it seems to be superfluous.
JE
_
> > NFS uses GFP_NOFS as appropriate so should always do the right thing
> > itself.
>
> What about the physical network io path ?
Thats using GFP_NOIO/GFP_ATOMIC already.
> IIRC and I may very well be wrong nfs now uses the page cache.
> Thus for any nfs write the rules for block device memory
> Unfortunately it's still not enough to prevent deadlocks.
> The host controller drivers allocate memory, too.
Wasn't the right fix for this to pass GFP/SLAB flag bits
into the usb_submit_urb() and the usb_bus.submit_urb?
> Basically the submit_urb() codepath must use only GFP_ATOMIC.
> I am n
> The arch maintainers will have to fix the odd drivers.
> Basically the submit_urb() codepath must use only GFP_ATOMIC.
submit_urb and submit_urb_atomic() ?
> I am not sure about urb unlinking. Does the scsi layer report an error
> before it goes through error handling ? If this is not the case
Am Dienstag, 11. Dezember 2001 23:32 schrieb Alan Cox:
> > Then we need a gfp parameter in virtually all api functions and the
> > api for host controllers. (Or do a lot of GFP_ATOMIC/GFP_NOIO. I mention
> > this only for completeness' sake.)
>
> You may need to yes. You might also want to preallo
Am Mittwoch, 12. Dezember 2001 01:17 schrieb Matthew Dharm:
> This is alreay in the CVS repository undergoing final testing before being
> sent to Greg.
>
> Matt
Very well.
Unfortunately it's still not enough to prevent deadlocks.
The host controller drivers allocate memory, too.
If nobody is qui
This is alreay in the CVS repository undergoing final testing before being
sent to Greg.
Matt
On Wed, Dec 12, 2001 at 01:07:02AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 12. Dezember 2001 00:40 schrieb Matthew Dharm:
> > I don't know what others think, but I think you missed a spot. devrequet
Am Mittwoch, 12. Dezember 2001 00:40 schrieb Matthew Dharm:
> I don't know what others think, but I think you missed a spot. devrequets
> is also used in the storage/ directory.
OK, here's the patch which removes the possible deadlocks from the storage
directory.
Regards
Hi,
could somebody tell me why usb_control_msg() uses the
p-forms of the endianness conversions ?
Regards
Oliver
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/lin
Am Mittwoch, 12. Dezember 2001 00:40 schrieb Matthew Dharm:
> I don't know what others think, but I think you missed a spot. devrequets
> is also used in the storage/ directory.
Yes, you are right. However storage uses GFP_KERNEL at a lot of places it shouldn't.
I'll make a patch.
Regar
I don't know what others think, but I think you missed a spot. devrequets
is also used in the storage/ directory.
Matt
On Wed, Dec 12, 2001 at 12:30:44AM +0100, Oliver Neukum wrote:
> Hi,
>
> here's the patch that introduces a buffer for usb_control_msg
> and fixes memory allocations in danger
Hi,
here's the patch that introduces a buffer for usb_control_msg
and fixes memory allocations in danger of deadlocking in usb.c
What do you think ?
Regards
Oliver
--- include/linux/usb.h.alt Sun Dec 9 13:49:56 2001
+++ include/linux/usb.h Wed Dec 12 00:19:26 2001
On Tue, Dec 11, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > Allocate devrequest when you allocate the device and it'll work in 99%
> > of the cases people care about, which is 100% of existing drivers.
>
> One suspects it's not common, but that can't be relied on. If
> anyone makes such
> > Actually there's no technical reason device shouldn't handle multiple
> > queued control transfers, and I could see it happening in cases
> > where more than one driver needs to talk to the device at a time.
> >
> > Whether drivers want to impose a exclusionary policy about
> > control transf
On Tue, Dec 11, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > You might also want to prealloc a scratch buffer or
> > > stuff one in your per instance structure for said usb device and use that.
> >
> > This is a fine idea.
>
> A fine typical-case optimization, yes.
>
> > You can on
> > You might also want to prealloc a scratch buffer or
> > stuff one in your per instance structure for said usb device and use that.
>
> This is a fine idea.
A fine typical-case optimization, yes.
> You can only do one control transfer at a time anyway.
Actually there's no technical rea
> Then we need a gfp parameter in virtually all api functions and the
> api for host controllers. (Or do a lot of GFP_ATOMIC/GFP_NOIO. I mention this only
> for completeness' sake.)
You may need to yes. You might also want to prealloc a scratch buffer or
stuff one in your per instance structure f
On Tue, Dec 11, 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Then we need a gfp parameter in virtually all api functions and the
> > api for host controllers. (Or do a lot of GFP_ATOMIC/GFP_NOIO. I mention this only
> > for completeness' sake.)
>
> You may need to yes. You might also want to pre
On Tue, Dec 11, 2001 at 10:51:21PM +0100, Oliver Neukum wrote:
> > > > Right. And that's 2.5 fodder that can be backported, yes?
> > >
> > > Only at the cost of breaking all external drivers.
> >
> > ...which will when the time comes have to cope with 2.5 and 2.4 being
> > different regardless.
> > > Right. And that's 2.5 fodder that can be backported, yes?
> >
> > Only at the cost of breaking all external drivers.
>
> ...which will when the time comes have to cope with 2.5 and 2.4 being
> different regardless. This happend (generically) in 2.2 a few times to
> make backporting easier,
Am Dienstag, 11. Dezember 2001 22:32 schrieb Alan Cox:
> > It's very likely that the type of the controller is not deciding the
> > issue. The question is rather how the architectures allocate the kernel
> > stack. Which architectures are hit ?
>
> If you are doing DMA off the stack your code will
On Tue, Dec 11, 2001 at 10:29:17PM +0100, Oliver Neukum wrote:
> > > Completely fixing this bug requires a change to a lot of api functions.
> > > Have a look at, eg. kaweth.c/kaweth_start_xmit(). It can deadlock on
> > > smp.
> > > There are a lot of drivers doing dma on the stack. I know it's b
On Tue, Dec 11, 2001, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > It's very likely that the type of the controller is not deciding the
> > > issue. The question is rather how the architectures allocate the kernel
> > > stack.
> >
> > Yes. My point is that we don't want to do this right now sin
kmalloc is implemented in terms of the slab cache, so we effectively
already have this.
I don't think creating our own slab cache will buy us very much.
JE
On Tue, Dec 11, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> Hrm... since a devrequest structure is needed by anyone who wants to do a
> > It's very likely that the type of the controller is not deciding the
> > issue. The question is rather how the architectures allocate the kernel
> > stack.
>
> Yes. My point is that we don't want to do this right now since it's a
> micro optimization and it'll break all of those changes for t
> It's very likely that the type of the controller is not deciding the issue.
> The question is rather how the architectures allocate the kernel stack.
> Which architectures are hit ?
If you are doing DMA off the stack your code will not work on anything but
x86 and maybe alpha in some cases.
>
On Tue, Dec 11, 2001 at 10:16:32PM +0100, Oliver Neukum wrote:
> Am Dienstag, 11. Dezember 2001 21:53 schrieb Tom Rini:
> > On Tue, Dec 11, 2001 at 09:42:02PM +0100, Oliver Neukum wrote:
> > > > IMHO, since the only safe thing to do across all architectures is to
> > > > kmalloc the devrequest str
Am Dienstag, 11. Dezember 2001 21:53 schrieb Tom Rini:
> On Tue, Dec 11, 2001 at 09:42:02PM +0100, Oliver Neukum wrote:
> > > IMHO, since the only safe thing to do across all architectures is to
> > > kmalloc the devrequest structure, anything other than that is
> > > essentially micro optimizatio
Hrm... since a devrequest structure is needed by anyone who wants to do a
control request, and most of the uses seem to be "allocate, use, destroy",
would a slab cache be useful here? I mean a USB-wide one, not a
per-sub-driver one.
Matt
On Tue, Dec 11, 2001 at 03:14:22PM -0500, Johannes Erdfel
On Tue, Dec 11, 2001 at 09:42:02PM +0100, Oliver Neukum wrote:
> > IMHO, since the only safe thing to do across all architectures is to
> > kmalloc the devrequest structure, anything other than that is essentially
> > micro optimization that's not worth it.
>
> On the other hand it makes using th
On Tue, Dec 11, 2001, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > IMHO, since the only safe thing to do across all architectures is to
> > kmalloc the devrequest structure, anything other than that is essentially
> > micro optimization that's not worth it.
>
> On the other hand it makes using th
> IMHO, since the only safe thing to do across all architectures is to
> kmalloc the devrequest structure, anything other than that is essentially
> micro optimization that's not worth it.
On the other hand it makes using that function in the block IO path safe.
Thus, if there's really no risk in
On Tue, Dec 11, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > All of the USB host controller drivers are PCI devices.
>
> Various folk have said they want to integrate patches
> for some of those non-PCI OHCIs in the 2.5 tree, so I'd
> expect that to change.
>
> Re the original patch, I th
> All of the USB host controller drivers are PCI devices.
Various folk have said they want to integrate patches
for some of those non-PCI OHCIs in the 2.5 tree, so I'd
expect that to change.
Re the original patch, I think that's a case of "better safe
than sorry". Not DMAing to/from the stack i
On Tue, Dec 11, 2001 at 10:43:18AM +0100, Oliver Neukum wrote:
> > Duncan's point was accurate: that locking is not an issue with
> > drivers accessed through char or block special files. On the
> > other hand, those would use the "regular" ioctl route, so it'd not
> > normally be an issue. (Ex
On Tue, Dec 11, 2001 at 06:24:47AM -, Pankaj Kumar Soni wrote:
>
> Hello All
> Can anybody tell me what steps i follow to
> write usb driver for ADC card. I have seen
> Mouse driver, and it is a bit difficult for
> me to design ADC driver based on this.
> Can any one will suggest me some sol
>Bad patch. The devrequest struct needs to be in DMAable memory, and the
>kernels stack isn't DMAable on all arches.
>usb-storage is broken that way... it's on my TODO list, too...
>Matt
Since my previous response to this message, I have now looked
through linux-2.5.1-pre8/Documentatio
[EMAIL PROTECTED] wrote:
> I consequently have a bunch of questions for anyone kind enough
> to answer them.
>
> 1. All USB host controller drivers are currently PCI
> drivers. I do not know non-PCI ohci or uhci conformant
> controllers are even possible. Am I correct in understand
Adam J. Richter wrote:
>>Bad patch. The devrequest struct needs to be in DMAable memory, and the
>>kernels stack isn't DMAable on all arches.
>>
>
>>usb-storage is broken that way... it's on my TODO list, too...
>>
>
>>Matt
>>
>
> Thanks for catching this so quickly.
>
> I conseq
Am Dienstag, 11. Dezember 2001 10:10 schrieb Adam J. Richter:
> >Bad patch. The devrequest struct needs to be in DMAable memory, and the
> >kernels stack isn't DMAable on all arches.
> >
> >usb-storage is broken that way... it's on my TODO list, too...
> >
> >Matt
>
> Thanks for catching th
> Duncan's point was accurate: that locking is not an issue with
> drivers accessed through char or block special files. On the
> other hand, those would use the "regular" ioctl route, so it'd not
> normally be an issue. (Except for stuff like "what's your major/minor?",
> which has been needed
>Bad patch. The devrequest struct needs to be in DMAable memory, and the
>kernels stack isn't DMAable on all arches.
>usb-storage is broken that way... it's on my TODO list, too...
>Matt
Thanks for catching this so quickly.
I consequently have a bunch of questions for anyone k
Bad patch. The devrequest struct needs to be in DMAable memory, and the
kernels stack isn't DMAable on all arches.
usb-storage is broken that way... it's on my TODO list, too...
Matt
On Tue, Dec 11, 2001 at 12:26:14AM -0800, Adam J. Richter wrote:
> Am I missing something, or does usb_co
Am I missing something, or does usb_control_msg do a completely
unnecessary kmalloc?
The following patch changes usb_control_msg to allocate the
16-byte devrequest structure on the stack, saving CPU cycles, eliminating
a mode of failure and making the code more readable. I suspec
49 matches
Mail list logo
