Am Freitag, 11. Oktober 2002 17:45 schrieb John Tyner:
> > Sorry, my humor got the better of me. You should add a few comment
> > regarding the locking through v4l open. YOur relienance on it makes
> > it very subtle and impossible to understand without comments.
> > The code itself is very well.
> Sorry, my humor got the better of me. You should add a few comment
> regarding the locking through v4l open. YOur relienance on it makes
> it very subtle and impossible to understand without comments.
> The code itself is very well.
Absolutely. Once there are no more problems with the code, I'l
Am Freitag, 11. Oktober 2002 02:50 schrieb John Tyner:
> > To be frank, your disconnection handling is the most outrageous abuse
> > of semaphores I've seen in months. But it is correct :-)
>
> Well, I'd like it to be correct in the "it's actually decent code"
> department as well. The "in months"
> To be frank, your disconnection handling is the most outrageous abuse
> of semaphores I've seen in months. But it is correct :-)
Well, I'd like it to be correct in the "it's actually decent code"
department as well. The "in months" part makes me feel a little bit better,
though, as it implies s
Am Donnerstag, 10. Oktober 2002 10:08 schrieb John Tyner:
> Let's try this one. Patch is against 2.5.41.
>
> The device is no longer unregistered in the disconnect but in the
> vicam_free_memory function. This introduced a race with the open call,
> which I believe I've taken care of. I also imple
Let's try this one. Patch is against 2.5.41.
The device is no longer unregistered in the disconnect but in the
vicam_free_memory function. This introduced a race with the open call, which
I believe I've taken care of. I also implemented the mechanism that I talked
about in my previous email for d
>>>Also, it's not strictly necessary to release mutexes you've
>>>grabbed if they're being freed, but it's good style to do so.
>>
>>That's assuming you've arranged (out-of-band) that nobody else
>>can be blocking on that lock (I was actually thinking 'spinlock')
>>as should be the case in correct
Am Mittwoch, 9. Oktober 2002 20:30 schrieb John Tyner:
> On Wed, 9 Oct 2002, Oliver Neukum wrote:
> > Hi,
> >
> > you make me feel like a villain from a bad movie, but ...
>
> Ha, ha, ha. Hopefully, you won't give up before I get it right. :)
Giving up? What is that? Can one eat it? How does it t
On Wed, 9 Oct 2002, Oliver Neukum wrote:
> Hi,
>
> you make me feel like a villain from a bad movie, but ...
Ha, ha, ha. Hopefully, you won't give up before I get it right. :)
> > release {
> > get disconnect mutex
> > decrement users
>
> Don't do this. Release does not map to close.
>
On Wed, Oct 09, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Also, it's not strictly necessary to release mutexes you've
> > grabbed if they're being freed, but it's good style to do so.
>
> That's assuming you've arranged (out-of-band) that nobody else
> can be blocking on that lock (I
> Also, it's not strictly necessary to release mutexes you've
> grabbed if they're being freed, but it's good style to do so.
That's assuming you've arranged (out-of-band) that nobody else
can be blocking on that lock (I was actually thinking 'spinlock')
as should be the case in correct disconne
> I've tried to solve it in the following manner:
>
> release {
> get disconnect mutex
I don't like the sound of "disconnect mutex" since it implies
a mutex that's not used everywhere it should be. The driver
has its own device state; just protect all access to it. Don't
ever try to get
Hi,
you make me feel like a villain from a bad movie, but ...
> I think it would allow, but the problem seems to be that the disconnect
> routine cannot wait indefinitely for a wake up call from the release
> function. Unfortunately, as Oliver pointed out, a user opening the
> device and not rel
On Wed, 9 Oct 2002, David Brownell wrote:
>
> Or better yet, use the primitives and
> call wait_for_completion() ... if your event model allows.
I think it would allow, but the problem seems to be that the disconnect
routine cannot wait indefinitely for a wake up call from the release
function.
>>What's wrong with sleep_on? What is the appropriate macro?
>
>
> sleep_on has a race condition by design, you may loose the wake up
> and there's nothing you can do about it. There's a risk of becoming
> a sleeping beauty.
> Use wait_event instead.
Or better yet, use the primitives and
call
> > + if ( vdev->users ) {
> > + sleep_on( &vicam_v4l_priv->no_users );
> > + }
> >
> > _Very_ bad idea.
> > First, never use sleep_on. Use the appropriate macro.
>
> What's wrong with sleep_on? What is the appropriate macro?
sleep_on has a race condition by design, you may loose t
Hi,
I'm removing Greg and the linux-kernel list from To/CC of this thread. I
think Greg gets it from the usb-devel list, and I don't want to take up
more bandwidth on the linux-kernel list with this single usb issue. :)
Now, on to the fun stuff.
> + if ( waitqueue_active( &vicam_v4l_priv->n
On Tuesday 08 October 2002 07:40, John Tyner wrote:
> This is a resend of the patch I sent earlier. I worked on the one earlier
> while away from home and was unable to test it. This one has been fixed,
> tested, and should be correct. Sorry for the confusion.
>
> Patch is against 2.5.41.
>
> Than
This is a resend of the patch I sent earlier. I worked on the one earlier
while away from home and was unable to test it. This one has been fixed,
tested, and should be correct. Sorry for the confusion.
Patch is against 2.5.41.
Thanks,
John
vicam-2.5.41.patch.gz
Description: GNU Zip compresse
On Mon, 7 Oct 2002, Oliver Neukum wrote:
> Well, here we go again, there are other issues as well.
> There's a race between open() and disconnect(). The best way to deal
[snip]
I believe this addresses (and hopefully corrects) this issues raised about
the race between disconnect and the device b
> Attached is a patch against 2.5.40 with __dev* uses removed and the error
> checking in the open routine fixed.
>
> Let me know if the ordering of the video_unregister_device and tasklet_kill
> is still an issue.
Well, here we go again, there are other issues as well.
There's a race between op
> Attached is a patch against 2.5.40 with __dev* uses removed and the error
> checking in the open routine fixed.
>
> Let me know if the ordering of the video_unregister_device and tasklet_kill
> is still an issue.
It isn't. But the disconnect is still wrong. You fail to unlink the current
urb.
22 matches
Mail list logo
