From: Carsten Langgaard <carstenl@mips.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux-mips@oss.sgi.com, Michael Shmulevich <michaels@jungo.com>
Subject: Re: User applications
Date: Mon, 08 Jan 2001 15:16:16 +0100 [thread overview]
Message-ID: <3A59CBB0.24160437@mips.com> (raw)
In-Reply-To: 00d801c0797d$5cc410c0$0deca8c0@Ulysses
"Kevin D. Kissell" wrote:
> > > When a new user process is started will its user space be cleared by the
> > > kernel or is there a potential leak from an older user process ?
> >
> > Usually it is defied by the loader. If the data section contents is set to
> > LOAD, then the contents of the section will be loaded from disk (no leak),
> > if not -- whatever values left i nmemory will be there, or exactly, the
> > virtual page of some other proccess that was swapped out or ended.
>
> Note that what you are describing here is the "exec()" behavior.
> I believe Carsten was talking about what happens on a "fork()".
>
> > > What about the registers values, are they cleared for each new user
> > > application or will it simply contain the current value it got when the
> > > user application is started ?
> >
> > It depends on the context switch algorithm of the processor, I think.
>
> On a fork() (or presumably clone()) operation, the set of registers
> is copied. Loading a new program ("exec()") should set up the
> registers that point to the base of the new stack, the environment,
> etc. Historically, it's up to the runtime startup code ("crt0" in old
> Unix systems) to do any other register initialization.
>
> > > How can you flush the data and instruction cashes from a user
> > > application ?
> > >
> >
> > As far as I understand, ASID must take care of it. It contains unique IDs
> > per process virtual space, so that even
> > though virtual addresses may be found in TLB, their ASID will be
> different,
> > causing TLB miss and probably page fault.
>
> That won't necessarily affect the caches, though. While it
> would be possible to do so, I don't believe any existing
> MIPS implementations include ASID in the cache tags.
> Hits are determined by an address match, period.
>
> Back in the Ancient Old Days of System V, every architecture
> had an architecture-specific system call entry, the first parameter
> of which expressed what needed to be done. Do we have
> such a thing in Linux? That would be the logical place to
> things like cache flush and the atomic operations that were
> being discussed here a couple of weeks ago.
I think I just found it.
The system call is sysmips(FLUSH_CACHE).
>
> Regards,
>
> Kevin K.
--
_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
Denmark http://www.mips.com
next prev parent reply other threads:[~2001-01-08 14:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-08 9:40 User applications Carsten Langgaard
2001-01-08 13:30 ` Michael Shmulevich
2001-01-08 13:52 ` Carsten Langgaard
2001-01-08 14:14 ` Kevin D. Kissell
2001-01-08 14:14 ` Kevin D. Kissell
2001-01-08 14:16 ` Carsten Langgaard [this message]
2001-01-08 16:03 ` Ralf Baechle
2001-01-08 15:07 ` Maciej W. Rozycki
2001-01-08 15:21 ` Kevin D. Kissell
2001-01-08 15:21 ` Kevin D. Kissell
2001-01-08 15:40 ` Maciej W. Rozycki
2001-01-08 16:27 ` Ralf Baechle
2001-01-08 16:43 ` Maciej W. Rozycki
2001-01-08 16:41 ` Ralf Baechle
2001-01-08 16:05 ` Ralf Baechle
2001-01-08 16:23 ` Carsten Langgaard
2001-01-08 16:30 ` Ralf Baechle
2001-01-08 16:50 ` Carsten Langgaard
2001-01-08 17:56 ` Maciej W. Rozycki
2001-01-08 16:40 ` Maciej W. Rozycki
2001-01-08 17:42 ` Ralf Baechle
2001-01-08 17:58 ` Maciej W. Rozycki
2001-01-09 11:49 ` Michael Shmulevich
2001-01-09 12:15 ` Geert Uytterhoeven
2001-01-09 12:17 ` Alan Cox
2001-01-09 12:17 ` Alan Cox
2001-01-09 13:00 ` Maciej W. Rozycki
2001-01-08 16:34 ` Maciej W. Rozycki
2001-01-08 14:16 ` Maciej W. Rozycki
2001-01-08 16:25 ` Ralf Baechle
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=3A59CBB0.24160437@mips.com \
--to=carstenl@mips.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
--cc=michaels@jungo.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.