Switch KM_SLEEP to KM_PUSHPAGE

I think I've found another point in which KM_SLEEP needs to be changed to KM_PUSHPAGE.

ZFS at commit: zfsonlinux/zfs@7bd04f2d7d99780f190d4027e6e81fc0df11ba95
SPL at commit: zfsonlinux/spl@bbdc6ae49518a4be7230ab673370e9231e2f72e7
Built into kernel 3.5.5+grsecurity.

kernel log:
[79553.413194] SPL: Fixing allocation for task txg_sync (2251) which used GFP flags 0xf6ce5b9c with PF_NOFS set
[79553.413196] SPL: Showing stack for process 2251
[79553.413198] Pid: 2251, comm: txg_sync Not tainted 3.5.5-grsec+ #1
[79553.413199] Call Trace:
[79553.413204]  [<ffffffff8114290f>] spl_debug_dumpstack+0x2f/0x50
[79553.413207]  [<ffffffff8181b69c>] sanitize_flags.part.13+0x6b/0x7a
[79553.413209]  [<ffffffff81147fef>] kmem_alloc_debug+0x38f/0x3c0
[79553.413212]  [<ffffffff811e2956>] snapshot_check+0xc6/0xf0
[79553.413215]  [<ffffffff8120c1dc>] dsl_sync_task_group_sync+0xfc/0x260
[79553.413217]  [<ffffffff81203c3b>] dsl_pool_sync+0x1eb/0x470
[79553.413219]  [<ffffffff8121a720>] spa_sync+0x3d0/0x9d0
[79553.413223]  [<ffffffff81822e4a>] ? __mutex_unlock_slowpath+0x1a/0x50
[79553.413225]  [<ffffffff812294a3>] txg_sync_thread+0x2c3/0x490
[79553.413226]  [<ffffffff812291e0>] ? txg_quiesce_thread+0x300/0x300
[79553.413228]  [<ffffffff8114b404>] thread_generic_wrapper+0x84/0xa0
[79553.413230]  [<ffffffff8114b380>] ? __thread_create+0x340/0x340
[79553.413232]  [<ffffffff8106a09f>] kthread+0x9f/0xb0
[79553.413235]  [<ffffffff8182f999>] kernel_thread_helper+0x9/0x20
[79553.413237]  [<ffffffff81825552>] ? retint_restore_args+0xb/0x12
[79553.413238]  [<ffffffff8106a000>] ? kthread_freezable_should_stop+0x70/0x70
[79553.413240]  [<ffffffff8182f990>] ? gs_change+0x13/0x13
[79559.970188] SPL: Fixing allocation for task txg_sync (2251) which used GFP flags 0xf6ce5b9c with PF_NOFS set
[79559.970191] SPL: Showing stack for process 2251
[79559.970192] Pid: 2251, comm: txg_sync Not tainted 3.5.5-grsec+ #1
[79559.970193] Call Trace:
[79559.970198]  [<ffffffff8114290f>] spl_debug_dumpstack+0x2f/0x50
[79559.970201]  [<ffffffff8181b69c>] sanitize_flags.part.13+0x6b/0x7a
[79559.970203]  [<ffffffff81147fef>] kmem_alloc_debug+0x38f/0x3c0
[79559.970206]  [<ffffffff811e2956>] snapshot_check+0xc6/0xf0
[79559.970209]  [<ffffffff8120c1dc>] dsl_sync_task_group_sync+0xfc/0x260
[79559.970211]  [<ffffffff81203c3b>] dsl_pool_sync+0x1eb/0x470
[79559.970213]  [<ffffffff8121a720>] spa_sync+0x3d0/0x9d0
[79559.970215]  [<ffffffff812294a3>] txg_sync_thread+0x2c3/0x490
[79559.970217]  [<ffffffff812291e0>] ? txg_quiesce_thread+0x300/0x300
[79559.970219]  [<ffffffff8114b404>] thread_generic_wrapper+0x84/0xa0
[79559.970221]  [<ffffffff8114b380>] ? __thread_create+0x340/0x340
[79559.970223]  [<ffffffff8106a09f>] kthread+0x9f/0xb0
[79559.970226]  [<ffffffff8182f999>] kernel_thread_helper+0x9/0x20
[79559.970228]  [<ffffffff81825552>] ? retint_restore_args+0xb/0x12
[79559.970230]  [<ffffffff8106a000>] ? kthread_freezable_should_stop+0x70/0x70
[79559.970231]  [<ffffffff8182f990>] ? gs_change+0x13/0x13

I've noticed those messages right after having deleted two snapshots and started a scrub.

I haven't rigorously tested this commit, but looking at the stack trace, looks like there is only a call to kmem_alloc which can cause this.