mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: ajones@riverbed.com, a.p.zijlstra@chello.nl, mszeredi@suse.cz,
	akpm@linux-foundation.org, kay.sievers@vrfy.org, greg@kroah.com,
	trond.myklebust@fys.uio.no, linux-kernel@vger.kernel.org
Subject: Re: [BUG] mm: bdi: export BDI attributes in sysfs
Date: Thu, 15 May 2008 12:18:57 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0805151213430.3019@woody.linux-foundation.org> (raw)
In-Reply-To: <E1JwiZa-0007UA-Tm@pomaz-ex.szeredi.hu>



On Thu, 15 May 2008, Miklos Szeredi wrote:
> 
> This is not meant as a final solution, I'm sure Greg or Kay can help
> find a better solution.

Yeah, don't do this:

> +static struct backing_dev_info *dev_get_bdi(struct device *dev)
> +{
> +	mutex_lock(&bdi_dev_mutex);
> +	mutex_unlock(&bdi_dev_mutex);
> +
> +	return dev_get_drvdata(dev);
> +}

This kind of serialization can often hide bugs, and in some cases even 
make them go away (if the caller of the function means that the device is 
pinned and the tear-down cannot happen, for example), but it's really 
really bad form.

In order to use locking in a repeatable manner that is easy to think 
about, you really need to *keep* the lock until you've stopped using the 
data (or have dereferenced it into a stable form - eg maybe accessing the 
pointer itself needs locking, but some individual data read _off_ the 
pointer does not).

So the above kind of "get and release the lock" does obviously serialize 
wrt others that hold the lock, but it's still wrong.

>  static ssize_t read_ahead_kb_store(struct device *dev,
>  				  struct device_attribute *attr,
>  				  const char *buf, size_t count)
>  {
> -	struct backing_dev_info *bdi = dev_get_drvdata(dev);
> +	struct backing_dev_info *bdi = dev_get_bdi(dev);
>  	char *end;
>  	unsigned long read_ahead_kb;
>  	ssize_t ret = -EINVAL;

You should just get the lock in the routines that acually use this thing.

Or, if the "struct backing_dev_info *" pointer itself is stable, and it 
really is just the access from "struct device" that needs protection, then 
at the very least it should have been

	static struct backing_dev_info *dev_get_bdi(struct device *dev)
	{
		struct backing_dev_info *bdi;

		mutex_lock(&bdi_dev_mutex);
		bdi = dev_get_drvdata(dev);
		mutex_unlock(&bdi_dev_mutex);
		return bdi;
	}

which makes it clear that it's the "dev_get_drvdata()" that needs the 
locking, not the bdi pointer itself.

		Linus

  reply	other threads:[~2008-05-15 19:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080513190435.GG23649@ajones-laptop.nbttech.com>
2008-05-14 14:40 ` Arthur Jones
2008-05-15 18:53   ` Miklos Szeredi
2008-05-15 19:18     ` Linus Torvalds [this message]
2008-05-15 19:27       ` Miklos Szeredi
2008-05-15 19:54         ` Linus Torvalds
2008-05-15 20:40           ` Greg KH
2008-05-15 21:02           ` Greg KH
2008-05-15 22:05             ` Arthur Jones
2008-05-15 23:20               ` Greg KH
2008-05-16  4:59               ` Greg KH
2008-05-15 20:37         ` Greg KH
2008-05-15 20:40           ` Greg KH
2008-05-15 20:44     ` Arthur Jones

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=alpine.LFD.1.10.0805151213430.3019@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ajones@riverbed.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@suse.cz \
    --cc=trond.myklebust@fys.uio.no \
    /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®