BLK_MAKE_REQUEST(9) Block Devices BLK_MAKE_REQUEST(9)NAME
blk_make_request - given a bio, allocate a corresponding struct request.
struct request * blk_make_request(struct request_queue * q, struct bio * bio, gfp_t gfp_mask);
target request queue
The bio describing the memory mappings that will be submitted for IO. It may be a chained-bio properly constructed by block/bio layer.
gfp flags to be used for memory allocation
blk_make_request is the parallel of generic_make_request for BLOCK_PC type commands. Where the struct request needs to be farther
initialized by the caller. It is passed a struct bio, which describes the memory info of the I/O transfer.
The caller of blk_make_request must make sure that bi_io_vec are set to describe the memory buffers. That bio_data_dir will return the
needed direction of the request. (And all bio's in the passed bio-chain are properly set accordingly)
If called under none-sleepable conditions, mapped bio buffers must not need bouncing, by calling the appropriate masked or flagged
allocator, suitable for the target device. Otherwise the call to blk_queue_bounce will BUG.
When allocating/cloning a bio-chain, careful consideration should be given to how you allocate bios. In particular, you cannot use
__GFP_WAIT for anything but the first bio in the chain. Otherwise you risk waiting for IO completion of a bio that hasn't been submitted
yet, thus resulting in a deadlock. Alternatively bios should be allocated using bio_kmalloc instead of bio_alloc, as that avoids the
mempool deadlock. If possible a big IO should be split into smaller parts when allocation fails. Partial allocation should not be an error,
or you risk a live-lock.
COPYRIGHT Kernel Hackers Manual 2.6. July 2010 BLK_MAKE_REQUEST(9)
Check Out this Related Man Page
BIO_ALLOC_BIOSET(9) The Linux VFS BIO_ALLOC_BIOSET(9)NAME
bio_alloc_bioset - allocate a bio for I/O
struct bio * bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set * bs);
the GFP_ mask given to the slab allocator
number of iovecs to pre-allocate
the bio_set to allocate from.
If bs is NULL, uses kmalloc to allocate the bio; else the allocation is backed by the bs's mempool.
When bs is not NULL, if __GFP_WAIT is set then bio_alloc will always be able to allocate a bio. This is due to the mempool guarantees. To
make this work, callers must never allocate more than 1 bio at a time from this pool. Callers that need to allocate more than 1 bio must
always submit the previously allocated bio for IO before attempting to allocate a new one. Failure to do so can cause deadlocks under
Note that when running under generic_make_request (i.e. any block driver), bios are not submitted until after you return - see the code in
generic_make_request that converts recursion into iteration, to prevent stack overflows.
This would normally mean allocating multiple bios under generic_make_request would be susceptible to deadlocks, but we have deadlock
avoidance code that resubmits any blocked bios from a rescuer thread.
However, we do not guarantee forward progress for allocations from other mempools. Doing multiple allocations from the same mempool under
generic_make_request should be avoided - instead, use bio_set's front_pad for per bio allocations.
Pointer to new bio on success, NULL on failure.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 BIO_ALLOC_BIOSET(9)
. Make a new copy of mars.txt called marsx. What happens if you give the following commands when the files bio and marsx both already exist? Don't guess, try it!
a) cp bio marsx
b) mv bio marsx (2 Replies)
Hi! I own a Qosmio f50 laptop and today i download the file from toshiba to update my bios. Everything went well until installer reaches block 16 when system freezes. I left it half an hour and then tried to power-off the pc with the button, but it dont. I unplug the ac-adaptor and the battery and... (0 Replies)