Just inform and dont warn when DM_DEV_REMOVE is tried on a open device
PATCH 1/1 Just inform and dont warn when DM_DEV_REMOVE is tried on a open device
Dont warn when DM_DEV_REMOVE ioctl is tried on a open device.
On openSUSE when cryptsetup and udev interact, cryptsetup sometimes tries to remove a dm device currently opened by blkid, which is not a serious issue to print a kernel warning. The application should retry if -EBUSY is returned. So let us make it an informational message instead.
---
drivers/md/dm-ioctl.c +1 -1
@@ -729,7 +729,7 @@ static int dev_remove(struct dm_ioctl *param, size_t param_size)*/ r =dm_lock_for_deletion (md);if (r) { -DMWARN ("unable to remove open device %s" , hc->name); +DMINFO ("unable to remove open device %s" , hc->name);up_write (&_hash_lock);dm_put (md);return r;
Milan Broz
NAKdrivers/md/dm-ioctl.c static int dev_remove(struct dm_ioctl *param, size_t param_size) · line 732
Quoted 9 lines · Nikanth Karthikesan
Dont warn when
DM_DEV_REMOVEioctl is tried on a open device.On openSUSE when cryptsetup and udev interact, cryptsetup sometimes tries to remove a dm device currently opened by blkid, which is not a serious issue to print a kernel warning. The application should retry if
-EBUSYis returned. So let us make it an informational message instead.drivers/md/dm-ioctl.c +1
-1-DMWARN ("unable to remove open device %s" , hc->name); +DMINFO ("unable to remove open device %s" , hc->name);
NAK.
Firstly, it is security problem if someone from udev rules tries to open temporary-cryptsetup device, it contains only private key material.
Secondly, it must be solved on application level and not paper kernel using patches which hides errors.
FYI there is already patch in upstream cryptsetup which uses udev cookie mechanism. It still cannot solve artificial change events (which causes scan from rules randomly), but should help here. (will be in cryptsetup 1.1.1)
Milan
Quoted 8 lines · On Tuesday 20 April 2010 13:30:18 Milan Broz wrote:
Quoted 7 lines · Nikanth Karthikesan
Dont warn when
DM_DEV_REMOVEioctl is tried on a open device.On openSUSE when cryptsetup and udev interact, cryptsetup sometimes tries to remove a dm device currently opened by blkid, which is not a serious issue to print a kernel warning. The application should retry if
-EBUSYis returned. So let us make it an informational message instead.
Quoted 8 lines
drivers/md/dm-ioctl.c static int dev_remove(struct dm_ioctl *param, size_t param_size) · line 732
Quoted 2 lines
drivers/md/dm-ioctl.c +1
-1-DMWARN ("unable to remove open device %s" , hc->name); +DMINFO ("unable to remove open device %s" , hc->name);NAK.
Firstly, it is security problem if someone from udev rules tries to open temporary-cryptsetup device, it contains only private key material.
Okay.
Quoted 3 lines
Secondly, it must be solved on application level and not paper kernel using patches which hides errors.
Agreed, it must be solved in the application level.
/me wonders whether this is an error worth a warning from kernel? Returning -EBUSY seems enough. May be a KERN_INFO message... But yes rest of DM prints warnings for these kind of events.
Quoted 5 lines
FYI there is already patch in upstream cryptsetup which uses udev cookie
mechanism. It still cannot solve artificial change events (which causes scan from rules randomly), but should help here. (will be in cryptsetup 1.1.1)
Oh, ok. Thanks for the pointer.
Thanks
Nikanth