linux/block
Neil Brown d89d87965d When stacked block devices are in-use (e.g. md or dm), the recursive calls
to generic_make_request can use up a lot of space, and we would rather they
didn't.

As generic_make_request is a void function, and as it is generally not
expected that it will have any effect immediately, it is safe to delay any
call to generic_make_request until there is sufficient stack space
available.

As ->bi_next is reserved for the driver to use, it can have no valid value
when generic_make_request is called, and as __make_request implicitly
assumes it will be NULL (ELEVATOR_BACK_MERGE fork of switch) we can be
certain that all callers set it to NULL.  We can therefore safely use
bi_next to link pending requests together, providing we clear it before
making the real call.

So, we choose to allow each thread to only be active in one
generic_make_request at a time.  If a subsequent (recursive) call is made,
the bio is linked into a per-thread list, and is handled when the active
call completes.

As the list of pending bios is per-thread, there are no locking issues to
worry about.

I say above that it is "safe to delay any call...".  There are, however,
some behaviours of a make_request_fn which would make it unsafe.  These
include any behaviour that assumes anything will have changed after a
recursive call to generic_make_request.

These could include:
 - waiting for that call to finish and call it's bi_end_io function.
   md use to sometimes do this (marking the superblock dirty before
   completing a write) but doesn't any more
 - inspecting the bio for fields that generic_make_request might
   change, such as bi_sector or bi_bdev.  It is hard to see a good
   reason for this, and I don't think anyone actually does it.
 - inspecing the queue to see if, e.g. it is 'full' yet.  Again, I
   think this is very unlikely to be useful, or to be done.

Signed-off-by: Neil Brown <neilb@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: <dm-devel@redhat.com>

Alasdair G Kergon <agk@redhat.com> said:

 I can see nothing wrong with this in principle.

 For device-mapper at the moment though it's essential that, while the bio
 mappings may now get delayed, they still get processed in exactly
 the same order as they were passed to generic_make_request().

 My main concern is whether the timing changes implicit in this patch
 will make the rare data-corrupting races in the existing snapshot code
 more likely. (I'm working on a fix for these races, but the unfinished
 patch is already several hundred lines long.)

 It would be helpful if some people on this mailing list would test
 this patch in various scenarios and report back.

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-05-11 13:28:37 +02:00
..
as-iosched.c kblockd: use flush_work 2007-05-09 12:30:51 -07:00
blktrace.c [PATCH] mark struct file_operations const 3 2007-02-12 09:48:45 -08:00
cfq-iosched.c KMEM_CACHE(): simplify slab cache creation 2007-05-07 12:12:55 -07:00
deadline-iosched.c [BLOCK] Cleanup unused variable passing 2006-12-01 10:42:33 +01:00
elevator.c [PATCH] elevator: elv_list_lock does not need irq disabling 2007-04-30 09:08:17 +02:00
genhd.c Display all possible partitions when the root filesystem failed to mount 2007-05-09 12:30:48 -07:00
ioctl.c mm: remove destroy_dirty_buffers from invalidate_bdev() 2007-05-07 12:12:55 -07:00
Kconfig [PATCH] Centralise definitions of sector_t and blkcnt_t 2006-12-04 19:41:15 -08:00
Kconfig.iosched update I/O sched Kconfig help texts - CFQ is now default, not AS. 2007-02-17 20:08:22 +01:00
ll_rw_blk.c When stacked block devices are in-use (e.g. md or dm), the recursive calls 2007-05-11 13:28:37 +02:00
Makefile [PATCH] BLOCK: Make it possible to disable the block layer [try #6] 2006-09-30 20:52:31 +02:00
noop-iosched.c [BLOCK] Cleanup unused variable passing 2006-12-01 10:42:33 +01:00
scsi_ioctl.c [SCSI] sg: cap reserved_size values at max_sectors 2007-04-17 18:09:56 -04:00