All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe deBlaquiere <jadb@redhat.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@oss.sgi.com>, Florian Lohoff <flo@rfc822.org>,
	linux-mips@oss.sgi.com
Subject: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call
Date: Fri, 26 Jan 2001 09:41:49 -0600	[thread overview]
Message-ID: <3A719ABD.5030206@redhat.com> (raw)
In-Reply-To: Pine.GSO.3.96.1010126111156.8903B-100000@delta.ds2.pg.gda.pl

Ralf gently pointed out that there was the possibility of needing to 
fault the page for *p, which couldn't occur with ints off. So here's an 
updated version...

#ifndef CONFIG_CPU_HAS_LLSC
	/* this version is inherently single processor! */
	/* borrowed from Linux-2.4.0-test12 */
	/* mlock/munlock added - jadb@redhat.com */
	
	case MIPS_ATOMIC_SET: {
		unsigned int tmp;
		unsigned int flags;

		p = (int *) arg1;
		errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
		if (errno)
			return errno;
		errno = 0;
		
		/* need to prevent page faults with ints off */
		if (sys_mlock(p,sizeof(*p)) != 0)
		{
			return -EAGAIN;
		}
		
		/* actually _do_ the exchange */
		save_and_cli(flags);
		errno |= __get_user(tmp, p);
		errno |= __put_user(arg2, p);
		restore_flags(flags);
		
		/* i don't think sys_munlock can fail here, and */
		/* I wouldn't know what to do if it did, so no  */
		/* reason to pay attention to the return value  */
		sys_munlock(p,sizeof(*p));

		return tmp;
	}
#endif

comments anyone?

Joe

Maciej W. Rozycki wrote:

> On Thu, 25 Jan 2001, Joe deBlaquiere wrote:
> 
> 
>> So I've got the following code which seems to work... (I can't use the 
>> ll/sc ops on the Vr41xx since they are not implemeted!)
>> 
>> #ifdef CONFIG_CPU_VR41XX
> 
> 
>  You are perfectly correct, with the exception you really want to make it: 
> 
> #ifndef CONFIG_CPU_HAS_LLSC
> 
> as that's the correct option -- just undef it in arch/mips/config.in for
> your CPU like it's done for others already.
> 
>  Shame on me I haven't sent the patch for MIPS_ATMIC_SET for non-ll/sc
> processors yet.  I have it but it needs a few minor cleanups.
> 
>  Ralf, BTW, what do you think if we send a segfault on a memory access
> violation instead of returning an error?  That would make the behaviour of
> MIPS_ATMIC_SET consistent for any memory contents.  Does anything actually
> rely on the function to return an error in such a situation? 
> 
>   Maciej


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

  reply	other threads:[~2001-01-26 15:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-24 15:30 OOps - very obscure Florian Lohoff
2001-01-24 15:59 ` Florian Lohoff
2001-01-24 16:22   ` Florian Lohoff
2001-01-24 21:18   ` Keith Owens
2001-01-25 12:43   ` Florian Lohoff
2001-01-25 18:59     ` Jun Sun
2001-01-25 19:22       ` Florian Lohoff
2001-01-25 15:55   ` [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call Florian Lohoff
2001-01-25 15:55     ` Florian Lohoff
2001-01-25 16:34     ` Origin 200 crash nick
2001-01-25 18:28     ` [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call Joe deBlaquiere
2001-01-25 19:35       ` Joe deBlaquiere
2001-01-25 22:19         ` Ralf Baechle
2001-01-26  0:53           ` Joe deBlaquiere
2001-01-26 10:21             ` Maciej W. Rozycki
2001-01-26 15:41               ` Joe deBlaquiere [this message]
2001-01-26 21:16                 ` Ralf Baechle
2001-01-27  7:20                 ` Maciej W. Rozycki
2001-01-26 21:15               ` Ralf Baechle
2001-01-27  7:28                 ` Maciej W. Rozycki
2001-01-27 19:42                   ` Ralf Baechle
2001-01-29 15:03                     ` Maciej W. Rozycki
2001-01-26 20:01             ` Jun Sun
2001-01-26 20:38               ` Joe deBlaquiere
2001-01-26 21:02                 ` Jun Sun
2001-04-04 22:13           ` Florian Lohoff
2001-02-19 13:11     ` strace sysmips support (was: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call) Wichert Akkerman
2001-02-19 19:52       ` newbie question Can Altineller
2001-02-20  7:06         ` David Jez
2001-02-20 20:26           ` Mike McDonald
2001-02-20 20:30             ` nick
2001-02-20 20:53             ` Ralf Baechle
2001-02-20 20:41       ` strace sysmips support (was: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call) 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=3A719ABD.5030206@redhat.com \
    --to=jadb@redhat.com \
    --cc=flo@rfc822.org \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ralf@oss.sgi.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.