[parisc-linux] Fwd: Problems with raw interface.

[parisc-linux] Fwd: Problems with raw interface.

[Santosh Abraham]

The problem seems to be with the flush_dcache_page () routine in
asm-parisc/pgalloc.h.  The routine does not handle the case when
page->mapping == NULL.  It simply ends up calling __flush_dcache_page ()
which only flushes out the cache lines corresponding to the kernel VA.

The cache lines corresponding to the user VA remain unaffected.  In order
for
the user cache lines to be flushed a call to flush_cache_page () or
flush_user_dcache_range ()
must be made.

In order to do this the flush_dcache_page () interface may need to be
modified to take in a user VA as an argument.

If this is not feasible we could as a hack check for page->mapping == NULL
in flush_dcache_page () and call flush_data_cache().  This would be very
expensive.

Also, does'nt __flush_dcache_page () need to have a for loop for "i_mmap"
similar to the one for "i_mmap_shared" ?

thanks,
santosh.

Re: [parisc-linux] Fwd: Problems with raw interface.

[Randolph Chung]

> Also, does'nt __flush_dcache_page () need to have a for loop for "i_mmap"
> similar to the one for "i_mmap_shared" ?
> 

no, this was discussed recently on this list.

see jejb's message:
http://lists.parisc-linux.org/pipermail/parisc-linux/2003-August/020791.html

and the corresponding thread for more info.

i thought flush_dcache_page is for making kernel mapping visible to
user, if you are trying to make user data visible to the kernel, you
should not be relying on flush_dcache_page.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

RE: [parisc-linux] Fwd: Problems with raw interface.

[Santosh Abraham]

hmm.. why is map_user_kiobuf () calling flush_dcache_page () then ?
should it not be calling flush_cache_{range,page} ?

map_user_kiobuf () called from the raw I/O path should ,in the
write case, be flushing user data out, so that its visible to
the kernel VA.
This is not being done in flush_dcache_page () when page->mapping is
NULL.

-----Original Message-----
From: Randolph Chung [mailto:randolph@tausq.org]
Sent: Thursday, September 25, 2003 4:20 PM
To: santosh.abraham@hp.com
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Fwd: Problems with raw interface.


> Also, does'nt __flush_dcache_page () need to have a for loop for "i_mmap"
> similar to the one for "i_mmap_shared" ?
>

no, this was discussed recently on this list.

see jejb's message:
http://lists.parisc-linux.org/pipermail/parisc-linux/2003-August/020791.html

and the corresponding thread for more info.

i thought flush_dcache_page is for making kernel mapping visible to
user, if you are trying to make user data visible to the kernel, you
should not be relying on flush_dcache_page.

randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Fwd: Problems with raw interface.

[Matthew Wilcox]

On Thu, Sep 25, 2003 at 04:49:21PM +0530, Santosh Abraham wrote:
> 
> hmm.. why is map_user_kiobuf () calling flush_dcache_page () then ?
> should it not be calling flush_cache_{range,page} ?
> 
> map_user_kiobuf () called from the raw I/O path should ,in the
> write case, be flushing user data out, so that its visible to
> the kernel VA.

I think you're right.  flush_dcache_page is for page cache pages, not for
random user addresses.  Would something like this make sense?

Index: mm/memory.c
===================================================================
RCS file: /var/cvs/linux-2.4/mm/memory.c,v
retrieving revision 1.24
diff -u -p -r1.24 memory.c
--- linux-2.4/mm/memory.c 29 Nov 2002 02:21:13 -0000      1.24
+++ linux-2.4/mm/memory.c 25 Sep 2003 14:22:42 -0000
@@ -569,12 +569,7 @@ int map_user_kiobuf(int rw, struct kiobu
                return err;
        }
        iobuf->nr_pages = err;
-       while (pgcount--) {
-               /* FIXME: flush superflous for rw==READ,
-                * probably wrong function for rw==WRITE
-                */
-               flush_dcache_page(iobuf->maplist[pgcount]);
-       }
+       flush_cache_range(mm, va, va + len);
        dprintk ("map_user_kiobuf: end OK\n");
        return 0;
 }

