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