Created attachment 503967 [details]
Patch to cope with possible short reads

Description of problem:
I am launching Xorg inside a KVM guest, where the root filesystem is passed through from the host using the '9p' filesystem with the virtio transport.
eg

    org.kernel.root / 9p rw,sync,dirsync,relatime,trans=virtio 0 0


When Xorg starts up it launches xkbcomp:

/usr/bin/xkbcomp  -w 1 -R/usr/share/X11/xkb -xkm - -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" /var/lib/xkb/server-0.xkm

when this runs, it displays many warnings:

Warning:          Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
                  Using last definition for duplicate fields
Warning:          Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
                  Using last definition for duplicate fields
Warning:          Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
                  Using last definition for duplicate fields
...

And errors

Internal error:   Could not resolve keysym XF86_Switch_VT_11
Internal error:   Could not resolve keysym XF86_Switch_VT_12
Internal error:   Could not resolve keysym XF86_Ungrab
Internal error:   Could not resolve keysym XF86_ClearGrab
Internal error:   Could not resolve keysym XF86_Prev_VMode
Internal error:   Could not resolve keysym XF86_Next_VMode
...

After a long debugging session with strace, I found this:

open("/usr/share/X11/XKeysymDB", O_RDONLY) = 4
fstat(4, {st_dev=makedev(0, 20), st_ino=786993, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=8192, st_blocks=18, st_size=8933, st_atime=2011/06/09-12:27:02, st_mtime=2011/03/22-01:45:56, st_ctime=2011/03/22-01:45:56}) = 0
read(4, "! Copyright 1993 Massachusetts Institute...", 8933) = 4096
close(4)                                = 0

So the file is 8933 bytes in length, and it got a short read only returning 4096 bytes. Instead of reading the rest of the file, it just closed it. This means it is missing at least 50% of the keysyms, which has a predictably bad impact on usability of the X server :-)

After investigation this turned out to be due to the following code in libX11/src/Xrm.c, ReadInFile() method:


     {
        struct stat status_buffer;
        if ( (fstat(fd, &status_buffer)) == -1 ) {
            close (fd);
            return (char *)NULL;
        } else
            size = status_buffer.st_size;
    }

    if (!(filebuf = Xmalloc(size + 1))) { /* leave room for '\0' */
        close(fd);
        return (char *)NULL;
    }
    size = read (fd, filebuf, size);


This is obviously making no allowance for the possibility of 'read' returning fewer bytes than were asking for (as allowed by POSIX).

While most filesystems don't return short reads, unfortunately the '9p' filesystem does.


Version-Release number of selected component (if applicable):
libX11-1.3.4-4.fc14

The same broken code is present in F15/rawhide versions too.

How reproducible:
Only if /usr/share/X11 is on a filesystem which returns short reads.

Steps to Reproduce:
1. Take an existing QEMU guest, and append '-virtfs local,path=/,mount_tag=org.kernel.root,security_model=none ' to the command line
2. Boot the guest,
3. SSH into the guest
4. mkdir /tmp/hostroot
5. mount -t 9p -o trans=virtio org.kernel.root /tmp/hostroot
6. chroot /tmp/hostroot
7. /usr/bin/xkbcomp  -w 1 -R/usr/share/X11/xkb -xkm - /tmp/foo.xkm <<EOF
xkb_keymap "default" {
    xkb_keycodes             { include "evdev+aliases(qwerty)" };
    xkb_types                { include "complete" };
    xkb_compatibility        { include "complete" };
    xkb_symbols              { include "pc+us+inet(evdev)" };
    xkb_geometry             { include "pc(pc105)" };
};

EOF
 
Actual results:
Many errors & warnings about keysyms (see earlier description)

Expected results:
No errors/warnings.

Additional info: