bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)

bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)

[Zhao Qian]

As i had written here before, sometimes bio which dispatched to the dm's target, it's bi_size could exceed
region size in dm-mirror.c, i also found similar problem in dm-stripe.c and dm-snap.c , in such situation,
bio's bi_size could exceed strip target's chunk size and snap target's chunk size, but in current code, we
never care about this. so in strip target we could read/write bad position after stripe_map() function,
and cause same effect in dm-snap.c.
I think such bugs are very dangerous then kernel panic or cracsh becasue it may destroy your data 
in silence. we'd better to annonuce our linux users don't use thus dm-targets before we correct it.

Sincerely,
                Zhao Qian <zhaoqian@aaastor.com>

Re: bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)

[Kevin Corry]

Hi Zhao,

On Wed June 29 2005 5:10 am, Zhao Qian wrote:
> As i had written here before, sometimes bio which dispatched to the dm's
> target, it's bi_size could exceed region size in dm-mirror.c, i also found
> similar problem in dm-stripe.c and dm-snap.c,

Have you specifically seen this problem happen during testing?

> in such situation, bio's 
> bi_size could exceed strip target's chunk size and snap target's chunk
> size, but in current code, we never care about this. so in strip target we
> could read/write bad position after stripe_map() function, and cause same
> effect in dm-snap.c.

I'm quite certain there is code in dm.c to prevent bio's from spanning the 
internal boundaries in the mirror, snapshot, and stripe targets. Have you 
read through the code starting in dm.c::dm_request()? The targets specify 
where their internal boundaries are, and the core driver is responsible for 
splitting up bio's so the targets never get a request that span those 
boundaries.

> I think such bugs are very dangerous then kernel panic or cracsh becasue it
> may destroy your data in silence. we'd better to annonuce our linux users
> don't use thus dm-targets before we correct it.

If you've seen a case of actual corruption due to this, please let us know and 
we'll investigate to see if something accidentally has been broken. But as I 
mentioned above, I don't think this should really be a problem.

-- 
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/

Re: bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)

[Kevin Corry]

On Wed June 29 2005 6:30 am, Kevin Corry wrote:
> > in such situation, bio's
> > bi_size could exceed strip target's chunk size and snap target's chunk
> > size, but in current code, we never care about this. so in strip target
> > we could read/write bad position after stripe_map() function, and cause
> > same effect in dm-snap.c.
>
> I'm quite certain there is code in dm.c to prevent bio's from spanning the
> internal boundaries in the mirror, snapshot, and stripe targets. Have you
> read through the code starting in dm.c::dm_request()? The targets specify
> where their internal boundaries are, and the core driver is responsible for
> splitting up bio's so the targets never get a request that span those
> boundaries.

And now that I've said this, I've gone back and looked, and indeed the 
dm-raid1.c code isn't setting the ti->split_io field (it does get set in 
dm-stripe.c and dm-snap.c).

Alasdair, should that field be set for dm-mirror targets? I'm not as familiar 
with that code, so I'll have to leave that up to you. If it does need to be 
set, I think the following patch should work.

-- 
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/


Set the target's split_io field when building a dm-mirror device so incoming 
bio's won't span the mirror's internal regions.

--- a/drivers/md/dm-raid1.c 2005-06-29 06:38:16.000000000 -0500
+++ b/drivers/md/dm-raid1.c 2005-06-29 06:41:59.000000000 -0500
@@ -1060,6 +1060,7 @@
  }
 
  ti->private = ms;
+ ti->split_io = ms->rh->region_size;
 
  r = kcopyd_client_create(DM_IO_PAGES, &ms->kcopyd_client);
  if (r) {

Re: bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)

[Alasdair G Kergon]

On Wed, Jun 29, 2005 at 06:46:00AM -0500, Kevin Corry wrote:
> Alasdair, should that field be set for dm-mirror targets? 

Like you, I assumed it already was:-)

Zhao, does Kevin's patch fix things for you?

Alasdair
-- 
agk@redhat.com

Re: bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)

[Zhao Qian]

Yes,i think so:)

Sincerely,
Zhao Qian zhaoqian@aaastor.com

----- Original Message ----- 
From: "Alasdair G Kergon" <agk@redhat.com>
To: "device-mapper development" <dm-devel@redhat.com>
Cc: "Zhao Qian" <zhaoqian@aaastor.com>
Sent: Wednesday, June 29, 2005 10:42 PM
Subject: Re: [dm-devel] bio's bi_size bug also be founded at dm-stripe.c and dm-snap.c (resend in correct charset)


> On Wed, Jun 29, 2005 at 06:46:00AM -0500, Kevin Corry wrote:
>> Alasdair, should that field be set for dm-mirror targets? 
> 
> Like you, I assumed it already was:-)
> 
> Zhao, does Kevin's patch fix things for you?
> 
> Alasdair
> -- 
> agk@redhat.com
>

Device Mapper corruption

[Suleyman Kutlu]

Hello all,

I have an AMD-64 machine running SuSE 9.2. I have one disk (for now,
will add another later on) and a VG on it. I have created some LVs.

Sometimes later, I realized that when I mount an LV (lets call it
lv_a) I see the directory structure of another LV (lets call it lv_b). If I issue a df -k, I see the size of lv_b for lv_a,
but in lvdisplay output, the size for lv_a is correct.

/mnt is mounted as lv_b
/mnt2 is mounted as lv_a but has contents as lv_b has.

I thought that, filesystem structure is corrupted and started to work
on some filesystem level utilities today, but today I see that,
another filesystem pair also got the same problem.

So I think it is a problem in device-mapper level, not the filesystem level. 

What can be the possible works to get what is wrong and how to fix ? 

I am new at device-mapper, I don't have enough experience on it and I
do not want to loose everything while there is something that can be
recovered...

Any help is appreciated. 

Thanks and best regards.. 

* 
* Suleyman Kutlu
*
* mailto: suleyman.kutlu@gmail.com
*