[dm-devel] dm: lock bd_mutex when setting device size

[Mike Snitzer]

On Mon, Nov 01 2010 at  3:19am -0400,
Jun'ichi Nomura <j-nomura at ce.jp.nec.com> wrote:

> Hi Mike,
> 
> (10/30/10 06:50), Mike Snitzer wrote:
> > Avoid taking md->bdev->bd_inode->i_mutex to update the DM block device's
> > size.  Using md->bdev->bd_mutex eliminates the potential for deadlock if
> > an fsync is racing with a device resize.
> > 
> > revalidate_disk() was avoided because it would flush_disk() while the DM
> > device is suspended.
> > 
> > Signed-off-by: Mike Snitzer <snitzer at redhat.com>
> > Cc: Jun'ichi Nomura <j-nomura at ce.jp.nec.com>
> > ---
> >  drivers/md/dm.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > Jun'ichi, was the following your implict Acked-by?  Care to make it
> > explicit?
> > "Anyway, I think your bd_mutex patch should be fine for now and is
> > better than the current code with i_mutex, which has a real deadlock
> > issue."
> 
> No, it was not an ACK.
> (This is not multipath. So I think you don't need my ack.)

Your ack is always meaningful but that is fine too.

> I'm reluctant to ack this because, as I wrote, it's prone to
> cause deadlock in future.
> But I couldn't find a real problem with the patch,
> so I'm not NACK-ing either.

dm_swap_table's md->suspend_mutex already provides adequate protection
of __set_size's i_size_write.  You didn't like this because it implied:
"dm_resume is the only code which calls i_size_write() for dm device".

I don't see that as a problem at all; its a more meaningful/enforcable
rule to have in DM than something tethered to the generic bd_mutex.

I'll discuss this further with Alasdair and/or others.

Mike