All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: naresh kamboju <naresh.kernel@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: cacheflush system call-MIPS
Date: Wed, 11 Feb 2009 13:16:49 +0000	[thread overview]
Message-ID: <20090211131649.GA1365@linux-mips.org> (raw)
In-Reply-To: <f5a7b3810902100716t2658ce95t2dcc7f85634522@mail.gmail.com>

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.

  Ralf

  reply	other threads:[~2009-02-11 13:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10 15:16 cacheflush system call-MIPS naresh kamboju
2009-02-11 13:16 ` Ralf Baechle [this message]
2009-02-13 23:50   ` peter fuerst
2009-02-13 23:56     ` Ralf Baechle
2009-02-15  2:20       ` peter fuerst
2009-02-17 17:06         ` David Daney
2009-02-17 19:45           ` Eugene Surovegin
2009-02-17 20:50             ` David VomLehn (dvomlehn)
2009-02-17 20:50               ` David VomLehn (dvomlehn)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090211131649.GA1365@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=naresh.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.