Thanks for explanation. I missed the last commit to
sys/kern/uipc_socket.c
> On 10 Jul 2021, at 22:56, Martin Pieuchot wrote:
>
> On 10/07/21(Sat) 21:53, Vitaliy Makkoveev wrote:
>> Hi,
>>
>> In filt_solisten_common() you touches `so_qlen’ only. It’s not
>> related to buffer and not protected
This member is never set or used. Also I kept 'SENT_IP6' definition for
prevent the potential break of third party software. Is it ok to
redefine it to '0x0002'? At least openswan wants this [1].
1.
https://github.com/xelerance/Openswan/blob/master/include/openswan/ipsec_encap.h#L20
Index:
The diff below documents locks of 'ipsec_ids', 'ipsec_acquire' and
'ipsec_policy' structures.
I marked `ipa_pcb' as immutable, but we never set or access it and I
want to remove it with the next diff.
Index: sys/netinet/ip_ipsp.h
On 10/07/21(Sat) 21:53, Vitaliy Makkoveev wrote:
> Hi,
>
> In filt_solisten_common() you touches `so_qlen’ only. It’s not
> related to buffer and not protected by introduced `sb_mtx’ so
> the solock() replacement in filt_solisten*() is wrong.
>
> However, in filt_solisten_common() you only
On 2021/07/09 17:22, Stuart Henderson wrote:
> On 2021/07/09 16:33, Stuart Henderson wrote:
> > Notes so far:
> >
> > > +xmmc*)
> > > + dev=${U%.*}
> > > + func=${U#*.}
> > > + M xmmc$U c 101 $(($(($dev*16))+$func)) 660
> > > + ;;
> >
> > "sh MAKEDEV xmmc" isn't enough, it needs "sh MAKEDEV
Hi,
In filt_solisten_common() you touches `so_qlen’ only. It’s not
related to buffer and not protected by introduced `sb_mtx’ so
the solock() replacement in filt_solisten*() is wrong.
However, in filt_solisten_common() you only checks is
`so_qlen’ != 0 condition and such check could be performed
Friendly weekly ping.
Ashton Fagg writes:
> Original thread and discussion here:
>
> https://marc.info/?l=openbsd-tech=162000231914017=2
>
> I started this a couple of months ago but realized I never actually
> finished this and submitted the full diff. So here it is, for whole
> src tree.
>
>
On Sat, Jul 10, 2021 at 09:05:15AM -0600, Theo de Raadt wrote:
> Job Snijders wrote:
> > A use case could be running rpki-client more frequently than once an
> > hour:
Perhaps I choose a poor example, because of $work *I* run rpki-client
very often, but do not recommend others to follow that
One of the reasons for the drop of performances in the kqueue-based
poll/select is the fact that kqueue filters are called up to 3 times
per syscall and that they all spin on the NET_LOCK() for TCP/UDP
packets.
Diff below is a RFC for improving the situation.
socket kqueue filters mainly check
Theo de Raadt wrote:
> It will do 5 minutes of compute, 15 minutes of pause, and do it all
> again.
A recent rpki-client took longer:
# Processing time 989 seconds (199 seconds user, 155 seconds system)
So that would be 6 minutes cpu, over 16 minutes elapsed.
Followed by a 15 minute pause.
Job Snijders wrote:
> A use case could be running rpki-client more frequently than once an
> hour:
I want to say I think running rpki-client so often is misguided for
these rpki-processing-on-the-router configurations.
rpki-processing-on-the-router seems like more a technology demonstration
On Sat, Jul 10, 2021 at 02:07:53PM +, Job Snijders wrote:
> Hi all,
>
> The below patch adds a new kind of time specifier: an interval (in
> minutes). When used, cron(8) will schedule the next instance of a job
> after the previous job has completed and a full interval has passed.
>
> A
Hi all,
The below patch adds a new kind of time specifier: an interval (in
minutes). When used, cron(8) will schedule the next instance of a job
after the previous job has completed and a full interval has passed.
A crontab(5) configured as following:
$ crontab -l
@3 sleep 100
Will
On 19/01/20(Sun) 14:44, Martin Pieuchot wrote:
> On 18/01/20(Sat) 14:16, Martin Pieuchot wrote:
> > When futex(2) got imported it didn't return ECANCELED. This was changed
> > later with futex-based semaphores.
> >
> > This modification introduced a behavior change in pthread_cond_*wait(3).
> >
Hello Yuichiro, thanks for your work !
> On 2021/06/16 16:34, Yuichiro NAITO wrote:
> > When I compile a multi-threaded application with '-pg' option, I always get
> > no
> > results in gmon.out. With bad luck, my application gets SIGSEGV while
> > running.
> > Because the buffer that holds
15 matches
Mail list logo
