Re: CVS commit: src/sys/dev/hdaudio
Date:Fri, 4 Aug 2017 00:25:24 + From:"matthew green" Message-ID: <20170804002524.16ba1f...@cvs.netbsd.org> | put all the ELD debugging messages under #ifdef HDAFG_HDMI_DEBUG. I am not sure that doing that with the ones that are hda_error() is the correct thing to do - if something is failing, getting an indication why, even when not debugging. seems like a good idea to me. kre
Re: CVS commit: src/sys/arch/amd64/conf
paulg adds: This is not making GENERIC fail because COMPAT_43 is not really removed on it. $ nm /home/fly/amd/sys/arch/amd64/compile/GENERIC/netbsd |grep compat_43 80403485 T compat_43_netbsd32_fstat43 8040371a T compat_43_netbsd32_killpg 80403431 T compat_43_netbsd32_lstat43 804037b5 T compat_43_netbsd32_oaccept ... This is from: sys/compat/netbsd32/files.netbsd32: filecompat/netbsd32/netbsd32_compat_43.ccompat_netbsd32 & (compat_43 | compat_sunos | compat_linux32) So with COMPAT_LINUX32, it still builds the COMPAT_43 code.
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, Jul 28, 2017 at 04:10:29PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Fri Jul 28 16:10:29 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU > > Log Message: > After a careful review, and all things considered, disable compat43 by > default on amd64. The use case is limited, the potential for damage too > high, and it is safer to run a BSD4.3 binary on i386 since the kernel does > not have to go through netbsd32 - which may not correctly reproduce i386. > > > To generate a diff of this commit: > cvs rdiff -u -r1.461 -r1.462 src/sys/arch/amd64/conf/GENERIC > cvs rdiff -u -r1.136 -r1.137 src/sys/arch/amd64/conf/XEN3_DOM0 > cvs rdiff -u -r1.75 -r1.76 src/sys/arch/amd64/conf/XEN3_DOMU This breaks running compat_linux as a kernel module: Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_sethostname' not found Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_lseek' not found Aug 4 00:19:19 loggy /netbsd: WARNING: module error: unable to affix module `compat_linux', error 8 I believe paulg made PR kern/51597 for similar issues
Re: CVS commit: src/sys/arch
On Thu, Aug 03, 2017 at 04:20:45PM +0200, Maxime Villard wrote: > > I was more thinking in terms of a single page in kernel VA, not in user > > VA. That would side step most of the issues with dynamic LDT or having > > to patch up the default LDT on context switches. That said, the latter > > wouldn't be that difficult either, given that we already do that for the > > GDT. > > Mmh, not sure what you mean. If you mean a page that is a kernel page (in the > sense of not having PG_u), then it's a privileged call gate, and we're back > on the first issue (being in kernel mode, with user segment registers, and > interrupts enabled). If you mean a page this a userland page (with PG_u), but > located in the kernel VA range, that's not a good idea: it all of a sudden > makes the map less consistent, and it is more complicated since the upper > levels of the page tree need to have PG_u too. I was thinking of a page in the kernel VA range that is accessible for userland. I thought we had some of those already for the comm page, but I might be misremember. We can also put it at the top of the user VA range of course, i.e. where the stack used to originate. Joerg
Re: CVS commit: src/sys/arch
Le 03/08/2017 à 15:16, Joerg Sonnenberger a écrit : On Thu, Aug 03, 2017 at 02:01:04PM +0200, Maxime Villard wrote: Le 03/08/2017 à 13:06, Joerg Sonnenberger a écrit : On Sat, Jul 01, 2017 at 10:44:43AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sat Jul 1 10:44:43 UTC 2017 Modified Files: src/sys/arch/amd64/amd64: locore.S src/sys/arch/i386/i386: locore.S machdep.c trap.c Log Message: Remove the osyscall call gate on i386, and emulate it. There is a one- instruction race in it that could panic the kernel. Looking back at this -- can't we provide a user-readable/executable page and replace the call gate with a normal segment pointing to that page? I thought about it, but I could see at least one issue: that page would be allocated dynamically in kern_exec, but the LDT entry is static. We would have to either put the page at a static location - which violates several principles, such as the fact that this area could contain a segment from the binary -, or create per-process LDTs and switch them each time we're doing a context switch - which has several performance drawbacks, along with creating new constraints in the LDT that may violate other ones -. It didn't seem like a good idea, so I ended up simply removing the gate. Chuck came up with another solution, and I just copied it in i386. I was more thinking in terms of a single page in kernel VA, not in user VA. That would side step most of the issues with dynamic LDT or having to patch up the default LDT on context switches. That said, the latter wouldn't be that difficult either, given that we already do that for the GDT. Mmh, not sure what you mean. If you mean a page that is a kernel page (in the sense of not having PG_u), then it's a privileged call gate, and we're back on the first issue (being in kernel mode, with user segment registers, and interrupts enabled). If you mean a page this a userland page (with PG_u), but located in the kernel VA range, that's not a good idea: it all of a sudden makes the map less consistent, and it is more complicated since the upper levels of the page tree need to have PG_u too.
Re: CVS commit: src/sys/arch
On Thu, Aug 03, 2017 at 02:01:04PM +0200, Maxime Villard wrote: > Le 03/08/2017 à 13:06, Joerg Sonnenberger a écrit : > > On Sat, Jul 01, 2017 at 10:44:43AM +, Maxime Villard wrote: > > > Module Name: src > > > Committed By: maxv > > > Date: Sat Jul 1 10:44:43 UTC 2017 > > > > > > Modified Files: > > > src/sys/arch/amd64/amd64: locore.S > > > src/sys/arch/i386/i386: locore.S machdep.c trap.c > > > > > > Log Message: > > > Remove the osyscall call gate on i386, and emulate it. There is a one- > > > instruction race in it that could panic the kernel. > > > > Looking back at this -- can't we provide a user-readable/executable page > > and replace the call gate with a normal segment pointing to that page? > > I thought about it, but I could see at least one issue: that page would be > allocated dynamically in kern_exec, but the LDT entry is static. We would > have to either put the page at a static location - which violates several > principles, such as the fact that this area could contain a segment from the > binary -, or create per-process LDTs and switch them each time we're doing a > context switch - which has several performance drawbacks, along with creating > new constraints in the LDT that may violate other ones -. > > It didn't seem like a good idea, so I ended up simply removing the gate. > Chuck came up with another solution, and I just copied it in i386. I was more thinking in terms of a single page in kernel VA, not in user VA. That would side step most of the issues with dynamic LDT or having to patch up the default LDT on context switches. That said, the latter wouldn't be that difficult either, given that we already do that for the GDT. Joerg
Re: CVS commit: src/sys/arch
Le 03/08/2017 à 13:06, Joerg Sonnenberger a écrit : On Sat, Jul 01, 2017 at 10:44:43AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sat Jul 1 10:44:43 UTC 2017 Modified Files: src/sys/arch/amd64/amd64: locore.S src/sys/arch/i386/i386: locore.S machdep.c trap.c Log Message: Remove the osyscall call gate on i386, and emulate it. There is a one- instruction race in it that could panic the kernel. Looking back at this -- can't we provide a user-readable/executable page and replace the call gate with a normal segment pointing to that page? I thought about it, but I could see at least one issue: that page would be allocated dynamically in kern_exec, but the LDT entry is static. We would have to either put the page at a static location - which violates several principles, such as the fact that this area could contain a segment from the binary -, or create per-process LDTs and switch them each time we're doing a context switch - which has several performance drawbacks, along with creating new constraints in the LDT that may violate other ones -. It didn't seem like a good idea, so I ended up simply removing the gate. Chuck came up with another solution, and I just copied it in i386. Maxime
Re: CVS commit: src/sys/arch
On Sat, Jul 01, 2017 at 10:44:43AM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sat Jul 1 10:44:43 UTC 2017 > > Modified Files: > src/sys/arch/amd64/amd64: locore.S > src/sys/arch/i386/i386: locore.S machdep.c trap.c > > Log Message: > Remove the osyscall call gate on i386, and emulate it. There is a one- > instruction race in it that could panic the kernel. Looking back at this -- can't we provide a user-readable/executable page and replace the call gate with a normal segment pointing to that page? So that osycall becomes a normal FAR CALL to a kernel provide routine that turns it into a normal system call. That has the advantage of not requiring special case logic in the trap handler and I want to move the direct system call logic out of libc in the near future, which requires the same infrastructure. Joerg
