zfs: Fatal trap 12: page fault while in kernel mode

[Thomas Backman]

On Jul 31, 2009, at 13:45, James R. Van Artsdalen wrote:

> 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 at 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
> ===================================================================
> ...
Nice job, thanks :)
Just wanted to chime in and say that your new patch seems to work just  
as well as the previous one. I hope you don't mind me hosting this too  
(I had to apply it manually thanks to spacing... I think it's my mail  
client not being very nice at retaining tabs/spaces)... Straight from  
svn diff: http://exscape.org/temp/libzfs_sendrecv.new.patch

BTW (maybe not on topic for this mail, but for this thread), I've  
created a test case to reproduce the new panic (every time). It  
happens with -DDEBUG=1, after destroying a filesystem and then doing  
an incremental backup. Currently recompiling world/kernel on a second  
box to reproduce before I post that.

Regards,
Thomas