Mark Kettenis wrote:
> > Isn't the vm_map_lock enough?
>
> Could be. The fast path is going to take that lock anyway. This
> would require a bit of surgery to uvm_map_extract() to make sure we
> don't take the vm_map_lock twice. Worth exploring I'd say.
I think the vm_map_lock can be dropped
> From: "Theo de Raadt"
> Date: Wed, 18 May 2022 10:48:01 -0600
>
> Mark Kettenis wrote:
>
> > > I guess there is another question -- should the ps_kbind_* variables
> > > be stored inside the uvmspace, rather than inside pr?
> >
> > I think there are arguments for both. But I don't think mov
> Date: Wed, 18 May 2022 21:43:29 +0200
> From: Alexander Bluhm
>
> On Tue, May 17, 2022 at 07:20:49PM +, Miod Vallat wrote:
> > As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> > POWER processors define exception addresses past EXC_LAST.
> >
> > The following diff
Joerg Sonnenberger wrote in
:
|Am Wed, May 18, 2022 at 12:49:21PM +0200 schrieb Steffen Nurpmeso:
|> What surprised me was that the Apple code requires more calls, and
|> that today divisions and multiplications still matter. I think it
|> was the Cyrix 166+ (or was it Athlon 1600+) where +,-
On Tue, May 17, 2022 at 07:20:49PM +, Miod Vallat wrote:
> As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> POWER processors define exception addresses past EXC_LAST.
>
> The following diff changes EXC_LAST to no longer be the last
> "traditional" (0x100 bytes long) e
On 18.5.2022. 17:31, Alexander Bluhm wrote:
> Hi,
>
> For parallel IP forwarding I had put kernel lock around arpresolve()
> as a quick workaround for crashes. Moving the kernel lock inside
> the function makes the hot path lock free. I see slight prerformace
> increase in my test and no lock co
Based upon the discussion of xterm a couple of days ago, I have been
working on a couple changes to reduce the privs of xterm in general,
by reducing the scope of the utmp egid by opening utmp early, improving
the unveil calls to match, and then tightening the pledge.
Additionally, some file-relat
Mark Kettenis wrote:
> > I guess there is another question -- should the ps_kbind_* variables
> > be stored inside the uvmspace, rather than inside pr?
>
> I think there are arguments for both. But I don't think moving it
> makes things easier.
Whatever proc sets the kbind configuration, wins.
> From: "Theo de Raadt"
> Date: Wed, 18 May 2022 10:09:38 -0600
>
> I guess there is another question -- should the ps_kbind_* variables
> be stored inside the uvmspace, rather than inside pr?
I think there are arguments for both. But I don't think moving it
makes things easier.
> From: "Theo de Raadt"
> Date: Wed, 18 May 2022 10:05:03 -0600
>
> David Gwynne wrote:
>
> > from yet another perspective, broad use of a common lock can end up
> > hurting in the long run because you may end up where everything is
> > serialised and you have to go back and do a ton of work ag
> On 18 May 2022, at 18:31, Alexander Bluhm wrote:
>
> Hi,
>
> For parallel IP forwarding I had put kernel lock around arpresolve()
> as a quick workaround for crashes. Moving the kernel lock inside
> the function makes the hot path lock free. I see slight prerformace
> increase in my test and
I guess there is another question -- should the ps_kbind_* variables
be stored inside the uvmspace, rather than inside pr?
David Gwynne wrote:
> from yet another perspective, broad use of a common lock can end up
> hurting in the long run because you may end up where everything is
> serialised and you have to go back and do a ton of work again anyway.
>
> > I think the theory is ps_kbind_addr is fixed to a shared ad
Hi,
For parallel IP forwarding I had put kernel lock around arpresolve()
as a quick workaround for crashes. Moving the kernel lock inside
the function makes the hot path lock free. I see slight prerformace
increase in my test and no lock contention in kstack flamegraph.
http://bluhm.genua.de/pe
ping...would like to get this in if possible so I can move onto fixing
some things in vmm.
Dave Voutila writes:
> tech@,
>
> Continuing my vmm/vmd bug hunt, the following diff adapts
> vcpu_readregs_vmx to optionally load the vmcs on the current cpu. This
> has gone unnoticed as the ioctl isn'
On Tue, May 17, 2022 at 10:44:54AM +1000, David Gwynne wrote:
> + cookie = SCARG(uap, proc_cookie);
> + if (pr->ps_kbind_addr == pc) {
> + membar_datadep_consumer();
> + if (pr->ps_kbind_cookie != cookie)
> + goto sigill;
> + } else {
You mus
Am Wed, May 18, 2022 at 12:49:21PM +0200 schrieb Steffen Nurpmeso:
> What surprised me was that the Apple code requires more calls, and
> that today divisions and multiplications still matter. I think it
> was the Cyrix 166+ (or was it Athlon 1600+) where +,-,<<,>> was
> one cycle, * was ten cycle
On Tue, May 17, 2022 at 10:14:18AM -0600, Theo de Raadt wrote:
> Martin Pieuchot wrote:
>
> > On 17/05/22(Tue) 10:44, David Gwynne wrote:
> > > this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall
> > > argument checks can be done without the kernel lock.
> > >
> > > care is take
Steffen Nurpmeso wrote in
<20220518104921.sr0ht%stef...@sdaoden.eu>:
...
|The web site that has been linked from the man from the country
|that has an even much worse Earth Country Overshoot Day than
|Germany and is almost en par with Australia or even USA (April
|3rd, pooh; never again a Saa
Philip Guenther wrote in
:
|On Tue, May 17, 2022 at 1:10 PM Steffen Nurpmeso \
|wrote:
|> Joerg Sonnenberger wrote in
|> :
|>|Am Fri, May 13, 2022 at 09:43:26AM -0500 schrieb Luke Small:
|>|> I made a couple new versions of a new kind of arc4random_uniform-like
|> ...
|>|If your main us
On Wed, May 18, 2022 at 05:08:02PM +1000, Damien Miller wrote:
> On Wed, 18 May 2022, Otto Moerbeek wrote:
>
> > instrumenting the code to count the number of arc4random calls I see thsi:
> >
> > openbsd; elapsed = 2.835819; calls = 12340949
> > bitmask; elapsed = 4.335576; calls = 17836216
> >
Hello,
On Tue, May 17, 2022 at 06:40:12PM +, Miod Vallat wrote:
> sys/net/pf.c r1.968 added a call to m_print() #ifdef DDB in a
> troublesome situation.
>
> Once the root cause of the problem was fixed, the DDB-specific code path
> was removed in r1.970, but the added includes were kept, alth
On Wed, 18 May 2022, Otto Moerbeek wrote:
> instrumenting the code to count the number of arc4random calls I see thsi:
>
> openbsd; elapsed = 2.835819; calls = 12340949
> bitmask; elapsed = 4.335576; calls = 17836216
> bitmask+reuse; elapsed = 3.710277; calls = 15245337
>
> (this is a different
23 matches
Mail list logo
