Re: netlink socket does not accept SOCK_DGRAM

[Alexander V. Chernikov]

> On 16 Jan 2023, at 15:13, Alexander V. Chernikov  wrote:
> 
> 
> 
>> On 15 Jan 2023, at 13:09, Alexander V. Chernikov  wrote:
>> 
>>> 
>>> On 15 Jan 2023, at 02:26, User Ngor  wrote:
>>> 
>>> man 4 rtnetlink says:
>>> 
>>>   int socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
>>> 
>>> 
>>> 
>>> The following snippet fails
>>> 
>>>  int fd = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
>>>  if (fd < 0) {
>>>  perror("Failed to open netlink socket");
>>>  return -1;
>>>  }
>>>  printf("all good\n");
>>>  close(fd);
>>>  return 0;
>>> 
>>> I get: Failed to open netlink socket: Protocol wrong type for socket
>>> 
>>> 
>>> but if I change
>>> int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
>>> 
>>> I get "all good"
>>> 
>>> Am I doing something wrong or is this a bug?
>> It’s a bug. The manage should state SOCK_RAW, but both options should be 
>> supported, which is not the case ATM.
>> I’ll fix it in a couple of days.
> Raised https://reviews.freebsd.org/D38075 with a fix.
Committed as 0079d177ab69.
>> Meanwhile it may be worth looking into snl(3) which abstracts issues like 
>> this one.
>>> 
>>> 
>>> 
>>> $ uname -a FreeBSD zen.hq 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
>>> main-n259967-11b5b9e8a520: Sat Jan  7 16:39:30 UTC 2023 
>>> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>>> 
>>> $ kldstat | grep netl
>>> 391 0x839fc00014af8 netlink.ko
>>> 
>>> 
>>> -- 
>>> Ihor Antonov

Re: netlink socket does not accept SOCK_DGRAM

[Alexander V. Chernikov]

> On 16 Jan 2023, at 18:00, User Ngor  wrote:
> 
> 
> On 1/15/23 12:43, Alexander V. Chernikov wrote:
>> The snl(3) manpage itself includes some examples, including the complete 
>> working program in the end
>> 
> man snl
> No manual entry for snl
> 
> 
> Looks like not connected to the buildworld..
Ups. Always keep forgetting that. Should be fixed now.
Btw, it can be seen directly by running man /share/man/man3/snl.3

> -- 
> 
> Ihor Antonov
> 
> 

Re: netlink socket does not accept SOCK_DGRAM

[Alexander V. Chernikov]

> On 15 Jan 2023, at 13:09, Alexander V. Chernikov  wrote:
> 
>> 
>> On 15 Jan 2023, at 02:26, User Ngor  wrote:
>> 
>> man 4 rtnetlink says:
>> 
>>int socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
>> 
>> 
>> 
>> The following snippet fails
>> 
>>   int fd = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
>>   if (fd < 0) {
>>   perror("Failed to open netlink socket");
>>   return -1;
>>   }
>>   printf("all good\n");
>>   close(fd);
>>   return 0;
>> 
>> I get: Failed to open netlink socket: Protocol wrong type for socket
>> 
>> 
>> but if I change
>> int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
>> 
>> I get "all good"
>> 
>> Am I doing something wrong or is this a bug?
> It’s a bug. The manage should state SOCK_RAW, but both options should be 
> supported, which is not the case ATM.
> I’ll fix it in a couple of days.
Raised https://reviews.freebsd.org/D38075 with a fix.
> Meanwhile it may be worth looking into snl(3) which abstracts issues like 
> this one.
>> 
>> 
>> 
>> $ uname -a FreeBSD zen.hq 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
>> main-n259967-11b5b9e8a520: Sat Jan  7 16:39:30 UTC 2023 
>> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>> 
>> $ kldstat | grep netl
>> 391 0x839fc00014af8 netlink.ko
>> 
>> 
>> -- 
>> Ihor Antonov

Re: close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP

[Alexander V. Chernikov]

> On 15 Jan 2023, at 13:50, Alexander V. Chernikov  wrote:
> 
> 
> 
>> On 14 Jan 2023, at 20:46, Guy Yur  wrote:
>> 
>> Hi,
>> 
>> close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP.
>> I am testing 14.0-CURRENT (main branch) built today.
>> On 13.1-RELEASE-p5 close returns 0.
>> 
>> The problem looks to be related to 36b10ac2cd18a535cac20ccf51e3fc6c408671e8.
>> 
>> The commit removed rts_disconnect and initialization for .pru_disconnect.
>> After the change, .pr_disconnect is not initialized in rtsock.c
>> so now it is set to pr_disconnect_notsupp.
>> This causes flow of:
>>  soclose()
>>  sodisconnect()
>>  so->so_proto->pr_disconnect()
>>  pr_disconnect_notsupp()
>>  return EOPNOTSUPP
>> On 13.1 it called the raw socket disconnect which returned ENOTCONN.
>> 
>> Noticed in dhcpcd error: if_route (ADD): Operation not supported
>> dhcpcd with privsep called write() which failed with EEXIST (expected since
>> route already existed) and then close() which overwrote the errno to
>> EOPNOTSUPP and the parent process received back EOPNOTSUPP instead of EEXIST.
> Thank you for the report!
> I’ve created https://reviews.freebsd.org/D38059 to address the issue.
Landed in 42904794b804.
>> 
>> 
>> 
>> Simple test program (prints error on head, no error on 13.1):
>> 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> int main(int argc, char *argv[])
>> {
>>  int s = socket(PF_ROUTE, SOCK_RAW, 0);
>>  if (s == -1)
>>err(1, "socket()");
>>  if (close(s) == -1)
>>err(1, "close()");
>>  return 0;
>> }
>> 
>> 
>> Regards,
>> Guy Yur

Re: netlink socket does not accept SOCK_DGRAM

[Alexander V . Chernikov]

The snl(3) manpage itself includes some examples, including the complete working program in the end/Alexander15.01.2023, 16:55, "User Ngor" : It’s a bug. The manage should state SOCK_RAW, but both options should be supported, which is not the case ATM. I’ll fix it in a couple of days. Meanwhile it may be worth looking into snl(3) which abstracts issues like this one.Thanks, I will take a look. Is there an example somewhere of snl usage? (my C skills are not very strong)

Re: close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP

[Alexander V. Chernikov]

> On 14 Jan 2023, at 20:46, Guy Yur  wrote:
> 
> Hi,
> 
> close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP.
> I am testing 14.0-CURRENT (main branch) built today.
> On 13.1-RELEASE-p5 close returns 0.
> 
> The problem looks to be related to 36b10ac2cd18a535cac20ccf51e3fc6c408671e8.
> 
> The commit removed rts_disconnect and initialization for .pru_disconnect.
> After the change, .pr_disconnect is not initialized in rtsock.c
> so now it is set to pr_disconnect_notsupp.
> This causes flow of:
>   soclose()
>   sodisconnect()
>   so->so_proto->pr_disconnect()
>   pr_disconnect_notsupp()
>   return EOPNOTSUPP
> On 13.1 it called the raw socket disconnect which returned ENOTCONN.
> 
> Noticed in dhcpcd error: if_route (ADD): Operation not supported
> dhcpcd with privsep called write() which failed with EEXIST (expected since
> route already existed) and then close() which overwrote the errno to
> EOPNOTSUPP and the parent process received back EOPNOTSUPP instead of EEXIST.
Thank you for the report!
I’ve created https://reviews.freebsd.org/D38059 to address the issue.
> 
> 
> 
> Simple test program (prints error on head, no error on 13.1):
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
>   int s = socket(PF_ROUTE, SOCK_RAW, 0);
>   if (s == -1)
> err(1, "socket()");
>   if (close(s) == -1)
> err(1, "close()");
>   return 0;
> }
> 
> 
> Regards,
> Guy Yur

Re: netlink socket does not accept SOCK_DGRAM

[Alexander V. Chernikov]

> On 15 Jan 2023, at 02:26, User Ngor  wrote:
> 
> man 4 rtnetlink says:
> 
> int socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
> 
> 
> 
> The following snippet fails
> 
>int fd = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
>if (fd < 0) {
>perror("Failed to open netlink socket");
>return -1;
>}
>printf("all good\n");
>close(fd);
>return 0;
> 
> I get: Failed to open netlink socket: Protocol wrong type for socket
> 
> 
> but if I change
> int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
> 
> I get "all good"
> 
> Am I doing something wrong or is this a bug?
It’s a bug. The manage should state SOCK_RAW, but both options should be 
supported, which is not the case ATM.
I’ll fix it in a couple of days.
Meanwhile it may be worth looking into snl(3) which abstracts issues like this 
one.
> 
> 
> 
> $ uname -a FreeBSD zen.hq 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
> main-n259967-11b5b9e8a520: Sat Jan  7 16:39:30 UTC 2023 
> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> 
> $ kldstat | grep netl
> 391 0x839fc00014af8 netlink.ko
> 
> 
> -- 
> Ihor Antonov
> 
> 

Re: mention AF_NETLINK in man 2 socket

[Alexander V. Chernikov]

Committed in b0286ee504c6.

> On 12 Jan 2023, at 17:23, Alexander V. Chernikov  wrote:
> 
> Ack, thanks for pointing that out.
> I’ll update the manage when I have time.
> 
> /Alexander
> 
>> On 12 Jan 2023, at 03:18, User Ngor  wrote:
>> 
>> Looks like there are no references to {PF|AF}_NETLINK in the socket manpage.
>> 
>> -- 
>> Ihor Antonov
>> 
>> 
> 
> 

Re: mention AF_NETLINK in man 2 socket

[Alexander V. Chernikov]

Ack, thanks for pointing that out.
I’ll update the manage when I have time.

/Alexander

> On 12 Jan 2023, at 03:18, User Ngor  wrote:
> 
> Looks like there are no references to {PF|AF}_NETLINK in the socket manpage.
> 
> -- 
> Ihor Antonov
> 
> 

Re: Build Break?

[Alexander V . Chernikov]

02.10.2022, 17:18, "Larry Rosenman" :On 10/02/2022 8:12 am, Alexander V. Chernikov wrote: On 1 Oct 2022, at 22:57, Larry Rosenman <l...@lerctr.org> wrote:  --- all_subdir_nfscommon --- Building  /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o --- all_subdir_netgraph --- --- all_subdir_netgraph/deflate --- Building  /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc --- all_subdir_netgraph/device --- Building  /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386 --- all_subdir_netgraph/echo --- ===> netgraph/echo (all) --- all_subdir_netlink --- --- netlink_io.o --- /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration  of function 'mtx_lock' is invalid in C99  [-Werror,-Wimplicit-function-declaration]NLP_LOCK(nlp); That’s interesting. netlink_io.c includes sys/mutex.h which defines  mutex_lock() / mutex_unlock().  Could you share the diff between GENERIC and LER-MINIMAL? I sent the diff in another message, but here is LER-MINIMAL.Thank you!So it’s non-networking config. I’ll make netlink build  conditional on INET || INET6 today/tomorrow.-- Larry Rosenman http://www.lerctr.org/~lerPhone: +1 214-642-9640 E-Mail: l...@lerctr.orgUS Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: Build Break?

[Alexander V. Chernikov]

> On 1 Oct 2022, at 22:57, Larry Rosenman  wrote:
> 
> --- all_subdir_nfscommon ---
> Building 
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
> --- all_subdir_netgraph ---
> --- all_subdir_netgraph/deflate ---
> Building 
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
> --- all_subdir_netgraph/device ---
> Building 
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386
> --- all_subdir_netgraph/echo ---
> ===> netgraph/echo (all)
> --- all_subdir_netlink ---
> --- netlink_io.o ---
> /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration of 
> function 'mtx_lock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>NLP_LOCK(nlp);
That’s interesting. netlink_io.c includes sys/mutex.h which defines 
mutex_lock() / mutex_unlock().
 Could you share the diff between GENERIC and LER-MINIMAL?

>^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 'NLP_LOCK'
> #define NLP_LOCK(_nlp)  mtx_lock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:159:2: error: implicit declaration of 
> function 'mtx_unlock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>NLP_UNLOCK(nlp);
>^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
> 'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)mtx_unlock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:159:2: note: did you mean 'mtx_lock'?
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
> 'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)mtx_unlock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:146:2: note: 'mtx_lock' declared here
>NLP_LOCK(nlp);
>^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 'NLP_LOCK'
> #define NLP_LOCK(_nlp)  mtx_lock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:177:2: error: implicit declaration of 
> function 'mtx_lock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>SOCKBUF_LOCK(sb);
>^
> /usr/src/sys/sys/sockbuf.h:187:28: note: expanded from macro 'SOCKBUF_LOCK'
> #define SOCKBUF_LOCK(_sb)   mtx_lock(SOCKBUF_MTX(_sb))
>^
> /usr/src/sys/netlink/netlink_io.c:189:2: error: implicit declaration of 
> function 'mtx_unlock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>SOCKBUF_UNLOCK(sb);
>^
> /usr/src/sys/sys/sockbuf.h:189:30: note: expanded from macro 'SOCKBUF_UNLOCK'
> #define SOCKBUF_UNLOCK(_sb) mtx_unlock(SOCKBUF_MTX(_sb))
>^
> /usr/src/sys/netlink/netlink_io.c:202:2: error: implicit declaration of 
> function 'mtx_lock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>NLP_LOCK(nlp);
>^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 'NLP_LOCK'
> #define NLP_LOCK(_nlp)  mtx_lock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:207:3: error: implicit declaration of 
> function 'mtx_unlock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>NLP_UNLOCK(nlp);
>^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
> 'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)mtx_unlock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:225:3: error: implicit declaration of 
> function 'mtx_unlock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>SOCKBUF_UNLOCK(sb);
>^
> /usr/src/sys/sys/sockbuf.h:189:30: note: expanded from macro 'SOCKBUF_UNLOCK'
> #define SOCKBUF_UNLOCK(_sb) mtx_unlock(SOCKBUF_MTX(_sb))
>^
> /usr/src/sys/netlink/netlink_io.c:232:2: error: implicit declaration of 
> function 'mtx_unlock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>NLP_UNLOCK(nlp);
>^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
> 'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)mtx_unlock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:281:2: error: implicit declaration of 
> function 'mtx_lock' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>NLP_LOCK(nlp);
>^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 'NLP_LOCK'
> #define NLP_LOCK(_nlp)  mtx_lock(&((_nlp)->nl_lock))
>^
> /usr/src/sys/netlink/netlink_io.c:299:2: error: implicit declaration of 
> function 'mtx_unlock' is invalid in C99 
> 

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Alexander V. Chernikov]

> On 12 Sep 2021, at 11:51, Yuri Tcherkasov  wrote:
> 
>  ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports

Looks pretty close to https://reviews.freebsd.org/D23450 


I guess rebuilding the ipfw(8) binary should help.

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Alexander V. Chernikov]

> On 12 Sep 2021, at 06:52, Yuri Tcherkasov  wrote:
> 
> Hi
> 
> I'm binary upgrade FreeBSD from 10.2 to 13.0
> 
> After upgrate all workin well, but I need add one more routing table. So add 
> to
> GENERIC kernel
You can add 'net.fibs=2' in the loader.conf, there is no need to recompile the 
kernel.
You can also set in runtime via sysctl.
> 
> options ROUTETABLES=2
> 
> and recompile it.
> After normaly recompile can't configure ipfw nat with error
> 
> ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument
Could you share the particular command failing?

> 
> Returning original kernel instataling with upgrade resolve problem with nat 
> but multiple route I can't use.
> 
> Anybody can help me?
> 
> Thanx!
> 
> -- 
> --
> Yuri Tcherkasov
> E-Mail:  t...@uats.od.ua
> 
> 

Re: ifa leak on VNET teardown

[Alexander V. Chernikov]

> On 6 Mar 2021, at 09:26, Kristof Provost  wrote:
> 
> On 13 Feb 2021, at 21:58, Alexander V. Chernikov wrote:
>> It turns out we're leaking some ifas for loopback interfaces on VNET 
>> teardown:
>> 
> There’s a recent bug about this as well: 253998.
> The problem’s been around for a long time though. The pf tests trigger it 
> from time to time, although it doesn’t appear to be 100% consistent, so my 
> current feeling is that it may be racy.
> 
> I see ‘in6_purgeaddr: err=65, destination address delete failed’ when we do 
> leak, and I’ve also been able to confirm this is about the ::1 IPv6 loopback 
> address.

The fun part is that it turns out that these side effects are caused by 3 
different issues. The unifying factor is that all of them are loopback-specific.

AF_LINK ifa leak exists simply because there is no domain teardown procedure 
associated with AF_LINK, so we leak it for every non-vmoved interface during 
VNET shutdown.
PR 253998 is caused by the fact that rt_flushifroutes_af() is not able to 
delete RTF_PINNED routes (e.g. all interface routes). D29116 addresses that.
in6_purgeaddr error is caused by the corner case with loopback interfaces. 
D29121 addresses that. 

> 
> Best regards,
> Kristof

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ifa leak on VNET teardown

[Alexander V . Chernikov]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic rtentry / hashdestroy /in6_purgeaddr related?

[Alexander V . Chernikov]

21.01.2021, 18:10, "Alexander Leidinger" :
> Hi,
>
> -current at d7fc908cffa as of 2021-01-20-154143.
>
> I've seen several failures to free an rtentry on the console shortly
> before the panic. May or may not be related..._
Sorry for the breakage, should be fixed by 130aebbab0d3.

> ---snip---
> in6_purgeaddr: err=65, destination address delete failed
> Freed UMA keg (rtentry) was not empty (1 items). Lost 1 pages of memory.
> j_gallery_hif: link state changed to DOWN
> j_gallery_jif: link state changed to DOWN
>   samba.leidinger.net
> in6_purgeaddr: err=65, destination address delete failed
> Freed UMA keg (rtentry) was not empty (1 items). Lost 1 pages of memory.
> j_samba_hif: link state changed to DOWN
> j_samba_jif: link state changed to DOWN
> ---snip---
>
> This is on shutdown with 22 vnet jails:
> ---snip---
> Unread portion of the kernel message buffer:
> <6>in6_purgeaddr: err=65, destination address delete failed
> panic: hashdestroy: hashtbl 0xf80be7108800 not empty (malloc type ifaddr)
> cpuid = 14
> time = 1611248408
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0064b55b10
> vpanic() at vpanic+0x181/frame 0xfe0064b55b60
> panic() at panic+0x43/frame 0xfe0064b55bc0
> hashdestroy() at hashdestroy+0x54/frame 0xfe0064b55bd0
> vnet_destroy() at vnet_destroy+0x146/frame 0xfe0064b55c00
> prison_deref() at prison_deref+0x28e/frame 0xfe0064b55c40
> taskqueue_run_locked() at taskqueue_run_locked+0xb0/frame 0xfe0064b55cc0
> taskqueue_thread_loop() at taskqueue_thread_loop+0x97/frame 0xfe0064b55cf0
> fork_exit() at fork_exit+0x85/frame 0xfe0064b55d30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0064b55d30
> ---snip---
>
> Full crashinfo output available on request. Kerneldump is also
> available if you want I peek into it at some specific place.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: jail fib no longer works after net.add_addr_allfibs=0

[Alexander V . Chernikov]

11.01.2021, 14:59, "qroxana" :
> On Mon, 11 Jan 2021 13:25:51 +0000, Alexander V. Chernikov  
> wrote:
>
>>  Could you please consider clarifying the end result you want to achieve?
>>  If you could include some more details of how it was configured earlier, it 
>> would help as well.
>
> Thank you for the quick reply.
> Let's say there are two jails defined in /etc/jail.conf
>
> jail1 {
> ...
> ip4.addr = 192.168.1.101;
> exec.fib = 1;
> ...
> }
>
> jail2 {
> ...
> ip4.addr = 192.168.1.102;
> exec.fib = 2;
> ...
> }
Got it, thank you for the clarification.
>
> All the traffic in jail1 goes to the default router defined in fib 1,
> and traffic in jail2 goes to the default router defined in fib 2.
Could you describe interface setup as well?
In particular, I'm looking into details of setting up # of fibs, interface 
configuration and default route setup.

> And I could only see 127.0.0.1 after starting the jails:
>
> # setfib -F 2 netstat -rn
> Routing tables (fib: 2)
>
> Internet:
> Destination Gateway Flags Netif Expire
> 127.0.0.1 link#2 UHS lo0
>
> Internet6:
> Destination Gateway Flags
> Netif Expire
> ... ...
>
> please let me know if you need more info. Thanks.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: jail fib no longer works after net.add_addr_allfibs=0

[Alexander V . Chernikov]

11.01.2021, 12:39, "qroxana" :
> I have exec.fib = 2 in /etc/jail.conf, but it seems the address of
> the jail is not inserted into this fib. What's the best practice
> for using jail with fib when net.add_addr_allfibs=0?
Could you please consider clarifying the end result you want to achieve?
If you could include some more details of how it was configured earlier, it 
would help as well.

Thank you!
>
> Thanks.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type

[Alexander V . Chernikov]

15.12.2020, 15:17, "Oleg V. Nauman" :
>  Hello,
>
> kernel: link_elf_obj: symbol fib6_lookup_rt undefined
> kernel: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type
>
> It seems ipf.ko unconditionally perform IPV6 lookup even on system built with
> WITHOUT_INET6=YES defined
Should be fixed in r368651.
> FreeBSD 13.0-CURRENT r368604 amd64
>
> Thank you
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: adding existing ipv6 network route returns ENOMEM instead of EEXIST if loopback route also exists

[Alexander V . Chernikov]

21.11.2020, 22:48, "Guy Yur" :
> Hi,
>
> When adding a route with a netmask, add_route() in route_ctl.c
> adds the route with destination address masked.
> If the add failed (for example, the route exists) it calls
> lookup_prefix() with the original unmasked destination.
Thank you for the report! Indeed, there is a problem w.r.t non-masked dst 
handling.
I'll look into that in the end of this week.

>
> In a scenario where a loopback route was added followed
> by the network route being added, if the network route
> is added again and the network route destination is the
> same as the loopback route, lookup_prefix() will match on
> the loopback route, not finding the network route and
> add_route() will return ENOMEM instead of EEXIST.
> Adding the route with just the network part returns EEXIST as expected.
>
> Example:
> # route -6 add -host fd53:: -prefixlen 128 ::1
> # route -6 add -net fd53:: -prefixlen 64 ::1
> # route -6 add -net fd53:: -prefixlen 64 ::1
> route: writing to routing socket: Cannot allocate memory
> add net fd53::: gateway ::1 fib 0: Cannot allocate memory
> # route -6 add -net fd53:: -prefixlen 64 ::1
> add net fd53::: gateway ::1 fib 0: route already in table
>
> I was testing https://reviews.freebsd.org/D15406
> changes applied to r367863.
> The changes call rtinit to add prefix route when
> interface address is added/updated and uses the
> interface address as the destination.
> rtinit returned ENOMEM instead of EEXIST
> causing dhcpcd to printCannot allocate memory.
>
> route commands above showing the problem were run
> in r367863 without D15406 changesas well.
>
> Thanks,
> Guy Yur
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD CI Weekly Report 2020-04-12

[Alexander V . Chernikov]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: net.add_addr_allfibs=1 behaviour deprecation

[Alexander V . Chernikov]

18.07.2020, 14:22, "Alexander V. Chernikov" :
> Dear FreeBSD users,
>
> I would like to make net.add_addr_allfibs=0 as the default system behaviour 
> and remove net.add_addr_allfibs.
> To do so, I would like to collect use cases with net.add_addr_allfibs=1 and 
> multiple fibs, to ensure they can still be supported after removal.
>
> Background:
>
> Multi-fib support was added in r17 [1], 12 years ago. Addition of 
> interface addresses to all fibs was a feature from day 1.
> The `net.add_addr_allfibs` sysctl  was added in r180840 [2], 12 years ago.
>
> Problem:
> The goal of the fib support is to provide multiple independent routing 
> tables, isolated from each other.
> `net.add_addr_allfibs` default tries to shift gears in the opposite 
> direction, unconditionally inserting all addresses to all of the fibs.
>
> It complicates the logic, kernel code and makes control plane performance 
> decrease with the number of fibs.
> It make impossible to use the same prefixes in multiple fibs, which may be 
> desired given shortage of IPv4 address space.
>
> I do understand that there are some cases where such behaviour is desired.
> For example, it can be used to achieve VRF route leaking or binding on 
> address from different fibs.
> I would like to collect such cases to consider supporting them in a different 
> way.
>
> The goal is to make net.add_addr_allfibs=0 default behaviour and remove 
> net.add_addr_allfibs.
> It will simplify kernel fib-related code and allow bringing more fib-related 
> features. It will also improve fib scaling.
No objections has been received.
Next steps:
* Switch net.add_addr_allfibs to 0 ( https://reviews.freebsd.org/D26076 )
* Provide an ability to use nexthops from different fibs
* Remove net.add_addr_allfibs
> Timeline:
> Aug 1: summarising feedback and the usecases, decision on proceeding further
> Aug 20 (tentative):  patches for supported usecases
> Sep 15 (tentative):  net.add_addr_allfibs removal.
>
> [1]: [base Contents of 
> /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17=markup)
> [2]: [base Diff of 
> /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839=180840;)
>
> /Alexander
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

net.add_addr_allfibs=1 behaviour deprecation

[Alexander V . Chernikov]

Dear FreeBSD users,

I would like to make net.add_addr_allfibs=0 as the default system behaviour and 
remove net.add_addr_allfibs.
To do so, I would like to collect use cases with net.add_addr_allfibs=1 and 
multiple fibs, to ensure they can still be supported after removal.

Background:

Multi-fib support was added in r17 [1], 12 years ago. Addition of interface 
addresses to all fibs was a feature from day 1.
The `net.add_addr_allfibs` sysctl  was added in r180840 [2], 12 years ago.

Problem:
The goal of the fib support is to provide multiple independent routing tables, 
isolated from each other.
`net.add_addr_allfibs` default tries to shift gears in the opposite direction, 
unconditionally inserting all addresses to all of the fibs.

It complicates the logic, kernel code and makes control plane performance 
decrease with the number of fibs.
It make impossible to use the same prefixes in multiple fibs, which may be 
desired given shortage of IPv4 address space.

I do understand that there are some cases where such behaviour is desired.
For example, it can be used to achieve VRF route leaking or binding on address 
from different fibs.
I would like to collect such cases to consider supporting them in a different 
way.


The goal is to make net.add_addr_allfibs=0 default behaviour and remove 
net.add_addr_allfibs.
It will simplify kernel fib-related code and allow bringing more fib-related 
features. It will also improve fib scaling.


Timeline:
Aug 1: summarising feedback and the usecases, decision on proceeding further
Aug 20 (tentative):  patches for supported usecases
Sep 15 (tentative):  net.add_addr_allfibs removal.

[1]: [base Contents of 
/head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17=markup)
[2]: [base Diff of 
/head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839=180840;)

/Alexander
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: routed && route6d removal proposal

[Alexander V . Chernikov]

22.06.2020, 14:54, "Hiroki Sato" :
> "Alexander V. Chernikov"  wrote
>   in <273191592779...@mail.yandex.ru>:
>
> me> Hey,
> me>
> me> I would like to propose removal of sbin/routed and usr.sbin/route6d.
>
>  I am still using both of them in production environments because they
>  work well at least for my configurations and most of promising
>  alternatives are under GPL, not BSDL.
That's actually a very good datapoint I certainly missed.
>
>  Why do we need to rush to remove them? Discussion about whether we
There is no rush. In my opinion, popularity of rip is going in one 
direction, for the reasons stated in the original e-mail.
At some point in time it's worth checking the reality and verify whether we 
still need it in base or not.
I stated 2 week timeframe (though I admit I wrongly written Jun instead of 
July) for collecting feedback to base a decision upon.
It looks like there is enough feedback already.
>  should keep or remove such old bits tends to be controversial when
>  there is a user like me. I would agree with the removal if they were
>  harmful or impossible to maintain, but would not for the reason that
>  they are simply old and probably no one uses it today. Reason 1 and
>  2 look like the latter at least to me. "too old to be worth keeping"
>  is a matter of degree. Uucp, rlogind, and timed should be removed
>  (and were removed) because there are few non-FreeBSD platforms which
>  support these protocols. RIP is still widely supported---just like
>  FTP, which nowadays no one prefers to use and major www browsers are
>  about to drop the support of---and not be considered an inherently
>  vulnerable protocol like telnet. And keeping these daemons is not
>  harmful even for users who want to use third-party routing daemons
>  you listed.
My concern is hidden housekeeping costs. You have to update the documentation, 
where
 it exists. There are some bugs and you have to do something there. There are 
security vulns or Coverity reports.
 when you do a change, you have to verify it somehow and you have to tests, so 
you have to spend more time.
Each of it is a small thing by itself, but they add up and drain developer time.

>
> me> 1.1. Nowadays the daemon name is simply misleading. Given situation
> me> described above, one does expect far wider functionality from the
> me> program named "route[6]d" than just RIP implementation.
>
>  I do not think this is a good reason to remove something nor people
>  have got confused actually. If this is true, quagga or bird are much
>  worse.
>
> me> 2. Multiple routing stacks supporting all major routing protocol
> me> including RIP exists these days: bird, frr, quagga. Many BGP-only
> me> designs in are gaining popularity, so do bgp speakers such as exabgp
> me> or gobgp. Nowadays, if one needs dynamic routing on the host, OSPF or
> me> BGP speaker is the choice. FreeBSD packages contains well-maintained
> me> ports for these. Having RIP[ng] speakers in base offers no advantage.
> me>
> me> 3. Both routed/route6d are largely unmaintained [4] and presents an
> me> additional attack vector. Here is the list of last non-trivial commits
> me> to routed/route6d:
>
>  I think this is a separate issue. What attack vectors which are
>  known to be vulnerable do they have?
I'm referring to the cases like SA 14:21 or SA 20:12.
>
>  The small commit counts are not equal to its unreliability. Older
>  daemons such as ppp(8), dhclient(8), ftpd(8), or bootpd(8) have
>  received few substantial changes in recent years because they are
>  mature.
Well, I see another alternative reason, but that's another discussion :-)
Also, dhclient got 50 commits in the last 4 years, so I wouldn't put it in this 
list.
>
>  I am not a strong protester and will be happy to keep them as ports
>  if everyone wants to remove them and it will happen, but I would like
>  consistent criteria on removing software in the base system (they do
>  not need to be perfect nor strict, though). I believe harmfulness is
My criteria (briefly) is the "moral" staleness, existence of the viable 
alternatives and no users.
I should have stated the latter more explicitly.
>  more important than the fact that it is old or we have more choices
>  in the ports tree. If we have negative factors on maintaining them,
>  removing them would be one of the choices as a result. If the
>  existing routed/route6d makes difficulty on people who want to use
>  third-party routing daemons, it should be fixed. These kind of
>  harmfulness look below the threshold to me at this moment though I
>  may be biased because I am still using them today...
>
> -- Hiroki
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: routed && route6d removal proposal

[Alexander V . Chernikov]

22.06.2020, 13:50, "Rodney W. Grimes" :
>>  Hey,
Hi Rodney,
>>
>>  I would like to propose removal of sbin/routed and usr.sbin/route6d.
>
> I disagree with removal, as your analysis is flawed.
Thank you for the feedback!
>
>>  routed(8) is the daemon implementing RIPv2 routing protocol.
>>  route6d(8) is the daemon implementing RIPng routing protocol for IPv6.
>>
>>  RIP [1] was one of the first protocols used in the networking. The first 
>> version was implemented back in 1982.
>
> RIPv1 was implemented in 1982, RIPv2 became RFC2453 in November 1998, and is 
> a current and valid IETF standard, STD56.
> It was updated by RFC4822 in February 2007.
>
>>  1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other 
>> routing protocols have been created and greatly improved over years. People 
>> have created and adopted numerous designs leveraging OSPF/ISIS or BGP.
>>  RIP became obsolete a while ago as there were no competitive advantage it 
>> can offer.
>
>>  "It is the oldest routing protocol used by the network industry and is 
>> considered by many to be inefficient or border-line obsolete." ? [2], 2009
>
> RIPv2 is not obosolete, and your reference is not authoritave on what is or 
> is not an obsolete network protocol.
Different people have different opinions :-)
Let me rephrase the point I'm trying to make: RIP original design was created a 
long time ago. The current landscape is different: there are multiple protocols 
that are superset of RIP. There are multiple implementations of these protocols 
that are easily available. The configuration is not non-zero, but simple.
Even further, more and more want their protocol daemon to have an api - and 
that makes implementations like goBGP extremely popular, moving people from 
"traditional" routing suites/daemons.
With all that in mind, I see RIP popularity and usage going in only one 
direction.
> I know of people using RIPv2 in networks.
Collecting people feedback is the goal of this exercise. If there are existing 
users, then that's certainly a valid point in keeping the daemons in question.
>
>>  "Today, the only reason you might run across a network running RIPv2 is 
>> either that the network is very old and in serious need of an upgrade or the 
>> network is running cheaper, consumer-grade routing hardware that can only 
>> support RIP" ? [3], 2016.
>
> Or there simply is no need for anything more complicated. RipV2 is a very 
> simple protocol and works fine for small networks in many settings.
>
>>  1.1. Nowadays the daemon name is simply misleading. Given situation 
>> described above, one does expect far wider functionality from the program 
>> named "route[6]d" than just RIP implementation.
>
> I'll agree the name is missleading, so change it, but removal on your false 
> basis is not.
>
>>  2. Multiple routing stacks supporting all major routing protocol including 
>> RIP exists these days: bird, frr, quagga. Many BGP-only designs in are 
>> gaining popularity, so do bgp speakers such as exabgp or gobgp. Nowadays, if 
>> one needs dynamic routing on the host, OSPF or BGP speaker is the choice. 
>> FreeBSD packages contains well-maintained ports for these. Having RIP[ng] 
>> speakers in base offers no advantage.
>
> Routing stacks? You mean routing daemons? Forcing users to install bir, frr 
> or quagga when all they need, or have been using for a long time is in base 
> ripv2 is not good for users.
Routing protocol suite, routing daemons, etc..
The question that I'm trying to get an answer for is the existence of these 
users :-)

>
>>  3. Both routed/route6d are largely unmaintained [4] and presents an 
>> additional attack vector. Here is the list of last non-trivial commits to 
>> routed/route6d:
>
> Whats unmaintained about code that has no need to change cause it just pretty 
> much works?
Yep, and then you get SA 14:21 or SA 20:12. 
>
>>  sbin/routed:
>>  r327276 - coverity
>>  r317035 - rtsock fix
>>  r299825 - coverity
>>  r299822 - coverity, from netbsd
>>  r299821 - coverity, from netbsd
>>  r299784 - coverity, from netbsd
>>  r299771 - coverify, from netbsd
>>  r286347 - bugfix
>>  r276602 - SA14:21 patch
>>  r271919 - SA14:21 fix
>>  r215702 - logic fix, 2010
>>
>>  usr.sbin/route6d:
>>  r337500 - functional fix, 2018
>>  r317035 - rtsock fix
>>  r311994 - coverity
>>  r311985 - coverity
>>  r299869 - coverity
>>  r299491 - coverity
>>  r270234 - link-local fix
>>  r243233 - functionality improvement, 2012
>>
>>  To summarise: RIP protocol is obsolete, implementations for newer protocols 
>> exists in ports, implementation in base is unmaintained.
>>
>>  With all that in mind I propose to remove routed and route6d from base in 
>> FreeBSD 13.
>>  Timeline:
>>  June 5 - feedback aggregation and decision point
>>  July 19 - removal (proposed)
>>
>>  [1] https://en.wikipedia.org/wiki/Routing_Information_Protocol
>>  [2] 
>> 

routed && route6d removal proposal

[Alexander V . Chernikov]

Hey,

I would like to propose removal of  sbin/routed and usr.sbin/route6d.

routed(8) is the daemon implementing RIPv2 routing protocol.
route6d(8) is the daemon implementing RIPng routing protocol for IPv6.

RIP [1] was one of the first  protocols used in the networking. The first 
version was implemented back in 1982.

1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other 
routing protocols have been created and greatly improved over years. People 
have created and adopted numerous designs leveraging OSPF/ISIS or BGP.
RIP became obsolete a while ago as there were no competitive advantage it can 
offer.
"It is the oldest routing protocol used by the network industry and is 
considered by many to be inefficient or border-line obsolete." — [2], 2009
"Today, the only reason you might run across a network running RIPv2 is either 
that the network is very old and in serious need of an upgrade or the network 
is running cheaper, consumer-grade routing hardware that can only support RIP" 
— [3], 2016.

1.1. Nowadays the daemon name is simply misleading. Given situation described 
above, one does expect far wider functionality from the program named 
"route[6]d" than just  RIP implementation.

2. Multiple routing stacks supporting all major routing protocol including RIP 
exists these days: bird, frr, quagga. Many BGP-only designs in are gaining 
popularity, so do bgp speakers such as exabgp or gobgp.  Nowadays, if one needs 
dynamic routing on the host, OSPF or BGP speaker is the choice. FreeBSD 
packages contains well-maintained ports for these. Having RIP[ng] speakers in 
base offers no advantage. 

3. Both routed/route6d are largely unmaintained [4] and presents an additional 
attack vector. Here is the list of last non-trivial commits to routed/route6d:

sbin/routed:
r327276 - coverity
r317035 - rtsock fix
r299825 - coverity
r299822 - coverity, from netbsd
r299821 - coverity, from netbsd
r299784 - coverity, from netbsd
r299771 - coverify, from netbsd
r286347 - bugfix
r276602 - SA14:21 patch
r271919 - SA14:21 fix
r215702 - logic fix, 2010

usr.sbin/route6d:
r337500 - functional fix, 2018
r317035 - rtsock fix
r311994 - coverity
r311985 - coverity
r299869 - coverity
r299491 - coverity
r270234 - link-local fix
r243233 - functionality improvement, 2012

To summarise: RIP protocol is obsolete, implementations for newer protocols 
exists in ports,  implementation in base  is unmaintained.

With all that in mind I propose to remove routed and route6d from base in 
FreeBSD 13.
Timeline:
June 5 - feedback aggregation and decision point
July 19 - removal (proposed)


[1] https://en.wikipedia.org/wiki/Routing_Information_Protocol
[2] 
https://www.globalknowledge.com/ca-en/resources/resource-library/articles/basics-of-understanding-rip/
[3] 
https://www.networkcomputing.com/data-centers/comparing-dynamic-routing-protocols
[4] 
https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed_id=361897=routed_prs

/Alexander
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: net.inet6.ip6.deembed_scopeid removal

[Alexander V . Chernikov]

[re-sending email with as non-html]

Hey,

I would like to deprecate net.inet6.ip6.deembed_scopeid sysctl while leaving 
the current default behaviour.

This sysctl controls whether IPv6 scope is embedded in the IPv6 address or not 
when reading or writing route/interface/ifaddr data via rtsock/sysctl.

Embedding scope in the address is a hack, that overwrites some of the bits that 
can be used otherwise. It was probably implemented that way to simplify route 
table interactions, as rtable uses this hack to add link-local addresses to the 
same radix tree.

The change to fix the userland api by filling in sin6_scopeid and avoid 
touching IPv6 address was added in r243187, 7 years ago. It provided the sysctl 
in question, allowing to preserve compatibility with older applications, by 
reverting to the old behavior.

7 years looks like enough timeframe for the applications to be adjusted. Unless 
any major objections arise, I'm going to remove the code and make de-embedded 
IPv6 addresses the only option on July 5 2020.

/Alexander
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

net.inet6.ip6.deembed_scopeid removal

[Alexander V . Chernikov]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Next-hop objects and scalable multipath routing project status update [May 8]

[Alexander V . Chernikov]

Hi,

I would like to share the current state and the next steps for the 
nhops/multipath project.

To recap: project is about modernising the current routing stack and 
implementing scalable multipath routing. 

Most changes are based on introduction of the concept of nexthops. Nexthops, 
which are separate datastructures, containing all necessary information to 
perform packet forwarding such as gateway, interface and mtu. They are shared 
among the routes, providing more pre-computed cache-efficient data while 
requiring less memory.
Interested reader can find more detailed description in 
https://reviews.freebsd.org/D24141 .

