bio_unmap_user(9) [suse man page]

BIO_UNMAP_USER(9)						   The Linux VFS						 BIO_UNMAP_USER(9)

NAME

       bio_unmap_user - unmap a bio

SYNOPSIS

       void bio_unmap_user(struct bio * bio);

ARGUMENTS

       bio
	   the bio being unmapped

DESCRIPTION

       Unmap a bio previously mapped by bio_map_user. Must be called with a process context.

       bio_unmap_user may sleep.

COPYRIGHT

Kernel Hackers Manual 2.6.					     July 2010							 BIO_UNMAP_USER(9)

BIO_ALLOC_BIOSET(9)						   The Linux VFS					       BIO_ALLOC_BIOSET(9)

NAME

       bio_alloc_bioset - allocate a bio for I/O

SYNOPSIS

       struct bio * bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set * bs);

ARGUMENTS

       gfp_mask
	   the GFP_ mask given to the slab allocator

       nr_iovecs
	   number of iovecs to pre-allocate

       bs
	   the bio_set to allocate from.

DESCRIPTION

       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
       memory pressure.

       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.

RETURNS

       Pointer to new bio on success, NULL on failure.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						       BIO_ALLOC_BIOSET(9)