Hi,
I want to annotate the locking for the per-process interval timers.
In the process struct, the ITIMER_REAL itimerspec and the ps_itimer_to
timeout are protected by the kernel lock. These should be annotated
with "K", right?
Also in the process struct, the ITIMER_VIRTUAL and ITIMER_PROF
On Sat, 8 Aug 2020 16:01:59 +0300
Vitaliy Makkoveev wrote:
> On Sat, Aug 08, 2020 at 08:49:24PM +0900, YASUOKA Masahiko wrote:
>> On Fri, 7 Aug 2020 22:19:05 +0300
>> Vitaliy Makkoveev wrote:
>> > Some times ago we disabled in-kernel timeout for pppx(4) related
>> > pipex(4) sessions. We did
On Sun, Aug 09, 2020 at 03:16:50AM +0300, Vitaliy Makkoveev wrote:
> vether(4) is pretty dummy. Nothing denies it to be `IFXF_MPSAFE'.
OK kn
vether(4) is pretty dummy. Nothing denies it to be `IFXF_MPSAFE'.
Index: sys/net/if_vether.c
===
RCS file: /cvs/src/sys/net/if_vether.c,v
retrieving revision 1.33
diff -u -p -r1.33 if_vether.c
--- sys/net/if_vether.c 28 Jul 2020
Hello Laurie,
On Sat, 8 Aug 2020 21:56:08 +0100
Laurence Tratt wrote:
> On Sat, Aug 08, 2020 at 09:30:18PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> >> I like your patch, which is better than my original! My only very
> >> minor comment is whether we might want to document that it's
On Sat, Aug 08, 2020 at 09:30:18PM +0200, Marcus Glocker wrote:
Hello Marcus,
>> I like your patch, which is better than my original! My only very minor
>> comment is whether we might want to document that it's safe to put "0" in
>> a "V4L2_CID_AUTO" settings, since the lowest value one of those
On Sat, 08 Aug 2020 17:08:01 +0200
sxv...@firemail.cc wrote:
> So I recently installed OpenBSD on an EeePC 900HD with an Elantech v1
> touchpad (fw_version 0x20022).
> This specific fw version for some reason sends inverted parity bits
> on a cold boot, returning to normal after suspend & resume.
So I recently installed OpenBSD on an EeePC 900HD with an Elantech v1
touchpad (fw_version 0x20022).
This specific fw version for some reason sends inverted parity bits on a
cold boot, returning to normal after suspend & resume. That leads to a
failed parity check, dropped packets and ultimately
On Sat, 8 Aug 2020 15:13:47 +0100
Laurence Tratt wrote:
> On Sat, Aug 08, 2020 at 02:45:16PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> > For now how about adding the according auto control id to our
> > dev_ctrls structure? In a next step we could change
> >
Stuart Henderson writes:
> This means that the regular expression must match the full process
> string. Equivalent to providing an expression with ^ at the start and
> $ at the end of the.
I see, so the documentation is already correct, sorry, and thanks
for the explanation.
I did audit for "idle-timeout" option.
On Sat, Aug 08, 2020 at 08:49:24PM +0900, YASUOKA Masahiko wrote:
> On Fri, 7 Aug 2020 22:19:05 +0300
> Vitaliy Makkoveev wrote:
> > Some times ago we disabled in-kernel timeout for pppx(4) related
> > pipex(4) sessions. We did this for prevent use after
On Sat, Aug 08, 2020 at 02:45:16PM +0200, Marcus Glocker wrote:
Hello Marcus,
> For now how about adding the according auto control id to our dev_ctrls
> structure? In a next step we could change
> dev_set_ctrl_auto_white_balance() to become a generic function
> dev_set_ctrl_auto() available
Another update.
The whole "while ((m = ifq_dequeue(ifq)) != NULL)" wrapped by netlock as
it was made for pppx(4). This is to exclude per-packet lock/unlock in
output path.
Index: sys/net/if_pppx.c
===
RCS file:
On Sat, Aug 08, 2020 at 08:49:24PM +0900, YASUOKA Masahiko wrote:
> On Fri, 7 Aug 2020 22:19:05 +0300
> Vitaliy Makkoveev wrote:
> > Some times ago we disabled in-kernel timeout for pppx(4) related
> > pipex(4) sessions. We did this for prevent use after free issue caused
> > by pipex_timer [1].
Hello Laurie,
On Wed, 5 Aug 2020 21:42:18 +0100
Laurence Tratt wrote:
> Following Marcus's commit of video(1) changes, the attached patch
> crudely solves the "-c output is misleading for
> white_balance_temperature" because we conflate
> auto_white_balance_temperature and
On Sat, 08 Aug 2020 05:09:22 +0200, Klemens Nanni wrote:
> Alternatively, we can avoid duplicating the ioctl specific min/max
> values in strtonum(3) calls, just use the struct member type's *_MAX
> defines and rely on the kernel for appropiate boundary checks - this is
> what the code does now.
On Fri, 7 Aug 2020 22:19:05 +0300
Vitaliy Makkoveev wrote:
> Some times ago we disabled in-kernel timeout for pppx(4) related
> pipex(4) sessions. We did this for prevent use after free issue caused
> by pipex_timer [1]. By default "idle-timeout" is not set in
> npppd.conf(5) and I guess this is
On Sat, Aug 08 2020, Florian Obser wrote:
> On Fri, Aug 07, 2020 at 11:52:46PM +0200, Jeremie Courreges-Anglas wrote:
>> If you don't want to remove M_ACAST from sys/mbuf.h, can you please at
>> least change the comment? /* obsolete */ or something.
>
> Good point, I forgot to ask about what to
On Fri, Aug 07, 2020 at 11:52:46PM +0200, Jeremie Courreges-Anglas wrote:
> If you don't want to remove M_ACAST from sys/mbuf.h, can you please at
> least change the comment? /* obsolete */ or something.
Good point, I forgot to ask about what to do with the flag.
I think we can remove it, from
19 matches
Mail list logo
