[Top] [All Lists]

Re: cacheflush system call-MIPS

To: naresh kamboju <>
Subject: Re: cacheflush system call-MIPS
From: Ralf Baechle <>
Date: Wed, 11 Feb 2009 13:16:49 +0000
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote:

> Hi Mr. Ralf,
> I have tried to test cacheflush system call to generate EINVAL
> on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel.
> I have referred latest Man pages there is a bug column.
> Please let me know whether this is bug in source code or in the man page.
> (arch/mips/mm/cache.c)

The answer is probably a bit of both.  The API and error behaviour was
defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier.

Gcc relies on the existence of this syscall - or rather a library
function which usually will be implemented to execute this syscall because
the operating requires kernel priviledges - so Linux had to get an
implementation as well.

Now in practice there is only one good reason to perform explicit
cacheflushes from userspace and that's to ensure I-cache coherency and
that's the one thing the Linux implementation of cacheflush(2) is trying
to do.  Therefore the implementation ignores the cache argument and
will instead perform whatever is necessary to guarantee I-cache coherency -
whatever this means on a particlar implementation.

Similarly the implementation won't verify that every byte of the range
is accessible.  For a large range it instead may choose to perform a full
writeback / invalidation of some or all parts of the cache hierarchy
which might mean there will not be an error return even though part of
the address space may not be accessible.

Talking about bugs - the "BUGS" section of the man page is wrong.  A full
cacheflush is only performed if this is considered to be faster than a
cacheline-by-cacheline flush.


<Prev in Thread] Current Thread [Next in Thread>