Date: Sun, 28 Jun 2009 13:41:43 -0700 From: Kip Macy <kmacy@freebsd.org> To: Thomas Backman <serenity@exscape.org> Cc: freebsd-fs@freebsd.org, FreeBSD current <freebsd-current@freebsd.org> Subject: Re: zfs send -R segfault, anyone else? Message-ID: <3c1674c90906281341w4b235dd7y809e1b23978ad5c3@mail.gmail.com> In-Reply-To: <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org> References: <08D1E6DF-89D3-4887-9234-C3DB9164D794@exscape.org> <20090514133017.362075dhcdy7o2bs@webmail.leidinger.net> <7CD27FF0-CBFA-48B7-9E18-763D8C3ED9B8@exscape.org> <4A0C9B0C.4050403@jrv.org> <B7DA57FE-0109-44D2-A970-E7BE7F3C24C5@exscape.org> <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm a bit preoccupied at the moment.
Keep reminding me ...
-Kip
On Sun, Jun 28, 2009 at 1:14 PM, Thomas Backman<serenity@exscape.org> wrote=
:
> On May 15, 2009, at 11:30 AM, Thomas Backman wrote:
>>
>> On May 15, 2009, at 12:28 AM, James R. Van Artsdalen wrote:
>>
>>> Thomas Backman wrote:
>>>>
>>>> [root@chaos ~]# zfs send -R -I $OLD tank@$NOW > diff-snap
>>>> [root@chaos ~]# cat diff-snap | zfs recv -Fvd slave
>>>> Segmentation fault: 11 (core dumped)
>>>>
>>>> Same kinda backtrace, but what's up with strcmp()?
>>>> I suppose the issue stems from libzfs, and is not within libc:
>>>
>>> Different problem =A0The SIGSEGV is happening in strcmp because it is
>>> called with strcmp(0,0)
>>> and tries to dereference address -4 (probably another bug itself).
>>>
>>> This hack gets around the issue but someone familiar with this needs to
>>> decide the correct action.
>>>
>>> The first change is actually unrelated (a sorry attempt at fixing the
>>> previous zfs send bug).
>>>
>>> The last change may be unnecessary as that case may never happen unless
>>> the pool can be renamed?
>>>
>>> [... patch ...]
>>
>> Thanks! This list is pretty impressive. :)
>> I can't validate how correct the fix is, considering my lacking knowledg=
e
>> in C (I know the basics, but kernel/related programming? no way!), but I=
CAN
>> say that it appears to work just fine!
>>
>> Regards,
>> Thomas
>>
> Any news on this? The bug's been around for a long time, and a fix has be=
en
> around for at least 1.5 months now, and AFAIK the bug still lives.
> The patch, again (I can't vouch for its correctness, but I can certainly =
say
> that it works just fine *for me*) follows.
>
> Regards,
> Thomas
>
> Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
> =A0(revision 194851)
> +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
> =A0(working copy)
> @@ -239,6 +239,8 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *propname =3D nvpair_name(elem);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zfs_prop_t prop =3D zfs_name_to_prop(propn=
ame);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nvlist_t *propnv;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (prop =3D=3D ZPROP_INVAL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!zfs_prop_user(propname) && zfs_prop_r=
eadonly(prop))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
> @@ -1126,7 +1128,7 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t originguid =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t stream_originguid =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t parent_fromsnap_guid, stream_pare=
nt_fromsnap_guid;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *fsname, *stream_fsname;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *fsname, *stream_fsname, *p1, *p2;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nextfselem =3D nvlist_next_nvpair(local_nv=
, fselem);
>
> @@ -1295,10 +1297,13 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"parentfromsnap", &stream_parent_f=
romsnap_guid));
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* check for rename */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 p1 =3D strrchr(fsname, '/');
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 p2 =3D strrchr(stream_fsname, '/');
> +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((stream_parent_fromsnap_guid !=3D 0 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stream_parent_fromsnap_guid !=3D p=
arent_fromsnap_guid) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strcmp(strrchr(fsname, '/'),
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strrchr(stream_fsname, '/')) !=3D 0=
) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (p1 !=3D NULL && p2 !=3D NULL && st=
rcmp (p1, p2) !=3D 0) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((p1 =3D=3D NULL) ^ (p2 =3D=3D N=
ULL))) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nvlist_t *parent;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char tryname[ZFS_MAXNAMELE=
N];
>
> @@ -1317,7 +1322,7 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VERIFY(0 =
=3D=3D nvlist_lookup_string(parent,
> "name",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&p=
name));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(void) snp=
rintf(tryname, sizeof (tryname),
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "%s=
%s", pname, strrchr(stream_fsname,
> '/'));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "%s%s", pna=
me, p2 ? p2 : "");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tryname[0]=
=3D '\0';
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (flags.=
verbose) {
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>
--=20
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
Edmund Burke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90906281341w4b235dd7y809e1b23978ad5c3>