I deleted the comment because it's not correct ;-)  The kernel is about
to access these pages.  Any existing cache for the contents of those pages
must now be invalidated if the kernel's about to write to it, and must be
written back if the kernel's about to read from it.  flush_cache_range()
must already have these properties otherwise munmap() wouldn't work.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Thu, 25 Sep 2003 15:26:23 +0100
Matthew Wilcox <willy@debian.org> wrote:

> I think you're right.  flush_dcache_page is for page cache pages, not for
> random user addresses.  Would something like this make sense?

The flush_dcache_page() is needed in case the platform has deferred
the flushing for a kernel cpu store to a page cache page.

You cannot just delete this call and replace it with a flush_cache_range()
call, that simply won't work.

Re: [parisc-linux] Fwd: Problems with raw interface.

[Matthew Wilcox]

On Thu, Sep 25, 2003 at 06:08:48PM -0700, David S. Miller wrote:
> On Thu, 25 Sep 2003 15:26:23 +0100
> Matthew Wilcox <willy@debian.org> wrote:
> 
> > I think you're right.  flush_dcache_page is for page cache pages, not for
> > random user addresses.  Would something like this make sense?
> 
> The flush_dcache_page() is needed in case the platform has deferred
> the flushing for a kernel cpu store to a page cache page.

But this isn't a page cache page.

> You cannot just delete this call and replace it with a flush_cache_range()
> call, that simply won't work.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Fri, 26 Sep 2003 12:24:00 +0100
Matthew Wilcox <willy@debian.org> wrote:

> On Thu, Sep 25, 2003 at 06:08:48PM -0700, David S. Miller wrote:
> > The flush_dcache_page() is needed in case the platform has deferred
> > the flushing for a kernel cpu store to a page cache page.
> 
> But this isn't a page cache page.

Are you sure?  Isn't raw I/O allowed on user buffers backed by
some kind of file based mmap()?

Re: [parisc-linux] Fwd: Problems with raw interface.

[Stephen C. Tweedie]

Hi,

On Fri, 2003-09-26 at 12:20, David S. Miller wrote:

> Are you sure?  Isn't raw I/O allowed on user buffers backed by
> some kind of file based mmap()?

Yes, it is.

--Stephen

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On 26 Sep 2003 12:57:01 +0100
"Stephen C. Tweedie" <sct@redhat.com> wrote:

> On Fri, 2003-09-26 at 12:20, David S. Miller wrote:
> 
> > Are you sure?  Isn't raw I/O allowed on user buffers backed by
> > some kind of file based mmap()?
> 
> Yes, it is.

So there we go, that's how page can be a page cache page Matthew.

Re: [parisc-linux] Fwd: Problems with raw interface.

[Matthew Wilcox]

On Fri, Sep 26, 2003 at 04:48:41AM -0700, David S. Miller wrote:
> On 26 Sep 2003 12:57:01 +0100
> "Stephen C. Tweedie" <sct@redhat.com> wrote:
> 
> > On Fri, 2003-09-26 at 12:20, David S. Miller wrote:
> > 
> > > Are you sure?  Isn't raw I/O allowed on user buffers backed by
> > > some kind of file based mmap()?
> > 
> > Yes, it is.
> 
> So there we go, that's how page can be a page cache page Matthew.

OK, so it *might* be a page cache page, but isn't necessarily.  So we
need to call *both* flush_dcache_page() and flush_cache_range(), right?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Fri, 26 Sep 2003 13:20:23 +0100
Matthew Wilcox <willy@debian.org> wrote:

> OK, so it *might* be a page cache page, but isn't necessarily.  So we
> need to call *both* flush_dcache_page() and flush_cache_range(), right?

I'm starting to think that flush_dcache_page() needs to take care
of this.

Santosh remarked that flush_dcache_page() doesn't get the user virtual
address, but that is not needed.  From the page you can walk the mmap()s
and flush the mapping in each address space it is contained within.

And you absolutely must flush each address space, not just the one currently
doing the raw I/O request.

In that light, doing a flush_cache_range() with a specific VMA (2.6.x)
or MM (2.4.x) is totally illogical here.

Re: [parisc-linux] Fwd: Problems with raw interface.

[SANTOSH ABRAHAM]

> On Fri, 26 Sep 2003 13:20:23 +0100
> Matthew Wilcox <willy@debian.org> wrote:
> 
> > OK, so it *might* be a page cache page, but isn't necessarily.  So we
> > need to call *both* flush_dcache_page() and flush_cache_range(), right?
> 
> I'm starting to think that flush_dcache_page() needs to take care
> of this.
> 
> Santosh remarked that flush_dcache_page() doesn't get the user virtual
> address, but that is not needed.  From the page you can walk the mmap()s
> and flush the mapping in each address space it is contained within.

Are you talking about the page->mapping->{i_mmap_shared, i_mmap} lists ?
If so, this is already handled in __flush_dcache_page ().

The problem in this case is page->mapping is NULL. 

> 
> And you absolutely must flush each address space, not just the one currently
> doing the raw I/O request.
> 
> In that light, doing a flush_cache_range() with a specific VMA (2.6.x)
> or MM (2.4.x) is totally illogical here.
> 

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Fri, 26 Sep 2003 18:41:41 +0530 (IST)
SANTOSH ABRAHAM <santosha@india.hp.com> wrote:

> The problem in this case is page->mapping is NULL. 

When page->mapping is NULL, flush_dcache_page() should purge the page
(by physical addres) from it's caches.  This is what sparc64 does.

Flushing just the current address space is incorrect, so don't get the
fancy idea to pass the 'mm' and 'va' into flush_dcache_page().

Re: [parisc-linux] Fwd: Problems with raw interface.

[Matthew Wilcox]

On Fri, Sep 26, 2003 at 05:56:52AM -0700, David S. Miller wrote:
> On Fri, 26 Sep 2003 18:41:41 +0530 (IST)
> SANTOSH ABRAHAM <santosha@india.hp.com> wrote:
> 
> > The problem in this case is page->mapping is NULL. 
> 
> When page->mapping is NULL, flush_dcache_page() should purge the page
> (by physical addres) from it's caches.  This is what sparc64 does.

But you can't do that on PA-RISC.  You can only purge virtual addresses.

> Flushing just the current address space is incorrect, so don't get the
> fancy idea to pass the 'mm' and 'va' into flush_dcache_page().

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Fri, 26 Sep 2003 14:29:01 +0100
Matthew Wilcox <willy@debian.org> wrote:

> On Fri, Sep 26, 2003 at 05:56:52AM -0700, David S. Miller wrote:
> > When page->mapping is NULL, flush_dcache_page() should purge the page
> > (by physical addres) from it's caches.  This is what sparc64 does.
> 
> But you can't do that on PA-RISC.  You can only purge virtual addresses.

Then for page->mapping == NULL your flush_dcache_page() is not doing
what it is supposed to, and you can expect problems extending further
than this raw I/O case.

You have to find a way to walk all the address spaces to figure out
where the page is mapped.

If you just put a flush_cache_range() there, you may get your current
test working but that code is wrong.  It will be wrong in any case
where the page is mapped to anywhere other then this mapping in
this address space.

The real problem for you guys is that in 2.4.x there is no easy way to
go from a page to it's mapping regardless of what kind of page it is.
That's what you need to rectify somehow.

Re: [parisc-linux] Fwd: Problems with raw interface.

[Matthew Wilcox]

On Fri, Sep 26, 2003 at 06:21:43AM -0700, David S. Miller wrote:
> On Fri, 26 Sep 2003 14:29:01 +0100
> Matthew Wilcox <willy@debian.org> wrote:
> 
> > On Fri, Sep 26, 2003 at 05:56:52AM -0700, David S. Miller wrote:
> > > When page->mapping is NULL, flush_dcache_page() should purge the page
> > > (by physical addres) from it's caches.  This is what sparc64 does.
> > 
> > But you can't do that on PA-RISC.  You can only purge virtual addresses.
> 
> Then for page->mapping == NULL your flush_dcache_page() is not doing
> what it is supposed to, and you can expect problems extending further
> than this raw I/O case.

Oh, come on, Dave.  You just changed the definition of
flush_dcache_page().  You can't claim the implementation isn't doing
what it's supposed to!  The definition in cachetlb talks *only* about
page cache pages.

> You have to find a way to walk all the address spaces to figure out
> where the page is mapped.

That's ridiculous.  For a start, pages can't be mapped into multiple
address spaces without being in the page cache.  Second, we already know
where it is, you just refuse to pass that information in.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Fri, 26 Sep 2003 15:09:48 +0100
Matthew Wilcox <willy@debian.org> wrote:

> > You have to find a way to walk all the address spaces to figure out
> > where the page is mapped.
> 
> That's ridiculous.  For a start, pages can't be mapped into multiple
> address spaces without being in the page cache.

How in the world can anonymous pages work then?  Of course anonymous
pages can be in multiple address spaces without being in the page
cache.

Re: [parisc-linux] Fwd: Problems with raw interface.

[Matthew Wilcox]

On Fri, Sep 26, 2003 at 07:04:50AM -0700, David S. Miller wrote:
> On Fri, 26 Sep 2003 15:09:48 +0100
> Matthew Wilcox <willy@debian.org> wrote:
> 
> > > You have to find a way to walk all the address spaces to figure out
> > > where the page is mapped.
> > 
> > That's ridiculous.  For a start, pages can't be mapped into multiple
> > address spaces without being in the page cache.
> 
> How in the world can anonymous pages work then?  Of course anonymous
> pages can be in multiple address spaces without being in the page
> cache.

How?  By fork()?  If so, that's not a problem -- the pages stay at the same
address in both processes, and flushing one will flush any inherited pages.
Otherwise you'll have to be more explicit.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

On Fri, 26 Sep 2003 15:30:52 +0100
Matthew Wilcox <willy@debian.org> wrote:

> On Fri, Sep 26, 2003 at 07:04:50AM -0700, David S. Miller wrote:
> > On Fri, 26 Sep 2003 15:09:48 +0100
> > Matthew Wilcox <willy@debian.org> wrote:
> > 
> > > > You have to find a way to walk all the address spaces to figure out
> > > > where the page is mapped.
> > > 
> > > That's ridiculous.  For a start, pages can't be mapped into multiple
> > > address spaces without being in the page cache.
> > 
> > How in the world can anonymous pages work then?  Of course anonymous
> > pages can be in multiple address spaces without being in the page
> > cache.
> 
> How?  By fork()?  If so, that's not a problem -- the pages stay at the same
> address in both processes, and flushing one will flush any inherited pages.
> Otherwise you'll have to be more explicit.

Any page can be mremap()'d to any other address.

You really do have to walk all the address spaces to sufficiently
tap the page out of the caches.  Unfortunately, this is only easy
in 2.6.x :(

Re: [parisc-linux] Fwd: Problems with raw interface.

[Stephen C. Tweedie]

Hi,

On Fri, 2003-09-26 at 15:20, David S. Miller wrote:

> Any page can be mremap()'d to any other address.

Yep.  At least this case is rare, and you can optimise for the simple
case by checking page->count.  But the general case really does need to
be covered if you're going to be fully correct for all cases.

And with O_DIRECT being an unprivileged operation, users have the
ability to expose this problem quite easily.

Cheers,
 Stephen

Re: [parisc-linux] Fwd: Problems with raw interface.

[Stephen C. Tweedie]

Hi,

On Fri, 2003-09-26 at 15:09, Matthew Wilcox wrote:

> That's ridiculous.  For a start, pages can't be mapped into multiple
> address spaces without being in the page cache.

fork().  At least we know the pages aren't dirty or writable in that
case, though.  But because of sys_mremap(), we don't know the VA for all
possible mappings, and the pages are _not_ necessarily in the page
cache.

There's only one place where anon pages get into the page cache, and
that's via swap cache.  Note that we don't have to worry about
kernel-context access to such pages: the contents are only ever seen
from user-space process context.  The fork case still means there are
multiple such referencing contexts, though.

--Stephen

RE: [parisc-linux] Fwd: Problems with raw interface.

[Santosh Abraham]

The flush_dcache_page () might be required in cases when the
same user buffer is being used for both reads and writes in an
alternating fashion, right ?

-----Original Message-----
From: willy@www.linux.org.uk [mailto:willy@www.linux.org.uk]On Behalf Of
Matthew Wilcox
Sent: Friday, September 26, 2003 4:54 PM
To: David S. Miller
Cc: Matthew Wilcox; santosh.abraham@hp.com; randolph@tausq.org;
parisc-linux@lists.parisc-linux.org; sct@redhat.com
Subject: Re: [parisc-linux] Fwd: Problems with raw interface.


On Thu, Sep 25, 2003 at 06:08:48PM -0700, David S. Miller wrote:
> On Thu, 25 Sep 2003 15:26:23 +0100
> Matthew Wilcox <willy@debian.org> wrote:
>
> > I think you're right.  flush_dcache_page is for page cache pages, not
for
> > random user addresses.  Would something like this make sense?
>
> The flush_dcache_page() is needed in case the platform has deferred
> the flushing for a kernel cpu store to a page cache page.

But this isn't a page cache page.

> You cannot just delete this call and replace it with a flush_cache_range()
> call, that simply won't work.

--
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead
bodies.
Do you think I want to have an academic debate on this subject?" -- Robert
Fisk

RE: [parisc-linux] Fwd: Problems with raw interface.

[Santosh Abraham]

A call to flush_cache_range(), before the call to flush_dcache_page ()
would fix the problem. I tested this a couple of days back,
but called flush_user_dcache_range () instead of flush_cache_range(), and
our apps seemed to work fine.

flush_cache_range () calls flush_user_dcache_range () internally.
(i am aware that flush_user_dcache_range () is not an exported
interface, but I urgently needed to get our apps working ).

Would the following be acceptable ?
------------------------------------------------------------------------
*** mm/memory.c.orig       Fri Nov 29 07:51:13 2002
--- mm/memory.c    Fri Sep 26 15:56:02 2003
***************
*** 570,578 ****
        }
        iobuf->nr_pages = err;
        while (pgcount--) {
!               /* FIXME: flush superflous for rw==READ,
!                * probably wrong function for rw==WRITE
                 */
                flush_dcache_page(iobuf->maplist[pgcount]);
        }
        dprintk ("map_user_kiobuf: end OK\n");
