Re: CVS commit: src/sys/arch
Maxime Villard writes: > AFAICT, emacs is known to be buggy on netbsd. That's strange, seeing as I've been using it daily since NetBSD 0.0, with no problems. That's on i386, vax, mips, sparc, and amd64 platforms. (It's been a while since I had a vax, mips, or sparc system with NetBSD on it, so I can't speak to current NetBSD on those.) ...and if you check the headers of this message, I think you can see which MUA I prefer... ;) -tih -- I like long walks, especially when they are taken by people who annoy me.
Re: CVS commit: src/sys/arch
On Fri, Nov 25, 2016 at 01:04:20PM +0100, Maxime Villard wrote: > ? It probably means there is some kind of stupid assumption or hack in > emacs. If you could send me the core, the binary and tell me which arch it > is, that would be nice. No, if there is a problem it is somewhere in crtstuff, ld.elf_so, or early libc initialization. When it dies, it dies long before main and long before anything in emacs itself gets control. In particular, _libc_init chokes on a wrong __ps_strings value apparently either passed in from the kernel, garbaged by ld.elf_so, or maybe otherwise mishandled somewhere in the startup logic. > AFAICT, emacs is known to be buggy on netbsd. Rubbish. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch
On Thu, Nov 24, 2016 at 10:28:56PM +0900, Masanobu SAITOH wrote: > > Put a one-page redzone between userland and the PTE space on amd64 and > > i386. > > > > The PTE space is a critical region that maps the page tree, and bugs have > > been found in both amd64 and i386 where the kernel would wrongly overflow > > userland data on this area. This kind of bug is terrible, since it allows > > userland to overwrite some entries of the page tree, which makes it easy > > to patch the kernel text and get ring0 privileges. > > My emacs dumps core with change. > > What should we do? Make maxv clean up his mess, or rebuild emacs. It seems that the stack location gets baked in somehow when emacs dumps, although I don't really see exactly how (see PR 51654) and this causes existing emacs binaries to stop working. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/kernel
On Nov 26, 3:24am, n...@gmx.com (Kamil Rytarowski) wrote: -- Subject: Re: CVS commit: src/tests/kernel | PT_READ_D and PT_READ_I read single int according to documentation. | | In tests io_read_d* io_read_i* data blocks are printed with appropriate | PRIxN. | | I cannot spot a mistake in the tests. | | I'm going to replace %x with %#x. Ok, so the minimum unit of reading is an int. Then the code is correct. christos
Re: CVS commit: src/tests/kernel
On 25.11.2016 23:41, Christos Zoulas wrote: > In article , > Christos Zoulas wrote: >> In article <20161125200105.5dbb4f...@cvs.netbsd.org>, >> Kamil Rytarowski wrote: >>> -=-=-=-=-=- >>> >>> Module Name:src >>> Committed By: kamil >>> Date: Fri Nov 25 20:01:05 UTC 2016 >>> >>> Modified Files: >>> src/tests/kernel: t_ptrace_wait.c >>> >>> Log Message: >>> Fix several printf(3)-like functions usage with printing integers >>> >>> Integers as hex shall no be printed with PRIx8, but with plain "x". >> >> I would use %#x... > > And I am not sure that passing 'int x; ptrace(.., &x, ...);' is right when > reading/writing 1 byte. It works on x86 if you initialize x = 0, but > it will will not work on sparc64, I think. Perhaps you need to pass > 'uint8_t x; ptrace(, ..., &x, ...);' Then the printf format is right :-) > > christos > PT_READ_D and PT_READ_I read single int according to documentation. In tests io_read_d* io_read_i* data blocks are printed with appropriate PRIxN. I cannot spot a mistake in the tests. I'm going to replace %x with %#x. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/kernel
In article , Christos Zoulas wrote: >In article <20161125200105.5dbb4f...@cvs.netbsd.org>, >Kamil Rytarowski wrote: >>-=-=-=-=-=- >> >>Module Name: src >>Committed By: kamil >>Date: Fri Nov 25 20:01:05 UTC 2016 >> >>Modified Files: >> src/tests/kernel: t_ptrace_wait.c >> >>Log Message: >>Fix several printf(3)-like functions usage with printing integers >> >>Integers as hex shall no be printed with PRIx8, but with plain "x". > >I would use %#x... And I am not sure that passing 'int x; ptrace(.., &x, ...);' is right when reading/writing 1 byte. It works on x86 if you initialize x = 0, but it will will not work on sparc64, I think. Perhaps you need to pass 'uint8_t x; ptrace(, ..., &x, ...);' Then the printf format is right :-) christos
Re: CVS commit: src/tests/kernel
In article <20161125200105.5dbb4f...@cvs.netbsd.org>, Kamil Rytarowski wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: kamil >Date: Fri Nov 25 20:01:05 UTC 2016 > >Modified Files: > src/tests/kernel: t_ptrace_wait.c > >Log Message: >Fix several printf(3)-like functions usage with printing integers > >Integers as hex shall no be printed with PRIx8, but with plain "x". I would use %#x... christos
Re: CVS commit: src/sys/arch
On Fri, Nov 25, 2016 at 01:04:20PM +0100, Maxime Villard wrote: > AFAICT, emacs is known to be buggy on netbsd. Works well enough for my daily use on 7.0.2/amd64 and 7.99.42/amd64 (from about two weeks ago) and most releases in-between that I tried. So I don't think this can be said in general. Thomas
Re: CVS commit: src/sys/arch
Den 2016-11-25 kl. 13:04, skrev Maxime Villard: Le 24/11/2016 à 14:28, Masanobu SAITOH a écrit : Hi! On 2016/11/19 18:22, Maxime Villard wrote: Module Name:src Committed By:maxv Date:Sat Nov 19 09:22:04 UTC 2016 Modified Files: src/sys/arch/amd64/include: vmparam.h src/sys/arch/i386/include: vmparam.h Log Message: Put a one-page redzone between userland and the PTE space on amd64 and i386. The PTE space is a critical region that maps the page tree, and bugs have been found in both amd64 and i386 where the kernel would wrongly overflow userland data on this area. This kind of bug is terrible, since it allows userland to overwrite some entries of the page tree, which makes it easy to patch the kernel text and get ring0 privileges. To generate a diff of this commit: cvs rdiff -u -r1.37 -r1.38 src/sys/arch/amd64/include/vmparam.h cvs rdiff -u -r1.82 -r1.83 src/sys/arch/i386/include/vmparam.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. My emacs dumps core with change. What should we do? ? It probably means there is some kind of stupid assumption or hack in emacs. If you could send me the core, the binary and tell me which arch it is, that would be nice. AFAICT, emacs is known to be buggy on netbsd. Some years ago (quite some years) I did a test by changing malloc() to only use mmap() and replacing sbrk() in libc with a large mmap() (if ever called). Everything worked fine except emacs, which did some quite nasty things; IIRC it expected sbrk to get memory just above the data area or something similar. So emacs has always been a big cause of trouble :-/ -- Ragge
Re: CVS commit: src/sys/arch
Le 24/11/2016 à 14:28, Masanobu SAITOH a écrit : Hi! On 2016/11/19 18:22, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sat Nov 19 09:22:04 UTC 2016 Modified Files: src/sys/arch/amd64/include: vmparam.h src/sys/arch/i386/include: vmparam.h Log Message: Put a one-page redzone between userland and the PTE space on amd64 and i386. The PTE space is a critical region that maps the page tree, and bugs have been found in both amd64 and i386 where the kernel would wrongly overflow userland data on this area. This kind of bug is terrible, since it allows userland to overwrite some entries of the page tree, which makes it easy to patch the kernel text and get ring0 privileges. To generate a diff of this commit: cvs rdiff -u -r1.37 -r1.38 src/sys/arch/amd64/include/vmparam.h cvs rdiff -u -r1.82 -r1.83 src/sys/arch/i386/include/vmparam.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. My emacs dumps core with change. What should we do? ? It probably means there is some kind of stupid assumption or hack in emacs. If you could send me the core, the binary and tell me which arch it is, that would be nice. AFAICT, emacs is known to be buggy on netbsd.