[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20100608003046.GA29325@dvomlehn-lnx2.corp.sa.net>
Date: Mon, 7 Jun 2010 17:30:46 -0700
From: David VomLehn <dvomlehn@...co.com>
To: to@...mlehn-lnx2.corp.sa.net, "netdev@...r.kernel.org"@cisco.com,
netdev@...r.kernel.org
Subject: [PATCH][RFC] Introduction to sk_buff state checking
Add state checking for sk_buffs
Several common errors in sk_buff usage can be caught by maintaining and
checking the sk_buff state. States are: free, allocated, and queued. Simply
reporting an error is not sufficient; it may be the previous state change
that was erroneous. Thus, the ability to record the location of the previous
state change is essential.
This patch was previously submitted and David Miller objected to to the
overhead of recording the previous state change. Specifically, he wrote:
The specifics are that if you showed me something that
added a "u16", at most, I'd go to bat for you and support
your work going upstream.
With only three states, only two bits are required to record the current
state but recording the location of the call that changed the state in
no more than 14 bits posed an interesting challenge. This patchset contains
the infrastructure required to map between a small value, the "callsite ID",
and the location of the call.
There are four patches in this patchset:
1. This introduction
2. A patch allowing the site of a call to be passed over multiple calls
without modifying the intervening functions.
3. A patch providing infrastructure that allows the location of a call,
the "callsite ID" to be encoded in a small integer.
4. Modifications to the sk_buff functions to add the two-bit state
and a 14-bit callsite ID, check the state, and report failures.
Restrictions
o Call site IDs are never reused, so it is possible to exceed the
maximum number of IDs by having a large number of call locations.
In addition, it does not recognize that the same module has been
unloaded and reloaded, so calls from the reloaded module will be
assigned new IDs. Detection of incorrect operations on an sk_buff
is not affected by exhaustion of call site IDs, but it may not be
possible to determine the location of the last operation.
CONFIG_DEBUG_SKB_ID_SIZE is set to reduce the sk_buff growth to 16
bits and should handle most cases. It could be made larger to allow
more call site IDs, if necessary.
o The callsite structures for a module will be freed when that module
is unloaded, even though sk_buffs may be using IDs corresponding to
those call sites. To allow useful error reporting, the call site
information in a module being unloaded is copied. If a module is
unloaded and CONFIG_CALLSITE_TERSE is enabled, the address of
the call site is not longer valid, so only the function name and
offset are printed. If CONFIG_CALLSITE_TERSE is enabled and the
is loaded, the address is also reported.
Signed-off-by: David VomLehn <dvomlehn@...co.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists