On Tue, Jan 11, 2022 at 4:09 PM Daniel Dickman wrote:
> On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack wrote:
> >
> > i386
> >
>
>
>
> with this diff I was able to install includes, rebuild ld.so and
> ctfconv. I've not managed to build a release yet.
...
Umm, with what diff? There was no diff
The patch over in ports that was blocking this has been in for a while:
https://github.com/openbsd/ports/commit/bd756bd601bfcfa9ee7fc265d6c90c3536e51727
Although I haven't committed any of the port fixes to tell the ones that
don't pick it up automatically to install into the vendor lib, the
I am saying I want better study on all architectures, so that I don't
hit problems (first) in the snapshots cluster.
Theo de Raadt wrote:
> I am blocking this.
>
> I don't see any messaging which suggests this has been run on all
> architectures. It might still hit some MD code which is
I am blocking this.
I don't see any messaging which suggests this has been run on all
architectures. It might still hit some MD code which is wrong.
Klemens Nanni wrote:
> On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > > Now this is clearly a "slow" path. I don't think
On Wed, Jan 12, 2022 at 02:32:31AM +0300, Vitaliy Makkoveev wrote:
> Does it make sense to document that kernel lock protects
> `ps_wxcounter’? We have such [K] in other structure definitions.
>
> + u_int64_t ps_wxcounter; /* [K] number of W^X violations */
Yes, that would be in
On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack wrote:
>
> i386
>
with this diff I was able to install includes, rebuild ld.so and
ctfconv. I've not managed to build a release yet.
Unfortunately polyml still fails to build, but I it did get quite a
bit further. most of the build log shown below.
Does it make sense to document that kernel lock protects
`ps_wxcounter’? We have such [K] in other structure definitions.
+ u_int64_t ps_wxcounter; /* [K] number of W^X violations */
The rest of diff looks good to me.
> On 12 Jan 2022, at 02:13, Klemens Nanni wrote:
>
> On Tue,
On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > Now this is clearly a "slow" path. I don't think there is any reason
> > not to put all the code in that if (uvw_wxabort) block under the
> > kernel lock. For now I think making access to ps_wxcounter atomic is
> > just too fine
Hello Stefan,
I tried to port the firmware detection and config values
from iwlwifi.
On iwx_cfg_trans_params and iwx_cfg structs I ported only
the fields iwx_attach was setting based on the iwx_device.
With best regards,
Iraklis Karagkiozoglou
diff --git sys/dev/pci/if_iwx.c
> Now this is clearly a "slow" path. I don't think there is any reason
> not to put all the code in that if (uvw_wxabort) block under the
> kernel lock. For now I think making access to ps_wxcounter atomic is
> just too fine grained.
Right. Lock the whole block.
On Tue, 11 Jan 2022 13:10:49 +0100, Theo Buehler wrote:
> This is completely mechanical, but a second set of eyes won't hurt.
>
> It won't build on -current since the API will only be exposed in the
> next bump.
Conversion looks correct. OK millert@
- todd
This is completely mechanical, but a second set of eyes won't hurt.
It won't build on -current since the API will only be exposed in the
next bump.
Index: auxil.c
===
RCS file: /cvs/src/lib/libkeynote/auxil.c,v
retrieving revision
On Tue, Jan 11, 2022 at 11:36:19AM +, Job Snijders wrote:
> On Mon, Jan 10, 2022 at 03:30:23PM +0100, Claudio Jeker wrote:
> > + if (RB_INSERT(repo_tree, , rp) != NULL)
> > + errx(1, "repository already added to repo tree %d, %s", id,
> > path);
> > + warnx("repository added to
> Date: Tue, 11 Jan 2022 17:01:45 +0800
> From: Kevin Lo
>
> ok?
Right. That's a leftover from when we were still cross-compiling.
ok kettenis@
> Index: sys/arch/riscv64/conf/Makefile.riscv64
> ===
> RCS file:
On Mon, Jan 10, 2022 at 03:30:23PM +0100, Claudio Jeker wrote:
> + if (RB_INSERT(repo_tree, , rp) != NULL)
> + errx(1, "repository already added to repo tree %d, %s", id,
> path);
> + warnx("repository added to repo tree %d, %s", id, path);
The above warnx() probably needs to
On Mon, Jan 10, 2022 at 03:30:23PM +0100, Claudio Jeker wrote:
> This diff changes the way the parser figures out which file to work on.
> Until now the parent process sent a full path to the parser but that does
> not work well with the idea of splitting the repo up into validated, rsync
> and
> Date: Tue, 11 Jan 2022 08:15:13 +
> From: Klemens Nanni
>
> On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay
On 11/01/22 09:57 +0100, Claudio Jeker wrote:
> On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> > On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > > The uvm_wxabort path within
ok?
Index: sys/arch/riscv64/conf/Makefile.riscv64
===
RCS file: /cvs/src/sys/arch/riscv64/conf/Makefile.riscv64,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile.riscv64
--- sys/arch/riscv64/conf/Makefile.riscv64 17
On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay
On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay
On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
>
> Right, I did not pay enough attention to W^X handling.
New diff, either alone or on top of the
22 matches
Mail list logo
