On Thursday 15 December 2005 21:15, Jeff Dike wrote:
> On Thu, Dec 15, 2005 at 05:26:44PM +0100, Blaisorblade wrote:
> > The problem is that the same declaration is used in kernel sources. I.e.,
> > we have (likely) COW files generated from 64-bit machines using a
> > different format from 32-bit ones. So we have two incompatible formats
> > out there in the wild.
> Hummm, this seems to call for a V4.
In short, not needed.
Very short term solution is to build 32-bit and 64-bit uml_moo versions. With
the existing code - i.e. compile -m32, compile normally.
Releasing a V4 is provably correct but suboptimal for 32-bit UMLs, where V3
and V4 would coincide. And actually, we've been lucky with this bug - it can
be completely avoided.
Also, detecting 64-bit format is easy (see below point c).
We want a utility read-wrong-V3-header / write right one. Unless we find no
one is using 64-bit files.
a) 64-bit users are few ones and smart
At that point (see below) 64-bit buggy programs (uml_moo and kernel) will
crash (SIGFPE) on correct V3 COWs. (And unlike real cows, crashing on COWs
doesn't hurt the obstacle).
However:
b) I've just tested running a 64-bit kernel on a 32-bit COW file and it gets
SIGFPE as expected:
Kernel panic - not syncing: Kernel mode signal 8
c) it should be possible to distinguish between broken 64-bit and 32-bit V3
files, with the following line:
if ( *((int*)header->backing_file) == 0)
printf("Hey, broken V3 file with 64-bit\n");
Broken 64-bit has 4 bytes of extra padding after ->mtime and before ->size:
struct cow_header_v3 {
__u32 magic;
__u32 version;
time_t mtime;
__u64 size;
__u32 sectorsize;
__u32 alignment;
__u32 cow_format;
char backing_file[PATH_LEN_V3];
};
== Fig. 1 - cow_header_v3 layout (for easier reference) ==
This moves the location of ->cow_format, which is by definition set to
COW_BITMAP == 0 - the only 4-byte zero'ed field out there, 4 bytes later,
where we normally find backing_file - and 4 zero'ed bytes are invalid in the
->backing_file field.
Btw, when 64-bit code tries to read ->alignment out of a 32-bit file, it is
indeed reading ->cow_format, which is always 0, leading to SIGFPE instead of
corruption. This time, we've been lucky in discovering this problem.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
