Am Samstag, 23. Dezember 2006 02:50 schrieb J:
> Apparently, my earlier reply was lost, trying again:
>
> > 2. You must not do IO after returning from
> > disconnect
>
> Does usb_kill_urb count as "IO"?
No, you may call that on any URB you have a reference to.
HTH
Oliver
Apparently, my earlier reply was lost, trying again:
> 2. You must not do IO after returning from
> disconnect
Does usb_kill_urb count as "IO"?
Many drivers call it from their shutdown routines,
which may be called after disconnect.
> It is perfectly valid to do (in pseudocode)
>
> disconnect:
Am Samstag, 23. Dezember 2006 00:37 schrieb J:
> * usb_get_dev - increments the reference count of the
> usb device structure
> * @dev: the device being referenced
> *
> * Each live reference to a device should be
> refcounted.
> *
> * Drivers for USB interfaces should normally record
> such
OK, if I got you right, usb-serial is not supposed to
access any USB stuff after usb_serial_disconnect
because device to driver association is already broken
(even if usb_device structure is still
in memory by means of ref counting),
In fact, I just noticed the following comment
(in usb_get_dev
Am Freitag, 22. Dezember 2006 23:45 schrieb J:
> > if (!port || port->serial->dev->state ==
> > USB_STATE_NOTATTACHED)
>
> > There's no use checking for attachement. The state
> > may have changed.
> > In fact, if a device is disconnected via sysfs, this
> > code will happily write
> > to a de
On Friday 22 December 2006 2:45 pm, J wrote:
> As for the USB_STATE_NOTATTACHED, there is a long
> comment in hub.c about it. Also I see plenty of
> code, which checks it without any lock.
> So, I guess, it should not kill anybody.
Remember that "device attached" doesn't correlate
well to "driver
> if (!port || port->serial->dev->state ==
> USB_STATE_NOTATTACHED)
> There's no use checking for attachement. The state
> may have changed.
> In fact, if a device is disconnected via sysfs, this
> code will happily write
> to a device somebody else has claimed.
I don't understand. serial->
Am Freitag, 22. Dezember 2006 21:51 schrieb J:
I am dropping linux-kernel. This is an USB issue.
> Now, I am not yet 100% convinced that ref counting
> will, indeed, work. Atomics are known to have
> problems on SMP CPUs, which can reorder operations.
> But I would not discard atomics yet.
> Glob
> No, this is a fundamental problem. You don't
> refcount
> a pointer, you refcount a data structure.
> But this is insufficient. We need to make
> sure the pointer points to valid memory.
I understand. But a typical definition of ref-count
requires the count in the data structure to be
equal to
Am Freitag, 22. Dezember 2006 20:08 schrieb J:
> > This problem will need some deeper surgery probably
> > involving
> > removal of the refcounting.
>
> Refcounting may be OK if used consistently.
> It is not OK when some pointers are ref-counted,
> but other (in serial_table) are not (like it i
> This problem will need some deeper surgery probably
> involving
> removal of the refcounting.
Refcounting may be OK if used consistently.
It is not OK when some pointers are ref-counted,
but other (in serial_table) are not (like it is
in the current version).
As for the deeper surgery, what d
Am Mittwoch, 20. Dezember 2006 23:24 schrieb J:
> > Could you test the attached patch against 2.6?
>
> Alas, I only have an old 2.4 right now.
> May be I will install 2.6 later (in few weeks).
> Currently I am just trying to read 2.6 code with my
> eyes.
>
> I studied the patch, which you sent.
>
On Wed, Dec 20, 2006 at 02:39:39PM -0800, J wrote:
> Thank you for your reply.
>
> > Which usb-serial driver are you having problems
> > with? What is the oops trace?
> > What version of the 2.4 kernel are you using?
>
> I was told to fix an old embedded device, which my
> company bought from
Thank you for your reply.
> Which usb-serial driver are you having problems
> with? What is the oops trace?
> What version of the 2.4 kernel are you using?
I was told to fix an old embedded device, which my
company bought from somebody many years ago.
It appears to have kernel 2.4.9 and a pat
> Please send in a patch for 2.4. It's very important
> to have a
> very reliable ultraconservative tested kernel
> available.
I will try later. I am new to Linux driver development
and never submitted any patches before.
Also I am not yet 100% sure about the correct way
to solve this issue. I wil
Am Mittwoch, 20. Dezember 2006 16:10 schrieb Alan Stern:
> On Wed, 20 Dec 2006, Oliver Neukum wrote:
> > People, do we take BKL in khubd?
>
> Nope.
OK. I've taken measures to correct the problem.
Regards
Oliver
---
On Wed, Dec 20, 2006 at 11:32:31AM -0800, J wrote:
> Thank you for the explanation.
>
> > serial_close is safe because serial_disconnect
> > lowers the refcount
>
> Sorry, I meant serial_open, as in my original example.
>
> I am currently trying to fix a legacy 2.4 based USB
> driver and I am ha
Am Mittwoch, 20. Dezember 2006 20:32 schrieb J:
> I am currently trying to fix a legacy 2.4 based USB
> driver and I am having various races,
> serial_open/usb_serial_disconnect is the most lively.
> I am not asking your help in fixing this old 2.4 junk
> (in fact I already fixed it using a globa
On Wed, 20 Dec 2006, Oliver Neukum wrote:
> The data structure to protect is serial_table. Everything else is
> protected by refcounts. Therefore the interesting race is between
> open and disconnect. Open is called with BKL (fs/char_dev.c::chrdev_open)
>
> Now, regarding disconnect. It used to b
Am Dienstag, 19. Dezember 2006 23:33 schrieb J:
> Thank you for the response.
>
> > This code depends on protection from BKL.
>
> Really? I cannot find many lock_kernel calls in
> USB directory and those, which I can find,
> don't appear to protect usb_serial_disconnect
> and serial_close from
20 matches
Mail list logo