--- 570,595 ----
        }
        iobuf->nr_pages = err;
        while (pgcount--) {
!               struct page *page;
!
!               page = iobuf->maplist[pgcount];
!
!               /*
!                * flush_dcache_page () calls flush_cache_page () internally
!                * in certain cases.  This check is an attempt to avoid
!                * spurious cache flushes.
                 */
+
+               if (!page->mapping) {
+                       unsigned long start = va + (pgcount * PAGE_SIZE);
+                       unsigned long end   = va + ((pgcount+1) *
PAGE_SIZE);
+
+                       /* Strictly not necessary, perhaps ? */
+                       if (end > va+len) {
+                               end = va+len;
+                       }
+                       flush_cache_range (mm, start, end);
+               }
                flush_dcache_page(iobuf->maplist[pgcount]);

-----------------------------------------------------------------------

Does the order of the calls to flush_cache_range ()/flush_dcache_page()
matter ?

Also, what would be the effect on other platforms ?


-----Original Message-----
From: willy@www.linux.org.uk [mailto:willy@www.linux.org.uk]On Behalf Of
Matthew Wilcox
Sent: Thursday, September 25, 2003 7:56 PM
To: santosh.abraham@hp.com
Cc: 'Randolph Chung'; parisc-linux@lists.parisc-linux.org; Stephen C.
Tweedie; David S. Miller
Subject: Re: [parisc-linux] Fwd: Problems with raw interface.


On Thu, Sep 25, 2003 at 04:49:21PM +0530, Santosh Abraham wrote:
>
> hmm.. why is map_user_kiobuf () calling flush_dcache_page () then ?
> should it not be calling flush_cache_{range,page} ?
>
> map_user_kiobuf () called from the raw I/O path should ,in the
> write case, be flushing user data out, so that its visible to
> the kernel VA.

I think you're right.  flush_dcache_page is for page cache pages, not for
random user addresses.  Would something like this make sense?

Index: mm/memory.c
===================================================================
RCS file: /var/cvs/linux-2.4/mm/memory.c,v
retrieving revision 1.24
diff -u -p -r1.24 memory.c
--- linux-2.4/mm/memory.c 29 Nov 2002 02:21:13 -0000      1.24
+++ linux-2.4/mm/memory.c 25 Sep 2003 14:22:42 -0000
@@ -569,12 +569,7 @@ int map_user_kiobuf(int rw, struct kiobu
                return err;
        }
        iobuf->nr_pages = err;
-       while (pgcount--) {
-               /* FIXME: flush superflous for rw==READ,
-                * probably wrong function for rw==WRITE
-                */
-               flush_dcache_page(iobuf->maplist[pgcount]);
-       }
+       flush_cache_range(mm, va, va + len);
        dprintk ("map_user_kiobuf: end OK\n");
        return 0;
 }

I deleted the comment because it's not correct ;-)  The kernel is about
to access these pages.  Any existing cache for the contents of those pages
must now be invalidated if the kernel's about to write to it, and must be
written back if the kernel's about to read from it.  flush_cache_range()
must already have these properties otherwise munmap() wouldn't work.

--
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead
bodies.
Do you think I want to have an academic debate on this subject?" -- Robert
Fisk

Re: [parisc-linux] Fwd: Problems with raw interface.

[David S. Miller]

1) Please use unified diffs when you post patches.

2) If you insist on using Microsoft Outlook when posting patches
   at least configure it properly when doing so.  By default it is
   going to turn tabs into spaces and that makes the patch corrupt
   and unusable by anyone.

2) Your patch is unacceptable because it is taking advantage
   of internal implementation details of flush_dcache_page()
   on parisc64 that might not (and in fact, is not) be true
   on other platforms.

RE: [parisc-linux] Fwd: Problems with raw interface.

[Santosh Abraham]

Apologies for 1) & 2). I guess ignorance is not bliss or excusable,
 is it :)

As for 3) i agree that there are issues, but what are the alternatives
 we have ?

Assuming that you agree that we need to call flush_cache_range ( ) to fix
the issue.

1) Call flush_cache_range () directly before the call to 
flush_dcache_page ().  But this could impact other architectures
too, right ?

2) Modify flush_dcache_page () in asm-parisc/pgalloc.h to handle
this.  But this is not easy cause we do not pass the user VA in
flush_dcache_page ().  


-----Original Message-----
From: David S. Miller [mailto:davem@redhat.com]
Sent: Friday, September 26, 2003 4:05 PM
To: santosh.abraham@hp.com
Cc: santosha@india.hp.com; willy@debian.org; randolph@tausq.org;
parisc-linux@lists.parisc-linux.org; sct@redhat.com
Subject: Re: [parisc-linux] Fwd: Problems with raw interface.



1) Please use unified diffs when you post patches.

2) If you insist on using Microsoft Outlook when posting patches
   at least configure it properly when doing so.  By default it is
   going to turn tabs into spaces and that makes the patch corrupt
   and unusable by anyone.

3) Your patch is unacceptable because it is taking advantage
   of internal implementation details of flush_dcache_page()
   on parisc64 that might not (and in fact, is not) be true
   on other platforms.