Date: Fri, 11 Oct 2019 16:29:50 -0700 From: "Kristof Provost" <kp@FreeBSD.org> To: "Gleb Smirnoff" <glebius@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r353292 - in head/sys: contrib/ipfilter/netinet dev/firewire dev/iicbus dev/usb/net kern net netgraph netinet netinet6 netipsec netpfil/ipfw netpfil/pf ofed/drivers/infiniband/ulp/ipoib Message-ID: <8EC71856-75DA-4231-AB73-22AB6621E9F5@FreeBSD.org> In-Reply-To: <201910072240.x97Me60x065650@repo.freebsd.org> References: <201910072240.x97Me60x065650@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 Oct 2019, at 15:40, Gleb Smirnoff wrote: > Author: glebius > Date: Mon Oct 7 22:40:05 2019 > New Revision: 353292 > URL: https://svnweb.freebsd.org/changeset/base/353292 > > Log: > Widen NET_EPOCH coverage. > > When epoch(9) was introduced to network stack, it was basically > dropped in place of existing locking, which was mutexes and > rwlocks. For the sake of performance mutex covered areas were > as small as possible, so became epoch covered areas. > > However, epoch doesn't introduce any contention, it just delays > memory reclaim. So, there is no point to minimise epoch covered > areas in sense of performance. Meanwhile entering/exiting epoch > also has non-zero CPU usage, so doing this less often is a win. > > Not the least is also code maintainability. In the new paradigm > we can assume that at any stage of processing a packet, we are > inside network epoch. This makes coding both input and output > path way easier. > > On output path we already enter epoch quite early - in the > ip_output(), in the ip6_output(). > > This patch does the same for the input path. All ISR processing, > network related callouts, other ways of packet injection to the > network stack shall be performed in net_epoch. Any leaf function > that walks network configuration now asserts epoch. > > Tricky part is configuration code paths - ioctls, sysctls. They > also call into leaf functions, so some need to be changed. > > This patch would introduce more epoch recursions (see EPOCH_TRACE) > than we had before. They will be cleaned up separately, as several > of them aren't trivial. Note, that unlike a lock recursion the > epoch recursion is safe and just wastes a bit of resources. > > Reviewed by: gallatin, hselasky, cy, adrian, kristof > Differential Revision: https://reviews.freebsd.org/D19111 > This appears to have broken vlan. To reproduce do: sudo ifconfig epair create sudo ifconfig vlan create vlandev epair0a vlan 42 I see the following panic: panic: Assertion in_epoch(net_epoch_preempt) failed at /usr/src/sys/net/if_vlan.c:1353 cpuid = 5 time = 1570828155 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0060d894c0 vpanic() at vpanic+0x17e/frame 0xfffffe0060d89520 panic() at panic+0x43/frame 0xfffffe0060d89580 vlan_config() at vlan_config+0x599/frame 0xfffffe0060d895c0 vlan_clone_create() at vlan_clone_create+0x29b/frame 0xfffffe0060d89630 if_clone_createif() at if_clone_createif+0x4a/frame 0xfffffe0060d89680 ifioctl() at ifioctl+0x6f4/frame 0xfffffe0060d89750 kern_ioctl() at kern_ioctl+0x295/frame 0xfffffe0060d897b0 sys_ioctl() at sys_ioctl+0x15c/frame 0xfffffe0060d89880 amd64_syscall() at amd64_syscall+0x2b5/frame 0xfffffe0060d899b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0060d899b0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047dc2a, rsp = 0x7fffffffe1a8, rbp = 0x7fffffffe1b0 --- I guess that we need to enter net_epoch in vlan_clone_create(). Or perhaps that’s something that’s generically needed and it should be done on if_clone_createif(). Best regards, Kristof From owner-svn-src-head@freebsd.org Sat Oct 12 18:18:12 2019 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2685D140589; Sat, 12 Oct 2019 18:18:12 +0000 (UTC) (envelope-from philip@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rCjw0DSPz4PjP; Sat, 12 Oct 2019 18:18:12 +0000 (UTC) (envelope-from philip@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DC938772A; Sat, 12 Oct 2019 18:18:11 +0000 (UTC) (envelope-from philip@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x9CIIBDT096498; Sat, 12 Oct 2019 18:18:11 GMT (envelope-from philip@FreeBSD.org) Received: (from philip@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x9CIIBJE096497; Sat, 12 Oct 2019 18:18:11 GMT (envelope-from philip@FreeBSD.org) Message-Id: <201910121818.x9CIIBJE096497@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: philip set sender to philip@FreeBSD.org using -f From: Philip Paeps <philip@FreeBSD.org> Date: Sat, 12 Oct 2019 18:18:11 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r353453 - head/sys/riscv/riscv X-SVN-Group: head X-SVN-Commit-Author: philip X-SVN-Commit-Paths: head/sys/riscv/riscv X-SVN-Commit-Revision: 353453 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 12 Oct 2019 18:18:12 -0000 Author: philip Date: Sat Oct 12 18:18:11 2019 New Revision: 353453 URL: https://svnweb.freebsd.org/changeset/base/353453 Log: A comment in subr_devmap.c mentions that devmap_print_table() should be called on bootverbose. Do so on RISV-V too. Submitted by: Nicholas O'Brien <nickisobrien_gmail.com> Reviewed by: imp, kp Sponsored by: Axiado Differential Revision: https://reviews.freebsd.org/D21998 Modified: head/sys/riscv/riscv/machdep.c Modified: head/sys/riscv/riscv/machdep.c ============================================================================== --- head/sys/riscv/riscv/machdep.c Sat Oct 12 17:57:03 2019 (r353452) +++ head/sys/riscv/riscv/machdep.c Sat Oct 12 18:18:11 2019 (r353453) @@ -158,6 +158,8 @@ cpu_startup(void *dummy) printf("avail memory = %ju (%ju MB)\n", ptoa((uintmax_t)vm_free_count()), ptoa((uintmax_t)vm_free_count()) / (1024 * 1024)); + if (bootverbose) + devmap_print_table(); bufinit(); vm_pager_bufferinit();
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8EC71856-75DA-4231-AB73-22AB6621E9F5>