linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it>
To: Andrew Morton <akpm@osdl.org>
Cc: Jeff Dike <jdike@addtoit.com>,
	linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: [PATCH 02/17] uml: safe migration path to the correct V3 COW format
Date: Fri, 07 Apr 2006 16:30:52 +0200	[thread overview]
Message-ID: <20060407143051.19201.67922.stgit@zion.home.lan> (raw)
In-Reply-To: <20060407142709.19201.99196.stgit@zion.home.lan>

From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

*) Correct the layout of all header versions - make all them well-specified for
any external event. As we don't have 1-byte or 2-byte wide fields, the 32-bit
layout (historical one) has no extra padding, so we can safely add
__attribute__((packed)).

*) Add detection and reading of the broken 64-bit COW format which has been
around for a while - to allow safe migration to the correct 32-bit format. Safe
detection is possible, thanks to some luck with the existing format, and it
works in practice.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 arch/um/drivers/cow_user.c |   91 +++++++++++++++++++++++++++++++++++++-------
 1 files changed, 76 insertions(+), 15 deletions(-)

diff --git a/arch/um/drivers/cow_user.c b/arch/um/drivers/cow_user.c
index afdf1ea..a9afccf 100644
--- a/arch/um/drivers/cow_user.c
+++ b/arch/um/drivers/cow_user.c
@@ -17,30 +17,34 @@
 
 #define PATH_LEN_V1 256
 
+typedef __u32 time32_t;
+
 struct cow_header_v1 {
-	int magic;
-	int version;
+	__s32 magic;
+	__s32 version;
 	char backing_file[PATH_LEN_V1];
-	time_t mtime;
+	time32_t mtime;
 	__u64 size;
-	int sectorsize;
-};
+	__s32 sectorsize;
+} __attribute__((packed));
 
-#define PATH_LEN_V2 MAXPATHLEN
+/* Define PATH_LEN_V3 as the usual value of MAXPATHLEN, just hard-code it in
+ * case other systems have different values for MAXPATHLEN.
+ *
+ * The same must hold for V2 - we want file format compatibility, not anything
+ * else.
+ */
+#define PATH_LEN_V3 4096
+#define PATH_LEN_V2 PATH_LEN_V3
 
 struct cow_header_v2 {
 	__u32 magic;
 	__u32 version;
 	char backing_file[PATH_LEN_V2];
-	time_t mtime;
+	time32_t mtime;
 	__u64 size;
-	int sectorsize;
-};
-
-/* Define PATH_LEN_V3 as the usual value of MAXPATHLEN, just hard-code it in
- * case other systems have different values for MAXPATHLEN
- */
-#define PATH_LEN_V3 4096
+	__s32 sectorsize;
+} __attribute__((packed));
 
 /* Changes from V2 -
  *	PATH_LEN_V3 as described above
@@ -66,6 +70,15 @@ struct cow_header_v2 {
  *	Fixed (finally!) the rounding bug
  */
 
