__get_free_pages(): is the MEM really mine?

From: Bernd Harries (mlbha@gmx.de)
Date: Thu Sep 27 2001 - 03:56:34 EST


Hi all,

this is my 4th try to post to the list. I didn't see any echo, so
I try again. Sorry if you did see the msg earlier (yesterday)..

Is __get_free_pages() not enough to allocate memory in the kernel?
Seems like something else is using the same memory. Do I have to lock the
pages I allocated?

I began with 2.4.6 on a dual CPU x86 box with 256 MB RAM and when I saw
probs I upgraded to 2.4.10. Still unstable.

In a driver I'm writing, in the open() method, I use multiple
__get_free_pages() to allocate a 4 MB kernel (image)buffer for DMA purposes.
The buffer I get is contiguous (I try until it is) and is freed in
close(). Order count is 9.

When I run the user appl. again after short time I mostly get the
same chunk of physical memory (virt_to_bus is identical!)

For access from userspace I implemented mmap() which uses the nopage()
method of the VMA. The user program hexdumps 256 bytes of the beginning
of the 4 MB buffer and 256 bytes of 0x2000 above the beginning.

After the hexdump fromm userspace I trigger a DMA engine to copy
0x8000 bytes (4 * the offset of the 2nd hexdump) from my kernelbuffer to a
'Local RAM' on a PCI card. (For now I only copy out to be sure the
buffer is not modified)

I see mostly zeroes in both of the 2 hexdumps.

If I repeat the user program within seconds, suddenly the 2nd
256 byte dump starts to change. Sometimes I see filenames of my harddisk
within the hexdump, looking like some directory listing. (e.g.
"/etc/ppp/options" ) Sometimes I see the contents of the printk buffer of
the kernel, sometimes stuff I cannot identify.

The dump form the first page seems to stay zero all the time.
The bus address of the Buffer is the same each time.

I wouldn't bother about the changes if the system wouldn't seem
to become compromised by the tests. Sometimes a dump occurs on the console
when I try to buid a new version of my driver module.
Sometimes the shell in which I started the test program gets logged out.

I have a feeling that the effect only occurs if the 2nd dump is beyond the
1st page of my kernel buffer.

Here is the output of my test program:

pcma73:/home/bharries/c/apr/>aprdma_shmw 0x8000 0 1
 open('/dev/aprsc027', ) seems ok! fd = 3
 Get fix par
 mmio: start=$DC800000 off=$00000000 len=$00001000
 mem1: start=$E0000000 off=$00000000 len=$02000000
 mem2: start=$DA000000 off=$00000000 len=$02000000

 colcon_offs=$00000000
 fifo1_offs =$01000000
 fifo2_offs =$01100000
 shm_offs =$01400000 shm_ram_size=$00400000
 hwcsr_offs =$01A00000

 Get var par
 rx_pmd_adr =$00000000 rx_msg_typ =$00000000
 tx_pmd_adr =$00000000 tx_msg_typ =$00000000
 dma_bus_adr0=$00000000 contig_len0=$00000000
 dma_bus_adr1=$03800000 contig_len1=$00400000 <-- BUS Addr

 dma0=$00000000 len=$00000000
 dma1=$40132000 len=$00400000 <-- mmapped User Addr

Diagnose Dump Adr=$40132000

:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  
Diagnose Dump Adr=$40134000

:3D 24 30 30 30 30 30 30 30 30 20 0A 53 65 70 20 =$00000000 *Sep
:32 36 20 31 32 3A 31 35 3A 30 34 20 70 63 6D 61 26 12:15:04 pcma
:37 33 20 6B 65 72 6E 65 6C 3A 20 20 73 74 61 72 73 kernel: star
:74 2B 6F 66 66 3D 24 43 33 38 30 30 30 30 30 20 t+off=$C3800000
:70 61 67 65 5F 70 74 72 3D 24 63 31 30 65 30 30 page_ptr=$c10e00
:30 30 20 0A 53 65 70 20 32 36 20 31 32 3A 31 35 00 *Sep 26 12:15
:3A 30 34 20 70 63 6D 61 37 33 20 6B 65 72 6E 65 :04 pcma73 kerne
:6C 3A 20 20 61 64 64 72 65 73 73 3D 24 34 30 31 l: address=$401
:33 34 30 30 30 20 61 64 20 2D 20 76 6D 5F 73 74 34000 ad - vm_st
:61 72 74 3D 24 30 30 30 30 32 30 30 30 20 56 4D art=$00002000 VM
:41 5F 4F 46 46 53 45 54 3D 24 30 30 30 30 30 30 A_OFFSET=$000000
:30 30 20 0A 53 65 70 20 32 36 20 31 32 3A 31 35 00 *Sep 26 12:15
:3A 30 34 20 70 63 6D 61 37 33 20 6B 65 72 6E 65 :04 pcma73 kerne
:6C 3A 20 20 73 74 61 72 74 2B 6F 66 66 3D 24 43 l: start+off=$C
:33 38 30 32 30 30 30 20 70 61 67 65 5F 70 74 72 3802000 page_ptr
:3D 24 63 31 30 65 30 30 38 30 20 0A 00 00 00 00 =$c10e0080 *
   Fill DMA ioctl struct
 Local RAM write triggered.
 Local RAM write end.

 Now close '/dev/aprsc027' fd = 3 ...

-- 
-- 
Bernd Harries

bha@gmx.de http://bharries.freeyellow.com bharries@web.de Tel. +49 421 809 7343 priv. | MSB First! harries@stn-atlas.de +49 421 457 3966 offi. | Linux-m68k bernd@linux-m68k.org +49 172 139 6054 handy | Medusa T40

GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

- 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/



This archive was generated by hypermail 2b29 : Sun Sep 30 2001 - 21:00:54 EST