__DEV_ALLOC_SKB(9) Linux Networking __DEV_ALLOC_SKB(9)NAME
__dev_alloc_skb - allocate an skbuff for receiving
SYNOPSIS
struct sk_buff * __dev_alloc_skb(unsigned int length, gfp_t gfp_mask);
ARGUMENTS
length
length to allocate
gfp_mask
get_free_pages mask, passed to alloc_skb
DESCRIPTION
Allocate a new sk_buff and assign it a usage count of one. The buffer has unspecified headroom built in. Users should allocate the headroom
they think they need without accounting for the built in space. The built in space is used for optimisations.
NULL is returned if there is no free memory.
COPYRIGHT Kernel Hackers Manual 2.6. July 2010 __DEV_ALLOC_SKB(9)
Check Out this Related Man Page
JOURNAL_TRY_TO_FREE_(9) The Linux Journalling API JOURNAL_TRY_TO_FREE_(9)NAME
journal_try_to_free_buffers - try to free page buffers.
SYNOPSIS
int journal_try_to_free_buffers(journal_t * journal, struct page * page, gfp_t gfp_mask);
ARGUMENTS
journal
journal for operation
page
to try and free
gfp_mask
we use the mask to detect how hard should we try to release buffers. If __GFP_WAIT and __GFP_FS is set, we wait for commit code to
release the buffers.
DESCRIPTION
For all the buffers on this page, if they are fully written out ordered data, move them onto BUF_CLEAN so try_to_free_buffers can reap
them.
This function returns non-zero if we wish try_to_free_buffers to be called. We do this if the page is releasable by try_to_free_buffers. We
also do it if the page has locked or dirty buffers and the caller wants us to perform sync or async writeout.
This complicates JBD locking somewhat. We aren't protected by the BKL here. We wish to remove the buffer from its committing or running
transaction's ->t_datalist via __journal_unfile_buffer.
This may *change* the value of transaction_t->t_datalist, so anyone who looks at t_datalist needs to lock against this function.
Even worse, someone may be doing a journal_dirty_data on this buffer. So we need to lock against that. journal_dirty_data will come out of
the lock with the buffer dirty, which makes it ineligible for release here.
Who else is affected by this? hmm... Really the only contender is do_get_write_access - it could be looking at the buffer while
journal_try_to_free_buffer is changing its state. But that cannot happen because we never reallocate freed data as metadata while the data
is part of a transaction. Yes?
Return 0 on failure, 1 on success
AUTHORS
Roger Gammans <rgammans@computer-surgery.co.uk>
Author.
Stephen Tweedie <sct@redhat.com>
Author.
COPYRIGHT Kernel Hackers Manual 2.6. July 2010 JOURNAL_TRY_TO_FREE_(9)