summaryrefslogtreecommitdiff
path: root/include/linux/device-mapper.h
diff options
context:
space:
mode:
authorStefan Bader <Stefan.Bader@de.ibm.com>2006-10-03 01:15:41 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-10-03 08:04:16 -0700
commit9faf400f7e51e56ec76b2fc481c3191c01cb3a57 (patch)
treedcc853af8b188b2eb59be84dac424698e561057b /include/linux/device-mapper.h
parent6a24c71843de1354d3bcc2ce47fd0b3bee936399 (diff)
downloadlwn-9faf400f7e51e56ec76b2fc481c3191c01cb3a57.tar.gz
lwn-9faf400f7e51e56ec76b2fc481c3191c01cb3a57.zip
[PATCH] dm: use private biosets
I found a problem within device-mapper that occurs in low-mem situations. It was found using a mirror target but I think in theory it would hit any setup that stacks device-mapper devices (like LVM on top of multipath). Since device-mapper core uses the common fs_bioset in clone_bio(), and a private, but still global, bio_set in split_bvec() it is possible that the filesystem and the first level target successfully get bios but the lower level target doesn't because there is no more memory and the pool was drained by upper layers. So the remapping will be stuck forever. To solve this device-mapper core needs to use a private bio_set for each device. Signed-off-by: Stefan Bader <Stefan.Bader@de.ibm.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include/linux/device-mapper.h')
0 files changed, 0 insertions, 0 deletions