Bug 14638
Summary: | device mapper unaccounted null pointer | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | bugzilla |
Component: | LVM2/DM | Assignee: | Alasdair G Kergon (agk) |
Status: | CLOSED INVALID | ||
Severity: | high | CC: | agk, akpm, gmazyland |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.32-rc7 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
bugzilla
2009-11-19 00:38:00 UTC
reassigned to lvm/dm Please supply diagnostics from dmsetup: dmsetup info -c dmsetup table dmsetup status Look for the major:minor device number on the 'crypt' table line, then check the state of that device directly. (NB If you have an old version of dmsetup, delete the encryption key before posting this output! Current versions remove it automatically unless you add --showkeys.) Damn I already reset. If it happens again I'll run those diagnostics. I goofed and typed dm-setup so thought it was just not installed. The (null) in cryptsetup status output can mean that cryptsetup simply cannot find underlying device in /dev (according to its major:minor pair). This is not kernel pointer btw, only userpace problem. (I'll probably change that (null) to "device not found" or so.) It can happen when you unplug USB disk while mapping is still active. Note that if you plug the device back, it is mapped to different device, the old mapping remains dead. Power glitch, cable malfunction etc can cause this also. (Read syslog - any disconnect or error message before that?) It's a relief that it's not going to dereference a null pointer in my kernel! What would also be good is if "cryptsetup remove" would still remove the mapping, even if the device is not found. I didn't unplug the device, but it might have hiccupped. It always maps to /dev/sdc but the major:minor pair may have changed (didn't check that). Doesn't look like there's anything to change in the kernel here, so closing this. Follow up on the dm-crypt@saout.de mailing list if necessary. |