> Date: Thu, 9 Jan 2020 14:01:32 +0100
> From: Alexander Bluhm
>
> On Thu, Jan 09, 2020 at 12:01:07PM +0100, Mark Kettenis wrote:
> > By splitting this out, the "retain the kernel lock" bit of the
> > comment doesn't make a lot of sense anymore...
>
> Then move the comment to the return where
On Thu, Jan 09, 2020 at 12:01:07PM +0100, Mark Kettenis wrote:
> By splitting this out, the "retain the kernel lock" bit of the
> comment doesn't make a lot of sense anymore...
Then move the comment to the return where we retain it.
bluhm
Index: arch/amd64/amd64/db_trace.c
> Date: Thu, 9 Jan 2020 10:42:55 +0100
> From: Alexander Bluhm
>
> On Thu, Dec 26, 2019 at 08:12:50PM +0100, Alexander Bluhm wrote:
> > Any more concerns or can this be commited?
>
> Any ok?
>
> > Index: arch/amd64/amd64/db_trace.c
> >
On Thu, Dec 26, 2019 at 08:12:50PM +0100, Alexander Bluhm wrote:
> Any more concerns or can this be commited?
Any ok?
> Index: arch/amd64/amd64/db_trace.c
> ===
> RCS file:
Any more concerns or can this be commited?
bluhm
Index: arch/amd64/amd64/db_trace.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/arch/amd64/amd64/db_trace.c,v
retrieving revision 1.47
diff -u -p -r1.47 db_trace.c
---
On Fri, Dec 20, 2019 at 11:15:09AM -0700, Theo de Raadt wrote:
> Alexander Bluhm wrote:
>
> > On Thu, Dec 19, 2019 at 06:25:06PM -0800, Philip Guenther wrote:
> > > For this part, should we reuse the 'faultstr' logic seen later to set the
> > > panic string and do something like, say...
> >
> >
Alexander Bluhm wrote:
> On Thu, Dec 19, 2019 at 06:25:06PM -0800, Philip Guenther wrote:
> > For this part, should we reuse the 'faultstr' logic seen later to set the
> > panic string and do something like, say...
>
> That makes sense. I need another workaround for the stack trace
> after
On Thu, Dec 19, 2019 at 06:25:06PM -0800, Philip Guenther wrote:
> For this part, should we reuse the 'faultstr' logic seen later to set the
> panic string and do something like, say...
That makes sense. I need another workaround for the stack trace
after calling the NULL function. This time I
On Fri, 20 Dec 2019, Alexander Bluhm wrote:
> Can we use the regular trap panic for SMEP and SMAP? pageflttrap()
> returns 0 to print a nice reason in kerntrap(). Especially if ddb is
> disabled, additional information is printed.
>
> attempt to access user address 0xe27539f1000 in supervisor
Hi,
Can we use the regular trap panic for SMEP and SMAP? pageflttrap()
returns 0 to print a nice reason in kerntrap(). Especially if ddb
is disabled, additional information is printed.
attempt to access user address 0xe27539f1000 in supervisor mode
fatal page fault in supervisor mode
trap type
10 matches
Mail list logo