All changes[*] from the stage1 (nexthop objects introduction) has landed.
Currently the focus is on upgrading various route change notification 
mechanisms to allow transparent multipath introduction.
After that the focus will switch on landing the actual multipath implementation.

[*] D24776 is pending commit tomorrow.

More detailed plan:

1 Nexthop objects [In progress]
1.1 Introduction of nexthop objects [DONE: r359823]
1.2 Conversion of old KPI users to the new one [DONE]
1.2.1 Conversion of route caching to nexthop caching [DONE: r360292]
1.3 Conversion of struct `rtentry` field access to nhop field access [DONE]
1.4 Eliminating old lookup KPI and hiding struct rtentry. [95% complete, 
rtentry: rS360824, kpi: D24776 (pending), ]

2 Multipath [In progress]
2.1 Switch control plane customers to use (rtentry, nhop) pair instead of 
rtentry to allow multipath changes happen transparently. [10% complete]
2.2 Introduce nexthop group objects
2.3 Add mutipath support for the rib manipulation functions
2.4 Add flowid generation for outbound traffic to enable load balancing


-- 
[No timeline]

3 Rtsock/netlink nhops support
3.1 Implement index lookup for nhops/nhop groups
3.2 Design rtsock messages for nhop/nhgrp operations& prefix binding
3.3 Implement kernel part
3.4 Implement frr or bird support

4 Modular longest-prefix-match lookup algorithm
4.1 Design control plane framework for attaching algos.
4.2 Implement one (IPv6?) lookup algorithm



/Alexander

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Next-hop objects and scalable multipath routing project status update

[Alexander V . Chernikov]

Hi,

I would like to share the current state and the next steps for the 
nhops/multipath project.

To recap: project is about modernising the current routing stack and 
implementing scalable multipath routing. 

Most changes are based on introduction of the concept of nexthops. Nexthops, 
which are separate datastructures, containing all necessary information to 
perform packet forwarding such as gateway, interface and mtu. They are shared 
among the routes, providing more pre-computed cache-efficient data while 
requiring less memory.
Interested reader can find more detailed description in 
https://reviews.freebsd.org/D24141 .


Notable progress has been done since the initial announce.

Most of the changes required to fully switch to use nexthop objects instead of 
routing entries has been landed.
If everything goes as expected, conversion will be completed in a couple of 
weeks.
After that the focus will switch on the actual multipath implementation.

More detailed plan:

1 Nexthop objects [In progress]
1.1 Introduction of nexthop objects [DONE: r359823]
1.2 Conversion of old KPI users to the new one [95% complete]
1.2.1 Conversion of route caching to nexthop caching [DONE: r360292]
1.3 Conversion of struct `rtentry` field access to nhop field access [90% 
complete]
1.4 Eliminating old lookup KPI and hiding struct rtentry. [50% complete]

2 Multipath [In progress]
2.1 Switch control plane customers to use (rtentry, nhop) pair instead of 
rtentry to allow multipath changes happen transparently. [10% complete]
2.2 Introduce nexthop group objects
2.3 Add mutipath support for the rib manipulation functions
2.4 Add flowid generation for outbound traffic to enable load balancing

--
[No timeline]

3 Rtsock/netlink nhops support
3.1 Implement index lookup for nhops/nhop groups
3.2 Design rtsock messages for nhop/nhgrp operations& prefix binding
3.3 Implement kernel part
3.4 Implement frr or bird support

4 Modular longest-prefix-match lookup algorithm
4.1 Design control plane framework for attaching algos.
4.2 Implement one (IPv6?) lookup algorithm



/Alexander

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r360294: buildkernel failure: etinet/tcp_stacks/bbr.c:5605:35: error: incomplete definition of type

[Alexander V . Chernikov]

25.04.2020, 11:18, "O. Hartmann" :
> Hello,
>
> recent commits to CURRENT makes buildkernel to fail due to some incomplete 
> definition errors
> during compiling:
Should be fixed by r360295. Sorry for the breakage.
>
> [...]
> - --- all_subdir_tcp ---
> - --- bbr.o ---
> /usr/src/sys/modules/tcp/bbr/../../../netinet/tcp_stacks/bbr.c:5605:35: 
> error: incomplete
> definition of type 'struct nhop_object' (bbr->rc_inp->inp_route.ro_nh->nh_ifp 
> == NULL)) {
>  ^
> /usr/src/sys/net/route.h:54:9: note: forward declaration of 'struct 
> nhop_object'
> struct nhop_object *ro_nh;
> ^
> /usr/src/sys/modules/tcp/bbr/../../../netinet/tcp_stacks/bbr.c:5621:36: 
> error: incomplete
> definition of type 'struct nhop_object' bbr->rc_inp->inp_route.ro_nh->nh_ifp,
>    ^
> /usr/src/sys/net/route.h:54:9: note: forward declaration of 'struct 
> nhop_object'
> struct nhop_object *ro_nh;
> ^
> - --- all_subdir_sound ---
>
> Kind regards,
>
> oh
>
> - --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
>> -BEGIN PGP SIGNATURE-
>>
>> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXqQOOAAKCRA4N1ZZPba5
>> R0vCAQCpZfq1XEolmh0i1s3RCyzLVYT4/gmnNreggF2Mz+kpLgEAnwVkwWyVCyxQ
>> BwZci0bIuJXh6sffWO2fD0yvNG1cKAM=
>> =/6QA
>> -END PGP SIGNATURE-
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD CI Weekly Report 2020-04-12

[Alexander V . Chernikov]

15.04.2020, 15:10, "Kristof Provost" :
> On 15 Apr 2020, at 15:34, Kristof Provost wrote:
>>  On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote:
>>>  (Please send the followup to freebsd-testing@ and note Reply-To is
>>>  set.)
>>>
>>>  FreeBSD CI Weekly Report 2020-04-12
>>>  ===
>>>
>>>  Here is a summary of the FreeBSD Continuous Integration results for
>>>  the period
>>>  from 2020-04-06 to 2020-04-12.
>>>
>>>  During this period, we have:
>>>
>>>  * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld
>>>  and
>>>    buildkernel (GENERIC and LINT) were executed on aarch64, amd64,
>>>  armv6,
>>>    armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64,
>>>    sparc64 architectures for head, stable/12, stable/11 branches.
>>>  * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1%
>>>  (+14.1)
>>>    exception) were executed on amd64, i386, riscv64 architectures for
>>>  head,
>>>    stable/12, stable/11 branches.
>>>  * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed)
>>>
>>>  Test case status (on 2020-04-12 23:59):
>>>  | Branch/Architecture | Total | Pass | Fail | Skipped
>>>  |
>>>  | --- | - | -- |  | 
>>>  |
>>>  | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20)
>>>  |
>>>  | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16)
>>>  |
>>>  | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2)
>>>  |
>>>  | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15)
>>>  |
>>>  | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5)
>>>  |
>>>  | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2)
>>>  |
>>>
>>>  (The statistics from experimental jobs are omitted)
>>>
>>>  If any of the issues found by CI are in your area of interest or
>>>  expertise
>>>  please investigate the PRs listed below.
>>>
>>>  The latest web version of this report is available at
>>>  https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is
>>>  available at
>>>  https://hackmd.io/@FreeBSD-CI/ , any help is welcome.
>>>
>>>  ## News
>>>
>>>  * The test env now loads the required module for firewall tests.
>>>
>>>  * New armv7 job is added (to replace armv6 one):
>>>    * FreeBSD-head-armv7-testvm
>>>    The images are available at https://artifact.ci.freebsd.org
>>>    FreeBSD-head-armv7-test is ready but needs test env update.
>>>
>>>  ## Failing jobs
>>>
>>>  * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/
>>>    * See console log for the error details.
>>>
>>>  ## Failing tests
>>>
>>>  * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/
>>>    * local.kyua.integration.cmd_about_test.topic__authors__installed
>>>    * sys.netipsec.tunnel.empty.v4
>>>    * sys.netipsec.tunnel.empty.v6
>>>    * sys.netpfil.common.forward.ipf_v4
>>>    * sys.netpfil.common.forward.ipfw_v4
>>>    * sys.netpfil.common.forward.pf_v4
>>>    * sys.netpfil.common.tos.ipfw_tos
>>>    * sys.netpfil.common.tos.pf_tos
>>>    * sys.netpfil.pf.forward.v4
>>  I can’t actually reproduce this failure in my test VM, but with the
>>  ci test VM I can reproduce the problem.
>>  It’s not related to pf, because the sanity check ping we do before
>>  we set up pf already fails.
>>  Or rather pft_ping.py sends an incorrect packet, because `ping` does
>>  get the packet to go where it’s supposed to go.
>>
>>  Scapy seems to fail to find the source IP address, so we get this:
>>
>>  12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0,
>>  seq 0, length 12
>>
>>  I have a vague recollection that we’ve seem this problem before, but
>>  I can’t remember what we did about it.
>>
>>  In all likelihood most of the other netpfil tests fail for exactly the
>>  same reason.
>
> The problem appears to be that
> /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing
> the `netstat -rnW` output.
Thanks for the analysis!

Sorry for breaking the tests.
I should have run tests with userland changes installed.

I'll revert the netstat output changes shortly to unbreak the tests.
Re longer-term: parsing textual output for the routes does not seem to be a 
good habit, especially in these days.
Structural (libxo) approach looks better, however I guess this will make scapy 
unusable on the routers with full-view.

So far light-weight sysctl-route reader looks like the best option.
What do you folks think?

>
> For reference, this is the output in the test VM:
>
> Routing tables
>
> Internet:
> Destination Gateway Flags Nhop# Mtu Netif
> Expire
> 127.0.0.1 link#2 UH 1 16384 lo0
> 192.0.2.0/24 link#4 U 2 1500 epair0a
> 192.0.2.1 link#4 UHS 1 16384 lo0
> 198.51.100.0/24 192.0.2.2 UGS 3 1500 epair0a
>
> Internet6:
> Destination Gateway Flags
> Nhop# Mtu Netif Expire
> ::/96 ::1 UGRS
>  4 16384 lo0
> ::1 link#2 UH
>  1 16384 lo0
> :::0.0.0.0/96 ::1 UGRS
>  

CFT: Next-hop objects and scalable multipath routing

[Alexander V . Chernikov]

I would like to introduce an implementation of scalable multipath routing.

Previous implementation (RADIX_MPATH) focused on a simpler case like having 2 
defaults, with performance falling linearly proportional to the number of 
paths. That implementation was also tightly coupled lookup algorithm details 
with the routing details, making it hard to hack both.

The proposed one allows O(1) lookup and is more cache-efficient with the large 
amount of routes.  Furthermore, multipath functionality is based on the number 
of internal changes, modernizing the old routing code.

Most of the changes revolves around introducing the concept of _nexthops_.
Nexthops are separate datastructures, containing all necessary information to 
perform packet forwarding such as gateway, interface and mtu. Nexthops are 
shared among the routes, providing more pre-computed cache-efficient data while 
requiring less memory.
Multipath implementation adds _nexthop groups_ which are basically collection 
of nexthops weights, compiled into an array, to allow direct nexthop selection.
More detailed technical description is available at [1].
Any comments/suggestions are welcome!

Presentation of the similar functionality in the other OS: [2]
Next-hop objects support was implemented in FRR in 2019 [3].

Next steps:
As these changes decouples routing code details from algorithm details and 
abstracts callers, it is much easier to introduce a number of other relevant 
features.
The most important proposed features are: nexthop-based route installation and  
custom per-address-family route lookup algorithms.
The former targets improving convergence times for the large-fib boxes, while 
the latter may improve dataplane performance, especially for IPv6.

How to test:
fetch the patch from  https://reviews.freebsd.org/D24141
rebuild kernel with ROUTE_MPATH option (already added to amd64 GENERIC)
Optionally, rebuild world to get netstat nexthops/multipath groups reporting.

Use route(8) to add multiple routes for the same destination, optionally 
specifying weight.
Example: add 2:1 load balancing for the default route:

route add -net default 192.168.53.1 -weight 100
route add -net default 192.168.53.2 -weight 200

netstat -4rnW
..
DestinationGatewayFlags   Nhop#Mtu  Netif Expire
default192.168.53.1   UGS 4   1500em0
default192.168.53.2   UGS 5   1500em0

netstat -4onW
Nexthop data
Idx   Type IFAGateway Flags  Use Mtu
 Netif Addrif Refcnt Prepend
..
4v4/gw 192.168.53.128 192.168.53.1   GS0   1500 
   em0   2
5v4/gw 192.168.53.128 192.168.53.2   GS0   1500 
   em0   1
Nexthop groups data
MpIdx NHIdx Weigh SlotsGateway Netif  Refcnt
1        1
  4   100 1   192.168.53.1   em0
  5   200 2   192.168.53.2   em0

[1] https://reviews.freebsd.org/D24141
[2] 
https://linuxplumbersconf.org/event/4/contributions/434/attachments/251/436/nexthop-objects-talk.pdf
[3] 
https://github.com/FRRouting/frr/commit/d9f5b2f50f53d625986dbd47cd12778c9f841f0c
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: current does not boot on vmware fusion 11

[Alexander V . Chernikov]

15.02.2020, 20:44, "Toomas Soome" :
>>  On 15. Feb 2020, at 22:19, Alexander V. Chernikov  wrote:
>>
>>  Hi folks,
>>
>>  I upgraded vmware fusion to version 11 recently and noticed that my -amd64 
>> VM stops booting immediately after printing EFI framebuffer information.
>>
>>  VM pops up a message stating that "The firmware encountered an unexpected 
>> exception. The virtual machine cannot boot."
>>
>>  Further digging revealed that the fusion upgrade bumped vmware virtual HW 
>> version to 16. Downgrading it to version 15 enabled VM to work again as 
>> expected.
>>
>>  Description of HWv16 include "UEFI Secure Boot" as one of the declared 
>> features, which looks like the potential candidate reason. The full feature 
>> list is available below.
>>  How can I debug this further?
>
> We do not do secure boot. However, there is known issue I am trying to fix. 
> You can try to run from ok prompt: ls and then boot.

Got it.
thank you for the prompt reply!
Any issue/review/code part/etc I can subscribe to get the notifications?

I switched the VM to version 16, jumped to the loader prompt, entered "ls", 
then "boot". The result is still the "The firmware encountered an unexpected 
exception" message.
Do I need to install the latest boot loader/do something else to workaround the 
issue?
I'm not blocked in any way with it, version 15 works just fine, just want to 
ensure this is the same problem.

Thank you!

>
> rgds,
> toomas
>
>>  Details:
>>  Host: macbook pro 2017, Intel core i7, Mojave 10.14.6
>>  VM: r357812, amd64.
>>  Vmware Fusion 11.5.1 (15018442)
>>
>>  Full VM output before the error:
>>
>>  Loading kernel...
>>  /boot/kernel/kernel text=0x1562084 data=0xe0 data=0x1b5158+0x449ea8 
>> syms=[0x8+0x 174e70+0x8+0x19408f] Loading configured modules...
>>  can't find I/boot/entropy'
>>  Start @ 0x80369000 ...
>>  EFI framebuffer information:
>>  adds, size 0xf000, 0x30
>>  dimensions 1024 x 768
>>  stride 1024
>>  masks 0x00ff, 0xff00, 0x00ff, 0xff00
>>  -
>>
>>  HWv16 description from https://blogs.vmware.com/teamfusion :
>>
>>  Included in HWv16 are:
>>  Improved Virtual NVMe Device Performance
>>  Important Security Fixes (Spectre, Meltdown and L1TF)
>>  Virtual Trusted Platform Module
>>  UEFI Secure Boot
>>  IOMMU
>>  VBS Support (guest only)
>>
>>  /Alexander
>>
>>  ___
>>  freebsd-current@freebsd.org mailing list
>>  https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>  To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

current does not boot on vmware fusion 11

[Alexander V . Chernikov]

Hi folks,

I upgraded vmware fusion to version 11 recently and noticed that my -amd64 VM 
stops booting immediately after printing EFI framebuffer information.

VM pops up a message stating that "The firmware encountered an unexpected 
exception. The virtual machine cannot boot."

Further digging revealed that the fusion upgrade bumped vmware virtual HW 
version to 16. Downgrading it to version 15 enabled VM to work again as 
expected.

Description of HWv16 include "UEFI Secure Boot" as one of the declared 
features, which looks like the potential candidate reason. The full feature 
list is available below.
How can I debug this further?


Details:
Host: macbook pro 2017, Intel core i7, Mojave 10.14.6
VM: r357812, amd64.
Vmware Fusion 11.5.1 (15018442)

Full VM output before the error:

Loading kernel... 
/boot/kernel/kernel text=0x1562084 data=0xe0 data=0x1b5158+0x449ea8 
syms=[0x8+0x 174e70+0x8+0x19408f] Loading configured modules... 
can't find I/boot/entropy'
Start @ 0x80369000 ...
EFI framebuffer information:
adds, size 0xf000, 0x30
dimensions 1024 x 768
stride 1024
masks 0x00ff, 0xff00, 0x00ff, 0xff00
-


HWv16 description from https://blogs.vmware.com/teamfusion :

Included in HWv16 are:
Improved Virtual NVMe Device Performance
Important Security Fixes (Spectre, Meltdown and L1TF)
Virtual Trusted Platform Module
UEFI Secure Boot
IOMMU
VBS Support (guest only)



/Alexander

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ip_divert.c:374:7: error: use of undeclared identifier

[Alexander V . Chernikov]

25.01.2020, 19:14, "AN" :
> FYI
Should be fixed by r357144.
Thanks for the report!
>
> FreeBSD Free_BSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #22 r356360: Sat Jan
> 4 20:10:21 EST 2020
> root@Free_BSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1300074
>
> --- all_subdir_dtrace ---
> --- prototype.o ---
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe
> -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc
> -I/usr/src/sys/cddl/compat/opensolaris
> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/sys
> -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/opt_global.h -I. -I/usr/src/sys
> -I/usr/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer
> -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include
> -fdebug-prefix-map=./x86=/usr/src/sys/x86/include
> -I/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL -MD
> -MF.depend.prototype.o -MTprototype.o -mcmodel=kernel -mno-red-zone
> -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables
> -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value
> -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx
> -std=iso9899:1999 -include
> /usr/src/sys/cddl/compat/opensolaris/sys/debug_compat.h -c
> /usr/src/sys/cddl/dev/prototype.c -o prototype.o
> --- all_subdir_iir ---
> --- iir.ko.debug ---
> objcopy --only-keep-debug iir.ko.full iir.ko.debug
> --- iir.ko ---
> objcopy --strip-debug --add-gnu-debuglink=iir.ko.debug iir.ko.full iir.ko
> --- all_subdir_ipdivert ---
> /usr/src/sys/netinet/ip_divert.c:374:7: error: use of undeclared
> identifier 'IPV6_VERSION'
>  case IPV6_VERSION >> 4:
>   ^
> --- all_subdir_ipfilter ---
> ===> ipfilter (all)
> [Creating objdir
> /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/modules/usr/src/sys/modules/ipfilter...]
> --- all_subdir_ipdivert ---
> 1 error generated.
> *** [ip_divert.o] Error code 1
>
> make[4]: stopped in /usr/src/sys/modules/ipdivert
> 1 error
>
> make[4]: stopped in /usr/src/sys/modules/ipdivert
> *** [all_subdir_ipdivert] Error code 2
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Alexander V . Chernikov]

