linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kanoj Sarcar <kanoj@google.engr.sgi.com>
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org,
	alan@lxorguk.ukuu.org.uk, torvalds@transmeta.com
Subject: Re: flush_icache_range
Date: Mon, 24 Jul 2000 09:10:30 -0700 (PDT)	[thread overview]
Message-ID: <200007241610.JAA33950@google.engr.sgi.com> (raw)
In-Reply-To: <20000723203609.A903@bacchus.dhis.org> from "Ralf Baechle" at Jul 23, 2000 08:36:09 PM

> 
> On Sat, Jul 22, 2000 at 06:07:08PM -0700, Kanoj Sarcar wrote:
> 
> > Can anyone point out the logic of continued existance of flush_icache_range
> > after the introduction of flush_icache_page()? I admit that 
> > flush_icache_range is still needed in the module loading code, but do we
> > need it anymore in the a.out loading code? That code should be incurring
> > page faults, which will do the flush_icache_page anyway. Seems like
> > double work to me to do flush_icache_range again after the loading has
> > been done.
> 
> binfmt_elf.c:load_aout_interp() uses file->f_op->read to read the interpreter
> from disk, so actually need to use something else to flush the cache.
> Similar for two of three cases in binfmt_aout.c.  For these the page
> fault won't sufficiently flush cashes.

Okay, got it. flush_icache_page() can flush the icache, then 
flush_icache_range() can writeback-invalidate the dcache (for the a.out
section loading code), and things should work. AFAICS, this would be
the most optimal way to do things (ie, you don't have to writeback-invalidate
dcache, and invalidate icache in flush_icache_range(), you can optimize
out the icache flush relying on flush_icache_page to do the work).

> 
> > This argument to delete the flush_icache_range calls from the a.out
> > loading code assumes that the f_op->read() code behaves sanely, ie does
> > not do unexpected things like touch the user address (thus allocating
> > the page, and doing the icache flush via the page fault handler much
> > earlier) before it starts reading the a.out sections in ...
> 
> There is another MIPS specific problem with this routine.  Originally
> introduced for kernel modules the various incarnations of flush_icache_range
> are not protected against access from userspace.  Unable to handle kernel
> paging request ahead ...

Could you elaborate? Use mips as an example. Note: for the a.out code,
there will be one thread, and for the module loading, userspace access 
to the vmalloced area is not possible.

Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-07-24 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-23  1:07 flush_icache_range Kanoj Sarcar
2000-07-23 18:36 ` flush_icache_range Ralf Baechle
2000-07-24 16:10   ` Kanoj Sarcar [this message]
2000-07-25  0:06     ` flush_icache_range Ralf Baechle
2000-07-25  1:11       ` flush_icache_range Kanoj Sarcar

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=200007241610.JAA33950@google.engr.sgi.com \
    --to=kanoj@google.engr.sgi.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=ralf@oss.sgi.com \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox