> Date: Thu, 20 Jul 2017 18:18:58 +0200
> From: Alexander Bluhm
>
> On Thu, Jul 20, 2017 at 02:03:10PM +0200, Mark Kettenis wrote:
> > If you can make the BUS_ADRERR -> BUS_OBJERR change (both here and in
> > the regress test), this is ok kettenis@
>
> This passes on amd64 and i386.
>
> ok?
ok
On Thu, Jul 20, 2017 at 02:03:10PM +0200, Mark Kettenis wrote:
> If you can make the BUS_ADRERR -> BUS_OBJERR change (both here and in
> the regress test), this is ok kettenis@
This passes on amd64 and i386.
ok?
bluhm
Index: sys/arch/amd64/amd64/trap.c
==
> Date: Mon, 17 Jul 2017 23:36:17 +0200
> From: Alexander Bluhm
>
> Hi,
>
> The tests regress/sys/kern/siginfo-fault accesses an mmap(2)ed file
> behind its end. Then it expects an SIGBUS, but gets an SIGSEGV.
As you found it, this was a bit controversial. Theo and I discussed
this and did so
> From: Theo de Raadt
> Date: Mon, 17 Jul 2017 16:06:05 -0600 (MDT)
>
> Sorry I disagree. SIGSEGV is the right answer. It was not mapped.
> That is segmentation.
Actually it is mapped in the sense that uvm has created mapping
entries for it. The mapping just isn't backed (because the backing
On Mon, Jul 17, 2017 at 04:06:05PM -0600, Theo de Raadt wrote:
> Finally, the diff here only touches 2 architectures.
Yes, I know. But why work on the others if the change is not
accepted anyway.
> Where is this coming from? Is it just to satisfy a regress test?
My concern is only the regress
The tests regress/sys/kern/siginfo-fault accesses an mmap(2)ed file
behind its end. Then it expects an SIGBUS, but gets an SIGSEGV.
Sorry I disagree. SIGSEGV is the right answer. It was not mapped.
That is segmentation.
A SIGBUS should be delivered when the mode of access is no
Hi,
The tests regress/sys/kern/siginfo-fault accesses an mmap(2)ed file
behind its end. Then it expects an SIGBUS, but gets an SIGSEGV.
Related commit message is:
Additionally, SIGBUS/BUS_ADRERR should be generated instead of SIGSEGV
for access to file mapped pages that exceed the end of