21.01.2020, 20:10, "Nick Hibma" :
> That (with the return added, thanks Cy) worked like a charm.
Got committed in r357038.
Thank you for the report!
>
> Thanks for the fast response.
>
> Nick Hibma
> n...@van-laarhoven.org
>
> -- Open Source: We stand on the shoulders of giants.
>
>>  On 21 Jan 2020, at 18:38, Alexander V. Chernikov  
>> wrote:
>>
>>  21.01.2020, 17:25, "Nick Hibma" :
>>>  When using a trivial program to read from the divert socket and post back 
>>> the machine panics instantly when a packet is sent to userland and back 
>>> again (incoming packet for the interface, so ifname is set). This is 
>>> current from today with no changes
>>>
>>>  Any pointers as to how to fix this?
>>  Could you please try to apply an attached patch and try again?
>>>  Thanks in advance for any help.
>>>
>>>  Nick Hibma
>>>  n...@van-laarhoven.org
>>>
>>>  -- Open Source: We stand on the shoulders of giants.
>>>
>>>  Unread portion of the kernel message buffer:
>>>  panic: Assertion in_epoch(net_epoch_preempt) failed at 
>>> /usr/src/sys/netinet/in.c:968
>>>  cpuid = 0
>>>  time = 1579626632
>>>  KDB: stack backtrace:
>>>  db_trace_self_wrapper(3836393a,1a9000a,0,1fdc088c,bd5320,...) at 
>>> db_trace_self_wrapper+0x2a/frame 0x1fdc0860
>>>  kdb_backtrace(2,1e03ebc,1fdc08e8,14683a4,20b72500,...) at 
>>> kdb_backtrace+0x2e/frame 0x1fdc08c0
>>>  vpanic(1461278,1fdc0904,1fdc0904,1fdc0918,11355ac,...) at 
>>> vpanic+0x11f/frame 0x1fdc08e4
>>>  panic(1461278,1512573,154b440,3c8,20b72500,...) at panic+0x14/frame 
>>> 0x1fdc08f8
>>>  in_broadcast(f02000a,94df400,20b72594,1dc0ae8,2001be24,...) at 
>>> in_broadcast+0x8c/frame 0x1fdc0918
>>>  div_send(2001bcc0,0,20b72500,9082e10,0,177f1a80) at div_send+0x1bd/frame 
>>> 0x1fdc0958
>>>  sosend_generic(2001bcc0,9082e10,1fdc0a18,0,0,0,177f1a80) at 
>>> sosend_generic+0x3c5/frame 0x1fdc09b4
>>>  sosend(2001bcc0,9082e10,1fdc0a18,0,0,...) at sosend+0x50/frame 0x1fdc09e4
>>>  kern_sendit(177f1a80,3,1fdc0aa0,0,0,0) at kern_sendit+0x1b4/frame 
>>> 0x1fdc0a50
>>>  sendit(1fdc0aa0,0) at sendit+0x196/frame 0x1fdc0a88
>>>  sys_sendto(177f1a80,177f1d0c) at sys_sendto+0x50/frame 0x1fdc0ac8
>>>  syscall(1fdc0ba8,3b,3b,3b,54,...) at syscall+0x2db/frame 0x1fdc0b9c
>>>  Xint0x80_syscall() at 0xffc033c9/frame 0x1fdc0b9c
>>>  --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0xffc01230, esp = 
>>> 0xffc07fe8, ebp = 0xffbfeb68 ---
>>>  KDB: enter: panic
>>>
>>>  0x00fd1129 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392
>>>  392 savectx();
>>>  (kgdb) quit
>>>  {e}nick@fimkjecurrent:/home/nick % svn info /usr/src
>>>  Path: /usr/src
>>>  Working Copy Root Path: /usr/src
>>>  URL: svn+ssh://repo.freebsd.org/base/head
>>>  Relative URL: ^/head
>>>  Repository Root: svn+ssh://repo.freebsd.org/base
>>>  Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>>  Revision: 356907
>>>  Node Kind: directory
>>>  Schedule: normal
>>>  Last Changed Author: jhibbits
>>>  Last Changed Rev: 356904
>>>  Last Changed Date: 2020-01-20 05:01:35 +0100 (Mon, 20 Jan 2020)
>>>
>>>>   On 9 Oct 2019, at 14:04, David Wolfskill  wrote:
>>>>
>>>>   On Tue, Oct 08, 2019 at 05:15:19AM -0700, David Wolfskill wrote:
>>>>>   This was on my laptop (build machine, which was updated in parallel,
>>>>>   but uses a different NIC, had no issues) after a src update from
>>>>>   r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in
>>>>>   this case).
>>>>
>>>>   After restoring the /boot/*.old set, I was able to reboot & update from
>>>>   r353298 to r353336. The subsequent reboot seemed OK ... until the
>>>>   keyboard & mouse were enabled (under X11; I use xdm on the laptop).
>>>>
>>>>   Then I got a slightly different panic:
>>>>
>>>>   panic: Assertion in_epoch(net_epoch_preempt) failed at 
>>>> /usr/src/sys/net/if.c:356
>>>>
>>>>   Backtrace:
>>>>
>>>>   panic: Assertion in_epoch(net_epoch_preempt) failed at 
>>>> /usr/src/sys/net/if.c:356
>>>>   cpuid = 0
>>>>   time = 1570621553
>>>>   KDB: stack backtrace:
>>>>   db_trace_self_wrapper() at 0x8049eba

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Alexander V . Chernikov]

21.01.2020, 17:25, "Nick Hibma" :
> When using a trivial program to read from the divert socket and post back the 
> machine panics instantly when a packet is sent to userland and back again 
> (incoming packet for the interface, so ifname is set). This is current from 
> today with no changes
>
> Any pointers as to how to fix this?
Could you please try to apply an attached patch and try again?
>
> Thanks in advance for any help.
>
> Nick Hibma
> n...@van-laarhoven.org
>
> -- Open Source: We stand on the shoulders of giants.
>
> Unread portion of the kernel message buffer:
> panic: Assertion in_epoch(net_epoch_preempt) failed at 
> /usr/src/sys/netinet/in.c:968
> cpuid = 0
> time = 1579626632
> KDB: stack backtrace:
> db_trace_self_wrapper(3836393a,1a9000a,0,1fdc088c,bd5320,...) at 
> db_trace_self_wrapper+0x2a/frame 0x1fdc0860
> kdb_backtrace(2,1e03ebc,1fdc08e8,14683a4,20b72500,...) at 
> kdb_backtrace+0x2e/frame 0x1fdc08c0
> vpanic(1461278,1fdc0904,1fdc0904,1fdc0918,11355ac,...) at vpanic+0x11f/frame 
> 0x1fdc08e4
> panic(1461278,1512573,154b440,3c8,20b72500,...) at panic+0x14/frame 0x1fdc08f8
> in_broadcast(f02000a,94df400,20b72594,1dc0ae8,2001be24,...) at 
> in_broadcast+0x8c/frame 0x1fdc0918
> div_send(2001bcc0,0,20b72500,9082e10,0,177f1a80) at div_send+0x1bd/frame 
> 0x1fdc0958
> sosend_generic(2001bcc0,9082e10,1fdc0a18,0,0,0,177f1a80) at 
> sosend_generic+0x3c5/frame 0x1fdc09b4
> sosend(2001bcc0,9082e10,1fdc0a18,0,0,...) at sosend+0x50/frame 0x1fdc09e4
> kern_sendit(177f1a80,3,1fdc0aa0,0,0,0) at kern_sendit+0x1b4/frame 0x1fdc0a50
> sendit(1fdc0aa0,0) at sendit+0x196/frame 0x1fdc0a88
> sys_sendto(177f1a80,177f1d0c) at sys_sendto+0x50/frame 0x1fdc0ac8
> syscall(1fdc0ba8,3b,3b,3b,54,...) at syscall+0x2db/frame 0x1fdc0b9c
> Xint0x80_syscall() at 0xffc033c9/frame 0x1fdc0b9c
> --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0xffc01230, esp = 
> 0xffc07fe8, ebp = 0xffbfeb68 ---
> KDB: enter: panic
>
> 0x00fd1129 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392
> 392 savectx();
> (kgdb) quit
> {e}nick@fimkjecurrent:/home/nick % svn info /usr/src
> Path: /usr/src
> Working Copy Root Path: /usr/src
> URL: svn+ssh://repo.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn+ssh://repo.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 356907
> Node Kind: directory
> Schedule: normal
> Last Changed Author: jhibbits
> Last Changed Rev: 356904
> Last Changed Date: 2020-01-20 05:01:35 +0100 (Mon, 20 Jan 2020)
>
>>  On 9 Oct 2019, at 14:04, David Wolfskill  wrote:
>>
>>  On Tue, Oct 08, 2019 at 05:15:19AM -0700, David Wolfskill wrote:
>>>  This was on my laptop (build machine, which was updated in parallel,
>>>  but uses a different NIC, had no issues) after a src update from
>>>  r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in
>>>  this case).
>>
>>  After restoring the /boot/*.old set, I was able to reboot & update from
>>  r353298 to r353336. The subsequent reboot seemed OK ... until the
>>  keyboard & mouse were enabled (under X11; I use xdm on the laptop).
>>
>>  Then I got a slightly different panic:
>>
>>  panic: Assertion in_epoch(net_epoch_preempt) failed at 
>> /usr/src/sys/net/if.c:356
>>
>>  Backtrace:
>>
>>  panic: Assertion in_epoch(net_epoch_preempt) failed at 
>> /usr/src/sys/net/if.c:356
>>  cpuid = 0
>>  time = 1570621553
>>  KDB: stack backtrace:
>>  db_trace_self_wrapper() at 0x8049ebab = 
>> db_trace_self_wrapper+0x2b/frame 0xfe1072956580
>>  vpanic() at 0x80b978fd = vpanic+0x19d/frame 0xfe10729565d0
>>  panic() at 0x80b97693 = panic+0x43/frame 0xfe1072956630
>>  if_ref() at 0x80ca1b10 = if_ref/frame 0xfe1072956650
>>  sysctl_ifdata() at 0x80cb247d = sysctl_ifdata+0x4d/frame 
>> 0xfe1072956760
>>  sysctl_root_handler_locked() at 0x80ba714b = 
>> sysctl_root_handler_locked+0x7b/frame 0xfe10729567a0
>>  sysctl_root() at 0x80ba64dc = sysctl_root+0x20c/frame 
>> 0xfe1072956820
>>  userland_sysctl() at 0x80ba6bab = userland_sysctl+0x17b/frame 
>> 0xfe10729568d0
>>  sys___sysctl() at 0x80ba69ef = sys___sysctl+0x5f/frame 
>> 0xfe1072956980
>>  amd64_syscall() at 0x810480f4 = amd64_syscall+0x2d4/frame 
>> 0xfe1072956ab0
>>  fast_syscall_common() at 0x8101eaa0 = 
>> fast_syscall_common+0x101/frame 0xfe1072956ab0
>>  --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8014d4d2a, rsp = 
>> 0x7fffeaa8, rbp = 0x7fffeae0 ---
>>  KDB: enter: panic
>>
>>>  The ddb "dump" command recorded a dump, which I managed to capture; the
>>>  information may be found at
>>>  http://www.catwhisker.org/~david/FreeBSD/head/r353298/
>>
>>  This one is at http://www.catwhisker.org/~david/FreeBSD/head/r353336
>>
>>  As before, the (headless) build machine had no issues that I could see.
>>
>>  Peace,
>>  david
>>  --
>>  David H. Wolfskill da...@catwhisker.org
>>  I am amazed that anyone would condone 

Re: panic "wlock already held" when changing ipv6 default route

[Alexander V . Chernikov]

25.03.2016, 02:11, "Guy Yur" :
> Hi,
>
> When changing the ipv6 default route I get a panic on wlock already held.
> Could be related to r293424 lock changes, haven't checked an older version 
> yet.
Hi,
Yes, there is a problem when the default route next hop is filled in 
incorrectly, so lookup fails (e.g. matches previous one).
Will be fixed soon.

Thanks for the report.
>
> route add -inet6 default fe80::7
> route change -inet6 default fe80::7
>
> panic: rw_rlock: wlock already held for rib head lock @
> /usr/src/sys/net/route.c:445
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0050ee01d0
> vpanic() at vpanic+0x182/frame 0xfe0050ee0250
> kassert_panic() at kassert_panic+0x126/frame 0xfe0050ee02c0
> __rw_rlock() at __rw_rlock+0xe7/frame 0xfe0050ee0360
> rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfe0050ee0420
> ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfe0050ee0460
> rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfe0050ee0480
> rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfe0050ee0570
> route_output() at route_output+0x653/frame 0xfe0050ee07c0
> sosend_generic() at sosend_generic+0x436/frame 0xfe0050ee0880
> soo_write() at soo_write+0x42/frame 0xfe0050ee08b0
> dofilewrite() at dofilewrite+0x87/frame 0xfe0050ee0900
> kern_writev() at kern_writev+0x68/frame 0xfe0050ee0950
> sys_write() at sys_write+0x60/frame 0xfe0050ee09a0
> amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0050ee0ab0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0050ee0ab0
> --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp =
> 0x7fffe2d8, rbp = 0x7fffeb90 ---
> KDB: enter: panic
> [ thread pid 644 tid 100054 ]
> Stopped at kdb_enter+0x3b: movq $0,kdb_why
>
> Booted into livecd with snapshot iso in a VirtualBox VM and ran the
> commands above.
> FreeBSD-11.0-CURRENT-amd64-20160308-r296485-bootonly.iso
>
> -- Guy
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: forwarding didn't work if wlan0 is member of a bridge

[Alexander V . Chernikov]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: forwarding didn't work if wlan0 is member of a bridge

[Alexander V . Chernikov]

13.01.2016, 13:02, "Olivier Cochard-Labbé" <oliv...@cochard.me>:
> On Wed, Jan 13, 2016 at 9:45 AM, Alexander V. Chernikov <melif...@ipfw.ru>
> wrote:
>
>>  I suspect the reason here is link state bridge handling.
>>  ix0 does not seem to have IFCAP_LINKSTATE option but re(4) does. Probably
>>  wlan0 doesn't have LINKSTATE option.
>>  Code in bridge_linkcheck() doesn't handle the case with both "has link
>>  state" and "no link state" interfaces well:
>>  if reX is the only interface w/ IFCAP_LINKSTATE and it goes down, bridge
>>  will also change its link state to down.
>>  (However, bridge does not seem to have link state option itself, so
>>  RT_LINK_IS_UP() macro should return true...)
>
> ​For validating your "IFCAP_LINKSTATE" hypothesis, I've plug an USB
> ethernet adapter ue(4) that didn't support IFCAP_LINKSTATE.
> And I've setup the bridge0 with wlan0 and ue0 (in place of re1): same bug
> triggered. I need to ​plug a cable for correct routing.
We discussed/investigated this behaviour on IRC. To summarise:
1) ip_tryforward() does check interface linkstate regardless of linkstate 
capability
2) bridge linkcheck function does not seem to care about linkstate capability.

What happened in original case:
802.11 does not provide linkstate cap and actual linkstate value is 0 (unknown).
re0 does provide linkstate cap, so on link down, bridge_linkcheck() code 
decided to set own linkstate as DOWN as well (has non-zero linkstate interface, 
0 up).
On packet transmission. ip_tryforward() checked bridge0 state, found it to be 
DOWN so the icmp_error() was triggered.

Attached patch fixes the problem, but I'm still thinking about better solution.

>
> ​root@fbsd-router:~ # ifconfig bridge0
> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> ether 02:6b:c0:de:b8:00
> inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255
> nd6 options=9<PERFORMNUD,IFDISABLED>
> groups: bridge
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: ue0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 7 priority 128 path cost 55
> member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 5 priority 128 path cost 3
> root@fbsd-router:~ # ifconfig ue0
> ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
> mtu 1500
> options=80008<VLAN_MTU,LINKSTATE>
> ether 00:19:fd:4e:77:4d
> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> media: Ethernet autoselect (none)
> status: no carrier
> ​
> ​Regards,
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"Index: /usr/src/sys/net/if_bridge.c
===
--- /usr/src/sys/net/if_bridge.c	(revision 293659)
+++ /usr/src/sys/net/if_bridge.c	(working copy)
@@ -3550,22 +3550,25 @@ static void
 bridge_linkcheck(struct bridge_softc *sc)
 {
 	struct bridge_iflist *bif;
-	int new_link, hasls;
+	int new_link, nols;
 
 	BRIDGE_LOCK_ASSERT(sc);
 	new_link = LINK_STATE_DOWN;
-	hasls = 0;
+	nols = 0;
 	/* Our link is considered up if at least one of our ports is active */
 	LIST_FOREACH(bif, >sc_iflist, bif_next) {
-		if (bif->bif_ifp->if_capabilities & IFCAP_LINKSTATE)
-			hasls++;
+		if ((bif->bif_ifp->if_capabilities & IFCAP_LINKSTATE) == 0) {
+			/* XXX: Handle admin down? */
+			nols++;
+			continue;
+		}
 		if (bif->bif_ifp->if_link_state == LINK_STATE_UP) {
 			new_link = LINK_STATE_UP;
 			break;
 		}
 	}
-	if (!LIST_EMPTY(>sc_iflist) && !hasls) {
-		/* If no interfaces support link-state then we default to up */
+	if (!LIST_EMPTY(>sc_iflist) && nols != 0) {
+		/* If some ifaces don't support link-state then we default to up */
 		new_link = LINK_STATE_UP;
 	}
 	if_link_state_change(sc->sc_ifp, new_link);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: forwarding didn't work if wlan0 is member of a bridge

[Alexander V . Chernikov]

12.01.2016, 23:48, "Olivier Cochard-Labbé" :
> On Tue, Jan 12, 2016 at 7:22 PM, Adrian Chadd 
> wrote:
>
>>  This is actually the intended behaviour, right? The routed interface
>>  is down, so the IP address on it and connected to it are unreachable.
>
> ​Hi Adrian,
>
> the routed interface is a bridge interface, and this bridge interface had
> only one of its 2 members interface down.
> Then the routed interface is not down.
Could you show 'netstat -rn' output when one of bridge members is down?
Btw, I tried to reproduce it today (but, with ix0 instead of wlan0) and I 
wasn't able to trigger the problem.

> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: forwarding didn't work if wlan0 is member of a bridge

[Alexander V . Chernikov]

12.01.2016, 01:53, "Olivier Cochard-Labbé" :
> After weeks of troubleshooting, at last I found how to reproduce this
> problem ;-)
Hi Olivier,
>
> Here is the setup:
>
> LAN0 <--> [(re0) fbsd router (bridge0 addm re1 addm wlan0)] <--> Wireless
> LAN
>
> If interface re1 (bridge0 member with wlan0) is in "active" status
> (=ethernet cable plugged to something): I don't have any problem, all is
> working great for my wireless clients connected to wlan0: They can ping
> devices in LAN0.
> But once I've unplug the ethernet cable connected to re1 (bridge member
> with wlan0) and re1 state switch to "no carrier", Wireless LAN clients are
> not able to reach LAN0.
It looks like ICMP unreach messages are generated by IP forwarding.
Probably because (for some reason) bridge0 interface prefix was removed from 
route table.
I'll try to reproduce that.

>
> Here is my rc.conf with simple subnetting for Adrian ;-)
>
> wlans_ath0="wlan0"
> ifconfig_wlan0="hostap channel 6"
> create_args_wlan0="wlanmode hostap"
> cloned_interfaces="bridge0"
> ifconfig_re0="inet 1.0.0.1/24"
> ifconfig_re1="up"
> ifconfig_bridge0="inet 1.1.1.1/24 addm re1 addm wlan0 up"
> gateway_enable="YES"
>
> And an example with re1 in "no carrier" status:
>
> root@fbsd-router:~ # ifconfig bridge0
> bridge0: flags=8843 metric 0 mtu
> 1500
> ether 02:6b:c0:de:b8:00
> inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255
> nd6 options=9
> groups: bridge
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: wlan0 flags=143
> ifmaxaddr 0 port 5 priority 128 path cost 3
> member: re1 flags=143
> ifmaxaddr 0 port 2 priority 128 path cost 55
>
> root@fbsd-router:~ # ifconfig re1
> re1: flags=8943 metric 0
> mtu 1500
>
> options=82099
> ether 00:0d:b9:3c:ae:25
> nd6 options=29
> media: Ethernet autoselect (none)
> status: no carrier
>
> => from a wireless LAN client (1.1.1.2) I'm trying to ping a host on LAN0
> (1.0.0.2):
>
> root@fbsd-router:~ # tcpdump -pni re0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 23:38:04.466866 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28
> 23:38:04.467052 ARP, Reply 1.0.0.2 is-at 00:08:a2:09:c4:a2, length 46
> 23:38:04.467090 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 1,
> length 64
> 23:38:04.467226 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 1, length
> 64
> 23:38:04.467300 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> 23:38:05.483053 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 2,
> length 64
> 23:38:05.483259 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 2, length
> 64
> 23:38:05.483318 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> 23:38:06.387304 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 3,
> length 64
> 23:38:06.387466 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 3, length
> 64
> 23:38:06.387514 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> ^C
> 11 packets captured
> 11 packets received by filter
> 0 packets dropped by kernel
> root@fbsd-router:~ # arp -na
> ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge]
> ? (1.1.1.2) at fc:64:ba:97:c0:ff on bridge0 expires in 1168 seconds [bridge]
> ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet]
>
> => The FreeBSD router answers "unreacheable" to the host: My wireless LAN
> client never get the ICMP reply.
>
> => Now I plug eth1 to a dummy machine (just for changing its status):
>
> root@fbsd-router:~ # ifconfig re1
> re1: flags=8943 metric 0
> mtu 1500
>
> options=82099
> ether 00:0d:b9:3c:ae:25
> nd6 options=29
> media: Ethernet autoselect (1000baseT )
> status: active
>
> => and I restart the same ping from the wireless LAN client:
>
> root@fbsd-router:~ # tcpdump -pni re0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 23:44:08.597429 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 1,
> length 64
> 23:44:08.597660 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 1, length
> 64
> 23:44:09.604447 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 2,
> length 64
> 23:44:09.604683 IP 

Re: panic: refcount inconsistency: found: 0 total: 1

[Alexander V . Chernikov]

03.11.2015, 17:05, "David Wolfskill" :
> This was on my laptop; yesterday, it built & booted:
>
> FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #230 
> r290270M/290270:1100085: Mon Nov 2 05:03:07 PST 2015 
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
>
> OK; today, after building:
>
> FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #231 
> r290334M/290334:1100086: Tue Nov 3 04:51:24 PST 2015 
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
>
> I tried booting it, and during the transition to multi-user mode,
> once ipfw was being invoked, I got the above-cited panic. Circumvention
> was to leave it disconnected from a network (turn off the WiFi
> switch, in my case), so we don't get a chance to use the network.
It is most probably related with r290334. Would you mind reverting it and 
checking if ipfw works correctly ?

>
> I was able to get a dump by explicitly typing "call doadump" -- an
> earlier attempt at "panic" didn't capture one. Stack trace:
>
> #0 doadump (textdump=0) at pcpu.h:221
> 221 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump (textdump=0) at pcpu.h:221
> #1 0x8037b6b6 in db_fncall (dummy1=,
> dummy2=, dummy3=,
> dummy4=) at /usr/src/sys/ddb/db_command.c:568
> #2 0x8037b14e in db_command (cmd_table=0x0)
> at /usr/src/sys/ddb/db_command.c:440
> #3 0x8037aee4 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:493
> #4 0x8037d97b in db_trap (type=, code=0)
> at /usr/src/sys/ddb/db_main.c:251
> #5 0x80a270f3 in kdb_trap (type=3, code=0, tf=)
> at /usr/src/sys/kern/subr_kdb.c:654
> #6 0x80db6668 in trap (frame=0xfe060bdde1d0)
> at /usr/src/sys/amd64/amd64/trap.c:549
> #7 0x80d961f7 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:234
> #8 0x80a267db in kdb_enter (why=0x812a5566 "panic",
> msg=0x80 ) at cpufunc.h:63
> #9 0x809ea01f in vpanic (fmt=,
> ap=) at /usr/src/sys/kern/kern_shutdown.c:750
> #10 0x809e9e76 in kassert_panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:647
> #11 0x80c2a788 in ipfw_rewrite_rule_uidx (chain=0x81be5310,
> ci=0xfe060bdde4b8) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:3395
> #12 0x80c267c3 in commit_rules (chain=0x81be5310,
> rci=0xfe060bdde4b8, count=1)
> at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:678
> #13 0x80c25d80 in add_rules (chain=0x81be5310,
> op3=, sd=)
> at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2594
> #14 0x80c232f4 in ipfw_ctl3 (sopt=0xfe060bdde920)
> at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:3242
> #15 0x80b3d8b1 in rip_ctloutput (so=,
> sopt=0xfe060bdde920) at /usr/src/sys/netinet/raw_ip.c:588
> #16 0x80a72bc6 in sogetopt (so=0xf80009e658b8,
> sopt=0xfe060bdde920) at /usr/src/sys/kern/uipc_socket.c:2731
> #17 0x80a7729e in kern_getsockopt (td=0xf800098119a0,
> s=, level=,
> name=, val=, valseg=464,
> valsize=0xfe060bdde98c) at /usr/src/sys/kern/uipc_syscalls.c:1540
> #18 0x80a771a0 in sys_getsockopt (td=0xf800098119a0,
> uap=0xfe060bddea40) at /usr/src/sys/kern/uipc_syscalls.c:1486
> #19 0x80db7519 in amd64_syscall (td=0xf800098119a0, traced=0)
> at subr_syscall.c:140
> #20 0x80d964db in Xfast_syscall ()
> at /usr/src/sys/amd64/amd64/exception.S:394
> #21 0x000800b2cbea in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language: auto; currently minimal
> (kgdb)
>
> I've copied the vmcore.z & core.txt.7 to
> ; gzipped
> copies are also available:
>
> Index of /~david/FreeBSD/head/ipfw
>
>  Icon Name Last modified Size Description
>   _
>  [PARENTDIR] Parent Directory -
>  [TXT] core.txt.7 2015-11-03 05:22 155K
>  [ ] core.txt.7.gz 2015-11-03 05:22 35K
>  [ ] vmcore.7 2015-11-03 05:22 528M
>  [ ] vmcore.7.gz 2015-11-03 05:22 45M
>   _
>
> I'll start taking a closer look at recent changes (e.g., in
> src/sys/netpfil/ipfw), but I'm not really all that familiar with
> the code.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous cowards.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic in arptimer in r289937

[Alexander V . Chernikov]

31.10.2015, 05:32, "Adrian Chadd" :
> Hiya,
>
> Here's a panic from arptimer:
Hi Adrian,

As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens 
after LLE_WUNLOCK().
So, it looks like (pre-cached) ifp had been freed before locking ifdata.
Do you have any more details on that? (e.g. was some interface detached at that 
moment, is it reproducible, etc..)

From a quick glance, potential use-after-free has been possible for quite a 
long time, but I wonder why it hasn't been observed before.
Probably lltable_free() changes might have triggered that.

I'll take a deeper look on that and reply.

>
> (kgdb) bt
> #0 doadump (textdump=0) at pcpu.h:221
> #1 0x803666b6 in db_fncall (dummy1=,
> dummy2=, dummy3=,
> dummy4=) at
> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
> #2 0x8036614e in db_command (cmd_table=0x0) at
> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440
> #3 0x80365ee4 in db_command_loop () at
> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493
> #4 0x8036897b in db_trap (type=, code=0)
> at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251
> #5 0x8096c0f3 in kdb_trap (type=9, code=0, tf= optimized out>) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654
> #6 0x80d34c81 in trap_fatal (frame=0xfe022815d7a0,
> eva=) at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829
> #7 0x80d34951 in trap (frame=) at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203
> #8 0x80d149f7 in calltrap () at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234
> #9 0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
> file=0x81211b1f
> "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c",
> line=205)
> at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261
> #10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at
> /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205
> #11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8,
> cc=0x81b2d480, direct=0) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722
> #12 0x80944f87 in softclock (arg=) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851
> #13 0x808f7eb6 in intr_event_execute_handlers (p= optimized out>, ie=0xf800035a6600) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262
> #14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275
> #15 0x808f57a4 in fork_exit (callout=0x808f84a0
> , arg=0xf800032c47c0, frame=0xfe022815dac0) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011
> #16 0x80d14f2e in fork_trampoline () at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609
> #17 0x in ?? ()
> Current language: auto; currently minimal
>
> (kgdb) print *(struct llentry *)c_arg
> $2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8},
> r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr =
> {__u6_addr8 = 0xf8005ecc4010 "�\024", __u6_addr16 =
> 0xf8005ecc4010,
> __u6_addr32 = 0xf8005ecc4010}}}, ll_addr = {mac_aligned =
> 110869256150596, mac16 = 0xf8005ecc4020, mac8 = 0xf8005ecc4020
> "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xf8005e867e00,
>   lle_head = 0xf8005e867dc8, lle_free = 0x80a2c5d0
> , la_hold = 0x0, la_numheld = 0, la_expire =
> 2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0,
> ln_router = 0, ln_ntick = 0,
>   lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0},
> lle_timer = {c_links = {le = {le_next = 0x0, le_prev =
> 0x81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
> tqe_prev = 0x81b2d588}},
> c_time = 9066299815445, c_precision = 322122525000, c_arg =
> 0xf8005ecc4000, c_func = 0x80a246e0 , c_lock =
> 0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object
> = {
>   lo_name = 0x8120fbce "lle", lo_flags = 90374144, lo_data
> = 0, lo_witness = 0xfeb53c80}, rw_lock = 1}}
>
> ..
>
> (kgdb) print *((struct llentry *)c_arg)->lle_tbl
> $4 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = -559038242,
> llt_hsize = -559038242, lle_head = 0xdeadc0dedeadc0de, llt_ifp =
> 0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de,
>   llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry =
> 0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de,
> llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de,
> llt_match_prefix = 0xdeadc0dedeadc0de,
>   llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry =
> 0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de,
> llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry =
> 

Re: panic in arptimer in r289937

[Alexander V . Chernikov]

31.10.2015, 16:46, "Adrian Chadd" <adr...@freebsd.org>:
> On 31 October 2015 at 09:34, Alexander V. Chernikov
> <melif...@freebsd.org> wrote:
>>  31.10.2015, 05:32, "Adrian Chadd" <adr...@freebsd.org>:
>>>  Hiya,
>>>
>>>  Here's a panic from arptimer:
>>  Hi Adrian,
>>
>>  As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which 
>> happens after LLE_WUNLOCK().
>>  So, it looks like (pre-cached) ifp had been freed before locking ifdata.
>>  Do you have any more details on that? (e.g. was some interface detached at 
>> that moment, is it reproducible, etc..)
>>
>>  From a quick glance, potential use-after-free has been possible for quite a 
>> long time, but I wonder why it hasn't been observed before.
>>  Probably lltable_free() changes might have triggered that.
>>
>>  I'll take a deeper look on that and reply.
>
> Hiya!
>
> Thanks for your quick response.
>
> I mean, I use wifi, and ARPs can get lost / transmit can get delayed /
> etc. I'm also testing through a MIPS CPU based bridge, so I'm also not
I remember that :)
> bridging at line rate. (The above is from one of the x86 laptops doing
> the traffic test.) These are both reasons why I may be poking at a
> path that you don't normally see. :)
Yup. So, once again, could you provide a bit more details? :)
Was it related with any interface being destroyed?
What was the test scenario (just bridging between interfaces?)
Is this reproducible?
>
> I appreciate you taking a very quick look at this!
>
> Thanks,
>
> -adrian
>
>>>  (kgdb) bt
>>>  #0 doadump (textdump=0) at pcpu.h:221
>>>  #1 0x803666b6 in db_fncall (dummy1=,
>>>  dummy2=, dummy3=,
>>>  dummy4=) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
>>>  #2 0x8036614e in db_command (cmd_table=0x0) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440
>>>  #3 0x80365ee4 in db_command_loop () at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493
>>>  #4 0x8036897b in db_trap (type=, code=0)
>>>  at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251
>>>  #5 0x8096c0f3 in kdb_trap (type=9, code=0, tf=>>  optimized out>) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654
>>>  #6 0x80d34c81 in trap_fatal (frame=0xfe022815d7a0,
>>>  eva=) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829
>>>  #7 0x80d34951 in trap (frame=) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203
>>>  #8 0x80d149f7 in calltrap () at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234
>>>  #9 0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
>>>  file=0x81211b1f
>>>  "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c",
>>>  line=205)
>>>  at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261
>>>  #10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205
>>>  #11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8,
>>>  cc=0x81b2d480, direct=0) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722
>>>  #12 0x80944f87 in softclock (arg=) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851
>>>  #13 0x808f7eb6 in intr_event_execute_handlers (p=>>  optimized out>, ie=0xf800035a6600) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262
>>>  #14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275
>>>  #15 0x808f57a4 in fork_exit (callout=0x808f84a0
>>>  , arg=0xf800032c47c0, frame=0xfe022815dac0) at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011
>>>  #16 0x80d14f2e in fork_trampoline () at
>>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609
>>>  #17 0x in ?? ()
>>>  Current language: auto; currently minimal
>>>
>>>  (kgdb) print *(struct llentry *)c_arg
>>>  $2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8},
>>>  r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr =
>>>  {__u6_addr8 = 0xf8005ecc4010 "�\024"

Re: r288951: ifconfig -alias, arp not removed

[Alexander V . Chernikov]

30.10.2015, 00:57, "Bryan Drewery" :
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>>  On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>>  On 10/29/2015 11:25, Bryan Drewery wrote:
  # ifconfig
  igb0: flags=8843 metric 0 mtu 1500

  
 options=403bb
  ether c8:0a:a9:04:39:78
  inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
  inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
  inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
  nd6 options=23
  media: Ethernet autoselect (1000baseT )
  status: active

  # ifconfig igb0 inet 10.10.0.9 -alias
  # arp -an|grep 10.10.0.9
  ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
  # arp -d 10.10.0.9
  arp: writing to routing socket: Operation not permitted

  I swear this is not normal. I'm on an older build as well, r288951.
Well, there were changes on arpscrub procedures in r287789.
(There was one bug fixed in r289501, but I think it is not relevant).
Could you consider trying more recent HEAD and check if this is still 
reproducible?
I was not able to reproduce that behavior.
>>>
>>>  That definitely looks abnormal. See what "route get" says. I think
>>>  that's the error you get when there is a route for that address.
>>
>>  # netstat -rn|grep 10.10.0.9
>>  # route get 10.10.0.9
>> route to: lapbox
>>  destination: 10.10.0.0
>> mask: 255.255.0.0
>>  fib: 0
>>    interface: igb0
>>    flags: 
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>  # route get 5.5.5.5
>> route to: 5.5.5.5
>>  destination: default
>> mask: default
>>  gateway: router.asus.com
>>  fib: 0
>>    interface: igb0
>>    flags: 
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>
>>  For more context, this current system had 10.10.0.9 added to it. I
>>  started up a VM which also started using 10.10.0.9 and managed to "win"
>>  on the local network for owning it. (I don't know arp and this stuff
>>  well). I then came to this system to remove the alias and the arp entry
>>  to allow me to connect from it and have gotten into this situation.
>
> Just saw this in dmesg, which is what I described:
>
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
>
> --
> Regards,
> Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel dtrace and current

[Alexander V . Chernikov]

13.09.2015, 23:54, "Mark Johnston" <ma...@freebsd.org>:
> On Sun, Sep 13, 2015 at 04:23:23PM +0300, Alexander V. Chernikov wrote:
>>  Hello all,
>>
>>  I keep running in
>>  "dtrace: failed to compile script: "/usr/lib/dtrace/psinfo.d", line 39: 
>> failed to copy type of 'pr_uid': Type information is in parent and 
>> unavailable"
>>  message more and more often while trying to trace different -current 
>> kernels.
>>
>>  Typically the reason besides that is the number of types embedded in kernel 
>> CTF:
>>  ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}'
>>  37160
>>
>>  We are bound to 32k of types by CTF format (and numbers above 32k (e.g.w/ 
>> highest bit set) are considered "child" types with the information stored in 
>> "parent").
>>  ctfmerge ignores this fact and instead of yelling emits type indices above 
>> 32k. On the other hand, libctf sees such indices while parsing sections and 
>> since there is no
>>  "parent" for kernel, it emits the error above and stops.
>>
>>  Thankfully, r287234 really improved the situation for ctfmerge, but there 
>> are still several thousands of identical structures and the total number is 
>> close to 32k.
>
> r281797 and r287234 should have fixed most instances of duplicate type
> definitions. At the moment, amd64 GENERIC and GENERIC-NODEBUG have
> roughly 25K types in their respective CTF containers; there is a small
> handful of duplicates, but at least some of them are legitimate (some
> pairs of drivers redefine the same types, e.g. aac(4)/aacraid(4) or
> mps(4)/mpr(4)).
>
> Could you post a config that results in the large number of duplicates
> you mention above?
I did clean buildworld/installworld w/ clean buildkernel and the situation is 
really much better now:
I've got only 27633 types, with 493 duplicates, so it is not _that_ close.
(So I suppose that for some reason I got old ctfmerge)

My config for that kernel:
include GENERIC
nomakeoptions   DEBUG
makeoptions DEBUG="-O2 -gdwarf-2"
options KTR
options KTR_MASK=(0)
options KDB_TRACE
options KDB_UNATTENDED
options BREAK_TO_DEBUGGER
options ALT_BREAK_TO_DEBUGGER
options MROUTING

>
>>  Personally I solved this by removing unneeded devices from 
>> GENERIC-inherited configs.
>>  I wonder, however if this can be handled better.
>
> FWIW, removing old drivers from GENERIC would be straightforward if we
> could auto-load KLDs based on device IDs.
>
>>  E.g. either show better error in dtrace(1) or make ctfmerge fail causing 
>> kernel build to stop (since we asked for dtrace but in reality it wouldn't 
>> work), or remove some stale devices from GENERIC, or .something totally 
>> different?
>
> One more radical option is to extend the width of CTF type IDs. I've
> been holding off on doing this for a few reasons:
> - Doing so would change the binary format, making us incompatible with
>   the reference CTF code in illumos.
> - Type IDs are embedded in quite a few places in the various CTF
>   structures, so enlarging them from 16 bits to 32 bits will bloat
>   CTF containers somewhat.
> - I was under the impression that r287234 addressed the problem
>   sufficiently for now.
>
> If type ID space is still a problem post-r287234, I think it's time to
> just go ahead and change the format. But first I'd like to understand
> the cause of the duplication you're seeing.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kernel dtrace and current

[Alexander V . Chernikov]

Hello all,

I keep running in
"dtrace: failed to compile script: "/usr/lib/dtrace/psinfo.d", line 39: failed 
to copy type of 'pr_uid': Type information is in parent and unavailable"
message more and more often while trying to trace different -current kernels.

Typically the reason besides that is the number of types embedded in kernel CTF:
ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}'
37160

We are bound to 32k of types by CTF format (and numbers above 32k (e.g.w/ 
highest bit set) are considered "child" types with the information stored in 
"parent").
ctfmerge ignores this fact and instead of yelling emits type indices above 32k. 
On the other hand, libctf sees such indices while parsing sections and since 
there is no
"parent" for kernel, it emits the error above and stops.

Thankfully, r287234 really improved the situation for ctfmerge, but there are 
still several thousands of identical structures and the total number is close 
to 32k.

Personally I solved this by removing unneeded devices from GENERIC-inherited 
configs.
I wonder, however if this can be handled better.

