Set current->bio_{list,tail} to NULL before submit_bio()

Linux attempts to avoid recursive processing of bios in
generic_make_request by storing a list of bios being processed in
current task_struct. Prior to Linux 2.6.34, this was done with
current->bio_list and current->bio_tail. When current->bio_tail
non-NULL, generic_make_request() would add IOs to the existing list and
return. In Linux 2.6.34, these two were consolidated into
current->bio_list. The value of that pointer serves the purpose that
current->bio_tail previously served in generic_make_request().

This will deadlock when we have a generic_make_request function
submitting IOs on top of ZFS and we execute a code path that is not
asynchronous until the operation is handed off to the underlying block
IO layer via zio_wait(). That causes us to block in zio_wait() block on
a ZIO that is effectively ignored because it will not be processed until
we return. Being blocked waiting for something that will not happen
until we return causes a deadlock.

An example of this is running mkfs.ext4 on a zvol with the zvol
refactoring code in place. In that case, zil_flush_vdevs() will hand off
the flush IOs to the block layer through zio_wait() in a synchronous
path, which deadlocks. We correct this by saving current->bio_tail or
current->bio_list depending on the kernel, changing the value is to NULL
for the duration of submit_bio() and changing it back afterward.

Signed-off-by: Richard Yao <ryao@gentoo.org>
zvol processing should use struct bio

The main impetus for this patch is the Illumos taskq import. The ZoL
zvol code operated in an interrupt context to take advantage of the IO
elevator and the SPL taskq code was (ab)used to form the bottom half.
The SPL taskq code was designed to be callable in an interrupt context
while the Illumos taskq code was designed to expect the assistance of
the thread thread scheduler. Since Linux's thread scheduler does not
provide that assistance, we must trampoline through the system workqueue
to continue providing the bottom half when using the Illumos taskq code.
This seems unnecessarily complex when we consider that Illumos itself
does not perform this emulation and the recent multiqueue work in Linux
has identified interrupt processing as a major bottleneck on Linux:

http://kernel.dk/systor13-final18.pdf

The entry point for zvol operations is zfs_request(). That is called in
an interrupt context by blk_queue_bio(), which is the kernel's generic
->make_request() handler. Registering our own handler allows us to avoid
this. Comments in the code suggest that this was not done to gain the
benefit of having Linux's IO elevator do merging. However, the DMU
already does write merging while arc_read() should implicitly merge read
IOs because only 1 thread is permitted to fetch the buffer. In addition,
the main consumers of zvols are VMs and iSCSI shares, which have their
own elevators to merge IOs. Furthermore, commercial ZFSOnLinux
distributions report that regular files are more performant than zvols.
That strongly suggests that the original rationale for using Linux'
generic ->make_request() handler was invalid.

Some minor refactoring allows us to register zfs_request() as our
->make_request() handler. This eliminates an obstacle to importing the
Illumos taskq code while giving us several additional benefits:

1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs under heavy load.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.

It is worth noting that the previous zvol code would redispatch IOs when
all zio taskq threads were in use. The consequence being that IOs could
be redispatched and potentially, reordered across barriers. This
explains an obscure IRC report about corruption on zvol-backed iSCSI
shares triggered by a kernel panic during heavy load. It was thought
that the initiator did something wrong, but now it is clear that the
zvol code itself could reorder, which explains the incident.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove rq_for_each_segment() autotools check

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove rq_is_sync() autotools check

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove blk_end_request() autotools check.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove blk_requeue_request() autotools check

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove blk_fetch_request() autotools check

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove blk_rq_pos() autotools check

Signed-off-by: Richard Yao <ryao@gentoo.org>
Remove blk_rq_bytes()/blk_rq_sectors autotools checks

Signed-off-by: Richard Yao <ryao@gentoo.org>
Explanation on merges etc.