lkml.org 
[lkml]   [2001]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Allocation of sk_buffs in the kernel
Em Thu, Aug 23, 2001 at 11:01:42AM +0200, Jens Hoffrichter escreveu:
> Hi,
>
> > Maybe Jens should use something like WAITQUEUE_DEBUG if he want to know
> > where alloc_skb and friends were called, see include/linux/wait.h 8)
> Do you mean I should use something LIKE the WAITQUEUE_DEBUG (eg.
> implementing something like that in skbuff.c) or I should use
> WAITQUEUE_DEBUG?

no, just use the same idea that is used to debug wait_queues

> The code in wait.h mainly seems to consist of issuing BUG() calls, and
> thats not quite what I want to ;) But how is it to use? I don't know much
> about waitqueues in the Linux kernel, I mainly played with the network
> stack...

heh, thats my use for the waitqueue debug now 8)

> Are there any examples how to use the WAITQUEUE_DEBUG?

oops, I mean the __waker thing, for debugging you could get the address of
the caller with current_text_addr() and store it in an extra sk_buff field
so that later on you could know who create the skb.

About the example of WAITQUEUE_DEBUG:

after being awaken you could do this:

dprintk("sleeper=%p, waker=%lx\n",
current_text_addr(), wait.__waker);

in a inline function does the trick, but this is just an example of a
function that uses an extra debug field in a structure that is alocated
somewhere and you want to know who allocated it later on.

Yes, you'll have to decode the address from syslog, gotcha?

- Arnaldo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:58    [W:0.051 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site