E.g. either show better error in dtrace(1) or make ctfmerge fail causing kernel 
build to stop (since we asked for dtrace but in reality it wouldn't work), or 
remove some stale devices from GENERIC, or .something totally different?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on kldload/kldunload in/near callout

[Alexander V . Chernikov]

12.09.2015, 20:30, "hiren panchasara" <hi...@strugglingcoder.info>:
> On 09/12/15 at 03:32P, Alexander V. Chernikov wrote:
>>  12.09.2015, 02:22, "hiren panchasara" <hi...@strugglingcoder.info>:
>>  > On 09/11/15 at 09:06P, Hans Petter Selasky wrote:
>
> [skip]
>>  > I'll try to get it. Meanwhile I am getting another panic on idle box:
>>  > http://pastebin.com/9qJTFMik
>>  The easiest explanation could be lack of lla_create() result check, fixed 
>> in r286945.
>>  This panic is triggered by fast interface down-up (or just up), when ARP 
>> packet is received but there are no (matching) IPv4 prefix on the interface.
>>  If this is not the case (e.g. it paniced w/o any interface changes and 
>> there were no other subnets in given L2 segment) I'd be happy to debug this 
>> further.
>
> Just hit another last night. (Box goes to db> ; let me know if you want
> to debug anything when that happens.)
Would you mind showing full backtrace for that core? (e.g. situation has to be 
different for newer -current).
> I am sure there were no interface changes on the box and it was sitting
> idle. (Unsure of the other subnets part.) And I am on 3 days old -head
> so I already have r286945. I disabled IPv6 on the box just to eliminate
> that but panic still happens.
>
> Cheers,
> Hiren
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on kldload/kldunload in/near callout

[Alexander V . Chernikov]

12.09.2015, 02:22, "hiren panchasara" :
> On 09/11/15 at 09:06P, Hans Petter Selasky wrote:
>>  On 09/10/15 21:23, hiren panchasara wrote:
>>  > I am on 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r286760M: Thu Sep 10
>>  > 08:15:43 MST 2015
>>  >
>>  > I get random (1 out of 10 tries) panics when I do:
>>  > # kldunload dummynet ; kldunload ipfw ;kldload ipfw ; kldload dummynet
>>  >
>>  > I used to get panics on a couple months old -head also.
>>  >
>>  > kernel trap 12 with interrupts disabled
>>  >
>>  > Fatal trap 12: page fault while in kernel mode
>>  > cpuid = 0; apic id = 00
>>  > fault virtual address = 0x8225cf58
>>  > fault code = supervisor read data, page not present
>>  > instruction pointer = 0x20:0x80aad500
>>  > stack pointer = 0x28:0xfe1f9d588700
>>  > frame pointer = 0x28:0xfe1f9d588790
>>  > code segment = base 0x0, limit 0xf, type 0x1b
>>  > = DPL 0, pres 1, long 1, def32 0, gran 1
>>  >
>>  > Following https://www.freebsd.org/doc/faq/advanced.html, I did:
>>  > # nm -n /boot/kernel/kernel | grep 80aad500
>>  > # nm -n /boot/kernel/kernel | grep 80aad50
>>  > # nm -n /boot/kernel/kernel | grep 80aad5
>>  > # nm -n /boot/kernel/kernel | grep 80aad
>>  > 80aad030 t itimers_event_hook_exec
>>  > 80aad040 t realtimer_expire
>>  > 80aad360 T callout_process
>>  > 80aad6b0 t softclock_call_cc
>>  > 80aadc10 T softclock
>>  > 80aadd20 T timeout
>>  > 80aade90 T callout_reset_sbt_on
>>  >
>>  > So I guess " 80aad360 T callout_process" is the closest match?
>>  >
>>  > I'll try to get real dump to get more information but that may take a
>>  > while.
>>  >
>>  > ccing jch and hans who've been playing in this area.
>>
>>  Hi,
>>
>>  Possibly it means some timer was not drained before the module was
>>  unloaded. It is not enough to only stop timers before freeing its
>>  memory. Or maybe a timer was restarted after drain.
>>
>>  Can you get the full backtrace and put debugging symbols into the kernel?
>
> I'll try to get it. Meanwhile I am getting another panic on idle box:
> http://pastebin.com/9qJTFMik
The easiest explanation could be lack of lla_create() result check, fixed in 
r286945.
This panic is triggered by fast interface down-up (or just up), when ARP packet 
is received but there are no (matching) IPv4 prefix on the interface.
If this is not the case (e.g. it paniced w/o any interface changes and there 
were no other subnets in given L2 segment) I'd be happy to debug this further.
>
> This "looks" similar to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156026 which got fixed
> via https://svnweb.freebsd.org/base?view=revision=r214675
> "Don't leak the LLE lock if the arptimer callout is pending or
> inactive."
>
> Is what I am seeing similar to this?
>
> I'll try and get more info.
>
> Cheers,
> Hiren
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Why does netstat not work in jails?

[Alexander V . Chernikov]

28.08.2015, 04:56, Chris H bsd-li...@bsdforge.com:
 I've been attempting to run jails on an 11-CURRENT
 for the purpose of building world/kernel  ports
 for all of our 9-STABLE production servers. I'm using
 standard/classic jail setup(s) -- not using any
 of the convenience ports/applications that abstract
 the process in any way.
 While everything seemed to go as intended/anticipated,
 I'm seeing things I *didn't* expect.
 The host network get's it's public IP from the router
 in front of it. From the router, I insure that it is
 allocated the same non-public IP everytime. So DHCP
 assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
 SSHD is started within the jail, root IS allowed login.
 But any attempt to ssh to 192.168.0.103 from the host,
 returns:
 ssh_exchange_identification: Connection closed by remote host.

 SSHD id NOT running on the host.

 inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
 is set on the host via rc.conf

 second issue; loging into the jail, via jexex. If I perform:
 netstat -nr
 The following is returned:
 netstat: kvm not available: /dev/mem: No such file or directory
 Routing tables
 rt_tables: symbol not in namelist

 Any thought's jump out at anyone?
Direct kvm interface was removed from head a year ago.
What you can do is recompiling netstat binary from 9 with NewTree variable 
defined to 1 and see if this helps.
Output will look  a bit different, but you'll be able to see routing tables 
from jail.
https://svnweb.freebsd.org/base/stable/9/usr.bin/netstat/route.c?revision=242025view=markup#l122

Another option is merging r261207 and r263335.


 Thanks!

 --Chris

 --

 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: The KASSERT from r282155 fired; have crash dump. will travel

[Alexander V . Chernikov]

30.04.2015, 15:31, David Wolfskill da...@catwhisker.org:
 From /var/crash/core.txt.6:

 Thu Apr 30 05:21:22 PDT 2015

 FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #47  r282269M/282269:1100071: Thu 
 Apr 30 05:07:08 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

 panic: refcount incosistency: found: 0 unr: 0 total: 1
Could you share your ruleset?
(And this panic should happen on one particular rule, could check this?)

Thank you.

 ...
 Unread portion of the kernel message buffer:
 ...
 Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
 Loaded symbols for /boot/kernel/if_lagg.ko.symbols
 #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
 ) at pcpu.h:219
 219 pcpu.h: No such file or directory.
 in pcpu.h
 (kgdb) #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
 ) at pcpu.h:219
 #1  0x80355f9e in db_dump (dummy=value optimized out, 
 dummy2=Unhandled dwarf expression opcode 0x93
 )
 at /usr/src/sys/ddb/db_command.c:533
 #2  0x80355b17 in db_command (cmd_table=0x0)
 at /usr/src/sys/ddb/db_command.c:440
 #3  0x80355794 in db_command_loop ()
 at /usr/src/sys/ddb/db_command.c:493
 #4  0x80358350 in db_trap (type=value optimized out, code=Unhandled 
 dwarf expression opcode 0x93
 )
 at /usr/src/sys/ddb/db_main.c:251
 #5  0x8096a1b4 in kdb_trap (type=Unhandled dwarf expression opcode 
 0x93
 ) at /usr/src/sys/kern/subr_kdb.c:654
 #6  0x80cd61fe in trap (frame=0xfe060cc04220)
 at /usr/src/sys/amd64/amd64/trap.c:540
 #7  0x80cb6702 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:235
 #8  0x8096988e in kdb_enter (why=0x80f5f68a panic,
 msg=0x80974750 
 UH\211åAWAVATSH\203ìPI\211÷A\211þH\213\004%Ðvd\201H\211EØ\201%x\206d\201) 
 at cpufunc.h:63
 #9  0x8092d949 in vpanic (fmt=value optimized out,
 ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:739
 #10 0x8092d792 in kassert_panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:634
 #11 0x80b56c11 in ipfw_rewrite_rule_uidx (chain=0x817b2be0,
 ci=0xfe060cc04508) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:3402
 #12 0x80b51613 in commit_rules (chain=0x817b2be0,
 rci=0xfe060cc04508, count=Unhandled dwarf expression opcode 0x93
 )
 at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:675
 #13 0x80b533ed in add_rules (chain=0x817b2be0,
 op3=value optimized out, sd=value optimized out)
 at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2589
 #14 0x80b4f9bb in ipfw_ctl3 (sopt=0xfe060cc04920)
 at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:3189
 #15 0x809be84e in kern_getsockopt (td=0xf8000a48b000,
 s=value optimized out, level=value optimized out,
 name=value optimized out, val=value optimized out, valseg=Unhandled 
 dwarf expression opcode 0x93
 )
 at /usr/src/sys/kern/uipc_syscalls.c:1531
 #16 0x809be750 in sys_getsockopt (td=0xf8000a48b000,
 uap=0xfe060cc04a40) at /usr/src/sys/kern/uipc_syscalls.c:1477
 #17 0x80cd714c in amd64_syscall (td=0xf8000a48b000, traced=0)
 at subr_syscall.c:133
 #18 0x80cb69eb in Xfast_syscall ()
 at /usr/src/sys/amd64/amd64/exception.S:395
 #19 0x000800b1caaa in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 (kgdb)
 

 I haven't tried i386 yet.  I can make the core.txt.6 file available.

 This was on my laptop, where I use ipfw in a failover LAGG environment.

 Anything else I can provide to help fix this?

 Peace,
 david
 --
 David H. Wolfskill da...@catwhisker.org
 Those who murder in the name of God or prophet are blasphemous cowards.

 See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD]

[Alexander V. Chernikov]

On 11.10.2014 18:15, David Wolfskill wrote:

On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote:

Hi,

I'm going to merge projects/ipfw branch to HEAD in the middle of next week.


OK; I was able to build  install head @r272938 this morning on my
laptop; on reboot, I was greeted by a panic.

Ups. Not the best greeting, definitely.

Can you send me ipfw ruleset?


Now, this is a laptop, so I don't have a serial console -- but I was
able to call doadump, then reboot with the wireless NIC disabled (to

Do you have some hooks to run ipfw on iface-up?

avoid the panic) and get the dump  core.txt captured.

Here's the first chunk of the core.txt file:

localhost dumped core - see /var/crash/vmcore.0

Sat Oct 11 07:02:26 PDT 2014

FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392  
r272938M/272938:1100037: Sat Oct 11 05:44:30 PDT 2014 
r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

panic: resize_storage() notify failure

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...

Unread portion of the kernel message buffer:
panic: resize_storage() notify failure
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c10ebfd8,d1070720,fc,1000,1,...) at 0xc0528cdd = 
db_trace_self_wrapper+0x2d/frame 0xfa0cc508
kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 = 
kdb_backtrace+0x30/frame 0xfa0cc570
vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d = 
vpanic+0x11d/frame 0xfa0cc5ac
kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a = 
kassert_panic+0xea/frame 0xfa0cc5d0
ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 
0xc0d25cfd = ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0
add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 = 
add_table_entry+0x348/frame 0xfa0cc7c8
manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b9 = 
manage_table_ent_v1+0x1c9/frame 0xfa0cc828
ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d = 
ipfw_ctl3+0xacd/frame 0xfa0ccb20
rip_ctloutput(d2432dc0,fa0ccbe0,,27f,1f,...) at 0xc0c3cf49 = 
rip_ctloutput+0x299/frame 0xfa0ccb48
sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 = 
sogetopt+0xb0/frame 0xfa0ccba8
kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 = 
kern_getsockopt+0x116/frame 0xfa0ccc0c
sys_getsockopt(d03afc40,fa08,c12ab55e,d5,c1455210,...) at 0xc0b71417 = 
sys_getsockopt+0x67/frame 0xfa0ccc40
syscall(fa0ccd08) at 0xc0f7c76b = syscall+0x31b/frame 0xfa0cccfc
Xint0x80_syscall() at 0xc0f665b1 = Xint0x80_syscall+0x21/frame 0xfa0cccfc
--- syscall (118, FreeBSD ELF32, sys_getsockopt), eip = 0x2815a3c7, esp = 
0xbfbfd2e4, ebp = 0xbfbfd300 ---
KDB: enter: panic

Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/kernel/coretemp.ko.symbols...done.
Loaded symbols for /boot/kernel/coretemp.ko.symbols
Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done.
Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/tmpfs.ko.symbols...done.
Loaded symbols for /boot/kernel/tmpfs.ko.symbols
Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
Loaded symbols for /boot/kernel/fdescfs.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
#0  doadump (textdump=0) at pcpu.h:233
233 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:233
#1  0xc0526acd in db_fncall (dummy1=-99826980, dummy2=0, dummy3=1573888,
 dummy4=0xfa0cc2b4 \036\211\220À¸\026MÁ)
 at /usr/src/sys/ddb/db_command.c:578
#2  0xc05267ab in db_command (cmd_table=value optimized out)
 at /usr/src/sys/ddb/db_command.c:449
#3  0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
#4  0xc0528e20 in db_trap (type=value optimized out,
 code=value optimized out) at /usr/src/sys/ddb/db_main.c:251
#5  0xc0b226f4 in kdb_trap (type=value optimized out,
 code=value optimized out, tf=value optimized out)
 at /usr/src/sys/kern/subr_kdb.c:654
#6  0xc0f7ba87 in trap (frame=value optimized out)
 at /usr/src/sys/i386/i386/trap.c:693
#7  0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169
#8  0xc0b21f7d in kdb_enter (why=0xc10e77dd panic,
 msg=value optimized out) at cpufunc.h:71
#9  0xc0ae7bb1 in vpanic (fmt=value optimized out, ap=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:739
#10

Re: HEADS UP: Merging projects/ipfw to HEAD

[Alexander V . Chernikov]

On 04 Oct 2014, at 16:35, Alexander V. Chernikov melif...@freebsd.org wrote:

 Hi,
 
 I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
Merged in r 272840.
 
 What has changed:
 
 Main user-visible changes are related to tables:
 
 * Tables are now identified by names, not numbers. There can be up to 65k 
 tables with up to 63-byte long names.
 * Tables are now set-aware (default off), so you can switch/move them 
 atomically with rules.
 * More functionality is supported (swap, lock, limits, user-level lookup, 
 batched add/del) by generic table code.
 * New table types are added (flow) so you can match multiple packet fields at 
 once.
 * Ability to add different type of lookup algorithms for particular table 
 type has been added.
 * New table algorithms are added (cidr:hash, iface:array, number:array and 
 flow:hash) to make certain types of lookup more effective.
 * Table value are now capable of holding multiple data fields for different 
 tablearg users
 
 Some examples (see ipfw(8) manual page for the description):
 
  0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port 
 algo flow:hash valtype skipto,fib
   0:02 [2] zfscurr0# ipfw table fl2 info
   +++ table(fl2), set(0) +++
kindex: 0, type: flow:src-ip,proto,dst-port
valtype: number, references: 0
algorithm: flow:hash
items: 0, size: 280
   0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12
   0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13
   0:02 [2] zfscurr0# ipfw table fl2 list
   +++ table(fl2), set(0) +++
   2a02:6b8::333,6,443 45000
   10.0.0.92,6,80 22000
   0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 
 'table(fl2)'
 
   ipfw table mi_test create type cidr algo cidr:hash masks=/30,/64
   ipfw table mi_test add 10.0.0.8/30
   ipfw table mi_test add 2a02:6b8:b010::1/64 25
 
   # ipfw table si add 1.1.1.1/32  2.2.2.2/32 
   added: 1.1.1.1/32 
   added: 2.2.2.2/32 
   # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 
   exists: 2.2.2.2/32 2200
   added: 4.4.4.4/32 
   ipfw: Adding record failed: record already exists
   ^ Returns error but keeps inserted items
   # ipfw table si list
   +++ table(si), set(0) +++
   1.1.1.1/32 
   2.2.2.2/32 
   4.4.4.4/32 
   # ipfw table si atomic add 3.3.3.3/32  4.4.4.4/32 4400 5.5.5.5/32 
   added(reverted): 3.3.3.3/32 
   exists: 4.4.4.4/32 4400
   ignored: 5.5.5.5/32 
   ipfw: Adding record failed: record already exists
   ^ Returns error and reverts added records
 
 Performance changes:
 * Main ipfw lock was converted to rmlock
 * Rule counters were separated from rule itself and made per-cpu.
 * Radix table entries fits into 128 bytes
 * struct ip_fw is now more compact so more rules will fit into 64 bytes
 * interface tables uses array of existing ifindexes for faster match
 
 ABI changes:
 All functionality supported by old ipfw(8) remains functional. Old  new 
 binaries can work together with the following restrictions:
 * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old 
 binaries
 * I'm a bit unsure about lookup src-port|dst-port N case, something may be 
 broken here. Anyway, this can be fixed for MFC
 
 Internal changes:.
 Changing table ids to numbers resulted in format modification for most 
 sockopt codes.
 Old sopt format was compact, but very hard to extend (no versioning, 
 inability to add more opcodes), so
 * All relevant opcodes were converted to TLV-based versioned IP_FW3-based 
 codes.
 * The remaining opcodes were also converted to be able to eliminate all older 
 opcodes at once
 * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly 
 to ease adding another communication methods
 * struct ip_fw is now different for kernel and userland
 * tablearg value has been changed to 0 to ease future extensions
 * table values are now indexes in special value array which holds extended 
 data for given index
 * Batched add/delete has been added to tables code
 * Most changes has been done to permit batched rule addition.
 * interface tracking API has been added (started on demand) to permit 
 effective interface tables operations
 * O(1) skipto cache, currently turned off by default at compile-time (eats 
 512K).
 
 * Several steps has been made towards making libipfw:
  * most of new functions were separated into parse/prepare/show and 
 actuall-do-stuff pieces (already merged).
  * there are separate functions for parsing text string into struct ip_fw 
 and printing struct ip_fw to supplied buffer (already merged).
 * Probably some more less significant/forgotten features
 
 ___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
 

___
freebsd-current@freebsd.org

HEADS UP: Merging projects/ipfw to HEAD

[Alexander V. Chernikov]

Hi,

I'm going to merge projects/ipfw branch to HEAD in the middle of next week.

What has changed:

Main user-visible changes are related to tables:

* Tables are now identified by names, not numbers. There can be up to 
65k tables with up to 63-byte long names.
* Tables are now set-aware (default off), so you can switch/move them 
atomically with rules.
* More functionality is supported (swap, lock, limits, user-level 
lookup, batched add/del) by generic table code.
* New table types are added (flow) so you can match multiple packet 
fields at once.
* Ability to add different type of lookup algorithms for particular 
table type has been added.
* New table algorithms are added (cidr:hash, iface:array, number:array 
and flow:hash) to make certain types of lookup more effective.
* Table value are now capable of holding multiple data fields for 
different tablearg users


Some examples (see ipfw(8) manual page for the description):

  0:02 [2] zfscurr0# ipfw table fl2 create type 
flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib

   0:02 [2] zfscurr0# ipfw table fl2 info
   +++ table(fl2), set(0) +++
kindex: 0, type: flow:src-ip,proto,dst-port
valtype: number, references: 0
algorithm: flow:hash
items: 0, size: 280
   0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12
   0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13
   0:02 [2] zfscurr0# ipfw table fl2 list
   +++ table(fl2), set(0) +++
   2a02:6b8::333,6,443 45000
   10.0.0.92,6,80 22000
   0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 
flow 'table(fl2)'


   ipfw table mi_test create type cidr algo cidr:hash masks=/30,/64
   ipfw table mi_test add 10.0.0.8/30
   ipfw table mi_test add 2a02:6b8:b010::1/64 25

   # ipfw table si add 1.1.1.1/32  2.2.2.2/32 
   added: 1.1.1.1/32 
   added: 2.2.2.2/32 
   # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 
   exists: 2.2.2.2/32 2200
   added: 4.4.4.4/32 
   ipfw: Adding record failed: record already exists
   ^ Returns error but keeps inserted items
   # ipfw table si list
   +++ table(si), set(0) +++
   1.1.1.1/32 
   2.2.2.2/32 
   4.4.4.4/32 
   # ipfw table si atomic add 3.3.3.3/32  4.4.4.4/32 4400 
5.5.5.5/32 

   added(reverted): 3.3.3.3/32 
   exists: 4.4.4.4/32 4400
   ignored: 5.5.5.5/32 
   ipfw: Adding record failed: record already exists
   ^ Returns error and reverts added records

Performance changes:
* Main ipfw lock was converted to rmlock
* Rule counters were separated from rule itself and made per-cpu.
* Radix table entries fits into 128 bytes
* struct ip_fw is now more compact so more rules will fit into 64 bytes
* interface tables uses array of existing ifindexes for faster match

ABI changes:
All functionality supported by old ipfw(8) remains functional. Old  new 
binaries can work together with the following restrictions:
* Tables named other than ^\d+$ are shown as table(65535) in ruleset in 
old binaries
* I'm a bit unsure about lookup src-port|dst-port N case, something 
may be broken here. Anyway, this can be fixed for MFC


