subject:"svn commit\: r332489 \- in head\: gnu\/usr.bin\/gdb\/kgdb sys\/conf sys\/dev\/dcons sys\/dev\/hyperv\/vmbus\/i386 sys\/dev\/ppc sys\/dev\/syscons sys\/i386\/conf sys\/i386\/i386 sys\/i386\/include sys\/i386\/include\/pc sy"

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

2018-04-23 Thread Tijl Coosemans

On Sun, 22 Apr 2018 23:51:03 +0300 Konstantin Belousov  
wrote:
> On Sun, Apr 22, 2018 at 10:26:14PM +0300, Konstantin Belousov wrote:
>> On Sun, Apr 22, 2018 at 09:06:56PM +0200, Tijl Coosemans wrote:  
>>> Could this have broken the linux futex syscall?  I have a linux program
>>> that gets stuck in linux_sys_futex and becomes unkillable.  Note that the
>>> routines in sys/i386/linux/linux_support.s try to do atomic operations on
>>> user space addresses.  
>> 
>> Yes, it is quite possible.  I will try to look next week.  
> 
> Try this.  I only compile-tested it as a module.

Yes, this fixes it.  That was quick, thanks!
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

2018-04-22 Thread Konstantin Belousov

On Sun, Apr 22, 2018 at 10:26:14PM +0300, Konstantin Belousov wrote:
> On Sun, Apr 22, 2018 at 09:06:56PM +0200, Tijl Coosemans wrote:
> > On Fri, 13 Apr 2018 20:30:49 + (UTC) Konstantin Belousov 
> >  wrote:
> > Could this have broken the linux futex syscall?  I have a linux program
> > that gets stuck in linux_sys_futex and becomes unkillable.  Note that the
> > routines in sys/i386/linux/linux_support.s try to do atomic operations on
> > user space addresses.
> 
> Yes, it is quite possible.  I will try to look next week.

Try this.  I only compile-tested it as a module.

diff --git a/sys/compat/linux/linux_futex.c b/sys/compat/linux/linux_futex.c
index 7741983bcd3..a82672eaa4f 100644
--- a/sys/compat/linux/linux_futex.c
+++ b/sys/compat/linux/linux_futex.c
@@ -273,14 +273,6 @@ static int handle_futex_death(struct linux_emuldata *, 
uint32_t *,
 static int fetch_robust_entry(struct linux_robust_list **,
 struct linux_robust_list **, unsigned int *);
 
-/* support.s */
-int futex_xchgl(int oparg, uint32_t *uaddr, int *oldval);
-int futex_addl(int oparg, uint32_t *uaddr, int *oldval);
-int futex_orl(int oparg, uint32_t *uaddr, int *oldval);
-int futex_andl(int oparg, uint32_t *uaddr, int *oldval);
-int futex_xorl(int oparg, uint32_t *uaddr, int *oldval);
-
-
 static int
 futex_copyin_timeout(int op, struct l_timespec *luts, int clockrt,
 struct timespec *ts)
diff --git a/sys/compat/linux/linux_futex.h b/sys/compat/linux/linux_futex.h
index d5798e91560..4171dd70504 100644
--- a/sys/compat/linux/linux_futex.h
+++ b/sys/compat/linux/linux_futex.h
@@ -78,6 +78,11 @@ extern struct mtx futex_mtx;
 #defineFUTEX_TID_MASK  0x3fff
 #defineFUTEX_BITSET_MATCH_ANY  0x
 
+int futex_xchgl(int oparg, uint32_t *uaddr, int *oldval);
+int futex_addl(int oparg, uint32_t *uaddr, int *oldval);
+int futex_orl(int oparg, uint32_t *uaddr, int *oldval);
+int futex_andl(int oparg, uint32_t *uaddr, int *oldval);
+int futex_xorl(int oparg, uint32_t *uaddr, int *oldval);
 void   release_futexes(struct thread *,
struct linux_emuldata *);
 
diff --git a/sys/conf/files.i386 b/sys/conf/files.i386
index ab48a533893..9fe32a20eb6 100644
--- a/sys/conf/files.i386
+++ b/sys/conf/files.i386
@@ -536,11 +536,10 @@ i386/ibcs2/ibcs2_xenix.c  optional ibcs2
 i386/ibcs2/ibcs2_xenix_sysent.coptional ibcs2
 i386/ibcs2/imgact_coff.c   optional ibcs2
 i386/linux/imgact_linux.c  optional compat_linux
+i386/linux/linux_copyout.c optional compat_linux
 i386/linux/linux_dummy.c   optional compat_linux
 i386/linux/linux_machdep.c optional compat_linux
 i386/linux/linux_ptrace.c  optional compat_linux
-i386/linux/linux_support.s optional compat_linux   \
-   dependency  "linux_assym.h"
 i386/linux/linux_sysent.c  optional compat_linux
 i386/linux/linux_sysvec.c  optional compat_linux
 i386/pci/pci_cfgreg.c  optional pci
diff --git a/sys/i386/i386/copyout.c b/sys/i386/i386/copyout.c
index 3767ff9e54b..9d855eea70e 100644
--- a/sys/i386/i386/copyout.c
+++ b/sys/i386/i386/copyout.c
@@ -97,7 +97,7 @@ copyout_init_tramp(void)
(uintptr_t)suword_fast + setidt_disp);
 }
 
