[Bug 233277] Panic when receiving incremental ZFS send (solaris assert: db->db_buf == ((void *)0))

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233277

            Bug ID: 233277
           Summary: Panic when receiving incremental ZFS send (solaris
                    assert: db->db_buf == ((void *)0))
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: delphij at FreeBSD.org

Seen on CURRENT (as of r340474) when receiving an incremental stream (zfs send
-e) from a 11.2-RELEASE system.

Panic message:

panic: solaris assert: db->db_buf == ((void *)0) (0xfffff801f7f43e40 == 0x0),
file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, line:
1097
cpuid = 6                                                                       
time = 1542352871                                                               
KDB: stack backtrace:                                                           
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b12f9940  
vpanic() at vpanic+0x1a3/frame 0xfffffe00b12f99a0                               
panic() at panic+0x43/frame 0xfffffe00b12f9a00                                  
assfail3() at assfail3+0x2c/frame 0xfffffe00b12f9a20                            
dmu_buf_will_fill() at dmu_buf_will_fill+0x24b/frame 0xfffffe00b12f9a60         
dmu_buf_write_embedded() at dmu_buf_write_embedded+0xe0/frame
0xfffffe00b12f9ab0                                                              
dmu_write_embedded() at dmu_write_embedded+0xea/frame 0xfffffe00b12f9b10        
receive_writer_thread() at receive_writer_thread+0x513/frame 0xfffffe00b12f9bb0 
fork_exit() at fork_exit+0x84/frame 0xfffffe00b12f9bf0                          
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00b12f9bf0               
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---                                       
KDB: enter: panic                                                               
[ thread pid 21 tid 101208 ]                                                    
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why                              
db> where                                                                       
Tracing pid 21 tid 101208 td 0xfffff8001cb49580                                 
kdb_enter() at kdb_enter+0x3b/frame 0xfffffe00b12f9940                          
vpanic() at vpanic+0x1c0/frame 0xfffffe00b12f99a0                               
panic() at panic+0x43/frame 0xfffffe00b12f9a00                                  
assfail3() at assfail3+0x2c/frame 0xfffffe00b12f9a20                            
dmu_buf_will_fill() at dmu_buf_will_fill+0x24b/frame 0xfffffe00b12f9a60         
dmu_buf_write_embedded() at dmu_buf_write_embedded+0xe0/frame
0xfffffe00b12f9ab0                                                              
dmu_write_embedded() at dmu_write_embedded+0xea/frame 0xfffffe00b12f9b10        
receive_writer_thread() at receive_writer_thread+0x513/frame 0xfffffe00b12f9bb0 
fork_exit() at fork_exit+0x84/frame 0xfffffe00b12f9bf0                          
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00b12f9bf0               
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---                                 


It seems that the call path was:

receive_writer_thread -> receive_process_record (DRR_WRITE_EMBEDDED) ->
receive_write_embedded -> dmu_write_embedded -> dmu_buf_hold_noread()

Then:

dmu_buf_write_embedded -> dmu_buf_will_not_fill -> dmu_buf_will_fill ->
dbuf_noread (db->db_state == DB_NOFILL) -> dbuf_clear_data ->
ASSERT3P(db->db_buf, ==, NULL); and failed there.

Looking at the code, it seems that dmu_buf_will_not_fill would
unconditionally set db_state to DB_NOFILL, but for some reason the dbuf
might have db_buf associated (maybe DB_CACHED?)

I can't reproduce the issue when not using -e at sending side.

-- 
You are receiving this mail because:
You are the assignee for the bug.