All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: rpm@xenomai.org
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] [Xenomai-commits] r3147 - __xn_access_ok changes
Date: Mon, 05 Nov 2007 20:20:01 +0100	[thread overview]
Message-ID: <472F6CE1.7050208@domain.hid> (raw)
In-Reply-To: <472F5990.5000408@domain.hid>

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>  > [Let's discuss this without bothering users :)]
>>  > 
>>  > Philippe Gerum wrote:
>>  > > Author: rpm
>>  > > Date: Sun Nov  4 18:18:39 2007
>>  > > New Revision: 3147
>>  > > 
>>  > > URL: http://svn.gna.org/viewcvs/xenomai?rev=3147&view=rev
>>  > > Log:
>>  > > Make __xn_access_ok() return false for addresses lower than the natural page size.
>>  > > 
>>  > > Modified:
>>  > >     trunk/ChangeLog
>>  > >     trunk/include/asm-x86/syscall_32.h
>>  > >     trunk/include/asm-x86/syscall_64.h
>>  > 
>>  > Could it be that you meant "PAGE_SIZE" instead of "PAGE_OFFSET"? Because
>>  > the current version is "slightly" broken, tagging any address in user
>>  > land as invalid.
>>  > 
> 
> Another example that committing last minute "fixes" before leaving for a 
> trip is just as safe as checking for your parachute _after_ you jumped 
> out of the plane. Fixed the trivial way for now. Sorry for this.
> 
>>  > And if this test was meant to catch NULL page accesses early, is the
>>  > intention to cope with all those current i-pipe patches that do not yet
>>  > include the discussed domain switch on non-root faults? If yes, this
>>  > test would be a workaround for legacy code and should not become default
>>  > (pure overhead for later versions).
>>
>> We can reduce the overhead of the two tests by testing 
>> (unsigned long) (addr - PAGE_SIZE) < (PAGE_OFFSET - PAGE_SIZE)
>>
> 
> Yep. I'd rather keep the reference to the actual task's segment limit in 
> this expression though, instead of hardcoding PAGE_OFFSET.
> 
> Aside of this, we should not need to pass the current task pointer to 
> each and every syscall anymore, so we may rely on the original uaccess code.
> 
> __xn_access_ok was there to allow for passing the task pointer
> explicitly in order to test the address range against the task's segment
> limit, at times when Adeos would switch the underlying stack to some
> private, non-Linux one.
> 
> With modern I-pipe, domains don't have any private stack, but simply
> reuse the current one, which means that any task running a syscall
> over the Xenomai domain may always be referenced by "current", including
> on archs using the stack pointer trick to determine this value.
> 
> I'll do this change early in the 2.5 series; it's too late for 2.4.
> 
> This said, we'll still need __xn_access_ok from now on, to pre-test the 
> address for obvious spuriousness, like the NULL case which started this 
> discussion.

...which still doesn't answer my original question: Is the current
(virtually fixed - please fix in real-life soon!) version a legacy
wrapper for you? Because I still don't see the need for it with, e.g.,
my latest patch for i386-ipipe.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux


  reply	other threads:[~2007-11-05 19:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1Ioj7Q-0004EI-JX@subversion.gna.org>
2007-11-04 21:19 ` [Xenomai-core] [Xenomai-commits] r3147 - __xn_access_ok changes Jan Kiszka
2007-11-04 21:40   ` Gilles Chanteperdrix
2007-11-05 17:57     ` Philippe Gerum
2007-11-05 19:20       ` Jan Kiszka [this message]
2007-11-05 20:00         ` Jan Kiszka
2007-11-05 23:06         ` Philippe Gerum
2007-11-06  6:20           ` Jan Kiszka

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=472F6CE1.7050208@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=rpm@xenomai.org \
    --cc=xenomai@xenomai.org \
    /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.