1BLK_MAKE_REQUEST(9) Block Devices BLK_MAKE_REQUEST(9)
2
3
4
6 blk_make_request - given a bio, allocate a corresponding struct
7 request.
8
10 struct request * blk_make_request(struct request_queue * q,
11 struct bio * bio, gfp_t gfp_mask);
12
14 q
15 target request queue
16
17 bio
18 The bio describing the memory mappings that will be submitted for
19 IO. It may be a chained-bio properly constructed by block/bio
20 layer.
21
22 gfp_mask
23 gfp flags to be used for memory allocation
24
26 blk_make_request is the parallel of generic_make_request for BLOCK_PC
27 type commands. Where the struct request needs to be farther initialized
28 by the caller. It is passed a struct bio, which describes the memory
29 info of the I/O transfer.
30
31 The caller of blk_make_request must make sure that bi_io_vec are set to
32 describe the memory buffers. That bio_data_dir will return the needed
33 direction of the request. (And all bio's in the passed bio-chain are
34 properly set accordingly)
35
36 If called under none-sleepable conditions, mapped bio buffers must not
37 need bouncing, by calling the appropriate masked or flagged allocator,
38 suitable for the target device. Otherwise the call to blk_queue_bounce
39 will BUG.
40
42 When allocating/cloning a bio-chain, careful consideration should be
43 given to how you allocate bios. In particular, you cannot use
44 __GFP_WAIT for anything but the first bio in the chain. Otherwise you
45 risk waiting for IO completion of a bio that hasn't been submitted yet,
46 thus resulting in a deadlock. Alternatively bios should be allocated
47 using bio_kmalloc instead of bio_alloc, as that avoids the mempool
48 deadlock. If possible a big IO should be split into smaller parts when
49 allocation fails. Partial allocation should not be an error, or you
50 risk a live-lock.
51
53Kernel Hackers Manual 3.10 June 2019 BLK_MAKE_REQUEST(9)