mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>,
	linux-iio@vger.kernel.org
Cc: Hartmut Knaack <knaack.h@gmx.de>,
	Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] iio/accel/bmc150: Improve unlocking of a mutex in two functions
Date: Wed, 25 Oct 2017 18:22:02 +0200	[thread overview]
Message-ID: <6a2c614a-4d0d-f2d2-1689-4c67a2fc3eea@redhat.com> (raw)
In-Reply-To: <c32ea2ea-5961-6589-6b51-1184d9565a38@users.sourceforge.net>

Hi,

On 25-10-17 18:15, SF Markus Elfring wrote:
>> IMHO, if you do this, you should rework the function so that there is a single unlock call
>> at the end, not a separate one in in error label.
> 
> Thanks for your update suggestion.
> 
> Does it indicate that I may propose similar source code adjustments
> in this software area?
> 
> 
>> Could e.g. change this:
>>
>>          ret = bmc150_accel_set_power_state(data, false);
>>          mutex_unlock(&data->mutex);
>>          if (ret < 0)
>>                  return ret;
>>
>>          return IIO_VAL_INT;
>> }
>>
>> To:
>>
>>          ret = bmc150_accel_set_power_state(data, false);
>>          if (ret < 0)
>>                  goto unlock;
>>
>>      ret = IIO_VAL_INT;

If that is the only unlock in the function, then it is probably
best to keep things as is. In general gotos are considered
better then multiple unlocks, but not having either is even
better.


> How do you think about to use the following code variant then?
> 
> 	if (!ret)
> 		ret = IIO_VAL_INT;


I believe the goto unlock variant and setting ret = IIO_VAL_INT;
directly above the unlock label variant is better, because that
way the error handling is consistent between all steps and if
another step is later added at the end, the last step will
not require modification.

>> unlock:
>>          mutex_unlock(&data->mutex);
>>
>>          return ret;
>> }
>>
>> And also use the unlock label in the other cases, this is actually
>> quite a normal pattern. I see little use in a patch like this if there
>> are still 2 unlock paths after the patch.
> 
> How long should I wait for corresponding feedback before another small
> source code adjustment will be appropriate?

That is hard to say. I usually just do a new version when I've time,
seldomly someone complains I should have waited longer for feedback
(when I'm quite quick) but usually sending out a new version as soon
as you've time to work on a new version is best, since if you wait
you may then not have time for the entire next week or so, at least
that is my experience :)  There is really no clear rule here.

Regards,

Hans

  reply	other threads:[~2017-10-25 16:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-25 14:33 SF Markus Elfring
2017-10-25 15:57 ` Hans de Goede
2017-10-25 16:15   ` SF Markus Elfring
2017-10-25 16:22     ` Hans de Goede [this message]
2017-10-25 16:58       ` SF Markus Elfring
2017-10-25 17:28         ` Hans de Goede
2017-10-25 18:07           ` SF Markus Elfring
2017-10-26 15:46             ` Jonathan Cameron
2017-10-26 15:51       ` [PATCH] " Jonathan Cameron
2017-10-26 16:04         ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a2c614a-4d0d-f2d2-1689-4c67a2fc3eea@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=elfring@users.sourceforge.net \
    --cc=jic23@kernel.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®