Hello,
On Fri, Apr 28, 2023 at 09:02:35PM +, Klemens Nanni wrote:
> Same logic and argument as for the parent *S ioctl, might as well have
> committed them together:
> ---
> Remove net lock from DIOCGETQUEUES
>
> Both ticket and number of queues stem from the pf_queues_active list
Same logic and argument as for the parent *S ioctl, might as well have
committed them together:
---
Remove net lock from DIOCGETQUEUES
Both ticket and number of queues stem from the pf_queues_active list which
is effectively static to pf_ioctl.c and fully protected by the pf lock.
> On 28 Apr 2023, at 15:38, Alexander Bluhm wrote:
>
> On Fri, Apr 28, 2023 at 02:51:23PM +0300, Vitaliy Makkoveev wrote:
>>> On 28 Apr 2023, at 14:03, Alexander Bluhm wrote:
>>>
>>> That basically means we must never call one of the pool get or put
>>> functions with kernel lock. This may be
The diff below adapts the way vmctl & vmd handle opening kernel images
when a vmctl user provides the -b argument and a path. This moves the
file opening into vmctl, as the current user, and passes the fd to vmd.
With some tweaks, it checks for this user-provided boot fd and uses it
as an override
> On 28 Apr 2023, at 15:57, Vitaliy Makkoveev wrote:
>
> On Fri, Apr 28, 2023 at 02:13:15PM +0200, Alexander Bluhm wrote:
>> After running stress test successfully with this diff, next day
>> machine crashed while compiling a new kernel. It is unclear whether
>> it is related to the diff. Th
Add default: cases in some switches to detect if shit goes very badly
wrong. Right now these code paths are unreachable since the callers of
these functions never use a value that is not covered in the switch() but
gcc is not smart enough for that.
--
:wq Claudio
Index: parse.y
=
On Fri, Apr 28, 2023 at 02:13:15PM +0200, Alexander Bluhm wrote:
> After running stress test successfully with this diff, next day
> machine crashed while compiling a new kernel. It is unclear whether
> it is related to the diff. The softdep in ps is problably processing
> make output via ssh. L
On Fri, Apr 28, 2023 at 02:51:23PM +0300, Vitaliy Makkoveev wrote:
> > On 28 Apr 2023, at 14:03, Alexander Bluhm wrote:
> >
> > That basically means we must never call one of the pool get or put
> > functions with kernel lock. This may be the case currently. But
> > at this stage while we are p
Hello,
On Fri, Apr 28, 2023 at 11:18:18AM +, Klemens Nanni wrote:
> On Fri, Apr 28, 2023 at 12:55:37PM +0200, Alexandr Nedvedicky wrote:
> > Hello,
> > [ sending off-list ]
> >
> > up-to-date complete diff.
>
> Builds, boots and works faster:
>
> $ time jot -w 'pass proto tcp to port
On Wed, Apr 26, 2023 at 11:17:37PM +0300, Vitaliy Makkoveev wrote:
> Route timers and route labels protected by corresponding mutexes. `ifa'
> uses references counting for protection. No protection required for `rt'
> passed to rt_mpls_clear() because only current thread owns it.
>
> ok?
>
> Inde
> On 28 Apr 2023, at 14:03, Alexander Bluhm wrote:
>
> That basically means we must never call one of the pool get or put
> functions with kernel lock. This may be the case currently. But
> at this stage while we are pushing locks around the network code,
> I would like to keep it as it is.
>
That basically means we must never call one of the pool get or put
functions with kernel lock. This may be the case currently. But
at this stage while we are pushing locks around the network code,
I would like to keep it as it is.
Allowing net interrupts during route pool get mutex gains nearly
> > - *is_prime = 0;
> > + *is_prime = 1;
>
> Nit: you call this a pseudo-prime - which I agree with, but the variable you
> have added
> is "is_prime" - maybe call it "maybe-prime" or "pseudo-prime"
Yes. I agree. I did this for consistency with the existing code. I will
keep this as-is and
On Fri, Apr 28, 2023 at 10:23:15AM +0200, Theo Buehler wrote:
> The behavior of BPSW for numbers > 2^64 is not very well understood.
> While there is no known composite that passes the test, there are
> heuristics that indicate that there are likely many. Therefore it seems
> appropriate to harden
The behavior of BPSW for numbers > 2^64 is not very well understood.
While there is no known composite that passes the test, there are
heuristics that indicate that there are likely many. Therefore it seems
appropriate to harden the test. Having a settable number of MR rounds
before doing a version
15 matches
Mail list logo
