This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: Virtual block devices (vbd) still not working... :-(

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Virtual block devices (vbd) still not working... :-(
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 11 Oct 2003 15:37:01 +0100
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, sven.kretzschmar@xxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 11 Oct 2003 15:38:13 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Sat, 11 Oct 2003 11:21:44 BST." <E1A8Gsb-0004AZ-00@xxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> Whenever Alex or I have used VDs they've just worked: There's
> no way to populate a vd with a file system unless you can access
> it from domain0, so its obviously been working for some people.
> I wander if it's got something to do with whether the newly
> created virtual disk just happens to have something approximating
> a valid partition table or not?

I've now fully worked outwhat was going on. The reason it 
worked for you is pretty vile, so I'll describe it here :-)

After doing 'vbd create' you must have executed 'mkfs' as
non-root. The test machine was incorrectly set up so that users had
read and write access directly via the /dev/xvd* files (NB. I've
checked in a fixed xen-mkdevnodes that ensures this cannot happen).

However, although the device file gives you write access to make a
filesystem, the first thing mkfs does is an ioctl to find the device
size. We have a check for CAP_SYS_ADMIN in our ioctl function
(incorrectly, since permission checking is done when opening the /dev
file --- I'll check in a fix to remove that, and another, bogus

The ioctl returns -1 (errno==EPERM), but mkfs is broken and doesn't
check the return value. It therefore thinks it's dealing with an
enormous blkdev of size ~0UL :-)

It proceeds to write the inode and superblock info over the disk. Even
though access checks are probably failing, enough are successfully
written at the start of the vbd that mount can still work.

It's unfortunate that you get no errors for the access violations by
mkfs (it must surely be writing off the end of the 128M vbd). Xen
returns an error condition, and this is propagated by the xenolinux
driver, but it appears to be silently dropped by the generic blkdev
layer :-( :-(

I did have the xenolinux driver make a noise about errors before, but
it got rather messy at boot time (generic blkdev layer would pass down
requests that failed for legitimate reasons) so I removed it.

 -- Keir

This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Xen-devel mailing list