0001 Using flexible arrays in the kernel
0002 Last updated for 2.6.32
0003 Jonathan Corbet <firstname.lastname@example.org>
0005 Large contiguous memory allocations can be unreliable in the Linux kernel.
0006 Kernel programmers will sometimes respond to this problem by allocating
0007 pages with vmalloc(). This solution not ideal, though. On 32-bit systems,
0008 memory from vmalloc() must be mapped into a relatively small address space;
0009 it's easy to run out. On SMP systems, the page table changes required by
0010 vmalloc() allocations can require expensive cross-processor interrupts on
0011 all CPUs. And, on all systems, use of space in the vmalloc() range
0012 increases pressure on the translation lookaside buffer (TLB), reducing the
0013 performance of the system.
0015 In many cases, the need for memory from vmalloc() can be eliminated by
0016 piecing together an array from smaller parts; the flexible array library
0017 exists to make this task easier.
0019 A flexible array holds an arbitrary (within limits) number of fixed-sized
0020 objects, accessed via an integer index. Sparse arrays are handled
0021 reasonably well. Only single-page allocations are made, so memory
0022 allocation failures should be relatively rare. The down sides are that the
0023 arrays cannot be indexed directly, individual object size cannot exceed the
0024 system page size, and putting data into a flexible array requires a copy
0025 operation. It's also worth noting that flexible arrays do no internal
0026 locking at all; if concurrent access to an array is possible, then the
0027 caller must arrange for appropriate mutual exclusion.
0029 The creation of a flexible array is done with:
0031 #include <linux/flex_array.h>
0033 struct flex_array *flex_array_alloc(int element_size,
0034 unsigned int total,
0035 gfp_t flags);
0037 The individual object size is provided by element_size, while total is the
0038 maximum number of objects which can be stored in the array. The flags
0039 argument is passed directly to the internal memory allocation calls. With
0040 the current code, using flags to ask for high memory is likely to lead to
0041 notably unpleasant side effects.
0043 It is also possible to define flexible arrays at compile time with:
0045 DEFINE_FLEX_ARRAY(name, element_size, total);
0047 This macro will result in a definition of an array with the given name; the
0048 element size and total will be checked for validity at compile time.
0050 Storing data into a flexible array is accomplished with a call to:
0052 int flex_array_put(struct flex_array *array, unsigned int element_nr,
0053 void *src, gfp_t flags);
0055 This call will copy the data from src into the array, in the position
0056 indicated by element_nr (which must be less than the maximum specified when
0057 the array was created). If any memory allocations must be performed, flags
0058 will be used. The return value is zero on success, a negative error code
0061 There might possibly be a need to store data into a flexible array while
0062 running in some sort of atomic context; in this situation, sleeping in the
0063 memory allocator would be a bad thing. That can be avoided by using
0064 GFP_ATOMIC for the flags value, but, often, there is a better way. The
0065 trick is to ensure that any needed memory allocations are done before
0066 entering atomic context, using:
0068 int flex_array_prealloc(struct flex_array *array, unsigned int start,
0069 unsigned int nr_elements, gfp_t flags);
0071 This function will ensure that memory for the elements indexed in the range
0072 defined by start and nr_elements has been allocated. Thereafter, a
0073 flex_array_put() call on an element in that range is guaranteed not to
0076 Getting data back out of the array is done with:
0078 void *flex_array_get(struct flex_array *fa, unsigned int element_nr);
0080 The return value is a pointer to the data element, or NULL if that
0081 particular element has never been allocated.
0083 Note that it is possible to get back a valid pointer for an element which
0084 has never been stored in the array. Memory for array elements is allocated
0085 one page at a time; a single allocation could provide memory for several
0086 adjacent elements. Flexible array elements are normally initialized to the
0087 value FLEX_ARRAY_FREE (defined as 0x6c in <linux/poison.h>), so errors
0088 involving that number probably result from use of unstored array entries.
0089 Note that, if array elements are allocated with __GFP_ZERO, they will be
0090 initialized to zero and this poisoning will not happen.
0092 Individual elements in the array can be cleared with:
0094 int flex_array_clear(struct flex_array *array, unsigned int element_nr);
0096 This function will set the given element to FLEX_ARRAY_FREE and return
0097 zero. If storage for the indicated element is not allocated for the array,
0098 flex_array_clear() will return -EINVAL instead. Note that clearing an
0099 element does not release the storage associated with it; to reduce the
0100 allocated size of an array, call:
0102 int flex_array_shrink(struct flex_array *array);
0104 The return value will be the number of pages of memory actually freed.
0105 This function works by scanning the array for pages containing nothing but
0106 FLEX_ARRAY_FREE bytes, so (1) it can be expensive, and (2) it will not work
0107 if the array's pages are allocated with __GFP_ZERO.
0109 It is possible to remove all elements of an array with a call to:
0111 void flex_array_free_parts(struct flex_array *array);
0113 This call frees all elements, but leaves the array itself in place.
0114 Freeing the entire array is done with:
0116 void flex_array_free(struct flex_array *array);
0118 As of this writing, there are no users of flexible arrays in the mainline
0119 kernel. The functions described here are also not exported to modules;
0120 that will probably be fixed when somebody comes up with a need for it.