Date: Mon, 29 May 2006 18:35:23 -0700
From: Andrew Morton <akpm@osdl.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, arjan@infradead.org
Subject: Re: [patch 34/61] lock validator: special locking: bdev
Message-Id: <20060529183523.0985b537.akpm@osdl.org>
In-Reply-To: <20060529212554.GH3155@elte.hu>
References: <20060529212109.GA2058@elte.hu>
	<20060529212554.GH3155@elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1416
Lines: 44

On Mon, 29 May 2006 23:25:54 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> 
> teach special (recursive) locking code to the lock validator. Has no
> effect on non-lockdep kernels.
> 

There's no description here of the problem which is being worked around. 
This leaves everyone in the dark.

> +static int
> +blkdev_get_whole(struct block_device *bdev, mode_t mode, unsigned flags)
> +{
> +	/*
> +	 * This crockload is due to bad choice of ->open() type.
> +	 * It will go away.
> +	 * For now, block device ->open() routine must _not_
> +	 * examine anything in 'inode' argument except ->i_rdev.
> +	 */
> +	struct file fake_file = {};
> +	struct dentry fake_dentry = {};
> +	fake_file.f_mode = mode;
> +	fake_file.f_flags = flags;
> +	fake_file.f_dentry = &fake_dentry;
> +	fake_dentry.d_inode = bdev->bd_inode;
> +
> +	return do_open(bdev, &fake_file, BD_MUTEX_WHOLE);
> +}

"crock" is a decent description ;)

How long will this live, and what will the fix look like?

(This is all a bit of a pain - carrying these patches in -mm will require
some effort, and they're not ready to go yet, which will lengthen the pain
arbitrarily).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/