NET_MPSAFE [was Re: CVS commit: src/sys]
On 08/13/16 14:27, Ryota Ozaki wrote: On Fri, Aug 12, 2016 at 11:04 PM, Nick Hudson wrote: On 07/28/16 10:03, Ryota Ozaki wrote: Module Name:src Committed By: ozaki-r Date: Thu Jul 28 09:03:51 UTC 2016 Modified Files: src/sys/netinet: if_arp.c in.c src/sys/netinet6: in6.c nd6_nbr.c Log Message: Fix panic on adding/deleting IP addresses under network load Adding and deleting IP addresses aren't serialized with other network opeartions, e.g., forwarding packets. So if we add or delete an IP address under network load, a kernel panic may happen on manipulating network-related shared objects such as rtentry and rtcache. To avoid such panicks, we still need to hold softnet_lock in in_control and in6_control that are called via ioctl and do network-related operations including IP address additions/deletions. Fix PR kern/51356 Hi, This is contributory to the problems in http://gnats.netbsd.org/49065 http://gnats.netbsd.org/50491 http://gnats.netbsd.org/51395 Where softnet_lock is held by something that sleeps, e.g. a usb transfer. http://mail-index.netbsd.org/tech-net/2015/12/06/msg005443.html This patch http://www.netbsd.org/~skrll/usb.softint.diff helps, but I'm not sure it deals with all the problems in the network stack. Is this something you intend to address? No. The commit prevents parallel accesses on shared data (rtentry, ifaddr, etc.). The issue of USB transfers seem to be a deadlock between softints of the network stack and USB interrupt processing. I think we can commit your patch if it fixes the PRs and doesn't break anything. Of course we should get rid of softnet_lock at some point. Thanks, ozaki-r This is hurting me again. Can you, or someone else at iij, explain the plan to allow NET_MPSAFE to be enabled by default. Perhaps others can help if there are clear steps. Thanks, Nick
Re: CVS commit: src/sys/dev/pci
On 2016/11/28 11:23, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Mon Nov 28 02:23:33 UTC 2016 Modified Files: src/sys/dev/pci: files.pci src/sys/dev/pci/ixgbe: ixgbe.c ixgbe.h Added Files: src/sys/dev/pci/ixgbe: ix_txrx.c Log Message: FreeBSD r280181 made new file ix_txrx.c and moved ixgbe.c and ixv's common s/r280181/r280182/ code into it. Before sync with whole of them, just move ixgbe.c and ixv.c's common code into ix_txrx.c from ixgbe.c. In this commit, only ixgbe.c is split into the device dependent part and the common part. ixv.c isn't change to make this commit no functional change. To use ixv.c with ix_txrx.c, it's required to modify the common part's API and functions themselves. This commit is done to make the next change easy to understand. To generate a diff of this commit: cvs rdiff -u -r1.382 -r1.383 src/sys/dev/pci/files.pci cvs rdiff -u -r0 -r1.1 src/sys/dev/pci/ixgbe/ix_txrx.c cvs rdiff -u -r1.41 -r1.42 src/sys/dev/pci/ixgbe/ixgbe.c cvs rdiff -u -r1.9 -r1.10 src/sys/dev/pci/ixgbe/ixgbe.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/arch
Le 27/11/2016 à 15:22, Joerg Sonnenberger a écrit : On Sun, Nov 27, 2016 at 12:21:48PM +0100, Maxime Villard wrote: Le 26/11/2016 à 07:43, David Holland a écrit : On Thu, Nov 24, 2016 at 10:28:56PM +0900, Masanobu SAITOH wrote: > > Put a one-page redzone between userland and the PTE space on amd64 and > > i386. > > > > The PTE space is a critical region that maps the page tree, and bugs have > > been found in both amd64 and i386 where the kernel would wrongly overflow > > userland data on this area. This kind of bug is terrible, since it allows > > userland to overwrite some entries of the page tree, which makes it easy > > to patch the kernel text and get ring0 privileges. > > My emacs dumps core with change. > > What should we do? Make maxv clean up his mess, or rebuild emacs. It seems that the stack location gets baked in somehow when emacs dumps, although I don't really see exactly how (see PR 51654) and this causes existing emacs binaries to stop working. The real "mess" was having a critical x86 region sitting right next to userland. I just fixed it. You "fixed" it by changing the VM layout. That's wrong. The correct approach would have been to shift the PTE by one page. You cannot shift the PTE area by one page. This area is recursively mapped by a single L4 entry. The smallest shift you can apply is 512GB, which obviously collides with VM_MIN_KERNEL_ADDRESS. If you have a better solution feel free, but to me reducing the VM space by one page at the top is strictly the only solution.
Re: CVS commit: src/sys/arch
On Sun, Nov 27, 2016 at 12:21:48PM +0100, Maxime Villard wrote: > Le 26/11/2016 à 07:43, David Holland a écrit : > > On Thu, Nov 24, 2016 at 10:28:56PM +0900, Masanobu SAITOH wrote: > > > > Put a one-page redzone between userland and the PTE space on amd64 and > > > > i386. > > > > > > > > The PTE space is a critical region that maps the page tree, and bugs > > have > > > > been found in both amd64 and i386 where the kernel would wrongly > > overflow > > > > userland data on this area. This kind of bug is terrible, since it > > allows > > > > userland to overwrite some entries of the page tree, which makes it > > easy > > > > to patch the kernel text and get ring0 privileges. > > > > > > My emacs dumps core with change. > > > > > > What should we do? > > > > Make maxv clean up his mess, or rebuild emacs. It seems that the stack > > location gets baked in somehow when emacs dumps, although I don't > > really see exactly how (see PR 51654) and this causes existing emacs > > binaries to stop working. > > > > The real "mess" was having a critical x86 region sitting right next to > userland. I just fixed it. You "fixed" it by changing the VM layout. That's wrong. The correct approach would have been to shift the PTE by one page. Joerg
Re: CVS commit: src/sys/arch
On Fri, Nov 25, 2016 at 01:04:20PM +0100, Maxime Villard wrote: > > ? It probably means there is some kind of stupid assumption or hack in > emacs. If you could send me the core, the binary and tell me which arch it > is, that would be nice. AFAICT, emacs is known to be buggy on netbsd. For context "However, it works a bit differently for Emacs. After loading up the bare minimum temacs executable with all necessary Emacs Lisp files, the so-called unexec function reads in it own executable it???s originating from, scans over the entire process memory, then modifies the file to contain the state obtained and saves it into the emacs executable. In other words, this file contains a partial and very platform-specific reimplementation of a linker. " http://emacshorrors.com/posts/unexecute.html
Re: CVS commit: src/sys/arch
Le 26/11/2016 à 07:43, David Holland a écrit : On Thu, Nov 24, 2016 at 10:28:56PM +0900, Masanobu SAITOH wrote: > > Put a one-page redzone between userland and the PTE space on amd64 and > > i386. > > > > The PTE space is a critical region that maps the page tree, and bugs have > > been found in both amd64 and i386 where the kernel would wrongly overflow > > userland data on this area. This kind of bug is terrible, since it allows > > userland to overwrite some entries of the page tree, which makes it easy > > to patch the kernel text and get ring0 privileges. > > My emacs dumps core with change. > > What should we do? Make maxv clean up his mess, or rebuild emacs. It seems that the stack location gets baked in somehow when emacs dumps, although I don't really see exactly how (see PR 51654) and this causes existing emacs binaries to stop working. The real "mess" was having a critical x86 region sitting right next to userland. I just fixed it. I see that there have been a lot of things going on in PR51654; is it fixed now? Is there still something amd64-related I need to investigate?
