linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: Joe Perches <joe@perches.com>,
	Luis Felipe Strano Moraes <lfelipe@profusion.mobi>,
	linville@tuxdriver.com, davem@davemloft.net,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Cleaning up code formatting errors in net/wireless pointed out by checkpatch.
Date: Mon, 20 Feb 2012 11:45:22 +0100	[thread overview]
Message-ID: <1329734722.3458.7.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <20120217110602.2c4e762a@nehalam.linuxnetplumber.net>

On Fri, 2012-02-17 at 11:06 -0800, Stephen Hemminger wrote:

> > I'd try to make the statement expression visually
> > distinct.  Something like:
> > 
> > 	wait_event(rdev->dev_wait,
> > 		   ({
> > 			   int __count;
> > 			   mutex_lock(&rdev->devlist_mtx);
> > 			   __count = rdev->opencount;
> > 			   mutex_unlock(&rdev->devlist_mtx);
> > 			   __count == 0;
> > 		   })
> > 		  );
> > 
> 
> I prefer to see this done as an inline function
> 
> wait_event(rdev->dev_wait, is_foo_ready(rdev))
> 
> Also, in this case wrapping a condition with a mutex really is
> meaningless because the state is longer protected out side the
> protected region; in other words the mutex here is bogus and
> provides no additional protection.

I don't really care about all the changes suggested here -- feel free to
make them. One thing I'd like to point out though is that generally the
mutex might serve a purpose even here. In this specific case, it
currently doesn't, but I still think it's safer to keep it in case
somebody modifies other code. The case where it matters is when the
modification of the "opencount" variable isn't the last thing that
happens in a locked section, but you here want or need to wait for
everything happening in that section to be done.

johannes


      reply	other threads:[~2012-02-20 10:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17 15:30 [PATCH] Cleaning up code formatting errors in net/wireless pointed out by checkpatch Luis Felipe Strano Moraes
2012-02-17 15:47 ` David Laight
2012-02-17 15:56   ` Luis Felipe Strano Moraes
2012-02-17 18:45 ` Joe Perches
2012-02-17 19:06   ` Stephen Hemminger
2012-02-20 10:45     ` Johannes Berg [this message]

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=1329734722.3458.7.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.net \
    --cc=joe@perches.com \
    --cc=lfelipe@profusion.mobi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.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;
as well as URLs for NNTP newsgroup(s).