[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <475ADFC5.4030108@gmail.com>
Date: Sat, 08 Dec 2007 14:17:41 -0400
From: Kevin Winchester <kjwinchester@...il.com>
To: Daniel Walker <dwalker@...sta.com>
CC: linux-kernel@...r.kernel.org
Subject: Re: Possible locking issue in viotape.c
Daniel Walker wrote:
> On Thu, 2007-12-06 at 21:29 -0400, Kevin Winchester wrote:
>> Daniel Walker wrote:
>>> I've posted all the ones I've done so far ..
>>>
>>> ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/
>>>
>>> Feel free to review or test them.. I've found it pretty easy to simply
>>> grep for certain class of semaphore usage, check if it's conforming to
>>> the mutex requirements, then convert it or not.. Checking them is
>>> getting to be a habit, so I don't think a list would help me.. However,
>>> someone else might be able to use it..
>>>
>> Thanks, that helps me not duplicate anything. One of the first ones I
>> was looking at (before your post) was viotape.c, which is in your patch
>> set. However, looking at the uses of the semaphore, I see that on line
>> 409-410 the following code:
>>
>> if (noblock)
>> return count;
>>
>> which seems to ignore the fact that the semaphore has been downed (not
>> to mention the dma buffer and op struct allocations. I think it should be:
>>
>> if (noblock)
>> ret = count;
>> goto free_dma;
>>
>> instead. Do you want to make sure I'm right about that and fold it into
>> your patch? Or have you already submitted your patch (or should it be
>> in a separate patch? Alternatively, I can submit the patch if you don't
>> want to bother with it.
>
> viotape was one of the first I started converting, but later I noticed
> the same thing you found above. I have it commented out of my series for
> that reason ..
>
> I think this noblock path is actually doing what the author intended..
> There are a few stray up() calls related to event handling and ioctls ,
> and I think those are used to release the semaphore..
>
> Daniel
>
>
Yes, you are right, I hadn't finished looking at all of the up() calls
when I came to my conclusion. I will try to convert a few that are not
on your list, but I would like to know how you are generating your
patches into those files with the diffstat and recipient list. Is that
a feature of some git command?
--
Kevin Winchester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists