Re: [PATCH] Btrfs: potential NULL dereferences
Roel Kluin roel.kl...@gmail.com writes: Allocations may fail, prevent NULL dereferences. Signed-off-by: Roel Kluin roel.kl...@gmail.com --- In several sections of fs/btrfs code a kmalloc() occurs without a check whether it succeeded. this potentially leads to dereferences of a NULL pointer. Are there reasons why we do not check the allocations? Did I choose an incorrect way to err out? please review. Yes, the erroring out needs much more work because often the callers don't handle errors and it can need quite a lot of surgery Until that is done it's actually better to oops than to silently leak resources. BUG_ON(name == NULL) is also fairly useless because it oopses anyways in a obvious way. I had some patches to add more error handling for ENOMEM, but it's fairly complicated. Should probably resurrect my old patchkit. It still wasn't fully complete. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discrepant st_rdev and st_dev stats in btrfs block and fs device ids
On Sun, Sep 06, 2009 at 04:51:55PM +0100, Marcus wrote: Hello, I think I found a btrfs 0.19 problem when used in an lvm2 volume; btrfs is returning a st_dev stat from the mounted filesystem / that is different from the lvm2 blockdevice st_rdev stat in /dev/mapper/vg0-os0. This btrfs behavior is different from ext4, where the st_dev and st_rdev stats match (http://pastebin.com/m64e90a8e or a summary below). Because of that, in grub2, 'grub-probe -t device / ' fails with ' grub-probe: error: cannot find a device for /. ' , and so update-grub2 fails causing cascading problems all around. Can anyone repeat this? Any ideas why this could be happening? Is this expected? Yes this is expected. Because of the way that btrfs can have multiple disks and snapshot and such, it creates this sort of virtual device as its backing device in the kernel to keep track of everything, so it's st_dev will not match the actual device it resides on. Thanks, Josef -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discrepant st_rdev and st_dev stats in btrfs block and fs device ids
Hey, Can anyone repeat this? Any ideas why this could be happening? Is this expected? There was some discussion about this some time ago, see http://news.gmane.org/find-root.php?message_id=%3c7b13a0f80904120735r41736455hb7e226ab8ad30bd7%40mail.gmail.com%3e I don't think it's resolved yet - the work-around I currently use in devkit-disks-daemon (which is used by e.g. GNOME to show names and icons for storage devices) looks like this: http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/tree/src/devkit-disks-mount-monitor.c?id=006#n351 and I don't think this will work for multi-disk btrfs filesystems. Thinking about this again, we probably want to treat such btrfs multi-disk filesystems in the UI the same way we treat e.g. md raid devices David -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