-static int
+int
 cp_slow0(vm_offset_t uva, size_t len, bool write,
 void (*f)(vm_offset_t, void *), void *arg)
 {
diff --git a/sys/i386/include/md_var.h b/sys/i386/include/md_var.h
index 828b633067d..73c3cba069f 100644
--- a/sys/i386/include/md_var.h
+++ b/sys/i386/include/md_var.h
@@ -55,6 +55,8 @@ structsegment_descriptor;
 union savefpu;
 
 void   bcopyb(const void *from, void *to, size_t len);
+intcp_slow0(vm_offset_t uva, size_t len, bool write,
+   void (*f)(vm_offset_t, void *), void *arg);
 void   cpu_switch_load_gs(void) __asm(__STRING(cpu_switch_load_gs));
 void   copyout_init_tramp(void);
 void   doreti_iret(void) __asm(__STRING(doreti_iret));
diff --git a/sys/i386/linux/linux_copyout.c b/sys/i386/linux/linux_copyout.c
new file mode 100644
index 000..6bb8165ddd9
--- /dev/null
+++ b/sys/i386/linux/linux_copyout.c
@@ -0,0 +1,193 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2018 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Konstantin Belousov 
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

2018-04-22 Thread Konstantin Belousov

On Sun, Apr 22, 2018 at 09:06:56PM +0200, Tijl Coosemans wrote:
> On Fri, 13 Apr 2018 20:30:49 + (UTC) Konstantin Belousov 
>  wrote:
> > Author: kib
> > Date: Fri Apr 13 20:30:49 2018
> > New Revision: 332489
> > URL: https://svnweb.freebsd.org/changeset/base/332489
> > 
> > Log:
> >   i386 4/4G split.
> >   
> >   The change makes the user and kernel address spaces on i386
> >   independent, giving each almost the full 4G of usable virtual addresses
> >   except for one PDE at top used for trampoline and per-CPU trampoline
> >   stacks, and system structures that must be always mapped, namely IDT,
> >   GDT, common TSS and LDT, and process-private TSS and LDT if allocated.
> 
> Could this have broken the linux futex syscall?  I have a linux program
> that gets stuck in linux_sys_futex and becomes unkillable.  Note that the
> routines in sys/i386/linux/linux_support.s try to do atomic operations on
> user space addresses.

Yes, it is quite possible.  I will try to look next week.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

2018-04-22 Thread Tijl Coosemans

On Fri, 13 Apr 2018 20:30:49 + (UTC) Konstantin Belousov  
wrote:
> Author: kib
> Date: Fri Apr 13 20:30:49 2018
> New Revision: 332489
> URL: https://svnweb.freebsd.org/changeset/base/332489
> 
> Log:
>   i386 4/4G split.
>   
>   The change makes the user and kernel address spaces on i386
>   independent, giving each almost the full 4G of usable virtual addresses
>   except for one PDE at top used for trampoline and per-CPU trampoline
>   stacks, and system structures that must be always mapped, namely IDT,
>   GDT, common TSS and LDT, and process-private TSS and LDT if allocated.

Could this have broken the linux futex syscall?  I have a linux program
that gets stuck in linux_sys_futex and becomes unkillable.  Note that the
routines in sys/i386/linux/linux_support.s try to do atomic operations on
user space addresses.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sy

4 matches

Site Navigation

Mail list logo

Footer information