lkml.org 
[lkml]   [2001]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
Subjectrd.c -- still buggy in 2.4.10?

I haven't tried the rd.c from 2.4.10 on a PA machine yet, but it seems
to me it's still buggy. Because we have such a huge dcache on PA, we're
perhaps more vulnerable to the problem than anyone else. We needed the
following patch in our tree (originally by John Marvin, rewritten by me):

--- linux-249/drivers/block/rd.c Mon Jul 23 04:37:30 2001
+++ linux-pa/drivers/block/rd.c Wed Sep 26 16:28:59 2001
@@ -227,8 +227,10 @@
*/
bdata = bh_kmap(sbh);
if (rw == READ) {
- if (sbh != rbh)
+ if (sbh != rbh) {
memcpy(bdata, rbh->b_data, rbh->b_size);
+ flush_dcache_page(sbh->b_page);
+ }
} else
if (sbh != rbh)
memcpy(rbh->b_data, bdata, rbh->b_size);
The equivalent bit in the 2.4.10 driver would seem to be in
rd_blkdev_pagecache_IO, and there's no flush_dcache_page after the memcpy.
There is one _earlier_, where page is memset, which seems spurious to me.

How about a patch along these lines?

--- linux-2410/drivers/block/rd.c Thu Sep 27 08:32:39 2001
+++ linux-2410-rd/drivers/block/rd.c Thu Sep 27 08:35:34 2001
@@ -276,7 +276,6 @@ static int rd_blkdev_pagecache_IO(int rw
if (!Page_Uptodate(page)) {
memset(kmap(page), 0, PAGE_CACHE_SIZE);
kunmap(page);
- flush_dcache_page(page);
SetPageUptodate(page);
}

@@ -301,8 +300,11 @@ static int rd_blkdev_pagecache_IO(int rw
kunmap(page);
bh_kunmap(sbh);

- if (rw != READ)
+ if (rw == READ) {
+ flush_dcache_page(page);
+ } else {
SetPageDirty(page);
+ }
if (unlock)
UnlockPage(page);
__free_page(page);

By the way, Documentation/cachetlb.txt does not mention how kunmap and
flush_dcache_page should be ordered. In rd.c, pages are kunmapped before
they are flushed. This seems unwise for any architecture where you need
the virtual address which was written to for the flush to work. If we
implemented kmap/kunmap on parisc, we'd have this problem. Fortunately,
HP managed to release 64-bit processors before shipping any machines
which could be fitted with more than 3GB of RAM. Is this a merely
theoretical issue, or does any architecture have problems with this?

--
Revolutions do not require corporate support.
-
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 13:03    [W:0.049 / U:3.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site