linux-kernel - device mapper wierdness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100528145533.GE13853@ojjektum.uhulinux.hu>
Date:	Fri, 28 May 2010 16:55:33 +0200
From:	Pozsar Balazs <pozsy@...linux.hu>
To:	linux-kernel@...r.kernel.org
Subject: device mapper wierdness


Hi all,

I found a wierd caching problem, and would like to ask if this is a bug, 
and how to avoid this behaviour properly.

First of all, I have a lvm device:

root:~# ls -l /dev/dm-2 /dev/bela/gazsi
lrwxrwxrwx 1 root root       7 2010-05-28 16:17 /dev/bela/gazsi -> ../dm-2
brw-rw---- 1 root media 254, 2 2010-05-28 16:17 /dev/dm-2
root:~# dmsetup info bela-gazsi
Name:              bela-gazsi
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      254, 2
Number of targets: 1
UUID: 
LVM-LrFvCCU7QzeyBsiXl2RC2VMnWvxGdS4n7xugPDcPzx1vD6SVElPELv0a8vf4mzH0

root:~# dmsetup table bela-gazsi
0 15114240 linear 8:4 384


Above that, I have another device mapper device, just a simple linear 
one:

brw-rw---- 1 root media 254, 1 2010-05-28 16:27 /dev/dm-1
root:~# ls -l /dev/dm-1 /dev/mapper/live
brw-rw---- 1 root media 254, 1 2010-05-28 16:27 /dev/dm-1
lrwxrwxrwx 1 root root       7 2010-05-28 16:17 /dev/mapper/live -> ../dm-1
root:~# dmsetup info live
Name:              live
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      254, 1
Number of targets: 1

root:~# dmsetup table live
0 15114240 linear 254:2 0


Because of the linear mapping, we can see the fs uuid is the same on the 
two
dm devices:
root:~# blkid /dev/mapper/live /dev/bela/gazsi
/dev/mapper/live: LABEL="UHU" UUID="3452e43d-d40a-4c13-b24d-07d4b1793e9b" TYPE="ext4"
/dev/bela/gazsi: LABEL="UHU" UUID="3452e43d-d40a-4c13-b24d-07d4b1793e9b" TYPE="ext4"


Now if I change the uuid of the filesystem with tune2fs, I cannot see 
this change on the /dev/bela/gazsi device, even if I do a sync:
root:~# tune2fs -U random /dev/mapper/live
tune2fs 1.41.11 (14-Mar-2010)
root:~# blkid /dev/mapper/live /dev/bela/gazsi
/dev/mapper/live: LABEL="UHU" UUID="f3fad2d6-451a-4ef6-98f8-5fcf51571b07" TYPE="ext4"
/dev/bela/gazsi: LABEL="UHU" UUID="3452e43d-d40a-4c13-b24d-07d4b1793e9b" TYPE="ext4"
root:~# sync
root:~# blkid /dev/mapper/live /dev/bela/gazsi
/dev/mapper/live: LABEL="UHU" UUID="f3fad2d6-451a-4ef6-98f8-5fcf51571b07" TYPE="ext4"
/dev/bela/gazsi: LABEL="UHU" UUID="3452e43d-d40a-4c13-b24d-07d4b1793e9b" TYPE="ext4"


But if drop caches, it gets into the proper state:
root:~# echo 1 >/proc/sys/vm/drop_caches
root:~# blkid /dev/mapper/live /dev/bela/gazsi
/dev/mapper/live: LABEL="UHU" UUID="f3fad2d6-451a-4ef6-98f8-5fcf51571b07" TYPE="ext4"
/dev/bela/gazsi: LABEL="UHU" UUID="f3fad2d6-451a-4ef6-98f8-5fcf51571b07" TYPE="ext4"


I fail to see why a sync is not enough and how this drop cache operation
helps. Could anyone enlighten me please?


I am using kernel 2.6.33.3.

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