Internal changes:.
Changing table ids to numbers resulted in format modification for most 
sockopt codes.
Old sopt format was compact, but very hard to extend (no versioning, 
inability to add more opcodes), so
* All relevant opcodes were converted to TLV-based versioned 
IP_FW3-based codes.
* The remaining opcodes were also converted to be able to eliminate all 
older opcodes at once
* All IP_FW3 handlers uses special API instead of calling sooptcopy* 
directly to ease adding another communication methods

* struct ip_fw is now different for kernel and userland
* tablearg value has been changed to 0 to ease future extensions
* table values are now indexes in special value array which holds 
extended data for given index

* Batched add/delete has been added to tables code
* Most changes has been done to permit batched rule addition.
* interface tracking API has been added (started on demand) to permit 
effective interface tables operations
* O(1) skipto cache, currently turned off by default at compile-time 
(eats 512K).


* Several steps has been made towards making libipfw:
  * most of new functions were separated into parse/prepare/show and 
actuall-do-stuff pieces (already merged).
  * there are separate functions for parsing text string into struct 
ip_fw and printing struct ip_fw to supplied buffer (already merged).

* Probably some more less significant/forgotten features

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Looping during boot-up process in FreeBSD-11 current

[Alexander V. Chernikov]

On 01.10.2014 02:02, Mike. wrote:
 On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote:
 
 
 |[snip]
 |Try the 271146,
 |[snip]
  =

This might be related with r271207.
Can you try r271206 (or any recent HEAD with reverted r271207) ?

 
 
 I installed the 10.0 release CD.
 
 Then (after installing pkg, svn, etc.):
 
 
 cd /usr/src
 
 svn update -r271146
 
 make buildkernel
 
 make installkernel
 
 reboot
 
 
 I got to the login prompt, so it did not exhibit the looping issue
 I've experienced.
 
 /usr/src/UPDATING shows  20140708 p7  as the latest patch for the
 source.
 
 dmesg (with boot -v) follows:
 (note: when I boot 11.0-current with boot -v, the looping begins
 right after the place where the GEOM: new disk cd0 line appears in
 the dmesg below)
 
 
 
 
 Copyright (c) 1992-2014 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
 1994
   The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 10.0-RELEASE-p7 #0 r271146: Tue Sep 30 16:38:12 EDT 2014
 root@a31pf:/usr/obj/usr/src/sys/GENERIC i386
 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
 Preloaded elf kernel /boot/kernel/kernel at 0xc1678000.
 Calibrating TSC clock ... TSC clock: 1698592154 Hz
 CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.59-MHz 686-class
 CPU)
   Origin = GenuineIntel  Id = 0xf24  Family = 0xf  Model =
 0x2  Stepping = 4
   Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PG
 E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM
 
 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64
 entries
 Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries
 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64
 byte line size
 Trace cache: 12K-uops, 8-way set associative
 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64
 byte line size
 real memory  = 1073741824 (1024 MB)
 Physical memory chunk(s):
 0x1000 - 0x0009dfff, 643072 bytes (157 pages)
 0x0010 - 0x003f, 3145728 bytes (768 pages)
 0x01826000 - 0x3ee0efff, 1029607424 bytes (251369
 pages)
 avail memory = 1029230592 (981 MB)
 XEN: CPU 0 has VCPU ID 4294967295
 bios32: Found BIOS32 Service Directory header at 0xc00f7030
 bios32: Entry = 0xfd7e0 (c00fd7e0)  Rev = 0  Len = 1
 pcibios: PCI BIOS entry at 0xfd770+0x18e
 pnpbios: Found PnP BIOS data at 0xc00f7090
 pnpbios: Entry = f:9d76  Rev = 1.0
 pnpbios: Event flag at 4b4
 Other BIOS signatures found:
 ULE: setup cpu 0
 wlan: 802.11 Link Layer
 snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32]
 c=0x03ff [1024]
 feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5
 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25
 Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present
 Hardware, Intel IvyBridge+ RNG: RDRAND is not present
 kbd: new array size 4
 kbd1 at kbdmux0
 mem: memory
 Pentium Pro MTRR support enabled
 nfslock: pseudo-device
 null: null device, zero device
 Falling back to Software, Yarrow random adaptor
 random: Software, Yarrow initialized
 VESA: INT 0x10 vector 0xc000:0x206c
 VESA: information block
    56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00
 0010   00 01 ff 03 00 01 19 01 00 01 2f 01 00 01 34 01
 0020   00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01
 0030   94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01
 0040   b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01
 0050   c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01
 0060   10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01
 0070   22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01
 0080   1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01
 0090   72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00
 00a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00c0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0100   41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44
 0110   45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63
 0120   68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50
 0130   37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00
 0140   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0150   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0160   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0170   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0180   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0190   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 01a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 01b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 01c0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 01d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 01e0   00 00 00 00 00 00 00 00 00 00 00 00 

Re: dhclient sucks cpu usage...

[Alexander V. Chernikov]

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

So, after finding out that nc has a stupidly small buffer size (2k
even though there is space for 16k), I was still not getting as good
as performance using nc between machines, so I decided to generate some
flame graphs to try to identify issues...  (Thanks to who included a
full set of modules, including dtraceall on memstick!)

So, the first one is:
https://www.funkthat.com/~jmg/em.stack.svg

As I was browsing around, the em_handle_que was consuming quite a bit
of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
me that the taskqueue for em was consuming about 50% cpu...  Also pretty
high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
or anything, but I think dhclient uses bpf to be able to inject packets
and listen in on them, so I kill off dhclient, and instantly, the taskqueue
thread for em drops down to 40% CPU... (transfer rate only marginally
improves, if it does)

I decide to run another flame graph w/o dhclient running:
https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

and now _rxeof drops from 17.22% to 11.94%, pretty significant...

So, if you care about performance, don't run dhclient...


Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

Hm, pretty interesting.
dhclient should setup proper filter (and it looks like it does so:
13:10 [0] m@ptichko s netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1224em0 -ifs--l  41225922 011 0 0 dhclient
)
see match count.
And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for 
each consumer on interface).

It should not introduce significant performance penalties.



diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index cb3ed27..9751986 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -2013,9 +2013,11 @@ bpf_gettime(struct bintime *bt, int tstype, struct mbuf 
*m)
return (BPF_TSTAMP_EXTERN);
}
}
+#if 0
if (quality == BPF_TSTAMP_NORMAL)
binuptime(bt);
else
+#endif

bpf_getttime() is called IFF packet filter matches some traffic.
Can you show your netstat -B output ?

getbinuptime(bt);
  
  	return (quality);




--
   John-Mark Gurney Voice: +1 415 225 5579

  All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: dhclient sucks cpu usage...

[Alexander V. Chernikov]

On 10.06.2014 20:24, John-Mark Gurney wrote:

Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17 +0400:

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

So, after finding out that nc has a stupidly small buffer size (2k
even though there is space for 16k), I was still not getting as good
as performance using nc between machines, so I decided to generate some
flame graphs to try to identify issues...  (Thanks to who included a
full set of modules, including dtraceall on memstick!)

So, the first one is:
https://www.funkthat.com/~jmg/em.stack.svg

As I was browsing around, the em_handle_que was consuming quite a bit
of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
me that the taskqueue for em was consuming about 50% cpu...  Also pretty
high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
or anything, but I think dhclient uses bpf to be able to inject packets
and listen in on them, so I kill off dhclient, and instantly, the
taskqueue
thread for em drops down to 40% CPU... (transfer rate only marginally
improves, if it does)

I decide to run another flame graph w/o dhclient running:
https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

and now _rxeof drops from 17.22% to 11.94%, pretty significant...

So, if you care about performance, don't run dhclient...


Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

Hm, pretty interesting.
dhclient should setup proper filter (and it looks like it does so:
13:10 [0] m@ptichko s netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1224em0 -ifs--l  41225922 011 0 0 dhclient
)
see match count.
And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
each consumer on interface).
It should not introduce significant performance penalties.

Don't forget that it has to process the returning ack's... So, you're
Well, it can be still captured with the proper filter like ip  udp  
port 67 or port 68.
We're using tcpdump on high packet ratios (1M) and it does not 
influence process _much_.
We should probably convert its rwlock to rmlock and use per-cpu counters 
for statistics, but that's a different story.

looking around 10k+ pps that you have to handle and pass through the
filter...  That's a lot of packets to process...

Just for a bit more double check, instead of using the HD as a
source, I used /dev/zero...   I ran a netstat -w 1 -I em0 when
running the test, and I was getting ~50.7MiB/s w/ dhclient running and
then I killed dhclient and it instantly jumped up to ~57.1MiB/s.. So I
launched dhclient again, and it dropped back to ~50MiB/s...
dhclient uses different BPF sockets for reading and writing (and it 
moves write socket to privileged child process via fork().
The problem we're facing with is the fact that dhclient does not set 
_any_ read filter on write socket:

21:27 [0] zfscurr0# netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1529em0 --fs--l 86774 86769 86784  4044  3180 dhclient
--- ^ --
 1526em0 -ifs--l 86789 0 1 0 0 dhclient

so all traffic is pushed down introducing contention on BPF descriptor 
mutex.


(That's why I've asked for netstat -B output.)

Please try an attached patch to fix this. This is not the right way to 
fix this, we'd better change BPF behavior not to attach to interface 
readers for write-only consumers.
This have been partially implemented as net.bpf.optimize_writers hack, 
but it does not work for all direct BPF consumers (which are not using 
pcap(3) API).




and some of this slowness is due to nc using small buffers which I will
fix shortly..

And with witness disabled it goes from 58MiB/s to 65.7MiB/s..  In
both cases, that's a 13% performance improvement by running w/o
dhclient...

This is using the latest memstick image, r266655 on a (Lenovo T61):
FreeBSD 11.0-CURRENT #0 r266655: Sun May 25 18:55:02 UTC 2014
 r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Core(TM)2 Duo CPU T7300  @ 2.00GHz (1995.05-MHz K8-class CPU)
   Origin=GenuineIntel  Id=0x6fb  Family=0x6  Model=0xf  Stepping=11
   
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
   AMD Features

Re: dhclient sucks cpu usage...

[Alexander V. Chernikov]

On 10.06.2014 22:11, Bryan Venteicher wrote:


- Original Message -

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

So, after finding out that nc has a stupidly small buffer size (2k
even though there is space for 16k), I was still not getting as good
as performance using nc between machines, so I decided to generate some
flame graphs to try to identify issues...  (Thanks to who included a
full set of modules, including dtraceall on memstick!)

So, the first one is:
https://www.funkthat.com/~jmg/em.stack.svg

As I was browsing around, the em_handle_que was consuming quite a bit
of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
me that the taskqueue for em was consuming about 50% cpu...  Also pretty
high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
or anything, but I think dhclient uses bpf to be able to inject packets
and listen in on them, so I kill off dhclient, and instantly, the
taskqueue
thread for em drops down to 40% CPU... (transfer rate only marginally
improves, if it does)

I decide to run another flame graph w/o dhclient running:
https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

and now _rxeof drops from 17.22% to 11.94%, pretty significant...

So, if you care about performance, don't run dhclient...


Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

Hm, pretty interesting.
dhclient should setup proper filter (and it looks like it does so:
13:10 [0] m@ptichko s netstat -B
Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   1224em0 -ifs--l  41225922 011 0 0 dhclient
)
see match count.
And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
each consumer on interface).
It should not introduce significant performance penalties.



It will be a bit before I'm able to capture that. Here's a Flamegraph from
earlier in the year showing an absurd amount of time spent in bpf_mtap():

Can you briefly describe test setup?
(Actually I'm interested in overall pps rate, bpf filter used and match 
ratio).


For example, for some random box at $work:
22:17 [0] m@sas1-fw1 netstat -I vlan802 -w1
input  (vlan802)   output
   packets  errs idrops  bytespackets  errs  bytes colls
430418 0 0  337712454 396282 0  333207773 0
CPU:  0.4% user,  0.0% nice,  1.2% system, 15.9% interrupt, 82.5% idle

2:17 [0] sas1-fw1# tcpdump -i vlan802 -lnps0 icmp and host X.X.X.X
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan802, link-type EN10MB (Ethernet), capture size 65535 bytes
22:17:14.866085 IP X.X.X.X  Y.Y.Y.Y: ICMP echo request, id 6730, seq 1, 
length 64


22:17 [0] m@sas1-fw1 s netstat -B 2/dev/null | grep tcpdump
98520 vlan802 ---s---  27979422 040 0 0 tcpdump

CPU:  0.9% user,  0.0% nice,  2.7% system, 17.6% interrupt, 78.8% idle
(Actually the load is floating due to bursty traffic in 14-20% rate but 
I can't see much difference with tcpdump turned on/off).




http://people.freebsd.org/~bryanv/vtnet/vtnet-bpf-10.svg



diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index cb3ed27..9751986 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -2013,9 +2013,11 @@ bpf_gettime(struct bintime *bt, int tstype, struct
mbuf *m)
return (BPF_TSTAMP_EXTERN);
}
}
+#if 0
if (quality == BPF_TSTAMP_NORMAL)
binuptime(bt);
else
+#endif

bpf_getttime() is called IFF packet filter matches some traffic.
Can you show your netstat -B output ?

getbinuptime(bt);
   
   	return (quality);




--
John-Mark GurneyVoice: +1 415 225 5579

   All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org





___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: dhclient sucks cpu usage...

[Alexander V. Chernikov]

On 10.06.2014 22:56, John-Mark Gurney wrote:
 Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 21:33 +0400:
 On 10.06.2014 20:24, John-Mark Gurney wrote:
 Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17 
 +0400:
 On 10.06.2014 07:03, Bryan Venteicher wrote:
 Hi,

 - Original Message -
 So, after finding out that nc has a stupidly small buffer size (2k
 even though there is space for 16k), I was still not getting as good
 as performance using nc between machines, so I decided to generate some
 flame graphs to try to identify issues...  (Thanks to who included a
 full set of modules, including dtraceall on memstick!)

 So, the first one is:
 https://www.funkthat.com/~jmg/em.stack.svg

 As I was browsing around, the em_handle_que was consuming quite a bit
 of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
 me that the taskqueue for em was consuming about 50% cpu...  Also pretty
 high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
 consuming ~3.18% (under ether_nh_input)..  I know I'm not running 
 tcpdump
 or anything, but I think dhclient uses bpf to be able to inject packets
 and listen in on them, so I kill off dhclient, and instantly, the
 taskqueue
 thread for em drops down to 40% CPU... (transfer rate only marginally
 improves, if it does)

 I decide to run another flame graph w/o dhclient running:
 https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

 and now _rxeof drops from 17.22% to 11.94%, pretty significant...

 So, if you care about performance, don't run dhclient...

 Yes, I've noticed the same issue. It can absolutely kill performance
 in a VM guest. It is much more pronounced on only some of my systems,
 and I hadn't tracked it down yet. I wonder if this is fallout from
 the callout work, or if there was some bpf change.

 I've been using the kludgey workaround patch below.
 Hm, pretty interesting.
 dhclient should setup proper filter (and it looks like it does so:
 13:10 [0] m@ptichko s netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1224em0 -ifs--l  41225922 011 0 0 dhclient
 )
 see match count.
 And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
 each consumer on interface).
 It should not introduce significant performance penalties.
 Don't forget that it has to process the returning ack's... So, you're
 Well, it can be still captured with the proper filter like ip  udp  
 port 67 or port 68.
 We're using tcpdump on high packet ratios (1M) and it does not 
 influence process _much_.
 We should probably convert its rwlock to rmlock and use per-cpu counters 
 for statistics, but that's a different story.
 looking around 10k+ pps that you have to handle and pass through the
 filter...  That's a lot of packets to process...

 Just for a bit more double check, instead of using the HD as a
 source, I used /dev/zero...   I ran a netstat -w 1 -I em0 when
 running the test, and I was getting ~50.7MiB/s w/ dhclient running and
 then I killed dhclient and it instantly jumped up to ~57.1MiB/s.. So I
 launched dhclient again, and it dropped back to ~50MiB/s...
 dhclient uses different BPF sockets for reading and writing (and it 
 moves write socket to privileged child process via fork().
 The problem we're facing with is the fact that dhclient does not set 
 _any_ read filter on write socket:
 21:27 [0] zfscurr0# netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1529em0 --fs--l 86774 86769 86784  4044  3180 dhclient
 --- ^ --
  1526em0 -ifs--l 86789 0 1 0 0 dhclient

 so all traffic is pushed down introducing contention on BPF descriptor 
 mutex.

 (That's why I've asked for netstat -B output.)

 Please try an attached patch to fix this. This is not the right way to 
 fix this, we'd better change BPF behavior not to attach to interface 
 readers for write-only consumers.
 This have been partially implemented as net.bpf.optimize_writers hack, 
 but it does not work for all direct BPF consumers (which are not using 
 pcap(3) API).
 
 Ok, looks like this patch helps the issue...
 
 netstat -B; sleep 5; netstat -B:
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   958em0 --fs--l   3881435  3868  2236 dhclient
   976em0 -ifs--l   3880014 0 1 0 0 dhclient
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   958em0 --fs--l   41785251435  3868  2236 dhclient
   976em0 -ifs--l   4178539 0 1 0 0 dhclient
 
 and now the rate only drops from ~66MiB/s to ~63MiB/s when dhclient is
 running...  Still a significant drop (5%), but better than before...
Interesting.
Can you provide some traces (pmc or dtrace ones)?

I'm unsure if this will help, but it's

Re: New and exciting panic, possibly re(4)

[Alexander V. Chernikov]

On 07.05.2014 23:24, Sean Bruno wrote:

While screwing around with comcast, I can trivially get this panic out
of my desktop machine, and am very confused.  It seems to happen on link
change up/down events.  I'm running 11.0-CURRENT FreeBSD 11.0-CURRENT #5
r265280M.  I don't have any direct evidence that this is re(4), just a

I'm sorry, that's my fault :)
Commit r265279 has introduced panic on IPv4 address removal.
That was fixed in r265288.

hunch from some discussions in clusteradm@

This can happen when reconnecting my modem or simply issues a netif
restart.

Fatal trap 9: general protection fault while in kernel mode
cpuid = 5; apic id = 15
instruction pointer = 0x20:0x80a4429e
stack pointer   = 0x28:0xfe046a7f5530
frame pointer   = 0x28:0xfe046a7f55d0
code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1306 (ifconfig)
trap number = 9
panic: general protection fault
cpuid = 5
KDB: stack backtrace:
#0 0x80998510 at kdb_backtrace+0x60
#1 0x80959d05 at panic+0x155
#2 0x80d9f2ff at trap_fatal+0x38f
#3 0x80d9ef5d at trap+0x74d
#4 0x80d82282 at calltrap+0x8
#5 0x80aa0aa1 at in_ifadownkill+0xd1
#6 0x80a412f0 at rn_walktree+0x80
#7 0x80aa0942 at in_ifadown+0xc2
#8 0x80a95591 at in_difaddr_ioctl+0x3a1
#9 0x80a94763 at in_control+0x463
#10 0x80a3010c at ifioctl+0x145c
#11 0x809b1a5d at kern_ioctl+0x3cd
#12 0x809b163c at sys_ioctl+0x13c
#13 0x80d9fd1b at amd64_syscall+0x3fb
#14 0x80d8256b at Xfast_syscall+0xfb
Uptime: 10m12s
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
Loaded symbols for /boot/kernel/fdescfs.ko.symbols
Reading symbols from /boot/modules/vboxguest.ko...done.
Loaded symbols for /boot/modules/vboxguest.ko
Reading symbols from /boot/modules/vboxvideo.ko...done.
Loaded symbols for /boot/modules/vboxvideo.ko
Reading symbols from /boot/kernel/drm.ko.symbols...done.
Loaded symbols for /boot/kernel/drm.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/uhid.ko.symbols...done.
Loaded symbols for /boot/kernel/uhid.ko.symbols
#0  doadump (textdump=value optimized out) at pcpu.h:219
219 pcpu.h: No such file or directory.
 in pcpu.h
(kgdb) #0  doadump (textdump=value optimized out) at pcpu.h:219
#1  0x80959888 in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:449
#2  0x80959d44 in panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:756
#3  0x80d9f2ff in trap_fatal (frame=value optimized out,
 eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:882
#4  0x80d9ef5d in trap (frame=value optimized out)
 at /usr/src/sys/amd64/amd64/trap.c:224
#5  0x80d82282 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:231
#6  0x80a4429e in rt_expunge (rnh=0x7f000210,
 rt=0xf800148e10c8) at /usr/src/sys/net/route.c:930
#7  0x80aa0aa1 in in_ifadownkill (rn=0xf800148e10c8,
 xap=0xfe046a7f5660) at /usr/src/sys/netinet/in_rmx.c:414
#8  0x80a412f0 in rn_walktree (h=value optimized out,
 f=0x80aa09d0 in_ifadownkill, w=0xfe046a7f5660)
 at /usr/src/sys/net/radix.c:1097
#9  0x80aa0942 in in_ifadown (ifa=0xf8000d542300, delete=1)
 at /usr/src/sys/netinet/in_rmx.c:447
#10 0x80a95591 in in_difaddr_ioctl (data=value optimized out,
 ifp=0xf8000d249000, td=value optimized out)
 at /usr/src/sys/netinet/in.c:580
#11 0x80a94763 in in_control (so=value optimized out,
 cmd=value optimized out, data=0xf80126c642c0 lo0,
 ifp=0xf8000d249000, td=0xf80108ad6000)
 at /usr/src/sys/netinet/in.c:219
#12 0x80a3010c in ifioctl (so=0xf80014839700,
cmd=2149607705,
 data=0xf80126c642c0 lo0, td=0xf80108ad6000)
 at /usr/src/sys/net/if.c:2638
#13 0x809b1a5d in kern_ioctl (td=0xf80108ad6000,
 fd=value optimized out, com=0) at file.h:323
#14 0x809b163c in sys_ioctl (td=0xf80108ad6000,
 

Re: r265279 causes gpf at sys/net/route.c:930

[Alexander V. Chernikov]

On 04.05.2014 00:02, Trond Endrestøl wrote:
 Hi,
 
 I updated one of my amd64 base/head VMs this afternoon.
 It crashes in rt_expunge(), and I think r265279 is to blame.
 
 If someone's interested, here's the crash report:
 
 http://ximalas.info/~trond/amd64-head-VBOX-crash/r265283/core.txt.0
Thanks for the report.
I'll try to investigate.
 
 Another amd64 base/head VM I updated earlier this afternoon, runs 
 smoothly at r265275.
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r265279 causes gpf at sys/net/route.c:930

[Alexander V. Chernikov]

On 04.05.2014 00:06, Alexander V. Chernikov wrote:
 On 04.05.2014 00:02, Trond Endrestøl wrote:
 Hi,

 I updated one of my amd64 base/head VMs this afternoon.
 It crashes in rt_expunge(), and I think r265279 is to blame.

 If someone's interested, here's the crash report:

 http://ximalas.info/~trond/amd64-head-VBOX-crash/r265283/core.txt.0
 Thanks for the report.
 I'll try to investigate.
My bad.
Fixed in r265288.

Thank you for the report!

 Another amd64 base/head VM I updated earlier this afternoon, runs 
 smoothly at r265275.

 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: picking a new AF_* number for NETLINK ?

[Alexander V. Chernikov]

On 17.01.2014 03:19, Luigi Rizzo wrote:

In porting the kernel openvswitch code to FreeBSD we
have implemented netlink sockets, so we need to pick a

Wow, great!
How deep you're planning to go with netlink support?

E.g. sockets with NETLINK_GENERIC OVS-related CMDs, or NETLINK_ROUTE 
(and other families like FW) as well?

number to use for AF_NETLINK/PF_NETLINK in the messages.

Obviously we'd like ovs to be loadable as a module on existing
kernels, so i wonder if there are any restrictions on what we
can use -- specifically, whether we should make sure that

AF_NETLINK  AF_MAX

or that is irrelevant.

cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: interesting routing bug...

[Alexander V. Chernikov]

On 09.01.2014 05:18, John-Mark Gurney wrote:

Well, I was trying to manually add a route for a host on the local
network (I can explain why, but it doesn't matter) and I got this:

Hello!
There are several different kernel  userland bugs :)


# netstat -rnfinet
Routing tables

Internet:
DestinationGatewayFlagsNetif Expire
default192.168.0.14   UGS   re0
127.0.0.1  link#3 UHlo0
192.168.0.0/24 link#1 U re0
192.168.0.21   link#1 UHS   lo0
# route add -host 192.168.0.254 -interface re0 -link 04:4a:31:d3:95:dc
add net 192.168.0.254: gateway re0
-link specifier assumes no parameter, so the next argument is treated 
as netmask (since dst/gw are already supplied).

It is successfully parsed by getaddr() as AF_LINK sockaddr.

I've added additional check which requires dst/mask address families to 
be equal (r260472).


Historically, our kernel is a bit relaxed on checking validness for 
network masks:

it does not check family does not perform usual (addrmask == addr) check.
masked copy is performed instead. This is a bit tricky to fix since most 
in-kernel consumers are supplying non-masked address.

I'm going to fix this soon.



# netstat -rnfinet
Routing tables

Internet:
DestinationGatewayFlagsNetif Expire
0.0.0.00x2050090:2b:34:ab:bb:85  USre0

Basically kernel treats sockaddr_dl as non-contiguos mask.

default192.168.0.14   UGS   re0
10.0.0.0/8 link#2 Umsk0
10.42.42.21link#2 UHS   lo0
127.0.0.1  link#3 UHlo0
192.168.0.0/24 link#1 U re0
192.168.0.21   link#1 UHS   lo0
# route delete 0.0.0.0
delete net 0.0.0.0
# route flush
Our rtsock protocol does not provide rtable flush, so internally 
route(8) does route dump for given table and issues RTF_DELETE messages 
for every route.

It seems that non-contiguous masks are handled incorrectly here..

::   localhost-fib 0   done
:::0.0.0.0   localhost-fib 0   done
fe80::   localhost-fib 0   done
ff02::   localhost-fib 0   done
# netstat -rnfinet
Routing tables

Internet:
DestinationGatewayFlagsNetif Expire
0.0.0.00x2050090:2b:34:ab:bb:85  USre0
127.0.0.1  link#3 UHlo0
192.168.0.0/24 link#1 U re0
192.168.0.21   link#1 UHS   lo0

So, as you can see, I have managed to add a bogus route w/o a way
to remove it short of rebooting the box...  And because of this route,
You should be able to delete this using exactly the same command 
(s/add/del/).

some hosts like svn0.us-west.freebsd.org will match causing the machine
to try to find the ip on the local network.

This route I assume should be rejected by the kernel and not added,
or there is a mismatch between the route program and how the kernel
understands it.

I can provide more information upon request.

Thanks.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [rfc] migrate lagg to an rmlock

[Alexander V. Chernikov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24.08.2013 00:54, Adrian Chadd wrote:
 Hi,
 
 I'd like to commit this to -10. It migrates the if_lagg locking
 from a rw lock to a rm lock. We see a bit of contention between the
 transmit and
We're running lagg with rmlock on several hundred heavily loaded
machines, it really works better.
However, there should not be any contention between receive and
transmit side since there is actually no _real_ need to lock RX (and
even use lagg receive code at all):

http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html

 receive sides of lagg during traffic loads (10+ gigabit per
 second.) Using rmlocks eliminate this.
 
 http://people.freebsd.org/~adrian/netflix/20130819-lagg-rmlock-1.diff

  Thanks,
 
 
 -adrian ___ 
 freebsd-...@freebsd.org mailing list 
 http://lists.freebsd.org/mailman/listinfo/freebsd-net To
 unsubscribe, send any mail to
 freebsd-net-unsubscr...@freebsd.org
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIYqjYACgkQwcJ4iSZ1q2n9fgCePHOfC3tzBIG54ayNg7d8TKMC
gIMAn2/paUBpDIRVd+3s7snNFCmZNWgd
=i6Ye
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: (i)frame based sites cause horrible performence in firefox 14.0.1

[Alexander V. Chernikov]

On 15.08.2012 07:04, Aryeh Friedman wrote:

Sites that are based on frames or iframes (such as google mail and
most of google's non-search services) kill the performance of
www/firefox [firefox-14.0.1_1,1] (last updated yesterday on a 9.1
built at the same time) here is the uname:


Same for me, downgrading to 12.0.X makes things work as expected.

FreeBSD 9.0-STABLE FreeBSD 9.0-STABLE #3 r237606: Tue Jun 26 23:45:44 
MSK 2012 r...@dhcp170-36-red.yandex.net:/usr/obj/usr/src/sys/BIRDIE 
 amd64





FreeBSD XXX 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Thu Aug  9
15:54:37 EDT 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC  i386
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org




--
WBR, Alexander


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: null pointer panic in bpf_peers_present

[Alexander V. Chernikov]

On 04.06.2012 02:22, Andriy Gapon wrote:

on 03/06/2012 23:56 Andriy Gapon said the following:


I wonder if anybody else is seeing this and if there is a fix...
This is very recent (today's) FreeBSD head with pretty dull network
configuration.  During boot I run into the following panic:

118Setting hostname: x
118Starting dhclient.


My current guess is that the panic occurs because of the newly added (r235745)
bpf_ifdetach which is an ifnet_departure_event handler.  My rc.conf is
configured to do interface renaming and SIOCSIFNAME seems to post
ifnet_departure_event followed by ifnet_arrival_event.

Not sure if it's a window between ifnet_departure_event and ifnet_arrival_event
when if_bpf is NULL, or if if_bpf is never restored in this case.

if_bpf is never restored.

Can you please try an attached patch ?








Index: sys/net/bpf.c
===
--- sys/net/bpf.c   (revision 236540)
+++ sys/net/bpf.c   (working copy)
@@ -2542,13 +2542,23 @@ bpf_ifdetach(void *arg __unused, struct ifnet *ifp
 {
struct bpf_if *bp;
 
-   if ((bp = ifp-if_bpf) == NULL)
+   BPF_LOCK();
+   if ((bp = ifp-if_bpf) == NULL) {
+   BPF_UNLOCK();
return;
+   }
 
+   if ((bp-flags  BPFIF_FLAG_DYING) == 0) {
+   BPF_UNLOCK();
+   return;
+   }
+
CTR3(KTR_NET, %s: freing BPF instance %p for interface %p,
__func__, bp, ifp);
 
ifp-if_bpf = NULL;
+   BPF_UNLOCK();
+
rw_destroy(bp-bif_lock);
free(bp, M_BPF);
 }
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: bpf kernel crash

[Alexander V. Chernikov]

On 04.06.2012 18:31, Michael Pounov wrote:

Kernel crash when you wish to change interface name from vlan0 to other name

It seems to be in arrival/departure events.

Yes, this is already fixed in r236559.


--
WBR, Alexander
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MPLS in freebsd

[Alexander V. Chernikov]

On 06.05.2012 12:11, Kurt Jaeger wrote:

Hello,


is there any on-job work on MPLS support in FreeBSD?


Do you know this site ? It points to some svn repository with mpls patches.

http://freebsd.mpls.in/


Major number of depends are already merged to the tree.

I'm currently working to update control plane software (net/bird-devel) 
to current upstream code (1.3.7+). This probably happen in a week or two.


Patches for -current and stable/8 will be announced in another week 
after that.


The only supported technology at the moment is L3vpn for IPv4.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Some performance measurements on the FreeBSD network stack

[Alexander V. Chernikov]

On 20.04.2012 01:12, Andre Oppermann wrote:

On 19.04.2012 22:34, K. Macy wrote:

This is indeed a big problem. I'm working (rough edges remain) on
changing the routing table locking to an rmlock (read-mostly) which




This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the rtentry's reference count.


The rtentry lock isn't obtained anymore. While the rmlock read
lock is held on the rtable the relevant information like ifp and
such is copied out. No later referencing possible. In the end
any referencing of an rtentry would be forbidden and the rtentry
lock can be removed. The second step can be optional though.


i was wondering, is there a way (and/or any advantage) to use the
fastforward code to look up the route for locally sourced packets ?



If the number of peers is bounded then you can use the flowtable. Max
PPS is much higher bypassing routing lookup. However, it doesn't scale
From my experience, turning fastfwd on gives ~20-30% performance 
increase (10G forwarding with firewalling, 1.4MPPS). ip_forward() uses 2 
lookups (ip_rtaddr + ip_output) vs 1 ip_fastfwd().
The worst current problem IMHO is number of locks packet have to 
traverse, not number of lookups.



to arbitrary flow numbers.




In theory a rmlock-only lookup into a default-route only routing
table would be faster than creating a flow table entry for every
destination. It a matter of churn though. The flowtable isn't
lockless in itself, is it?




--
WBR, Alexander
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Problem with r233937 on i386

[Alexander V. Chernikov]

On 06.04.2012 16:09, David Wolfskill wrote:

Kernel build @ r233941 failed for me this morning, running:

FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #525 233918M: 
Thu Apr  5 04:42:37 PDT 2012 
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386


thus:

...
ototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fstack-protector -Werror  /usr/src/sys/net/bpf.c
/usr/src/sys/net/bpf.c: In function 'bpf_setf':
/usr/src/sys/net/bpf.c:1683: error: 'need_upgrade' undeclared (first use in 
this function)
/usr/src/sys/net/bpf.c:1683: error: (Each undeclared identifier is reported 
only once
/usr/src/sys/net/bpf.c:1683: error: for each function it appears in.)
*** [bpf.o] Error code 1

Stop in /common/S4/obj/usr/src/sys/CANARY.
*** [buildkernel] Error code 1

Stop in /usr/src.
*** [buildkernel] Error code 1

Stop in /usr/src.


Fixed in r233946. Thanks!


--
WBR, Alexander
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Thoughts on TMPFS no longer being considered highly experimental

[Alexander V. Chernikov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Jacob wrote:
 
 I gave up on using it after a brief try earlier this year. I can't
 remember the details, but it did lock up my amd64 system.
 
 On Thu, 23 Jun 2011, David O'Brien wrote:
 
 Does anyone object to this patch?

 David Wolfskill and I have run TMPFS on a number of machines for two
 years with no problems.

 I may have missed something, but I'm not aware of any serious PRs on
 TMPFS either.

There was some issues with sendfile(2) and mmap(2) causing kernel hangs
in some cases. vim triggers such hangs for me. However, those problems
were fixed and MFCed (afair).

I'm using tmpfs on several machines in production without any problems.
Maybe being _highly_ experimental for nearly 4 years is enough? :)




 Index: tmpfs_vfsops.c
 ===
 --- tmpfs_vfsops.c(revision 221113)
 +++ tmpfs_vfsops.c(working copy)
 @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
 return EOPNOTSUPP;
 }

 -printf(WARNING: TMPFS is considered to be a highly experimental 
 -feature in FreeBSD.\n);
 -
 vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY);
 error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred);
 VOP_UNLOCK(mp-mnt_vnodecovered, 0);

 -- 
 -- David  (obr...@freebsd.org)
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4Dg1cACgkQwcJ4iSZ1q2m3uACfcUoGrQeAZdAHDm8VnbKInzWI
gIoAn3SMoNAdABZ39GHS6HSyIHLXGNIt
=aXnk
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[patch] permit fib to be set on interface

[Alexander V. Chernikov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At the moment the only possible way to set packet fib from userland is
ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows
with every fib.
Additionally, there is no way to set packet fib before netgraph
processing: L2 ipfw hook is called after ng_ether_input()

Those reasons (not mentioning kern/134931) makes it hard to use multiple
routing tables.

The following path:
* adds SIOCGIFIB/SIOCSIFIB ioctl(2) calls to get/set per-interface fib
* adds IFF_CUSTOMFIB interface flags
* adds ifi_fib field to if_data structure
* adds 'fib' keyword for ifconfig(8)

Example:
16:42 [0] zfscurr0# ifconfig vlan2 create inet 10.11.12.13/30 fib 15
vlan 2 vlandev em0
16:42 [0] zfscurr0# ifconfig vlan2
vlan2: flags=808843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,CUSTOMFIB
metric 0 mtu 1500 fib 15
options=3RXCSUM,TXCSUM
ether 08:00:27:c5:29:d4
inet 10.11.12.13 netmask 0xfffc broadcast 10.11.12.15
inet6 fe80::a00:27ff:fec5:29d4%vlan2 prefixlen 64 scopeid 0x4
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active
vlan: 2 parent interface: em0


Interface fib is applied on inbound only (for forwarded packets fib
decision should be done on inbound, for locally-originated packets there
is setfib(1))

How to install:
** WARNING - world (libc actually) rebuild required !! **
Apply both patches (abi first)
rebuild kernel (ROUTETABLES define required)  world
reboot (you should have console access)
use ifconfig(8) to set fib

Comments on source code:

Since we need fib to be set before ng_ether_input() we cannot set fib on
per-netisr basis which is easier.

Patch is split into 2 pieces.

struct if_data is exported to userland via:
* rtsock sysctl_iflist() sysctl (used by libc getifaddr(3) only)
* ifmib(4) interfaces (used by bsnmpd and others)

abi_ifdata patch permits if_data changes (actually, tail-adding) without
ABI breaking (and it doesn't break ABI by itself)

fibs patch does the rest described.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3GlfwACgkQwcJ4iSZ1q2ncmQCfYT01sjTLcuxZsYyJA/hH7lFb
sjIAn3r5aXIhtMK5zxyBWOLm+vKYehfY
=PvjZ
-END PGP SIGNATURE-
Index: sbin/ifconfig/ifconfig.8
===
--- sbin/ifconfig/ifconfig.8(revision 221313)
+++ sbin/ifconfig/ifconfig.8(working copy)
@@ -294,6 +294,17 @@
 Fill interface index
 (lowermost 64bit of an IPv6 address)
 automatically.
+.It Cm fib Ar fib_number
+Specify interface fib. Fib 
+.Ar fib_number
+is assigned to all frames received on that interface. Fib is not inherited,
+e.g. vlans or other sub-interfaces gets default fib (0) irrespective of parent
+interface fib.
+.Ar CUSTOMFIB
+flag is added to interface flags if non-zero fib is set. Kernel needs to be 
compiled 
+with the option
+.Cd options ROUTETABLES
+for this to work.
 .It Cm ipdst
 This is used to specify an Internet host who is willing to receive
 IP packets encapsulating IPX packets bound for a remote network.
Index: sbin/ifconfig/ifconfig.c
===
--- sbin/ifconfig/ifconfig.c(revision 221313)
+++ sbin/ifconfig/ifconfig.c(working copy)
@@ -823,6 +823,16 @@
 }
 
 static void
+setifib(const char *val, int dummy __unused, int s, 
+const struct afswtch *afp)
+{
+   strncpy(ifr.ifr_name, name, sizeof (ifr.ifr_name));
+   ifr.ifr_fib = atoi(val);
+   if (ioctl(s, SIOCSIFIB, (caddr_t)ifr)  0)
+   warn(ioctl (set fib));
+}
+
+static void
 setifname(const char *val, int dummy __unused, int s, 
 const struct afswtch *afp)
 {
@@ -880,7 +890,7 @@
 #defineIFFBITS \
 \020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING \
 \10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2 \
-\20MULTICAST\22PPROMISC\23MONITOR\24STATICARP
+\20MULTICAST\22PPROMISC\23MONITOR\24STATICARP\30CUSTOMFIB
 
 #defineIFCAPBITS \
 \020\1RXCSUM\2TXCSUM\3NETCONS\4VLAN_MTU\5VLAN_HWTAGGING\6JUMBO_MTU\7POLLING \
@@ -919,6 +929,8 @@
printf( metric %d, ifr.ifr_metric);
if (ioctl(s, SIOCGIFMTU, ifr) != -1)
printf( mtu %d, ifr.ifr_mtu);
+   if (((ifa-ifa_flags  IFF_CUSTOMFIB)  0)  (ioctl(s, SIOCGIFIB, 
ifr) != -1))
+   printf( fib %d, ifr.ifr_fib);
putchar('\n');
 
for (;;) {
@@ -1169,6 +1181,7 @@
DEF_CMD(compress, IFF_LINK0,  setifflags),
DEF_CMD(noicmp,   IFF_LINK1,  setifflags),
DEF_CMD_ARG(mtu,  setifmtu),
+   DEF_CMD_ARG(fib,  setifib),
DEF_CMD_ARG(name, setifname),
 };
 
Index: share/man/man9/ifnet.9
===
--- share/man/man9/ifnet.9