+/* Until Dec2005, __attribute__((packed)) was left out from the below
+ * definition, leading on 64-bit systems to 4 bytes of padding after mtime, to
+ * align size to 8-byte alignment.  This shifted all fields above (no padding
+ * was present on 32-bit, no other padding was added).
+ *
+ * However, this _can be detected_: it means that cow_format (always 0 until
+ * now) is shifted onto the first 4 bytes of backing_file, where it is otherwise
+ * impossible to find 4 zeros. -bb */
+
 struct cow_header_v3 {
 	__u32 magic;
 	__u32 version;
@@ -77,6 +90,18 @@ struct cow_header_v3 {
 	char backing_file[PATH_LEN_V3];
 } __attribute__((packed));
 
+/* This is the broken layout used by some 64-bit binaries. */
+struct cow_header_v3_broken {
+	__u32 magic;
+	__u32 version;
+	__s64 mtime;
+	__u64 size;
+	__u32 sectorsize;
+	__u32 alignment;
+	__u32 cow_format;
+	char backing_file[PATH_LEN_V3];
+};
+
 /* COW format definitions - for now, we have only the usual COW bitmap */
 #define COW_BITMAP 0
 
@@ -84,6 +109,7 @@ union cow_header {
 	struct cow_header_v1 v1;
 	struct cow_header_v2 v2;
 	struct cow_header_v3 v3;
+	struct cow_header_v3_broken v3_b;
 };
 
 #define COW_MAGIC 0x4f4f4f4d  /* MOOO */
@@ -300,7 +326,8 @@ int read_cow_header(int (*reader)(__u64,
 		*align_out = *sectorsize_out;
 		file = header->v2.backing_file;
 	}
-	else if(version == 3){
+	/* This is very subtle - see above at union cow_header definition */
+	else if(version == 3 && (*((int*)header->v3.backing_file) != 0)){
 		if(n < sizeof(header->v3)){
 			cow_printf("read_cow_header - failed to read V3 "
 				   "header\n");
@@ -310,9 +337,43 @@ int read_cow_header(int (*reader)(__u64,
 		*size_out = ntohll(header->v3.size);
 		*sectorsize_out = ntohl(header->v3.sectorsize);
 		*align_out = ntohl(header->v3.alignment);
+		if (*align_out == 0) {
+			cow_printf("read_cow_header - invalid COW header, "
+				   "align == 0\n");
+		}
 		*bitmap_offset_out = ROUND_UP(sizeof(header->v3), *align_out);
 		file = header->v3.backing_file;
 	}
+	else if(version == 3){
+		cow_printf("read_cow_header - broken V3 file with"
+			   " 64-bit layout - recovering content.\n");
+
+		if(n < sizeof(header->v3_b)){
+			cow_printf("read_cow_header - failed to read V3 "
+				   "header\n");
+			goto out;
+		}
+
+		/* this was used until Dec2005 - 64bits are needed to represent
+		 * 2038+. I.e. we can safely do this truncating cast.
+		 *
+		 * Additionally, we must use ntohl() instead of ntohll(), since
+		 * the program used to use the former (tested - I got mtime
+		 * mismatch "0 vs whatever").
+		 *
+		 * Ever heard about bug-to-bug-compatibility ? ;-) */
+		*mtime_out = (time32_t) ntohl(header->v3_b.mtime);
+
+		*size_out = ntohll(header->v3_b.size);
+		*sectorsize_out = ntohl(header->v3_b.sectorsize);
+		*align_out = ntohl(header->v3_b.alignment);
+		if (*align_out == 0) {
+			cow_printf("read_cow_header - invalid COW header, "
+				   "align == 0\n");
+		}
+		*bitmap_offset_out = ROUND_UP(sizeof(header->v3_b), *align_out);
+		file = header->v3_b.backing_file;
+	}
 	else {
 		cow_printf("read_cow_header - invalid COW version\n");
 		goto out;

  parent reply	other threads:[~2006-04-07 14:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07 14:27 [PATCH 00/17] Uml little fixups for new and existing code [for 2.6.17] Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:30 ` [PATCH 01/17] uml: make 64-bit COW files compatible with 32-bit ones Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:30 ` Paolo 'Blaisorblade' Giarrusso [this message]
2006-04-07 14:30 ` [PATCH 03/17] uml: fix 2 harmless cast warnings for 64-bit Paolo 'Blaisorblade' Giarrusso
2006-04-07 16:02   ` Jeff Dike
2006-04-07 21:46     ` Blaisorblade
2006-04-07 14:30 ` [PATCH 04/17] uml: request format warnings to GCC for appropriate functions Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 05/17] uml: fix format errors Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 06/17] uml: fix some double export warnings Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 07/17] uml: fix "extern-vs-static" proto conflict in TLS code Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 08/17] uml: prepare fixing compilation output Paolo 'Blaisorblade' Giarrusso
2006-04-07 16:05   ` Jeff Dike
2006-04-07 21:50     ` Blaisorblade
2006-04-07 14:31 ` [PATCH 09/17] uml: fix critical typo for TT mode Paolo 'Blaisorblade' Giarrusso
2006-04-07 15:45   ` Jeff Dike
2006-04-07 14:31 ` [PATCH 10/17] uml: support sparse for userspace files Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 11/17] uml: move outside spinlock call not needing it Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 12/17] uml: fix hang on run_helper() failure on uml_net Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 13/17] uml: fix failure path after conversion Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 14/17] uml: fix big stack user Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 15/17] uml: local_irq_save, not local_save_flags Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 16/17] uml: fix parallel make early failure on clean tree Paolo 'Blaisorblade' Giarrusso
2006-04-07 14:31 ` [PATCH 17/17] uml: avoid warnings for diffent names for an unsigned quadword Paolo 'Blaisorblade' Giarrusso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060407143051.19201.67922.stgit@zion.home.lan \
    --to=blaisorblade@yahoo.it \
    --cc=akpm@osdl.org \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).