From: Eric Dumazet <dada1@cosmosbay.com>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Something very strange on x86_64 2.6.X kernels
Date: Fri, 21 Jan 2005 17:49:25 +0100 [thread overview]
Message-ID: <41F13295.40702@cosmosbay.com> (raw)
In-Reply-To: <20050121162601.GA8469@vana.vc.cvut.cz>
Petr Vandrovec wrote:
>
> Maybe I already missed answer, but try patch below. It is definitely bad
> to mark syscall page as global one...
>
Hi Petr
If I follow you, any 64 bits program is corrupted as soon one 32bits
program using sysenter starts ?
Thank you for the patch, I will try it as soon as possible.
I tried your tpg program and had the same behavior you describe.
I confirm that avoiding the 0xFFFFE000 - 0x100000000 VM ranges is also
OK , the program never crash...
Eric
> When you build program below, once as 64bit and once as 32bit, 32bit one
> should print 464C457F and 64bit one should die with SIGSEGV. But when
> you run both in parallel, 64bit one sometime gets SIGSEGV as it should,
> sometime it gets 464C457F. (actually results below are from SMP system;
> I believe that on UP you'll get reproducible 464C457F on UP system...)
>
> vana:~/64bit-test# ./tpg32
> Memory at ffffe000 is 464C457F
> vana:~/64bit-test# ./tpg
> Segmentation fault
> vana:~/64bit-test# ./tpg32 & ./tpg
> [1] 8450
> Memory at ffffe000 is 464C457F
> Memory at ffffe000 is 464C457F
> [1]+ Exit 31 ./tpg32
> vana:~/64bit-test# ./tpg32 & ./tpg
> [1] 8454
> Memory at ffffe000 is 464C457F
> [1]+ Exit 31 ./tpg32
> Segmentation fault
> vana:~/64bit-test# ./tpg32 & ./tpg
> [1] 8456
> Memory at ffffe000 is 464C457F
> Memory at ffffe000 is 464C457F
> [1]+ Exit 31 ./tpg32
> vana:~/64bit-test# ./tpg32 & ./tpg
> [1] 8458
> Memory at ffffe000 is 464C457F
> Memory at ffffe000 is 464C457F
> [1]+ Exit 31 ./tpg32
> vana:~/64bit-test#
>
>
> void main(void) {
> int acc;
> int i;
>
> for (i = 0; i < 100000000; i++) ;
> acc = *(volatile unsigned long*)(0xffffe000);
> printf("Memory at ffffe000 is %08X\n", acc);
> }
>
> Petr
>
>
> diff -urdN linux/arch/x86_64/ia32/syscall32.c linux/arch/x86_64/ia32/syscall32.c
> --- linux/arch/x86_64/ia32/syscall32.c 2005-01-17 12:29:05.000000000 +0000
> +++ linux/arch/x86_64/ia32/syscall32.c 2005-01-21 16:15:04.000000000 +0000
> @@ -55,7 +55,7 @@
> if (pte_none(*pte)) {
> set_pte(pte,
> mk_pte(virt_to_page(syscall32_page),
> - PAGE_KERNEL_VSYSCALL));
> + PAGE_KERNEL_VSYSCALL32));
> }
> /* Flush only the local CPU. Other CPUs taking a fault
> will just end up here again
> diff -urdN linux/include/asm-x86_64/pgtable.h linux/include/asm-x86_64/pgtable.h
> --- linux/include/asm-x86_64/pgtable.h 2005-01-17 12:29:11.000000000 +0000
> +++ linux/include/asm-x86_64/pgtable.h 2005-01-21 16:14:44.000000000 +0000
> @@ -182,6 +182,7 @@
> #define PAGE_KERNEL_EXEC MAKE_GLOBAL(__PAGE_KERNEL_EXEC)
> #define PAGE_KERNEL_RO MAKE_GLOBAL(__PAGE_KERNEL_RO)
> #define PAGE_KERNEL_NOCACHE MAKE_GLOBAL(__PAGE_KERNEL_NOCACHE)
> +#define PAGE_KERNEL_VSYSCALL32 __pgprot(__PAGE_KERNEL_VSYSCALL)
> #define PAGE_KERNEL_VSYSCALL MAKE_GLOBAL(__PAGE_KERNEL_VSYSCALL)
> #define PAGE_KERNEL_LARGE MAKE_GLOBAL(__PAGE_KERNEL_LARGE)
> #define PAGE_KERNEL_VSYSCALL_NOCACHE MAKE_GLOBAL(__PAGE_KERNEL_VSYSCALL_NOCACHE)
>
>
next prev parent reply other threads:[~2005-01-21 16:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-19 23:13 COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6 Janos Farkas
2005-01-20 4:21 ` Chris Bruner
2005-01-20 16:28 ` Adrian Bunk
2005-01-20 16:40 ` Linus Torvalds
2005-01-20 16:48 ` Andi Kleen
2005-01-20 20:53 ` Something very strange on x86_64 2.6.X kernels Eric Dumazet
2005-01-20 21:08 ` Andrew Morton
2005-01-20 21:19 ` Eric Dumazet
2005-01-21 16:26 ` Petr Vandrovec
2005-01-21 16:49 ` Eric Dumazet [this message]
2005-01-21 18:30 ` Petr Vandrovec
2005-01-22 1:54 ` Andi Kleen
2005-01-22 2:14 ` Linus Torvalds
2005-01-21 6:58 ` COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6 Catalin(ux aka Dino) BOIE
2005-01-21 7:11 ` Andi Kleen
2005-01-21 17:46 ` Matt Domsch
2005-01-21 19:05 ` H. Peter Anvin
2005-02-07 6:57 ` Werner Almesberger
2005-02-12 13:54 ` Eric W. Biederman
2005-02-12 14:51 ` Werner Almesberger
2005-02-12 15:17 ` Eric W. Biederman
2005-02-14 5:49 ` Werner Almesberger
2005-02-14 7:36 ` Eric W. Biederman
2005-02-14 6:15 ` Adam Sulmicki
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=41F13295.40702@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vandrove@vc.cvut.cz \
/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.