Date: Fri, 31 Jul 2009 06:45:10 -0500 From: "James R. Van Artsdalen" <james-freebsd-fs2@jrv.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-fs@freebsd.org, FreeBSD current <freebsd-current@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, Thomas Backman <serenity@exscape.org> Subject: Re: zfs: Fatal trap 12: page fault while in kernel mode Message-ID: <4A72D946.4090401@jrv.org> In-Reply-To: <4A71B2DA.9060902@freebsd.org> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <F4F82B3E-C119-40EF-9AA4-937052876D1E@exscape.org> <4A7030B6.8010205@icyb.net.ua> <97D5950F-4E4D-4446-AC22-92679135868D@exscape.org> <4A7048A9.4020507@icyb.net.ua> <52AA86CB-6C06-4370-BA73-CE19175467D0@exscape.org> <4A705299.8060504@icyb.net.ua> <D3491B77-DA5C-4E10-BE1D-D6EF8CFB112E@exscape.org> <4A7054E1.5060402@icyb.net.ua> <5918824D-A67C-43E6-8685-7B72A52B9CAE@exscape.org> <4A705E50.8070307@icyb.net.ua> <4A70728C.7020004@freebsd.org> <6D47A34B-0753-4CED-BF3D-C505B37748FC@exscape.org> <4A708455.5070304@freebsd.org> <86983A55-E5C4-4C04-A4C7-0AE9A9EE37A3@exscape.org> <4A718E03.6030909@freebsd.org> <71A038EC-02B1-4606-96C2-5E84BE80F005@exscape.org> <4A719CA4.4060400@freebsd.org> <19347561-3CE6-40B3-930A-EB9925D3AFD1@exscape.org> <4A71AD29.10705@freebsd.org> <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B2DA.9060902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > on 30/07/2009 17:39 Thomas Backman said the following: > >> Or, in patch form (I think the intendation screws the patch up as linked >> there): >> http://exscape.org/temp/libzfs_sendrecv.patch >> > > One comment on the patch - I personally don't like bit-wise xor in a logical > expression. But if otherwise the expression would be huge and ugly, then OK. > If you're going to code an XOR, use an XOR. Don' make the reader untangle code to figure out that that some other code is really just an XOR. However I think I was trying to handle two cases that can't happen: the top filesystem cannot be renamed to somewhere else in the pool, and no other filesystem can be renamed to the root. So the new version of the patch below needs no XOR. Without this or something like it you can't replicate an entire pool, i.e. zfs send -R -I @yesterday pool@today | ssh backup zfs recv -vF -d pool dumps core from the strccmp(0, 0) in the original code below. Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c =================================================================== --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c (revision 192136) +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c (working copy) @@ -1126,7 +1126,7 @@ uint64_t originguid = 0; uint64_t stream_originguid = 0; uint64_t parent_fromsnap_guid, stream_parent_fromsnap_guid; - char *fsname, *stream_fsname; + char *fsname, *stream_fsname, *p1, *p2; nextfselem = nvlist_next_nvpair(local_nv, fselem); @@ -1295,10 +1295,11 @@ "parentfromsnap", &stream_parent_fromsnap_guid)); /* check for rename */ + p1 = strrchr(fsname, '/'); + p2 = strrchr(stream_fsname, '/'); if ((stream_parent_fromsnap_guid != 0 && stream_parent_fromsnap_guid != parent_fromsnap_guid) || - strcmp(strrchr(fsname, '/'), - strrchr(stream_fsname, '/')) != 0) { + (p1 != NULL && p2 != NULL && strcmp (p1, p2) != 0)) { nvlist_t *parent; char tryname[ZFS_MAXNAMELEN]; @@ -1317,7 +1318,7 @@ VERIFY(0 == nvlist_lookup_string(parent, "name", &pname)); (void) snprintf(tryname, sizeof (tryname), - "%s%s", pname, strrchr(stream_fsname, '/')); + "%s%s", pname, p2 ? p2 : ""); } else { tryname[0] = '\0'; if (flags.verbose) {
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A72D946.4090401>