On Sun, Aug 18, 2013 at 9:01 AM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Sun, 18 Aug 2013, Ming Lei wrote:
>
>> Complete() will be run with interrupt enabled, so change to
>> spin_lock_irqsave().
>>
>> Cc: Alan Stern <st...@rowland.harvard.edu>
>> Signed-off-by: Ming Lei <ming....@canonical.com>
>> ---
>> drivers/usb/core/message.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
>> index 82927e1..8bba734 100644
>> --- a/drivers/usb/core/message.c
>> +++ b/drivers/usb/core/message.c
>> @@ -266,8 +266,9 @@ static void sg_complete(struct urb *urb)
>> {
>> struct usb_sg_request *io = urb->context;
>> int status = urb->status;
>> + unsigned long flags;
>>
>> - spin_lock(&io->lock);
>> + spin_lock_irqsave(&io->lock, flags);
>>
>> /* In 2.5 we require hcds' endpoint queues not to progress after fault
>> * reports, until the completion callback (this!) returns. That lets
>> @@ -326,7 +327,7 @@ static void sg_complete(struct urb *urb)
>> if (!io->count)
>> complete(&io->complete);
>>
>> - spin_unlock(&io->lock);
>> + spin_unlock_irqrestore(&io->lock, flags);
>> }
>
> As far as I can see, these don't need to disable interrupts. All they
> protect against is the code in usb_sg_wait() and usb_sg_cancel(), which
> both run in process context.
Yes.
> But will lockdep complain if they don't disable interrupts?
Looks lockdep won't complain because the lock can't be held in
another hardirq context.
As I mentioned in 00/50, the patchset is basically a mechanical
change, so one patch can be dropped if anyone reviews and
concludes it isn't needed.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
