Re: CVS commit: src/sys/arch

[Tom Ivar Helbekkmo]

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

[David Holland]

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

[David Holland]

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

[Christos Zoulas]

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

[Kamil Rytarowski]

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(.., , ...);' 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(, ..., , ...);' 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

[Christos Zoulas]

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

[Thomas Klausner]

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

[Anders Magnusson]

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

[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.