[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1923596b-ce14-7b80-6148-f67143b4a367@users.sourceforge.net>
Date: Sun, 5 Nov 2017 09:29:22 +0100
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-usb@...r.kernel.org, kernel-janitors@...r.kernel.org
Cc: Alan Stern <stern@...land.harvard.edu>,
Eugene Korenevsky <ekorenevsky@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Günter Röck <linux@...ck-us.net>,
Jaejoong Kim <climbbb.kim@...il.com>,
Johan Hovold <johan@...nel.org>,
Jonathan Corbet <corbet@....net>,
Mathias Nyman <mathias.nyman@...ux.intel.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] USB: core: Improve unlocking of a mutex in two functions
>> @@ -5529,8 +5528,7 @@ static int usb_reset_and_verify_device(struct usb_device *udev)
>> dev_err(&udev->dev,
>> "can't restore configuration #%d (error=%d)\n",
>> udev->actconfig->desc.bConfigurationValue, ret);
>> - mutex_unlock(hcd->bandwidth_mutex);
>> - goto re_enumerate;
>> + goto unlock;
>> }
>> mutex_unlock(hcd->bandwidth_mutex);
>> usb_set_device_state(udev, USB_STATE_CONFIGURED);
>> @@ -5583,6 +5581,8 @@ static int usb_reset_and_verify_device(struct usb_device *udev)
>> udev->bos = bos;
>> return 0;
>>
>> +unlock:
>> + mutex_unlock(hcd->bandwidth_mutex);
>
> This makes it harder for the reader,
I am curious if the view on the preferred code readability can be clarified further.
> as the mutex_unlock() is now far below the block
> of code that's protected by the lock.
I got an other software development opinion for this aspect.
Can the label be clear enough about the shown purpose already?
Regards,
Markus
Powered by blists - more mailing lists