bio_alloc() with __GFP_WAIT never returns NULL

Mark the error handling branch as unlikely() because the current
kernel interface can never return NULL.  However, we want to keep
the error handling in case this behavior changes in the futre.

Plus fix a small style issue.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Isaac Huang <he.huang@intel.com>
Closes #2703
Fix systemd config for zfs-share.service

The zfs-share.service rule needs to be modified to ensure that it
does not execute before zfs-mount.service.

Signed-off-by: Dan Swartzendruber <dswartz@druber.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ralf Ertzinger <ralf@skytale.net>
Closes #2893
Fix snapshots with dirty inodes

Filesystems which are mounted read-only or are immutable because
they are snapshots must not be allowed to dirty and inode.  This
will result in a write which will correctly cause a kernel panic
because these filesystem are (and must be) immutable.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #2812
Mark DMU transaction processing with PF_FSTRANS

It was thought that we could ensure forward progress by avoiding memory
allocations during transaction processing and avoiding KM_SLEEP in the
few instances in which we could not.

Recent tests involving L2ARC on systems without swap have shown that
this is not enough. VMWare's bencharmk on a system with 8GB of RAM and
200GB of L2ARC will reliably deadlock when atime is enabled, but will
run fine when atime is not enabled. This was initially thought to be a
mix of an extreme case of ARC contention and atime updates somehow
blocking on transaction group commit, but further examination showed
that only 137MB of RAM were in use by L2ARC's headers and additional
testing showed no deadlocks occurred with 24GB of RAM when atime was
enabled.

Subsequent review of the code revealed that the only change was that
direct reclaim no longer started transactions to perform atime updates.
The logical conclusion is that direct reclaim can occur in locations
that hold locks that block an open transaction through some unforeseen
dependency chain. This patch attempts to address that by modifying the
KM_SLEEP avoidance mechanism to be used in all transaction processing,
rather than just operations on zvols. We also take the opportunity to do
some cleanup by replacing PF_NOIO with PF_FSTRANS, which is the proper
Linux flag for this.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Use is_vmalloc_addr() in vdev_disk.c

The initial port of ZFS to Linux required a way to identify virtual
memory to make IO to virtual memory backed slabs work, so kmem_virt()
was created. Linux 2.6.25 introduced is_vmalloc_addr(), which is
logically equivalent to kmem_virt(). Support for kernels before 2.6.26
was later dropped and more recently, support for kernels before Linux
2.6.32 has been dropped. We retire kmem_virt() in favor of
is_vmalloc_addr() to cleanup the code.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Retire KM_NODEBUG

Callers of kmem_alloc() which passed the KM_NODEBUG flag to suppress
the large allocation warning have been replaced by vmem_alloc().
The updated vmem_alloc() call will not print a warning regardless
of the size of the allocation.

Originally I felt this would be a nice way to clean up the code in
a way upstream would accept.  However, it may be better to just
increase the warning threshold to 32k which would prevent most
warning.  The few remaining instances could then take advange of
vmem_alloc().  Regardless, I'm including this patch is the stack
to allow futher discussion.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Change KM_PUSHPAGE -> KM_SLEEP

By marking DMU transaction processing contexts with PF_FSTRANS
we can revert the KM_PUSHPAGE -> KM_SLEEP changes.  This brings
us back in line with upstream.

The one place KM_PUSHPAGE is kept is when allocating ARC buffers
which allows us to dip in to reserved memory.  This is again the
same as upstream.