From: "David Mosberger-Tang" <dmosberger@gmail.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] Ensure PSR.ac is cleared for early userspace
Date: Sat, 15 Nov 2008 03:03:27 +0000 [thread overview]
Message-ID: <ed5aea430811141903w1de4c8b7p362aa4c0d307c03b@mail.gmail.com> (raw)
In-Reply-To: <200811120135.mAC1ZoSd017352@agluck-lia64.sc.intel.com>
Tony,
Have you checked the IA64 ABI? I remember there being a section
talking about the state in which signal handlers should be started. I
don't remember off hand if it said anything about psr.ac.
--david
On 11/14/08, Luck, Tony <tony.luck@intel.com> wrote:
> GLOBAL_ENTRY(kernel_execve)
> + rum IA64_PSR_AC
> mov r15=__NR_execve // put syscall number in place
> break __BREAK_SYSCALL
> br.ret.sptk.many rp
>
> I'm not overly happy with this because I still don't understand how
> the PSR.ac bit became set in this context. This patch papers
> over the problem by clearing psr.ac ... but it shouldn't be
> set at this point!
>
> As far as I can see usage of psr.ac is as follows:
>
> 1) When Linux first boots the code in head.S transitions to
> virtual mode ... this code sets PSR.ac=0.
>
> 2) Eight of the code paths in ivt.S set PSR.ac=1 before
> transitioning to C code. Thus interrupt handlers, page faults
> and other traps are executed with .ac=1. This is controlled by the
> PSR_DEFAULT_BITS define ... which is (and I think always has)
> been defined to set psr.ac.
>
> [I'm a bit puzzled as to why we want strict alignment checking
> in interrupt/fault handlers, but are satisfied with more relaxed
> behaivour in base code]
>
> I'm also puzzled why this issue only just surfaced, and why I
> only see it on generic kernels.
>
> The problem may be related to some interrupt behavior. If I
> tweak just the "__interrupt" code to not set psr.ac (but leave
> the other seven fault handlers setting psr.ac=1) then I don't
> see any unaligned traps in early init code.
>
> -Tony
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
next prev parent reply other threads:[~2008-11-15 3:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 1:35 [PATCH] Ensure PSR.ac is cleared for early userspace Luck, Tony
2008-11-13 6:22 ` Isaku Yamahata
2008-11-15 1:38 ` Luck, Tony
2008-11-15 3:03 ` David Mosberger-Tang [this message]
2008-11-15 19:57 ` Tony Luck
2008-11-17 18:59 ` Rick Jones
2008-11-17 19:45 ` Luck, Tony
2008-11-17 19:52 ` Rick Jones
2008-11-17 20:58 ` Luck, Tony
2008-11-18 7:06 ` Petr Tesarik
2008-11-18 7:12 ` Matthew Wilcox
2008-11-18 11:58 ` Robin Holt
2008-11-20 22:45 ` Luck, Tony
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=ed5aea430811141903w1de4c8b7p362aa4c0d307c03b@mail.gmail.com \
--to=dmosberger@gmail.com \
--cc=linux-ia64@vger.kernel.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.