> You also need to warn folks that the page used to do this cannot span a
> page boundry. We use tracking labels to track memory leaks (since the
> linux kernel does not provide this service) and discovered that the
> drivers get DMA timeout errors if you allocate two pages (since the
> tracking header is above the allocation and causes the page start addres
> to be 16 bytes into the page), then use a buffer heads to span one
> (which seems broken).
The assumption of buffer_heads having their data aligned to the power of 2
that the size of the buffer is at is widely present, and why buffers are
populated with pages (or aligned portions thereof). If you're looking to
check for memory leaks, there are patches out there that do all the hard
work for you (memleak-something, I don't remember the url) -- no need to
reinvent the wheel.
> Also, I noticed that brw page locks the page in memory. I am not doing
> this and am not seeing any problems, but should I? I am calling kmallov
> with GFP_BUFFER. Does this take care of the locking problem for IO?
If you don't lock the page, then you'll run into troubles if someone else
tries to read the same page, or the system tries to reclaim the memory.
Of course, such bugs will tend to only show up under high load.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/