Hi,
asr_run.3 is explaining that ar_rrsetinfo must be freed only for the
blocking function, but I think it must be freed regardless of the
function blocking type.
ok?
Index: lib/libc/asr/asr_run.3
===
RCS file:
Hello,
On Wed, 26 Apr 2023 16:32:28 +0900
Yuichiro NAITO wrote:
> These 2 revisions of 'attr_val' and 'attr_thr' are different on this
> disk.
> The comment says that it's wrong vendor implementation but I can see
> 'smartctl' shows the attributes as follows. NetBSD's atactl doesn't
> see these
Hi,
carpdemote is increased/decreased when the link state of the carpdev
is down/up. This behavior is not related to net.inet.carp.preempt since
"carpdemote" is introduced.
But the faq still says the "net.inet.carp.preempt" variable enables it.
I'd like to commit the diff.
ok or any comment
Hi,
On Wed, 1 Feb 2023 21:32:29 +0300
Vitaliy Makkoveev wrote:
> On Wed, Feb 01, 2023 at 09:00:13PM +0900, YASUOKA Masahiko wrote:
>> ...
>>
>> But I think we should keep the part since it is needed when adding a
>> tunneling protocol which is not supported
I'm sorry for sending 2 mails. First one was a draft. Please read second one.
Hi
On Tue, 31 Jan 2023 11:30:43 +0300
Vitaliy Makkoveev wrote:
> On Tue, Jan 31, 2023 at 01:40:19PM +0900, YASUOKA Masahiko wrote:
>> Hi,
>>
>> On Sun, 29 Jan 2023 14:35:05 +0300
>> Vitaliy Makkoveev wrote:
>> > While switchind pppx(4) and pppac(4) from s
On Tue, 31 Jan 2023 11:30:43 +0300
Vitaliy Makkoveev wrote:
> On Tue, Jan 31, 2023 at 01:40:19PM +0900, YASUOKA Masahiko wrote:
>> Hi,
>>
>> On Sun, 29 Jan 2023 14:35:05 +0300
>> Vitaliy Makkoveev wrote:
>> > While switchind pppx(4) and pppac(4) from selwake
Hi,
On Sun, 29 Jan 2023 14:35:05 +0300
Vitaliy Makkoveev wrote:
> While switchind pppx(4) and pppac(4) from selwakeup() to KNOTE(9), I
> found npppd(8) doesn't create pppx interface with "pipex no" in
> npppd.conf, but successfully connects the client. So packets don't flow.
> However, the
Hi,
On Wed, 04 Jan 2023 21:52:35 +0100
Mark Kettenis wrote:
> Dear Sergii and others,
>
> I've committed the change that passes the ESRT from the bootloader to
> the kernel. So now it is time to add the interfaces to the kernel to
> read it. And add the interfaces to manipulate EFI variables.
ok yasuoka
On Fri, 06 Jan 2023 15:14:05 +0900 (JST)
Masato Asou wrote:
> I have updated my patch.
>
> From: YASUOKA Masahiko
> Date: Tue, 27 Dec 2022 11:58:34 +0900 (JST)
>
>> After diff, it doesn't use PAGE_SIZE any more. And VMware software
>> limit see
Hi,
Sorry for separating emails.
On Tue, 27 Dec 2022 11:58:34 +0900 (JST)
YASUOKA Masahiko wrote:
>> @@ -1115,12 +1116,19 @@ xs_kvop(void *xsc, int op, char *key, char *value,
>> size_t valuelen)
>> }
>> /* FALLTHROUGH */
>> case X
Hi,
On Mon, 26 Dec 2022 13:37:45 +0900 (JST)
Masato Asou wrote:
> My new patch is not returned value length from ioctl() system call
> when read the KEY's value.
>
> The hostctl command allocate 4k bytes memory for store the value. Then
> read the value by ioctl() system call. If ioctl()
Yes, my previous commit was wrong. Calling vm_rpc_close() was missing.
Thank you for finding.
ok yasuoka
On Tue, 13 Dec 2022 19:26:05 +0900 (JST)
Masato Asou wrote:
> From: Masato Asou
> Date: Tue, 13 Dec 2022 18:26:22 +0900 (JST)
>
> Delete #define VMT_DEBUG
> ok?
> --
> ASOU Masato
>
>>
This is obvious. M_ZERO must be for 3rd argument.
ok?
Index: sys/dev/pv/pvbus.c
===
RCS file: /cvs/src/sys/dev/pv/pvbus.c,v
retrieving revision 1.25
diff -u -p -r1.25 pvbus.c
--- sys/dev/pv/pvbus.c 25 Aug 2022 17:38:16 -
It doesn't seem to have a problem. Sorry for my delay.
ok yasuoka
On Wed, 9 Nov 2022 13:24:21 +0300
Vitaliy Makkoveev wrote:
> ping...
>
> On Tue, Nov 01, 2022 at 03:16:02PM +0300, Vitaliy Makkoveev wrote:
>> Push netlock down to pppx_add_session(). The 'pppx_if' structure has
>> the
On Sat, 19 Nov 2022 14:41:18 +0900 (JST)
YASUOKA Masahiko wrote:
> On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
> YASUOKA Masahiko wrote:
>> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
>> Masato Asou wrote:
>>> From: "Theo de Raadt"
>>> Date: Tue, 04 Oct
On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
YASUOKA Masahiko wrote:
> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
> Masato Asou wrote:
>> From: "Theo de Raadt"
>> Date: Tue, 04 Oct 2022 21:58:13 -0600
>>> Userland may not ask the kernel to allocate such a huge
Hello,
On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
Masato Asou wrote:
> From: "Theo de Raadt"
> Date: Tue, 04 Oct 2022 21:58:13 -0600
>> Userland may not ask the kernel to allocate such a huge object. The
>> kernel address space is quite small. First off, huge allocations will
>> fail.
>>
>>
Hello,
My colleague hit the following kernel panic when he is doing "psctl
-ss" repeatedly by a script during a performance test.
uvm_fault(0xfd811b869110, 0x10, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at pf_state_export+0x42: movq0x10(%rax),%rcx
TIDPID
ok yasuoka
On Fri, 2 Sep 2022 14:44:29 +0200
Alexander Bluhm wrote:
> + now = READ_ONCE(tcp_now);
> +
> /*
>* Determine length of data that should be transmitted,
>* and flags that will be used.
> @@ -228,7 +231,7 @@ tcp_output(struct tcpcb *tp)
>* to send, then
Hi,
On Fri, 2 Sep 2022 17:40:13 +0200
Alexander Bluhm wrote:
> On Fri, Sep 02, 2022 at 03:04:34PM +0200, YASUOKA Masahiko wrote:
>> The diff is to fix a problem in a complex setup.
>>
>> Normal setup of divert-reply for TCP connection:
>>
>>
Hi,
The diff is to fix a problem in a complex setup.
Normal setup of divert-reply for TCP connection:
client --- relayd --- server
- transparently forward TCP connections
- divert-reply is configured the outbound connection to the server
- so that the PF state is removed when the PCB is
Hello,
For HTTP request body, if neither "Content-Encoding: chunked" nor
"Content-Length" is specified, it should mean body length is 0.
In RFC 9112 Section 6.3, 7.:
| 7. If this is a request message and none of the above are true, then
| the message body length is zero (no message body
Hi,
Tested.
ok yasuoka
On Tue, 30 Aug 2022 15:41:29 +0200
Alexander Bluhm wrote:
> Hi,
>
> I looks like syzkaller has found a missing input validation in pipex.
>
> https://syzkaller.appspot.com/bug?id=c7ac769bd7ee15549b8a2be188bcee07d98a5357
>
> As I have no pipex setup, can anyone test
On Tue, 30 Aug 2022 14:09:40 +0200
Theo Buehler wrote:
> On Tue, Aug 30, 2022 at 01:01:47PM +0200, YASUOKA Masahiko wrote:
>> On Tue, 30 Aug 2022 11:56:53 +0200
>> Claudio Jeker wrote:
>> > On Tue, Aug 30, 2022 at 11:18:01AM +0200, YASUOKA Masahiko wrote:
>> >
On Tue, 30 Aug 2022 11:56:53 +0200
Claudio Jeker wrote:
> On Tue, Aug 30, 2022 at 11:18:01AM +0200, YASUOKA Masahiko wrote:
>> @@ -423,11 +423,13 @@ uu_decode(void)
>> }
>> }
>>
>> +#define ROUNDDOWN(x,y) (((x)/(y)) * (y))
>> +
>> static
b64decode(8) fails if a long line is given.
% wc test
1 11370 test
%
% ./b64decode -r test > /dev/null
b64decode: test: /dev/stdout: error decoding base64 input stream
%
uudecode.c
426 static int
427 base64_decode(void)
428 {
429 int n;
430
ok yasuoka
On Mon, 18 Jul 2022 13:50:37 +0300
Vitaliy Makkoveev wrote:
> pipex(4) doesn't rely on netlock anymore.
>
> Index: sys/net/if_pppx.c
> ===
> RCS file: /cvs/src/sys/net/if_pppx.c,v
> retrieving revision 1.119
> diff -u -p
ok yasuoka
On Mon, 18 Jul 2022 12:31:47 +0300
Vitaliy Makkoveev wrote:
> We don't use "static" keyword for functions declaration to allow ddb(4)
> debug. Also, many "Static" functions are called by pppx(4) layer outside
> pipex(4) layer.
>
> This is the mostly mechanic diff, except the
Hello,
Let me ask "ok",
The diff fixes the problem as follows:
Configure wg0 without wgrtable
# ifconfig wg0 create wgport 7111 wgkey `openssl rand -base64 32` up
# ifconfig wg0
wg0: flags=80c3 mtu 1420
index 6 priority 0 llprio 3
Hello,
On Thu, 14 Jul 2022 14:09:52 +0900 (JST)
Masato Asou wrote:
> The TUNNEL in the man ifconfig(8) is described as follows:
>
> TUNNEL
>
> tunneldomain rtable
> ^^here
> Use routing table rtable instead of the default table. The
>
ok yasuoka
On Mon, 11 Jul 2022 01:11:22 +0300
Vitaliy Makkoveev wrote:
> Long time ago pipex(4) session can't be deleted until both pipex(4)
> input and output queues become empty. Dead sessions were linked to the
> stack and the `ip_forward' flag was used to prevent packets forwarding.
>
ok yasuoka
On Sat, 9 Jul 2022 18:04:04 +0300
Vitaliy Makkoveev wrote:
> On Sat, Jul 09, 2022 at 10:46:56PM +0900, YASUOKA Masahiko wrote:
>> Hello,
>>
>> On Sat, 9 Jul 2022 01:43:41 +0300
>> Vitaliy Makkoveev wrote:
>> > On Sat, Jul 09, 2022 at 12:08
Hello,
On Sat, 9 Jul 2022 01:43:41 +0300
Vitaliy Makkoveev wrote:
> On Sat, Jul 09, 2022 at 12:08:49AM +0300, Vitaliy Makkoveev wrote:
>> Thanks for pointing.
>>
>> > On 8 Jul 2022, at 23:13, Alexander Bluhm wrote:
>> >
>> > On Fri, Jul 08, 2022 at 05:42:23PM +0300, Vitaliy Makkoveev wrote:
Hello,
On Fri, 8 Jul 2022 00:53:16 +0300
Vitaliy Makkoveev wrote:
> The `pipex_list_mtx' mutex(9) protects global pipex(4) lists so it need
> to be taken while we perform this foreach loop.
>
> The all sessions loop was reworked to make possible to drop the lock
> within. This is required
On Thu, 07 Jul 2022 14:02:35 +0900 (JST)
YASUOKA Masahiko wrote:
> Hello Scott,
>
> With the patch, my machine on ESXi it doesn't show any extra message.
>
> *Without* the patch, the machine shows
>
> % grep 'TSC.*skew' dmesg.current-tsc-debug
> cpu1: disabling user
Hello Scott,
With the patch, my machine on ESXi it doesn't show any extra message.
*Without* the patch, the machine shows
% grep 'TSC.*skew' dmesg.current-tsc-debug
cpu1: disabling user TSC (skew=-2603)
cpu2: disabling user TSC (skew=-2959)
cpu3: disabling user TSC (skew=-3784)
%
and
ok yasuoka
On Thu, 30 Jun 2022 12:26:55 +0300
Vitaliy Makkoveev wrote:
> yasuoka@ remonded me, long time ago pipex(4) sessions can't be deleted
> until both input and output queues become empty:
>
> pipex_timer(void *ignored_arg)
> {
> /* ... */
> switch (session->state) {
>
On Thu, 16 Jun 2022 19:37:57 +0200 (CEST)
Mark Kettenis wrote:
>> Date: Thu, 16 Jun 2022 23:49:05 +0900 (JST)
>> From: YASUOKA Masahiko
(snip)
>> @@ -444,6 +445,30 @@ efi_video_init(void)
>> int i, mode80x25, m
On Thu, 16 Jun 2022 15:52:41 +0300
Nick Henderson wrote:
> Any updates on this patch? Would love to see it included in the next release.
Yes.
I'll commit this this weekend even if I don't get no ok.
ok?
Index: sys/arch/amd64/stand/efiboot/efiboot.c
Hi,
On Sun, 27 Mar 2022 18:25:18 +0900 (JST)
YASUOKA Masahiko wrote:
> On Wed, 9 Mar 2022 15:28:44 +0900
> Yuichiro NAITO wrote:
>> I see 'Address already in use' message,
>> when I change wgrtable for a running wg interface.
>> It doesn't make sense to me.
>
Hello,
The below diff originally posted by Alexei K. on bugs@:
Garbled screen when booting with UEFI
https://marc.info/?l=openbsd-bugs=165087969227708=2
The same problem had been reported periodically and we have asked to
use "machine gop" to workaround it. But the diff from Alexei seems
fails with
EADDRINUSE when 7111/udp on rtable 0 is used.
> On 3/28/22 15:59, YASUOKA Masahiko wrote:
>> On Mon, 28 Mar 2022 15:20:02 +0900
>> Yuichiro NAITO wrote:
>>> Thanks for the explanation.
>>> I understand how your patch works.
>>>
>>> I
thing to do, since the command is to bind the same
port, protocol, and domain of prevous.
The code seems to do such the skip already, but it lacks consideration
for rtable_l2(rtable) != rtable case.
> On 3/28/22 14:01, YASUOKA Masahiko wrote:
>> Hi,
>> On Mon, 28 Mar 2022 12:12:39 +0900
>
Hi,
On Mon, 28 Mar 2022 12:12:39 +0900
Yuichiro NAITO wrote:
> On 3/27/22 18:25, YASUOKA Masahiko wrote:
>> Hi,
>> On Wed, 9 Mar 2022 15:28:44 +0900
>> Yuichiro NAITO wrote:
>>> I see 'Address already in use' message,
>>> when I change wgrtable for a ru
Hi,
On Wed, 9 Mar 2022 15:28:44 +0900
Yuichiro NAITO wrote:
> I see 'Address already in use' message,
> when I change wgrtable for a running wg interface.
> It doesn't make sense to me.
>
> It can be reproduced by the following command sequence.
>
> ```
> # route -T1 add default `cat
Hi,
On Sat, 25 Dec 2021 21:50:47 +0300
Vitaliy Makkoveev wrote:
> On Fri, Dec 24, 2021 at 12:50:23PM +0100, Alexander Bluhm wrote:
>> On Fri, Dec 24, 2021 at 04:16:28PM +0900, YASUOKA Masahiko wrote:
>> > > - npppd l2pt ipsecflowinfo is not MP safe
>> >
>
Hello,
On Fri, 24 Dec 2021 00:55:04 +0100
Alexander Bluhm wrote:
> On Fri, Dec 03, 2021 at 08:35:45PM +0100, Alexander Bluhm wrote:
>> Note that IPsec still has the workaround to disable multiple queues.
>
> I think we can remove the ipsec_in_use workaround now. The IPsec
> path is protected
Hi,
On Mon, 20 Dec 2021 13:20:46 +0100
Alexander Bluhm wrote:
> On Tue, Dec 14, 2021 at 06:25:20PM +0900, YASUOKA Masahiko wrote:
>> Yes, if there is another better idea, it will be welcome.
>> For this moment, the diff is the best idea for me.
>
> Sorry, no better idea.
Hi,
On Tue, 14 Dec 2021 01:20:49 +0100
Alexander Bluhm wrote:
> I don't know much about l2tp, pipex or npppd. So I cannot say if
> the new logic is correct. But I guess you have tested that.
Yes, I've tested some L2TP/IPsec cases already.
> The tdb mutex and ref counting looks correct.
>
>>
On Wed, 1 Dec 2021 00:27:06 +0100
Alexander Bluhm wrote:
> On Tue, Nov 30, 2021 at 05:53:34PM +0300, Vitaliy Makkoveev wrote:
>> Hi,
>>
>> This question is mostly for bluhm@. Should the gettdbbyflow() grab the
>> extra reference on returned `tdbp' like other other gettdb*() do? I'm
>> pointing
Hi,
Let me update the diff. Previous has a problem in ipsp_spd_lookup()
which uses "rn" without initialization.
On Sat, 20 Nov 2021 21:44:20 +0900 (JST)
YASUOKA Masahiko wrote:
> On Wed, 12 May 2021 19:11:09 +0900 (JST)
> YASUOKA Masahiko wrote:
>> Radek repo
Hi,
On Wed, 12 May 2021 19:11:09 +0900 (JST)
YASUOKA Masahiko wrote:
> Radek reported a problem to misc@ that multiple Windows clients behind
> a NAT cannot use a L2TP/IPsec server simultaneously.
>
> https://marc.info/?t=16099681611=1=2
>
> There is two problems.
Hi,
On Tue, 2 Nov 2021 07:03:43 +
Jason McIntyre wrote:
> On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
>> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
>>
>> sbin/ipsecctl/ike.c:
>> 201
ok?
Clarify that ANY can be used for several parameters of IPsec transform.
Index: sbin/isakmpd/isakmpd.conf.5
===
RCS file: /cvs/src/sbin/isakmpd/isakmpd.conf.5,v
retrieving revision 1.135
diff -u -p -r1.135 isakmpd.conf.5
---
I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
sbin/ipsecctl/ike.c:
201 case ENCXF_AES:
202 enc_alg = "AES";
203 key_length = "128,128:256";
204
Hi,
# drop ccing misc@
The diff seems ok for me.
ok to commit it in?
On Tue, 19 Oct 2021 10:42:04 +0900
Yuichiro NAITO wrote:
> Following patch changes pkg_add to return a error code,
> if a package name is wrong.
>
> diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
>
On Wed, 12 May 2021 19:11:09 +0900 (JST)
YASUOKA Masahiko wrote:
> Radek reported a problem to misc@ that multiple Windows clients behind
> a NAT cannot use a L2TP/IPsec server simultaneously.
>
> https://marc.info/?t=16099681611=1=2
>
> There is two problems. First i
On Wed, 12 May 2021 19:15:29 +0300
Vitaliy Makkoveev wrote:
>> On 12 May 2021, at 18:42, YASUOKA Masahiko wrote:
>> On Wed, 12 May 2021 17:26:51 +0300
>> Vitaliy Makkoveev wrote:
>>> On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote:
>>&g
On Wed, 12 May 2021 17:26:51 +0300
Vitaliy Makkoveev wrote:
> On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote:
>> Radek reported a problem to misc@ that multiple Windows clients behind a NAT
>> cannot use a L2TP/IPsec server simultaneously.
>>
&g
Hi,
Radek reported a problem to misc@ that multiple Windows clients
behind a NAT cannot use a L2TP/IPsec server simultaneously.
https://marc.info/?t=16099681611=1=2
There is two problems. First is pipex(4) doesn't pass the proper
ipsecflowinfo to ip_output(). Second is the IPsec
:21:40 +0200
Giovanni Bechis wrote:
> On Mon, Apr 05, 2021 at 07:14:49PM +0900, YASUOKA Masahiko wrote:
>> Hi,
>>
>> > Another issue that I see is that people have not reported, at least
> [...]
>> > publicly, that this runs fine on their normal OpenBSD machines.
On Mon, 5 Apr 2021 14:24:03 +0200 (CEST)
Mark Kettenis wrote:
>> Date: Mon, 05 Apr 2021 19:14:49 +0900 (JST)
>> From: YASUOKA Masahiko
>>
>> Hi,
>>
>> On Mon, 5 Apr 2021 10:43:00 +0300
>> Paul Irofti wrote:
>> > On 05.04.2021 06:13, Scott
Hi,
On Mon, 5 Apr 2021 10:43:00 +0300
Paul Irofti wrote:
> On 05.04.2021 06:13, Scott Cheloha wrote:
>> On Mon, Mar 29, 2021 at 02:00:01PM +0900, YASUOKA Masahiko wrote:
>>> On Thu, 25 Mar 2021 19:41:35 +0100 (CET)
>>> Mark Kettenis wrote:
>>>>> From: S
On Thu, 25 Mar 2021 19:41:35 +0100 (CET)
Mark Kettenis wrote:
>> From: Scott Cheloha
>> Date: Thu, 25 Mar 2021 13:18:04 -0500
>> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
>> Which diff did you apply? Yasuoka provided two diffs.
>>
On Fri, 26 Mar 2021 12:12:44 +0100 (CET)
Mark Kettenis wrote:
>> Date: Fri, 26 Mar 2021 19:43:23 +0900 (JST)
>> From: YASUOKA Masahiko
>>
>> Hi,
>>
>> On Fri, 26 Mar 2021 09:30:43 +0100
>> Jan Klemkow wrote:
>> > If you want to boot O
Hi,
On Fri, 26 Mar 2021 09:30:43 +0100
Jan Klemkow wrote:
> If you want to boot OpenBSD on an HP EliteBook 830 G7/G8, the bootloader
> will hang while loading the kernel. Because, the UEFI loads the
> bootloader on the same place in memory, where the bootloader will copy
> the kernel. We are
900, 900, 900, 900, 0, 900, 900, 900 you pick 0 which could lead
> to some problems, right? Or am I missing something?"
>
> So could people give the minimum skew approach a spin on real machines
> to see if there are any issues popping up?
>
> All the best,
> Paul
>
>
Hi,
I hit a problem which is caused by going back of monotonic time. It
happens on hosts on VMware ESXi.
I wrote the program which repeats the problem.
% cc -o monotime monotime.c -lpthread
% ./monotime
194964 Starting
562210 Starting
483046 Starting
148865 Starting
148865 Back
On Wed, 10 Mar 2021 13:15:58 +0100 (CET)
Mark Kettenis wrote:
>> On Wed, 10 Mar 2021 20:35:41 +0900 (JST)
>> YASUOKA Masahiko wrote:
>> > efiboot cannot load the kernel properly on some machines if booted
>> > from CD-ROM. In that case boot fa
versed..
On Wed, 10 Mar 2021 20:35:41 +0900 (JST)
YASUOKA Masahiko wrote:
> efiboot cannot load the kernel properly on some machines if booted
> from CD-ROM. In that case boot fails with a message like follow:
>
>booting cd0a:. [359648read symbols: Unknown error: code 255
>
Hi,
efiboot cannot load the kernel properly on some machines if booted
from CD-ROM. In that case boot fails with a message like follow:
booting cd0a:. [359648read symbols: Unknown error: code 255
As far as Asou and my test, this happens on hosts on VMware ESXi 6.7,
7.0 and asou's
Hi,
Let me update "diff #2".
On Fri, 26 Feb 2021 13:42:32 +0900 (JST)
YASUOKA Masahiko wrote:
> My vaio repeatedly crashed by "Data modified on freelist"(*1) or other
> memory corruptions. After my long time debug, I found the route cause
> is a handling
Hi,
My vaio repeatedly crashed by "Data modified on freelist"(*1) or other
memory corruptions. After my long time debug, I found the route cause
is a handling of references of LocalX, like the following:
If ((SMRW (0x0B, 0x16, 0x21, RefOf (Local0)) == Zero))
In the called
ok yasuoka
Thanks,
On Tue, 9 Feb 2021 12:06:08 +0300
Vitaliy Makkoveev wrote:
> `sc_dead' is used to prevent pppac_ioctl() be called on dying pppac(4)
> interface. But now if_detach() makes dying `ifp' inaccessible and waits
> for references which are in-use. This logic is not required anymore.
Yes,
ok yasuoka
On Fri, 29 Jan 2021 14:32:39 +0300
Vitaliy Makkoveev wrote:
> Since OpenBSD 6.7 npppd(8) can't work over tun(4) anymore. I propose to
> remove dummy TUNSIFMODE ioctl(2) call.
>
> Index: sys/net/if_pppx.c
> ===
>
Hi,
On Thu, 14 Jan 2021 08:54:36 +0900
Yuichiro NAITO wrote:
> Does anybody please review my code?
>
> Yasuoka-san is my coleague of my work.
> So, he is interested in this topic. That’s why I CCed this mail.
> I don’t mean he is an reviewer.
>
>> 2021/01/12 11:27、Yuichiro NAITO のメール:
>> I
Yes,
ok yasuoka
On Wed, 30 Dec 2020 03:02:55 +0300
Vitaliy Makkoveev wrote:
> This time pipex(4) related ioctl(2) calls PIPEX{S,G}MODE are pretty
> dummy and were kept for backward compatibility reasons. The diff below
> removes them.
>
> ok?
>
> Index: share/man/man4/pipex.4
>
the condition was reversed.
ok?
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.702
diff -u -p -r1.702 parse.y
--- parse.y 17 Sep 2020 10:09:43 - 1.702
+++ parse.y 17 Sep 2020
Hi,
I just committed yours.
Thanks,
On Wed, 16 Sep 2020 16:07:40 +0200
Klemens Nanni wrote:
> On Wed, Sep 16, 2020 at 07:49:19PM +0900, YASUOKA Masahiko wrote:
>> New diff is using -1 for ENOENT.
>>
>> Also domainid == 0 is a valid domain id, but previous diff c
Hi,
On Wed, 16 Sep 2020 12:04:55 +0200
Klemens Nanni wrote:
> Using the function verb would reads a bit clearer/more intuitive,
> i.e.
Yes, "if (!rtable_exists($2))" seems better.
>> @@ -5887,17 +5897,37 @@ rdomain_exists(u_int rdomain)
>>
>> len = sizeof(info);
>> if (sysctl(mib,
Hi,
So, it seems we need to more code and test for pf(4) part.
Let me continue this separetely.
On Mon, 14 Sep 2020 11:07:53 +0200
Klemens Nanni wrote:
> On Mon, Sep 14, 2020 at 02:09:27PM +0900, YASUOKA Masahiko wrote:
>> Make pfctl check if the rtable really exists when parsing t
Hi,
On Tue, 15 Sep 2020 02:31:24 +0200
Klemens Nanni wrote:
> On Tue, Sep 15, 2020 at 12:30:35AM +0200, Klemens Nanni wrote:
>> Actually, that should just work regardless of whether the rounting
>> domain exists at ruleset creation time; just like it is the case with
>> interface names/groups
Hi,
When pf rule with a "on rdomain n" with nonexisting rdomain n causes
/etc/pf.conf:XXX: rdomain n does not exist
error. But with a "rtable n" with nonexisting rtable n will cause
pfctl: DIOCADDRULE: Device busy
error. It is hard to find the cause by this error message.
Anyone?
This is a tiny change but makes httpd(8) more correct.
The diff is not so complicated.
On Thu, 03 Sep 2020 13:09:49 +0900 (JST)
YASUOKA Masahiko wrote:
> Let me update the diff. Previous doesn't have an error handling when
> strdup() failed.
>
> On Thu, 03 Sep 2020 13:02:5
Let me update the diff. Previous doesn't have an error handling when
strdup() failed.
On Thu, 03 Sep 2020 13:02:51 +0900 (JST)
YASUOKA Masahiko wrote:
> The diff makes REQUEST_URI in FastCGI become the original request
> URI. Currently it is an url which is url decoded and canonicalize
The diff makes REQUEST_URI in FastCGI become the original request
URI. Currently it is an url which is url decoded and canonicalized.
I could not find a specification of REQUEST_URI, but I suppose it is
the URI in HTTP request. Apache httpd and nginx is using the original
URI for it.
ok?
Use
On Mon, 24 Aug 2020 20:07:48 +0300
Vitaliy Makkoveev wrote:
> I pointed some comments inline.
Thanks,
>> +case PIPEXASESSION:
>> +{
>> +struct pipex_session_req *req =
>> +(struct pipex_session_req *)data;
>> +if ((error = pipex_init_session(,
Hi,
Thank you for your comments.
On Mon, 17 Aug 2020 00:15:08 +0300
Vitaliy Makkoveev wrote:
> I like your idea to kill `pipex_iface_context'. I had trying to keep it
> by myself and this was wrong way. Could you rework your diff to be
> against the recent sources?
I'm sorry the diff was for
Let me update the diff. A bug found by the test.
diff --git a/sys/net/if_pppx.c b/sys/net/if_pppx.c
index 62b85bc34af..6d3de6973bd 100644
--- a/sys/net/if_pppx.c
+++ b/sys/net/if_pppx.c
@@ -163,7 +163,6 @@ struct pppx_if {
struct ifnetpxi_if;
struct pppx_dev
This diff makes pipex become more common for pppac and pppx.
- Delete "pipex_iface_context".
It had been created when pppx doesn't exist. This creates some
confusions. For example session->pipex_iface is the device context
when pppac(4) but it's not when pppx(4).
623 Static int
On Wed, 12 Aug 2020 12:26:22 +0300
Vitaliy Makkoveev wrote:
> We destroy pppx(4) related sessions while we performing PIPEXDSESSION
> command. But with pppac(4) we set session's state to
> PIPEX_STATE_CLOSE_WAIT2 and we wait garbage collector to do destruction.
pppac's PIPEXDSESSION set the
Hi,
On Wed, 12 Aug 2020 12:38:39 +0300
Vitaliy Makkoveev wrote:
> We don't need to mark pppx(4) sessions because there is no special cases
> for them. We just need to kill pppx(4) related "pr_timeout_sec != 0"
> checks and call pipex_get_closed() by pppx_get_closed().
How do you implement that
On Tue, 11 Aug 2020 23:06:45 +0300
Vitaliy Makkoveev wrote:
> We removed `pipex{in,out}q'. So now we can destroy pppac(4) session just
> like we do in pppx(4) case. Also there is no reason to allow
> pipex_timer() to destroy sessions - userland will do this by
> PIPEXDSESSION. This permit us to
my diff is to make pppx(4) have the same "idle-timeout"
functionality. I strongly think pppx(4) must have the same
functionalities of pppac(4) because I don't see any reason to have
any difference between pppx(4) and pppac(4).
Your pseudo code is suggesting another thing. You would like to
Hi,
On Mon, 10 Aug 2020 16:30:27 +0300
Vitaliy Makkoveev wrote:
> On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote:
>> On Sun, 9 Aug 2020 20:03:50 +0300
>> Vitaliy Makkoveev wrote:
>> > On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev
Hi,
Thank you for your review.
On Sun, 9 Aug 2020 20:03:50 +0300
Vitaliy Makkoveev wrote:
> On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote:
>> You propose to unlink pppx(4) related session which reached timeout. I'm
>> ok with this direction. But I see no reason to rework
This diff makes pipex "idle-timeout" work with pppx(4).
ok?
Index: sys/net/if_pppx.c
===
RCS file: /disk/cvs/openbsd/src/sys/net/if_pppx.c,v
retrieving revision 1.98
diff -u -p -r1.98 if_pppx.c
--- sys/net/if_pppx.c 28 Jul 2020
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
>&g
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
1 - 100 of 317 matches
Mail list logo
