from lkml.

Any mm people here have any comments on this?

Thanks,
~Randy
___________________________________________________
|Randy Dunlap     Intel Corp., DAL    Sr. SW Engr.|
|randy.dunlap.at.intel.com            503-696-2055|
|NOTE:  Any views presented here are mine alone   |
|and may not represent the views of my employer.  |
|_________________________________________________|

-----Original Message-----
From: wollny [mailto:[EMAIL PROTECTED]] 
Sent: Monday, June 12, 2000 7:25 AM
To: [EMAIL PROTECTED]
Subject: PROBLEM: usage of page_address and CONFIG_HIGHMEM on ix86


Hello,

hitting on a BUG() statement in bttv.c i found out that it seems to be no
good idea, to use the 'page_address' macro from <asm/pgtable.h> on the
ix86 with CONFIG_HIGHMEM enabled.

>From the comment in mm/highmem.c function kmap_high:

"for highmem pages we can't trust "virtual" until after we have the
lock."

Since 'page_address' accesses page->virtual without a lock, the BUG()
statement may be hit (and is so randomly at least with bttv) because of
this. 

Replacing 'page_address' with 'kmap' (from <linux/highmem.h>) in
bttv.c solved the problem for me (patch sent to Gerd Knorr).
Without CONFIG_HIGHMEM this simply is defined as 'page_address' and else as
'kmap_high'. 

There are more files affected in the arch-independen tree: 

./drivers/block/loop.c
./drivers/block/raid1.c
./drivers/block/raid5.c
./drivers/char/bttv.c
./drivers/char/cpia.c
./drivers/scsi/sg.c
./drivers/usb/ov511.c
./drivers/usb/ibmcam.c
./fs/buffer.c
./fs/smbfs/file.c
./fs/romfs/inode.c
./fs/udf/file.c
./fs/cramfs/inode.c
./fs/ramfs/inode.c
./include/linux/mm.h
./mm/filemap.c
./mm/highmem.c

But i not sure if the replacement is always neccessary or
even more if it is not possible at some places since 'kmap_high' is not
irq-save.

Thanks for your time and comments and best wishes

Gert

PS: Please CC me in your answers to the list.  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to