Re: rasops: implement scrollback for inteldrm and efifb

> Date: Mon, 16 Apr 2018 10:45:52 -0500 > From: joshua stein Does this do the right thing for early consoles? The initial efifb_bs[] doesn't have space for the scrollback. At the point where the scrollback code gets code, we've replaced that with a malloc'ed buffer? > Index:

Re: map stack problem with "homemade" stackguard

Ted Unangst wrote: > Sebastien Marie wrote: > > Assuming the check on protection is a bit too restrictive, and it is > > fine to have some chunks with PROT_NONE, I think we want something like: > > are readonly stacks meaningful? if so, we should fix that too now instead of

Re: map stack problem with "homemade" stackguard

Sebastien Marie wrote: > Assuming the check on protection is a bit too restrictive, and it is > fine to have some chunks with PROT_NONE, I think we want something like: are readonly stacks meaningful? if so, we should fix that too now instead of waiting. > > Index: uvm/uvm_map.c >

Re: FREF(9) in unp_internalize()

On Mon, 16 Apr 2018 10:19:40 +0200, Martin Pieuchot wrote: > Diff below does FREF(9) earlier instead of incrementing `f_count' by hand. > > The error path is also updated to call FRELE(9) accordingly. Wouldn't it be less error prone to simply add: if (fp != NULL)

map stack problem with "homemade" stackguard

Hi, I recently tried to run qemu, and it failed with SIGABRT and dmesg contains: map stack 0x86277000-0x86378000 of map 0xd5343afc failed: bad protection map stack for pid 43079 failed I initially think about missing MAP_STACK. And effectively, the flag is missing on the port (function

rasops: implement scrollback for inteldrm and efifb

Index: arch/amd64/amd64/efifb.c === RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v retrieving revision 1.12 diff -u -p -u -p -r1.12 efifb.c --- arch/amd64/amd64/efifb.c28 Oct 2017 01:48:03 - 1.12 +++

www/faq/upgrade63.html - add links for macppc

Index: upgrade63.html === RCS file: /cvs/www/faq/upgrade63.html,v retrieving revision 1.4 diff -u -p -r1.4 upgrade63.html --- upgrade63.html 3 Apr 2018 12:31:59 - 1.4 +++ upgrade63.html 16 Apr 2018 10:56:48 -

FREF(9) in unp_internalize()

Diff below does FREF(9) earlier instead of incrementing `f_count' by hand. The error path is also updated to call FRELE(9) accordingly. ok? Index: kern/uipc_usrreq.c === RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v retrieving

FREF() in sys_fcntl()

Diff below adds a FREF()/FRELE() dance after fd_getfile() in sys_fcntl(). This will help upcoing diff moving FREF() inside fd_getfile(). ok? Index: kern/kern_descrip.c === RCS file: /cvs/src/sys/kern/kern_descrip.c,v retrieving

[patch] man for vgafb(4) should have list of supported architectures

diff --git share/man/man4/vgafb.4 share/man/man4/vgafb.4 index d9ccfa469..6e9a9875c 100644 --- share/man/man4/vgafb.4 +++ share/man/man4/vgafb.4 @@ -31,6 +31,7 @@ .Nm vgafb .Nd VGA frame buffer .Sh SYNOPSIS +.Cd # sparc64, macppc .Cd "vgafb* at pci?" .Cd "wsdisplay* at vgafb?" .Sh

fdcopy() w/o memcpy()

Diff below is a rewrite/cleanup of fdcopy() to avoid using memcpy(). The problem with the memcpys is that they introduce a window where some 'struct file *' are duplicated without being refcounted. We should instead use the following common idiom: FREF(fp); fdp->fd_ofiles[i] =