Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

zfs diff triggers another PF_NOFS panic #1855

Closed
cwedgwood opened this issue Nov 11, 2013 · 4 comments
Closed

zfs diff triggers another PF_NOFS panic #1855

cwedgwood opened this issue Nov 11, 2013 · 4 comments
Milestone
0.6.3

Comments

@cwedgwood
Copy link
Contributor 

SPLError: 4125:0:(kmem.h:91:sanitize_flags()) FATAL allocation for task txg_sync (4125) which used GFP flags 0x23023aa4 with PF_NOFS set
SPLError: 4125:0:(kmem.h:91:sanitize_flags()) SPL PANIC
SPL: Showing stack for process 4125
CPU: 1 PID: 4125 Comm: txg_sync Tainted: P           O 3.11.7.cw0 #37
Hardware name: Supermicro X8DTL/X8DTL, BIOS 2.1a       12/30/2011
 0000000000000000 ffff880a230239d8 ffffffff8166ae48 0000000000000000
 ffff880a230239e8 ffffffffa003d4d7 ffff880a23023a10 ffffffffa003e721
 ffffffffa0057311 0000000000000000 0000000000000028 ffff880a23023a40
Call Trace:
 [<ffffffff8166ae48>] dump_stack+0x45/0x56
 [<ffffffffa003d4d7>] spl_debug_dumpstack+0x27/0x40 [spl]
 [<ffffffffa003e721>] spl_debug_bug+0x81/0xe0 [spl]
 [<ffffffffa0055a1e>] sanitize_flags.part.5+0x66/0x68 [spl]
 [<ffffffffa0045d37>] kmem_alloc_debug+0x307/0x420 [spl]
 [<ffffffff81009999>] ? read_tsc+0x9/0x20
 [<ffffffff8109fc1a>] ? __getnstimeofday+0x3a/0xc0
 [<ffffffff8109fcae>] ? getnstimeofday+0xe/0x30
 [<ffffffffa004e2ca>] ? __gethrestime+0x1a/0x30 [spl]
 [<ffffffffa007e468>] nv_alloc_sleep_spl+0x28/0x30 [znvpair]
 [<ffffffffa00787b7>] nvlist_xalloc.part.13+0x27/0xd0 [znvpair]
 [<ffffffffa00788ba>] nvlist_alloc+0x3a/0x60 [znvpair]
 [<ffffffffa007c070>] fnvlist_alloc+0x20/0x90 [znvpair]
 [<ffffffff8109fc1a>] ? __getnstimeofday+0x3a/0xc0
 [<ffffffffa020e111>] dsl_dataset_user_hold_sync_one+0x31/0x80 [zfs]
 [<ffffffffa01510fa>] dsl_dataset_snapshot_tmp_sync+0xda/0x110 [zfs]
 [<ffffffffa015048f>] ? dsl_dataset_snapshot_tmp_check+0xcf/0x110 [zfs]
 [<ffffffffa016505a>] dsl_sync_task_sync+0x15a/0x160 [zfs]
 [<ffffffffa0194605>] ? txg_list_remove+0x75/0xf0 [zfs]
 [<ffffffffa015affb>] dsl_pool_sync+0x68b/0x990 [zfs]
 [<ffffffffa017ba19>] spa_sync+0x3d9/0xda0 [zfs]
 [<ffffffffa0193264>] txg_sync_thread+0x354/0x660 [zfs]
 [<ffffffffa0192f10>] ? txg_thread_wait+0x110/0x110 [zfs]
 [<ffffffffa00476e3>] thread_generic_wrapper+0x83/0xe0 [spl]
 [<ffffffffa0047660>] ? __thread_create+0x390/0x390 [spl]
 [<ffffffffa0047660>] ? __thread_create+0x390/0x390 [spl]
 [<ffffffff81076780>] kthread+0xc0/0xd0
 [<ffffffff810766c0>] ? kthread_create_on_node+0x120/0x120
 [<ffffffff8167ae2c>] ret_from_fork+0x7c/0xb0
 [<ffffffff810766c0>] ? kthread_create_on_node+0x120/0x120
@dweeezil
Copy link
Contributor

@cwedgwood You are running recent master code, right? If so, looks like dweeezil/zfs@393b281 should fix this.

@behlendorf
Copy link
Contributor

@dweeezil Did you link to the wrong patch? This looks like another instance fnvlist_alloc being used in the sync context, in this case by dsl_dataset_user_hold_sync_one

@dweeezil
Copy link
Contributor

@behlendorf and @cwedgwood Oops, I'm really sorry. Yes, I meant to reference dweeezil/zfs@4381976.

@dweeezil
Copy link
Contributor

I'm waiting to hear back from @jojun regarding #1852 before making a pull request.

@jojun jojun mentioned this issue Nov 13, 2013
Closed
@jojun jojun mentioned this issue Nov 20, 2013
Closed
behlendorf pushed a commit that referenced this issue Dec 3, 2013
@dweeezil @behlendorf
Some nvlist allocations in hold processing need to use KM_PUSHPAGE.
f707635 
This should hopefully catch the rest of the allocations in the
user hold/release processing that were missed by commit
65c67ea.

Signed-off-by: Brian Behlendorf <[email protected]>
Closes #1852
Closes #1855
unya pushed a commit to unya/zfs that referenced this issue Dec 13, 2013
@dweeezil @unya
Some nvlist allocations in hold processing need to use KM_PUSHPAGE.
030e3f9 
Commit 95fd54a restructured the
hold/release processing and moved some of the work into the sync task.
A number of nvlist allocations now need to use KM_PUSHPAGE.

Signed-off-by: Brian Behlendorf <[email protected]>
Closes openzfs#1852
Closes openzfs#1855
unya pushed a commit to unya/zfs that referenced this issue Dec 13, 2013
@dweeezil @unya
Some nvlist allocations in hold processing need to use KM_PUSHPAGE.
96f6454 
This should hopefully catch the rest of the allocations in the
user hold/release processing that were missed by commit
65c67ea.

Signed-off-by: Brian Behlendorf <[email protected]>
Closes openzfs#1852
Closes openzfs#1855
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.6.3
Development

No branches or pull requests
3 participants
@behlendorf @cwedgwood @dweeezil