Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux-mips@oss.sgi.com>, "Carsten Langgaard" <carstenl@mips.com>,
	"Michael Shmulevich" <michaels@jungo.com>
Subject: Re: User applications
Date: Mon, 8 Jan 2001 15:14:38 +0100	[thread overview]
Message-ID: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> (raw)
In-Reply-To: 3A59C0FB.62E52EF0@jungo.com

> > 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.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: linux-mips@oss.sgi.com, Carsten Langgaard <carstenl@mips.com>,
	Michael Shmulevich <michaels@jungo.com>
Subject: Re: User applications
Date: Mon, 8 Jan 2001 15:14:38 +0100	[thread overview]
Message-ID: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> (raw)
Message-ID: <20010108141438.AhWMyYyl0bYFJ9-LF-MP4vC1Fz0vyLECtmcBsKAlSgk@z> (raw)
In-Reply-To: 3A59C0FB.62E52EF0@jungo.com

> > 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.

            Regards,

            Kevin K.

  parent reply	other threads:[~2001-01-08 14:12 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 [this message]
2001-01-08 14:14     ` Kevin D. Kissell
2001-01-08 14:16     ` Carsten Langgaard
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='00d801c0797d$5cc410c0$0deca8c0@Ulysses' \
    --to=kevink@mips.com \
    --cc=carstenl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox