mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Thu Oct 7 14:27:00 UTC 2021 finished at Sun Oct 17 17:11:00 UTC 2021 lasted 11D02h44m done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #702: Wed Oct 6 18:29:25 MDT 2021 built packages:9374 Oct 7:2221 Oct 8:934 Oct 9:482 Oct 10:669 Oct 11:674 Oct 12:227 Oct 13:375 Oct 14:471 Oct 15:422 Oct 16:684 Oct 17:2214 build failures: 78 http://build-failures.rhaalovely.net/mips64/2021-10-07/cad/kicad.log http://build-failures.rhaalovely.net/mips64/2021-10-07/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-10-07/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-10-07/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-10-07/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-10-07/devel/go-sys.log http://build-failures.rhaalovely.net/mips64/2021-10-07/devel/promu.log http://build-failures.rhaalovely.net/mips64/2021-10-07/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-10-07/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2021-10-07/editors/micro.log http://build-failures.rhaalovely.net/mips64/2021-10-07/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-10-07/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-10-07/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-10-07/games/freeorion.log http://build-failures.rhaalovely.net/mips64/2021-10-07/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-10-07/games/goldberg_emulator.log http://build-failures.rhaalovely.net/mips64/2021-10-07/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-10-07/games/stone-soup.log http://build-failures.rhaalovely.net/mips64/2021-10-07/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-10-07/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-10-07/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2021-10-07/graphics/gimp/stable.log http://build-failures.rhaalovely.net/mips64/2021-10-07/graphics/gmic.log http://build-failures.rhaalovely.net/mips64/2021-10-07/graphics/simgear.log http://build-failures.rhaalovely.net/mips64/2021-10-07/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-10-07/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-10-07/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-10-07/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-10-07/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2021-10-07/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-10-07/math/lean.log http://build-failures.rhaalovely.net/mips64/2021-10-07/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-10-07/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2021-10-07/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-10-07/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2021-10-07/multimedia/synfigstudio.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/barrier.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/gortr.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/powerdns.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/tailscale.log http://build-failures.rhaalovely.net/mips64/2021-10-07/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-10-07/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-10-07/print/scribus.log http://build-failures.rhaalovely.net/mips64/2021-10-07/productivity/gnucash.log http://build-failures.rhaalovely.net/mips64/2021-10-07/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-10-07/security/go-siphash.log http://build-failures.rhaalovely.net/mips64/2021-10-07/security/gobuster.log http://build-failures.rhaalovely.net/mips64/2021-10-07/security/py-keyring,python3.log http://build-failures.rhaalovely.net/mips64/2021-10-07/security/vault.log http://build-failures.rhaalovely.net/mips64/2021-10-07/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2021-10-07/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-10-07/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2021-10-07/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/mips64/2021-10-07/sysutils/beats/heartbeat.log
Re: Unlock kevent(2)
On Sun, Oct 03, 2021 at 08:05:17AM +, Visa Hankala wrote:
> The internals of kqueue should now be safe without the kernel lock.
> To keep changes relatively small, it is logical to unlock the kevent(2)
> system call next. By doing this before unlocking any event filters,
> it ought to be easier to untangle any problems that might crop up.
>
> Please test. Experiences from normal interactive use would be valuable,
> as it tends to stress the system in ways that test benches usually
> do not cover.
>
> After applying the patch, remember to run "make syscalls" in the
> directory sys/kern/ before compiling the kernel.
>
> It is possible that unlocking kevent(2) degrades performance somewhat
> until more of the code gets unlocked. This is because the kernel-locked
> region becomes more fragmented. This fragmentation increases the
> frequency of kernel lock operations.
>
> Index: kern/syscalls.master
> ===
> RCS file: src/sys/kern/syscalls.master,v
> retrieving revision 1.218
> diff -u -p -r1.218 syscalls.master
> --- kern/syscalls.master 4 Jun 2021 09:05:19 - 1.218
> +++ kern/syscalls.master 3 Oct 2021 07:23:57 -
> @@ -166,7 +166,7 @@
> struct itimerval *itv); }
> 71 STD { int sys_select(int nd, fd_set *in, fd_set *ou, \
> fd_set *ex, struct timeval *tv); }
> -72 STD { int sys_kevent(int fd, \
> +72 STD NOLOCK { int sys_kevent(int fd, \
> const struct kevent *changelist, int nchanges, \
> struct kevent *eventlist, int nevents, \
> const struct timespec *timeout); }
Testers would be very helpful here. I have not received any feedback
so far.
Note that this unlocking is separate from the kqueue backend work
of poll(2) and select(2). I would prefer to be fairly confident on
the MP-safety of kevent(2) before the unlocking of kqueue-based poll(2)
and select(2) is even considered because kevent(2) is the native
interface to the kqueue subsystem.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/10/12 08:06:05 Modified files: gnu/usr.bin/binutils-2.17/bfd: elfxx-mips.c Log message: Do not extend PT_DYNAMIC segment on mips64 The IRIX-specific extension of the PT_DYNAMIC segment is not needed by the dynamic linker on OpenBSD/mips64. Disable it so that the .dynamic section stays at the start of the PT_DYNAMIC segment even when .dynstr, .dynsym or .hash precedes .dynamic in the ELF file. This enables Binutils 2.17 tools, such as strip(1), rewrite executables and shared libraries that have been produced by LLD. OK kettenis@
Re: UPDATE: audio/flite on mips64
On Sat, Oct 02, 2021 at 07:50:26PM -0400, Brad Smith wrote: > With mips64 moving to Clang it should be possible to remove the BROKEN > tags. Indeed, it builds fine now. I have committed this. Thank you. > Index: Makefile > === > RCS file: /home/cvs/ports/audio/flite/Makefile,v > retrieving revision 1.24 > diff -u -p -u -p -r1.24 Makefile > --- Makefile 7 Mar 2021 08:03:48 - 1.24 > +++ Makefile 2 Oct 2021 23:30:30 - > @@ -1,8 +1,6 @@ > # $OpenBSD: Makefile,v 1.24 2021/03/07 08:03:48 bentley Exp $ > > BROKEN-m88k= out of memory compiling cmu_us_kal_diphone.c > -BROKEN-mips64= GCC hangs compiling cmu_us_kal_diphone.c > -BROKEN-mips64el= GCC hangs compiling cmu_us_kal_diphone.c > > COMMENT= text to speech utility > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: v...@cvs.openbsd.org2021/10/07 07:35:23 Modified files: audio/flite: Makefile Log message: With Clang, audio/flite is no longer broken on mips64. >From Brad
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/10/07 07:08:17 Modified files: sys/arch/mips64/include: cpu.h sys/arch/mips64/mips64: tlbhandler.S Log message: Remove unused TLB routines.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/10/07 06:40:16 Modified files: sys/arch/mips64/include: pcb.h sys/arch/mips64/mips64: genassym.cf Log message: Remove struct members that were used by the R4000 EoP workaround.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/10/07 06:32:10 Modified files: sys/arch/mips64/include: reg.h Log message: Use tabs instead of spaces.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/10/07 06:31:03 Modified files: sys/arch/mips64/include: reg.h Log message: Remove a stale comment.
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: v...@cvs.openbsd.org2021/10/06 08:20:04 Modified files: . : 70.html Log message: mips64 package count
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Mon Sep 27 12:28:29 UTC 2021 finished at Wed Oct 6 13:14:42 UTC 2021 lasted 10D00h46m done with kern.version=OpenBSD 7.0 (GENERIC.MP) #696: Sun Sep 26 16:59:31 MDT 2021 built packages:9387 Sep 27:2346 Sep 28:755 Sep 29:417 Sep 30:551 Oct 1:862 Oct 2:576 Oct 3:556 Oct 4:784 Oct 5:2506 Oct 6:33 build failures: 72 http://build-failures.rhaalovely.net/mips64/2021-09-27/cad/kicad.log http://build-failures.rhaalovely.net/mips64/2021-09-27/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-09-27/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-09-27/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-09-27/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-09-27/devel/go-sys.log http://build-failures.rhaalovely.net/mips64/2021-09-27/devel/promu.log http://build-failures.rhaalovely.net/mips64/2021-09-27/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-09-27/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2021-09-27/editors/micro.log http://build-failures.rhaalovely.net/mips64/2021-09-27/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-09-27/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-09-27/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-09-27/games/freeorion.log http://build-failures.rhaalovely.net/mips64/2021-09-27/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-09-27/games/goldberg_emulator.log http://build-failures.rhaalovely.net/mips64/2021-09-27/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-09-27/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-09-27/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-09-27/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2021-09-27/graphics/gimp/stable.log http://build-failures.rhaalovely.net/mips64/2021-09-27/graphics/gmic.log http://build-failures.rhaalovely.net/mips64/2021-09-27/graphics/openscenegraph.log http://build-failures.rhaalovely.net/mips64/2021-09-27/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-09-27/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-09-27/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-09-27/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-09-27/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2021-09-27/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-09-27/math/lean.log http://build-failures.rhaalovely.net/mips64/2021-09-27/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-09-27/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2021-09-27/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-09-27/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2021-09-27/multimedia/synfigstudio.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/barrier.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/gortr.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/tailscale.log http://build-failures.rhaalovely.net/mips64/2021-09-27/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-09-27/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-09-27/productivity/gnucash.log http://build-failures.rhaalovely.net/mips64/2021-09-27/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-09-27/security/go-siphash.log http://build-failures.rhaalovely.net/mips64/2021-09-27/security/gobuster.log http://build-failures.rhaalovely.net/mips64/2021-09-27/security/vault.log http://build-failures.rhaalovely.net/mips64/2021-09-27/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2021-09-27/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/beats/packetbeat.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/dep.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/direnv.log http://build-failures.rhaalovely.net/mips64/2021-09-27/sysutils/envconsul.log
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/10/06 06:50:10 Modified files: sys/arch/armv7/armv7: armv7_machdep.c sys/arch/armv7/stand/efiboot: conf.c efiboot.c Log message: Add openbsd,dma-constraint property to /chosen node on armv7 On the Zynq-7000, the DMA constraint has to be adjusted because many bus masters are unable to access the lowest part of RAM. OK patrick@ kettenis@
Re: Handle openbsd,dma-constraint on armv7
On Mon, Oct 04, 2021 at 05:04:11PM +0200, Mark Kettenis wrote:
> > Date: Mon, 4 Oct 2021 13:42:48 +
> > From: Visa Hankala
> >
> > On the Zynq-7000, the lowest 512KiB of physical address space usually
> > contains RAM that is usable by the CPUs. However, many other bus
> > masters, such as the Ethernet and SDIO controllers, are not able to
> > access the 256KiB range that starts at physical address 0x4.
> >
> > So far I have used a device tree that says that RAM starts at 0x8,
> > to avoid the DMA hole. This is unconventional, though. Typically the
> > memory node for Zynq-7000 specifies 0x0 as the starting address for RAM.
> >
> > I think armv7 DMA constraint should be adjusted on the Zynq-7000 so that
> > less device tree customization would be needed.
> >
> > This diff makes armv7 efiboot and kernel handle the
> > openbsd,dma-constraint device tree property, with a tweak for the Zynq.
> > The code is similar to what is already present on arm64 and riscv64.
> >
> > OK?
>
> Hmm. How does Linux know it can't do DMA to that memory range?
> Normally that is done through a dma-ranges property in the device
> tree, and my idea has always been to add code to parse these
> properties to determine the valid DMA constraints. The reason there
> is special code for the rpi4 is because the initial device trees for
> the rpi4 didn't have those dma-ranges properties.
Linux reserves the first 512KiB in Zynq platform init code to prevent
the region from being used.
> I'm not necessarily against this diff going in, just curious if there
> is a better way.
>
> > Index: arch/armv7/armv7/armv7_machdep.c
> > ===
> > RCS file: src/sys/arch/armv7/armv7/armv7_machdep.c,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 armv7_machdep.c
> > --- arch/armv7/armv7/armv7_machdep.c25 Mar 2021 04:12:01 -
> > 1.63
> > +++ arch/armv7/armv7/armv7_machdep.c4 Oct 2021 13:32:11 -
> > @@ -453,6 +453,12 @@ initarm(void *arg0, void *arg1, void *ar
> > len = fdt_node_property(node, "openbsd,uefi-mmap-desc-ver",
> > );
> > if (len == sizeof(mmap_desc_ver))
> > mmap_desc_ver = bemtoh32((uint32_t *)prop);
> > +
> > + len = fdt_node_property(node, "openbsd,dma-constraint", );
> > + if (len == sizeof(uint64_t[2])) {
> > + dma_constraint.ucr_low = bemtoh64((uint64_t *)prop);
> > + dma_constraint.ucr_high = bemtoh64((uint64_t *)prop +
> > 1);
> > + }
> > }
> >
> > process_kernel_args();
> > Index: arch/armv7/stand/efiboot/conf.c
> > ===
> > RCS file: src/sys/arch/armv7/stand/efiboot/conf.c,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 conf.c
> > --- arch/armv7/stand/efiboot/conf.c 10 Jun 2021 22:17:58 - 1.31
> > +++ arch/armv7/stand/efiboot/conf.c 4 Oct 2021 13:32:11 -
> > @@ -42,7 +42,7 @@
> > #include "efidev.h"
> > #include "efipxe.h"
> >
> > -const char version[] = "1.18";
> > +const char version[] = "1.19";
> > intdebug = 0;
> >
> > struct fs_ops file_system[] = {
> > Index: arch/armv7/stand/efiboot/efiboot.c
> > ===
> > RCS file: src/sys/arch/armv7/stand/efiboot/efiboot.c,v
> > retrieving revision 1.34
> > diff -u -p -r1.34 efiboot.c
> > --- arch/armv7/stand/efiboot/efiboot.c 7 Jun 2021 21:18:31 -
> > 1.34
> > +++ arch/armv7/stand/efiboot/efiboot.c 4 Oct 2021 13:32:11 -
> > @@ -435,6 +435,28 @@ efi_framebuffer(void)
> > sizeof(framebuffer_path));
> > }
> >
> > +uint64_t dma_constraint[2] = { 0, -1 };
> > +
> > +void
> > +efi_dma_constraint(void)
> > +{
> > + void *node;
> > +
> > + /* Raspberry Pi 4 is "special". */
> > + node = fdt_find_node("/");
> > + if (fdt_node_is_compatible(node, "brcm,bcm2711"))
> > + dma_constraint[1] = htobe64(0x3bff);
> > +
> > + /* Not all bus masters can access 0x4-0x7 on Zynq-7000. */
Even range 0x0-0x3 has fine print on it, so I will change the above
comment to:
/* Not all bus masters can access 0x0-0x7 on Zynq-7000. */
> > + if (fdt_node_is_compatible(node, "xlnx,zynq-7000"))
> > + dma_constraint[0] = htobe64(0x0008);
> > +
> > + /* Pass DMA constraint. */
> > + node = fdt_find_node("/chosen");
> > + fdt_node_add_property(node, "openbsd,dma-constraint",
> > + dma_constraint, sizeof(dma_constraint));
> > +}
> > +
> > void
> > efi_console(void)
> > {
> > @@ -515,6 +537,7 @@ efi_makebootargs(char *bootargs, int how
> >
> > efi_framebuffer();
> > efi_console();
> > + efi_dma_constraint();
> >
> > fdt_finalize();
> >
> >
> >
>
Handle openbsd,dma-constraint on armv7
On the Zynq-7000, the lowest 512KiB of physical address space usually
contains RAM that is usable by the CPUs. However, many other bus
masters, such as the Ethernet and SDIO controllers, are not able to
access the 256KiB range that starts at physical address 0x4.
So far I have used a device tree that says that RAM starts at 0x8,
to avoid the DMA hole. This is unconventional, though. Typically the
memory node for Zynq-7000 specifies 0x0 as the starting address for RAM.
I think armv7 DMA constraint should be adjusted on the Zynq-7000 so that
less device tree customization would be needed.
This diff makes armv7 efiboot and kernel handle the
openbsd,dma-constraint device tree property, with a tweak for the Zynq.
The code is similar to what is already present on arm64 and riscv64.
OK?
Index: arch/armv7/armv7/armv7_machdep.c
===
RCS file: src/sys/arch/armv7/armv7/armv7_machdep.c,v
retrieving revision 1.63
diff -u -p -r1.63 armv7_machdep.c
--- arch/armv7/armv7/armv7_machdep.c25 Mar 2021 04:12:01 - 1.63
+++ arch/armv7/armv7/armv7_machdep.c4 Oct 2021 13:32:11 -
@@ -453,6 +453,12 @@ initarm(void *arg0, void *arg1, void *ar
len = fdt_node_property(node, "openbsd,uefi-mmap-desc-ver",
);
if (len == sizeof(mmap_desc_ver))
mmap_desc_ver = bemtoh32((uint32_t *)prop);
+
+ len = fdt_node_property(node, "openbsd,dma-constraint", );
+ if (len == sizeof(uint64_t[2])) {
+ dma_constraint.ucr_low = bemtoh64((uint64_t *)prop);
+ dma_constraint.ucr_high = bemtoh64((uint64_t *)prop +
1);
+ }
}
process_kernel_args();
Index: arch/armv7/stand/efiboot/conf.c
===
RCS file: src/sys/arch/armv7/stand/efiboot/conf.c,v
retrieving revision 1.31
diff -u -p -r1.31 conf.c
--- arch/armv7/stand/efiboot/conf.c 10 Jun 2021 22:17:58 - 1.31
+++ arch/armv7/stand/efiboot/conf.c 4 Oct 2021 13:32:11 -
@@ -42,7 +42,7 @@
#include "efidev.h"
#include "efipxe.h"
-const char version[] = "1.18";
+const char version[] = "1.19";
intdebug = 0;
struct fs_ops file_system[] = {
Index: arch/armv7/stand/efiboot/efiboot.c
===
RCS file: src/sys/arch/armv7/stand/efiboot/efiboot.c,v
retrieving revision 1.34
diff -u -p -r1.34 efiboot.c
--- arch/armv7/stand/efiboot/efiboot.c 7 Jun 2021 21:18:31 - 1.34
+++ arch/armv7/stand/efiboot/efiboot.c 4 Oct 2021 13:32:11 -
@@ -435,6 +435,28 @@ efi_framebuffer(void)
sizeof(framebuffer_path));
}
+uint64_t dma_constraint[2] = { 0, -1 };
+
+void
+efi_dma_constraint(void)
+{
+ void *node;
+
+ /* Raspberry Pi 4 is "special". */
+ node = fdt_find_node("/");
+ if (fdt_node_is_compatible(node, "brcm,bcm2711"))
+ dma_constraint[1] = htobe64(0x3bff);
+
+ /* Not all bus masters can access 0x4-0x7 on Zynq-7000. */
+ if (fdt_node_is_compatible(node, "xlnx,zynq-7000"))
+ dma_constraint[0] = htobe64(0x0008);
+
+ /* Pass DMA constraint. */
+ node = fdt_find_node("/chosen");
+ fdt_node_add_property(node, "openbsd,dma-constraint",
+ dma_constraint, sizeof(dma_constraint));
+}
+
void
efi_console(void)
{
@@ -515,6 +537,7 @@ efi_makebootargs(char *bootargs, int how
efi_framebuffer();
efi_console();
+ efi_dma_constraint();
fdt_finalize();
Unlock kevent(2)
The internals of kqueue should now be safe without the kernel lock.
To keep changes relatively small, it is logical to unlock the kevent(2)
system call next. By doing this before unlocking any event filters,
it ought to be easier to untangle any problems that might crop up.
Please test. Experiences from normal interactive use would be valuable,
as it tends to stress the system in ways that test benches usually
do not cover.
After applying the patch, remember to run "make syscalls" in the
directory sys/kern/ before compiling the kernel.
It is possible that unlocking kevent(2) degrades performance somewhat
until more of the code gets unlocked. This is because the kernel-locked
region becomes more fragmented. This fragmentation increases the
frequency of kernel lock operations.
Index: kern/syscalls.master
===
RCS file: src/sys/kern/syscalls.master,v
retrieving revision 1.218
diff -u -p -r1.218 syscalls.master
--- kern/syscalls.master4 Jun 2021 09:05:19 - 1.218
+++ kern/syscalls.master3 Oct 2021 07:23:57 -
@@ -166,7 +166,7 @@
struct itimerval *itv); }
71 STD { int sys_select(int nd, fd_set *in, fd_set *ou, \
fd_set *ex, struct timeval *tv); }
-72 STD { int sys_kevent(int fd, \
+72 STD NOLOCK { int sys_kevent(int fd, \
const struct kevent *changelist, int nchanges, \
struct kevent *eventlist, int nevents, \
const struct timespec *timeout); }
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Sat Sep 11 10:53:15 UTC 2021 finished at Sun Sep 19 10:07:01 UTC 2021 lasted 08D23h13m done with kern.version=OpenBSD 7.0-beta (GENERIC.MP) #681: Fri Sep 10 17:47:42 MDT 2021 built packages:9259 Sep 11:2366 Sep 12:779 Sep 13:352 Sep 14:672 Sep 15:928 Sep 16:489 Sep 17:848 Sep 18:683 Sep 19:2141 build failures: 74 http://build-failures.rhaalovely.net/mips64/2021-09-11/cad/kicad.log http://build-failures.rhaalovely.net/mips64/2021-09-11/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-09-11/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-09-11/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-09-11/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-09-11/devel/go-sys.log http://build-failures.rhaalovely.net/mips64/2021-09-11/devel/promu.log http://build-failures.rhaalovely.net/mips64/2021-09-11/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-09-11/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2021-09-11/editors/micro.log http://build-failures.rhaalovely.net/mips64/2021-09-11/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-09-11/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-09-11/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-09-11/games/freeorion.log http://build-failures.rhaalovely.net/mips64/2021-09-11/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-09-11/games/goldberg_emulator.log http://build-failures.rhaalovely.net/mips64/2021-09-11/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-09-11/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-09-11/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-09-11/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2021-09-11/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-09-11/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-09-11/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-09-11/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-09-11/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2021-09-11/mail/perdition,-ldap.log http://build-failures.rhaalovely.net/mips64/2021-09-11/mail/postfix/stable,ldap.log http://build-failures.rhaalovely.net/mips64/2021-09-11/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-09-11/math/lean.log http://build-failures.rhaalovely.net/mips64/2021-09-11/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-09-11/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2021-09-11/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-09-11/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2021-09-11/multimedia/frei0r-plugins.log http://build-failures.rhaalovely.net/mips64/2021-09-11/multimedia/get_iplayer.log http://build-failures.rhaalovely.net/mips64/2021-09-11/multimedia/mkvtoolnix,no_x11.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/barrier.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/gortr.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/pure-ftpd,ldap.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/tailscale.log http://build-failures.rhaalovely.net/mips64/2021-09-11/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-09-11/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-09-11/productivity/gnucash.log http://build-failures.rhaalovely.net/mips64/2021-09-11/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-09-11/security/go-siphash.log http://build-failures.rhaalovely.net/mips64/2021-09-11/security/gobuster.log http://build-failures.rhaalovely.net/mips64/2021-09-11/security/vault.log http://build-failures.rhaalovely.net/mips64/2021-09-11/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2021-09-11/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-09-11/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2021-09-11/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/mips64/2021-09-11/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/mips64/2021-09-11/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/mips64/2021-09-11/sysutils/beats/packetbeat.log
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/09/16 06:35:20 Modified files: usr.sbin/tcpdump: print-wg.c Log message: tcpdump: Fix data alignment issue in WireGuard printer Access 8-byte nonce as unaligned data to avoid a crash on strict alignment architectures. With IP and UDP, payload alignment is guaranteed to 4-byte boundary only. Reported and tested by Peter J. Philipp OK deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/09/16 06:34:13 Modified files: usr.sbin/tcpdump: extract.h Log message: Add EXTRACT_LE_64BITS(). OK deraadt@
Re: bus error on octeon
On Tue, Sep 14, 2021 at 07:31:33PM +0200, Peter J. Philipp wrote:
> On Tue, Sep 14, 2021 at 10:48:44AM -0600, Theo de Raadt wrote:
> > Mark Kettenis wrote:
> >
> > > To be honest, I do think that adding __packed is a reasonable way to
> > > handle protocol structs like this where performance doesn't really
> > > matter. This translates into __attribute__((packed)) and both GCC and
> > > LLVM started treating that in a way to signal that the data might not
> > > be properly aligned and use byte access on architectures that need
> > > strict alignment. This is still not explicitly documented but I don't
> > > think the compiler writers can backtrack on that at this point.
> >
> > __packed does not mean "use bytes". It means ensure there are no
> > padding bytes, and then on strict alignment systems when something is
> > misaligned, the compiler can see it must use smaller loads.
> >
> > Unfortunately, tcpdump also parses encapsulated protocols, and some of
> > the outer layers are limited to short-alignment. So if an inner layer
> > has a 32-bit value inside the __packed array after packing, the compiler
> > will believe it is still on a 32-bit boundary, and not use char or short
> > accesses. This will fault, because tcpdump is passing a pointe to an
> > object with tighter alignment.
> >
> > __packed is not saying "each object must be loaded as bytes", and I
> > really am susprised you claim that is what happens today. That is a
> > crazy expensive choice on some architectures.
> >
> > So I think __packed is not enough for what tcpdump is doing.
> >
> > Perhaps some of the compilers are being more cynical, or their costing
> > of loads leads them to do smaller-storage operations... but I have a
> > recollection that at least gcc on the alpha gets confused and does the
> > wrong thing.
>
> To appease the situation, I have 1. taken what Visa said about the nonce,
> 2. taken my old patch and changed the memcpy's to EXTRACT_64BITS() which
> I had to homeroll off EXTRACT_32BITS(), and made a patch and tested it.
>
> No bus errors again, though I don't know if it's the right approach. The
> nonces in the tcpdump were sequential counting up from 1 as my wireguard
> hardware was rebooting. I think I control-c'ed by 218 nonce or so.
EXTRACT_64BITS() followed by letoh64() is not correct because the former
converts byte order from big endian to host. It is better to add
EXTRACT_LE_64BITS().
The patch assumes that the data already are 4-byte aligned (bpf(4) and
libpcap ensure proper alignment for the network header; also, print-ip.c
and print-ip6.c do last-resort fixing when needed).
Index: extract.h
===
RCS file: src/usr.sbin/tcpdump/extract.h,v
retrieving revision 1.9
diff -u -p -r1.9 extract.h
--- extract.h 7 Oct 2007 16:41:05 - 1.9
+++ extract.h 15 Sep 2021 12:40:56 -
@@ -51,3 +51,12 @@
(u_int32_t)*((const u_int8_t *)(p) + 2) << 16 | \
(u_int32_t)*((const u_int8_t *)(p) + 1) << 8 | \
(u_int32_t)*((const u_int8_t *)(p) + 0))
+#define EXTRACT_LE_64BITS(p) \
+ ((u_int64_t)*((const u_int8_t *)(p) + 7) << 56 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 6) << 48 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 5) << 40 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 4) << 32 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 3) << 24 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 2) << 16 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 1) << 8 | \
+ (u_int64_t)*((const u_int8_t *)(p) + 0))
Index: print-wg.c
===
RCS file: src/usr.sbin/tcpdump/print-wg.c,v
retrieving revision 1.6
diff -u -p -r1.6 print-wg.c
--- print-wg.c 14 Apr 2021 19:34:56 - 1.6
+++ print-wg.c 15 Sep 2021 12:40:56 -
@@ -142,8 +142,9 @@ wg_print(const u_char *bp, u_int length)
printf("[wg] keepalive ");
if (caplen < offsetof(struct wg_data, mac))
goto trunc;
+ /* data->nonce may be unaligned. */
printf("to 0x%08x nonce %llu",
- letoh32(data->receiver), letoh64(data->nonce));
+ letoh32(data->receiver), EXTRACT_LE_64BITS(>nonce));
break;
}
return;
Re: bus error on octeon
On Tue, May 04, 2021 at 07:29:20AM +0200, Peter J. Philipp wrote:
> > Index: print-wg.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdump/print-wg.c,v
> > retrieving revision 1.6
> > diff -u -p -u -r1.6 print-wg.c
> > --- print-wg.c 14 Apr 2021 19:34:56 - 1.6
> > +++ print-wg.c 3 May 2021 16:29:29 -
> > @@ -21,6 +21,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #include "interface.h"
> > #include "extract.h"
> > @@ -104,6 +105,9 @@ wg_print(const u_char *bp, u_int length)
> > struct wg_data *data = (void *)bp;
> > u_intcaplen;
> >
> > + uint32_treceiver;
> > + uint64_tnonce;
> > +
> > caplen = snapend - bp;
> > if (caplen < sizeof(type))
> > goto trunc;
> > @@ -142,8 +146,12 @@ wg_print(const u_char *bp, u_int length)
> > printf("[wg] keepalive ");
> > if (caplen < offsetof(struct wg_data, mac))
> > goto trunc;
> > +
> > + memcpy((void *), (void *)>receiver,
> > sizeof(receiver));
> > + memcpy((void *), (void *)>nonce, sizeof(nonce));
> > +
> > printf("to 0x%08x nonce %llu",
> > - letoh32(data->receiver), letoh64(data->nonce));
> > + letoh32(receiver), letoh64(nonce));
> > break;
> > }
> > return;
> >
> >
> > There may be other variables that need the same treatment... if that looks
> > ok
> > for you I'll work on that and submit the patch formally.
>
> I dumped with this patch for about an hour, and even restarted the wg tunnel
> on the device behind vlan6 so that other types get used (initialization) and
> I found that there was no more SIGBUS's for tcpdump on octeon, so I am unsure
> if other variables actually do need same treatment still.
data->nonce is the (most) offending variable because it needs 8-byte
alignment.
An alternative to memcpy() is to use tcpdump's EXTRACT_* macros that
handle unaligned data.
Yet another option is to declare the structs with the "packed" type
attribute. This makes the compiler emit machine code that is safe with
unaligned data. This also enables type checking that is better than with
EXTRACT_* because types are not overridden with explicit type casts.
However, "packed" makes it non obvious that unaligned accesses
may happen.
Index: print-wg.c
===
RCS file: src/usr.sbin/tcpdump/print-wg.c,v
retrieving revision 1.6
diff -u -p -r1.6 print-wg.c
--- print-wg.c 14 Apr 2021 19:34:56 - 1.6
+++ print-wg.c 14 Sep 2021 12:42:32 -
@@ -34,20 +34,20 @@ struct wg_initiation {
uint32_ttype;
uint32_tsender;
uint8_t fill[140]; /* Includes ephemeral + MAC */
-};
+} __packed;
struct wg_response {
uint32_ttype;
uint32_tsender;
uint32_treceiver;
uint8_t fill[80]; /* Includes ephemeral + MAC */
-};
+} __packed;
struct wg_cookie {
uint32_ttype;
uint32_treceiver;
uint8_t fill[56]; /* Includes nonce + encrypted cookie */
-};
+} __packed;
struct wg_data {
uint32_ttype;
@@ -55,7 +55,7 @@ struct wg_data {
uint64_tnonce;
/* uint8_t data[variable]; - Variable length data */
uint8_t mac[16];
-};
+} __packed;
/*
* Check if packet is a WireGuard packet, as WireGuard may run on any port.
[OE-core] [dunfell][PATCH] iputils: Fix regression of arp table update
Backport a fix from iputils 20210202 to make arp table updating
work again.
Fixes: 77c5792aa5e7 ("iputils: fix various arping regressions")
Signed-off-by: Visa Hankala
---
...ng-make-update-neighbours-work-again.patch | 79 +++
.../iputils/iputils_s20190709.bb | 1 +
2 files changed, 80 insertions(+)
create mode 100644
meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
diff --git
a/meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
b/meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
new file mode 100644
index 00..bf86115843
--- /dev/null
+++
b/meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
@@ -0,0 +1,79 @@
+From 86ed08936d49e2c81ef49dfbd02aca1c74d0c098 Mon Sep 17 00:00:00 2001
+From: lac-0073 <61903197+lac-0...@users.noreply.github.com>
+Date: Mon, 26 Oct 2020 09:45:42 +0800
+Subject: [PATCH] arpping: make update neighbours work again
+
+The arping is using inconsistent sender_ip_addr and target_ip_addr in
+messages. This causes the client receiving the arp message not to update
+the arp table entries.
+
+The specific performance is as follows:
+
+There is a machine 2 with IP 10.20.30.3 configured on eth0:0 that is in the
+same IP subnet as eth0. This IP was originally used on another machine 1,
+and th IP needs to be changed back to the machine 1. When using the arping
+command to announce what ethernet address has IP 10.20.30.3, the arp table
+on machine 3 is not updated.
+
+Machine 3 original arp table:
+
+10.20.30.3 machine 2 eth0:000:00:00:00:00:02
+10.20.30.2 machine 2 eth0 00:00:00:00:00:02
+10.20.30.1 machine 1 eth0 00:00:00:00:00:01
+
+Create interface eth0:0 on machine 1, and use the arping command to send arp
+packets. Expected outcome on machine 3:
+
+10.20.30.3 machine 1 eth0:000:00:00:00:00:01
+10.20.30.2 machine 2 eth0 00:00:00:00:00:02
+10.20.30.1 machine 1 eth0 00:00:00:00:00:01
+
+Actual results on machine 3:
+
+10.20.30.3 machine 2 eth0:000:00:00:00:00:02
+10.20.30.2 machine 2 eth0 00:00:00:00:00:02
+10.20.30.1 machine 1 eth0 00:00:00:00:00:01
+
+Fixes: https://github.com/iputils/iputils/issues/298
+Fixes: 68f12fc4a0dbef4ae4c404da24040d22c5a14339
+Signed-off-by: Aichun Li
+Upstream-Status: Backport
[https://github.com/iputils/iputils/commit/86ed08936d49e2c81ef49dfbd02aca1c74d0c098]
+Signed-off-by: Visa Hankala
+---
+ arping.c | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/arping.c b/arping.c
+index a002786..53fdbb4 100644
+--- a/arping.c
b/arping.c
+@@ -968,7 +968,7 @@ int main(int argc, char **argv)
+ }
+ memset(, 0, sizeof(saddr));
+ saddr.sin_family = AF_INET;
+- if (!ctl.unsolicited && (ctl.source || ctl.gsrc.s_addr)) {
++ if (ctl.source || ctl.gsrc.s_addr) {
+ saddr.sin_addr = ctl.gsrc;
+ if (bind(probe_fd, (struct sockaddr *),
sizeof(saddr)) == -1)
+ error(2, errno, "bind");
+@@ -979,12 +979,14 @@ int main(int argc, char **argv)
+ saddr.sin_port = htons(1025);
+ saddr.sin_addr = ctl.gdst;
+
+- if (setsockopt(probe_fd, SOL_SOCKET, SO_DONTROUTE,
(char *), sizeof(on)) == -1)
+- error(0, errno, _("WARNING:
setsockopt(SO_DONTROUTE)"));
+- if (connect(probe_fd, (struct sockaddr *),
sizeof(saddr)) == -1)
+- error(2, errno, "connect");
+- if (getsockname(probe_fd, (struct sockaddr *),
) == -1)
+- error(2, errno, "getsockname");
++ if (!ctl.unsolicited) {
++ if (setsockopt(probe_fd, SOL_SOCKET,
SO_DONTROUTE, (char *), sizeof(on)) == -1)
++ error(0, errno, _("WARNING:
setsockopt(SO_DONTROUTE)"));
++ if (connect(probe_fd, (struct sockaddr
*), sizeof(saddr)) == -1)
++ error(2, errno, "connect");
++ if (getsockname(probe_fd, (struct sockaddr
*), ) == -1)
++ error(2, errno, "getsockname");
++ }
+ ctl.gsrc = saddr.sin_addr;
+ }
+ close(probe_fd);
diff --git a/meta/recipes-extended/iputils/iputils_s20190709.bb
b/meta/recipes-extended/iputils/iputils_s20190709.bb
index d652bfcaad..b33b913817 100644
--- a/meta/recipes-extended/iputils/iputils_s20190709.bb
+++ b/meta/recipes-extended/iputils/iputils_s20190709.bb
@@ -20,6 +20,7 @
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/09/13 06:19:11 Modified files: sys/arch/mips64/mips64: pmap.c Log message: Remember to lock user pmap in pmap_extract() pmap_extract() has to lock user pmap to prevent concurrent pruning of the page table. The kernel pmap is exempt from this because it uses a fixed page table structure.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/09/13 06:16:43 Modified files: sys/arch/mips64/mips64: pmap.c Log message: Consistently use unsigned long for CPU masks in pmap.c.
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Sat Aug 7 13:37:27 UTC 2021 finished at Sat Aug 21 11:38:14 UTC 2021 lasted 14D22h00m done with kern.version=OpenBSD 6.9-current (GENERIC.MP) #658: Fri Aug 6 02:20:11 MDT 2021 built packages:9377 Aug 7:2286 Aug 8:715 Aug 9:496 Aug 10:484 Aug 11:635 Aug 12:455 Aug 13:267 Aug 14:385 Aug 15:409 Aug 16:452 Aug 17:382 Aug 18:2084 Aug 20:323 Aug 21:3 build failures: 74 http://build-failures.rhaalovely.net/mips64/2021-08-07/archivers/innoextract.log http://build-failures.rhaalovely.net/mips64/2021-08-07/cad/kicad.log http://build-failures.rhaalovely.net/mips64/2021-08-07/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-08-07/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/ccache.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/go-sys.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/promu.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-08-07/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2021-08-07/editors/micro.log http://build-failures.rhaalovely.net/mips64/2021-08-07/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-08-07/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-08-07/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-08-07/games/eduke32.log http://build-failures.rhaalovely.net/mips64/2021-08-07/games/freeorion.log http://build-failures.rhaalovely.net/mips64/2021-08-07/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-08-07/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-08-07/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-08-07/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-08-07/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2021-08-07/graphics/gimp/stable.log http://build-failures.rhaalovely.net/mips64/2021-08-07/graphics/gmic.log http://build-failures.rhaalovely.net/mips64/2021-08-07/graphics/simgear.log http://build-failures.rhaalovely.net/mips64/2021-08-07/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-08-07/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-08-07/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-08-07/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-08-07/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2021-08-07/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-08-07/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-08-07/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2021-08-07/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-08-07/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2021-08-07/multimedia/synfigstudio.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/barrier.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/gortr.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/termshark.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-08-07/net/yggdrasil-go.log http://build-failures.rhaalovely.net/mips64/2021-08-07/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-08-07/productivity/gnucash.log http://build-failures.rhaalovely.net/mips64/2021-08-07/security/age.log http://build-failures.rhaalovely.net/mips64/2021-08-07/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-08-07/security/go-siphash.log http://build-failures.rhaalovely.net/mips64/2021-08-07/security/gobuster.log http://build-failures.rhaalovely.net/mips64/2021-08-07/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2021-08-07/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-08-07/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2021-08-07/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/mips64/2021-08-07/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/mips64/2021-08-07/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/mips64/2021-08-07/sysutils/beats/packetbeat.log
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Mon Jul 26 06:13:30 UTC 2021 finished at Mon Aug 2 16:10:56 UTC 2021 lasted 08D09h57m done with kern.version=OpenBSD 6.9-current (GENERIC.MP) #644: Sat Jul 24 16:43:48 MDT 2021 built packages:8904 Jul 26:2651 Jul 27:568 Jul 28:848 Jul 29:825 Jul 30:881 Jul 31:1185 Aug 1:1915 Aug 2:30 build failures: 70 http://build-failures.rhaalovely.net/mips64/2021-07-26/archivers/innoextract.log http://build-failures.rhaalovely.net/mips64/2021-07-26/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-07-26/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/ccache.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/go-sys.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/promu.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-07-26/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2021-07-26/editors/micro.log http://build-failures.rhaalovely.net/mips64/2021-07-26/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-07-26/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-07-26/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-07-26/games/eduke32.log http://build-failures.rhaalovely.net/mips64/2021-07-26/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-07-26/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-07-26/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-07-26/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-07-26/graphics/clutter/cogl.log http://build-failures.rhaalovely.net/mips64/2021-07-26/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2021-07-26/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-07-26/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-07-26/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-07-26/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-07-26/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2021-07-26/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-07-26/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-07-26/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2021-07-26/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-07-26/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2021-07-26/multimedia/gstreamer1/plugins-base.log http://build-failures.rhaalovely.net/mips64/2021-07-26/multimedia/mpv.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/gortr.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/py-txtorcon,python3.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/termshark.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-07-26/net/yggdrasil-go.log http://build-failures.rhaalovely.net/mips64/2021-07-26/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-07-26/security/age.log http://build-failures.rhaalovely.net/mips64/2021-07-26/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-07-26/security/go-siphash.log http://build-failures.rhaalovely.net/mips64/2021-07-26/security/gobuster.log http://build-failures.rhaalovely.net/mips64/2021-07-26/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2021-07-26/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/beats/packetbeat.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/dep.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/direnv.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/envconsul.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/loki.log http://build-failures.rhaalovely.net/mips64/2021-07-26/sysutils/nomad.log
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/29 08:11:53 Modified files: sys/arch/octeon/dev: if_ogx.c Log message: Fix device class.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/24 02:21:13 Modified files: sys/arch/loongson/loongson: generic3a_machdep.c machdep.c sys/arch/mips64/include: cpu.h sys/arch/mips64/mips64: cpu.c ipifuncs.c pmap.c sys/arch/octeon/octeon: machdep.c Log message: Replace cpus_running with CPU_IS_RUNNING().
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/23 23:45:49 Modified files: regress/lib/libc: Makefile Added files: regress/lib/libc/strchr: Makefile strchrtest.c Log message: Add basic regression tests for strchr() and strrchr().
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/23 23:42:25 src/regress/lib/libc/strchr Update of /cvs/src/regress/lib/libc/strchr In directory cvs.openbsd.org:/tmp/cvs-serv84776/strchr Log Message: Directory /cvs/src/regress/lib/libc/strchr added to the repository
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/23 23:35:56 Modified files: lib/libc/arch/mips64/string: strchr.S strrchr.S Log message: Fix strchr() and strrchr() on mips64 Truncate the character arguments of strchr() and strrchr() to eight bits so that the implied char conversion would work correctly. Otherwise the functions would always return NULL when the character argument is negative. OK miod@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/22 01:22:43 Modified files: sys/kern : kern_event.c Log message: Make kqpoll_dequeue() usable with lazy removal of knotes Adjust kqpoll_dequeue() so that it will clear only badfd knotes when called from kqpoll_init(). This is needed by kqpoll's lazy removal of knotes. Eager removal in kqpoll_dequeue() would defeat kqpoll's attempt to reuse previously established knotes under workloads where knote activation tends to occur already before next kqpoll scan. Prompted by mpi@
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Mon Jul 12 11:49:51 UTC 2021 finished at Wed Jul 21 05:48:34 UTC 2021 lasted 09D17h58m done with kern.version=OpenBSD 6.9-current (GENERIC.MP) #632: Sun Jul 11 05:48:30 MDT 2021 built packages:9257 Jul 12:2347 Jul 13:768 Jul 14:316 Jul 15:660 Jul 16:957 Jul 17:572 Jul 18:803 Jul 19:1921 Jul 20:912 build failures: 78 http://build-failures.rhaalovely.net/mips64/2021-07-12/archivers/innoextract.log http://build-failures.rhaalovely.net/mips64/2021-07-12/cad/kicad.log http://build-failures.rhaalovely.net/mips64/2021-07-12/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2021-07-12/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-07-12/comms/lcdproc.log http://build-failures.rhaalovely.net/mips64/2021-07-12/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/ccache.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/go-sys.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/promu.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-07-12/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2021-07-12/editors/micro.log http://build-failures.rhaalovely.net/mips64/2021-07-12/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-07-12/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-07-12/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-07-12/games/eduke32.log http://build-failures.rhaalovely.net/mips64/2021-07-12/games/freeorion.log http://build-failures.rhaalovely.net/mips64/2021-07-12/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-07-12/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-07-12/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-07-12/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-07-12/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2021-07-12/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net/mips64/2021-07-12/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-07-12/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-07-12/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-07-12/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-07-12/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2021-07-12/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-07-12/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-07-12/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2021-07-12/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-07-12/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2021-07-12/multimedia/frei0r-plugins.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/barrier.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/cadaver.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/go-ipfs.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/gortr.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/kea,mysql.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/termshark.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-07-12/net/yggdrasil-go.log http://build-failures.rhaalovely.net/mips64/2021-07-12/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-07-12/productivity/gnucash.log http://build-failures.rhaalovely.net/mips64/2021-07-12/security/age.log http://build-failures.rhaalovely.net/mips64/2021-07-12/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-07-12/security/go-siphash.log http://build-failures.rhaalovely.net/mips64/2021-07-12/security/gobuster.log http://build-failures.rhaalovely.net/mips64/2021-07-12/security/gopass.log http://build-failures.rhaalovely.net/mips64/2021-07-12/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2021-07-12/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-07-12/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2021-07-12/sysutils/beats/filebeat.log
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/20 01:53:39 Modified files: sys/arch/mips64/mips64: ipifuncs.c Log message: Remove bogus use of CPU_MAXID and get cpu_info only once.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/20 01:51:08 Modified files: sys/arch/mips64/conf: files.mips64 Removed files: sys/lib/libkern/arch/mips64: sync.S Log message: Remove unneeded __sync_* library functions from the kernel. These library functions were added as stopgaps because GCC 4.2.1 lacks the corresponding __sync_* builtins on mips64. However, the builtins are now provided by Clang.
[Pkg-tcltk-devel] Oportunidad para MIGRAR A TEXAS - Apoyos para el Empresario
Hola Buen día. Me da gusto saludarte. Le escribo para invitarlo a participar en el próximo Evento exclusivo "COMO HACER NEGOCIOS EN TEXAS", con este programa Conocerá Todos los detalles que debe evaluar antes de iniciar un negocio en Texas, las ciudades principales y oportunidades y cuál es el mejor modelo de negocio para usted, así mismo trazar un plan de acción idóneo para su primer negocio en Texas. Los principales trámites que se requieren para iniciar el negocio y de esta manera todos los detalles de las relaciones laborales para asegurar el éxito del negocio.., la fecha del evento es el 30 y 31 de JULIO de 2021 en Modalidad Online en VIVO Si está interesado en recibir TODA la información responda la palabra "TEMARIO-TEXAS-2021-" + Su Nombre + Teléfono: SOLICITE EL TEMARIO COMPLETO AQUÍ Le envió un saludo Comuníquese al: +001 (305) 425-9975 También puede hacernos llegar sus dudas a través de WhatsApp 55-8379-5727 Correo dirigido a: pkg-tcltk-de...@lists.alioth.debian.org Para dejar de recibir nuestras promociones, reenvíe este correo con el asunto "EXCLUIR". Este proceso podría tomar hasta 48 horas en tomar efecto. Copyright © 2021 QTC., All rights reserved ___ Pkg-tcltk-devel mailing list Pkg-tcltk-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tcltk-devel
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/13 01:37:50 Modified files: sys/miscfs/fifofs: fifo_vnops.c Log message: Add f_modify and f_process callbacks to FIFO filterops. OK millert@ mpi@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/12 03:32:37 Modified files: sys/arch/loongson/loongson: machdep.c sys/arch/octeon/octeon: machdep.c Log message: Remember to set CPUF_RUNNING on secondary CPUs.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/07/12 03:29:18 Modified files: sys/arch/loongson/loongson: machdep.c sys/arch/octeon/octeon: machdep.c Log message: Make hw_cpu_hatch() more similar on loongson and octeon.
Re: Do not spin on the NET_LOCK() in kqueue
On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote: > One of the reasons for the drop of performances in the kqueue-based > poll/select is the fact that kqueue filters are called up to 3 times > per syscall and that they all spin on the NET_LOCK() for TCP/UDP > packets. > > Diff below is a RFC for improving the situation. > > socket kqueue filters mainly check for the amount of available items to > read/write. This involves comparing various socket buffer fields (sb_cc, > sb_lowat, etc). The diff below introduces a new mutex to serialize > updates of those fields with reads in the kqueue filters. > > Since these fields are always modified with the socket lock held, either > the mutex or the solock are enough to have a coherent view of them. > Note that either of these locks is necessary only if multiple fields > have to be read (like in sbspace()). > > Other per-socket fields accessed in the kqueue filters are never > combined (with &&) to determine a condition. So assuming it is fine to > read register-sized fields w/o the socket lock we can safely remove it > there. > > Could such mutex also be used to serialize klist updates? I think the lock should be such that it can serialize socket klists. As the main motivator for this change is kqueue, the viability of using the mutex for the klist locking should be checked now. The mutex has to be held whenever calling KNOTE() on sb_sel.si_note, or selwakeup() on sb_sel. Then the socket f_event callbacks will not need to lock the mutex themselves. I had a diff that serialized socket klists using solock(). It did not work well because it increased lock contention, especially when using kqueue as backend for poll(2) and select(2). The diff is not even correct any longer since recent changes to socket locking have introduced new lock order constraints that conflict with it.
Add f_modify and f_process callbacks to FIFO filterops
This patch adds f_modify and f_process callbacks to FIFO event filters.
The general idea is the same as with sockets, discussed in thread
"Add f_modify and f_process callbacks to socket filterops" on tech@.
I think it is best to add the callbacks now, before further changes to
socket locking.
OK?
Index: miscfs/fifofs/fifo_vnops.c
===
RCS file: src/sys/miscfs/fifofs/fifo_vnops.c,v
retrieving revision 1.79
diff -u -p -r1.79 fifo_vnops.c
--- miscfs/fifofs/fifo_vnops.c 17 Jan 2021 05:23:34 - 1.79
+++ miscfs/fifofs/fifo_vnops.c 11 Jul 2021 12:04:07 -
@@ -104,14 +104,22 @@ const struct vops fifo_vops = {
void filt_fifordetach(struct knote *kn);
intfilt_fiforead(struct knote *kn, long hint);
+intfilt_fiforeadmodify(struct kevent *kev, struct knote *kn);
+intfilt_fiforeadprocess(struct knote *kn, struct kevent *kev);
+intfilt_fiforead_common(struct knote *kn, struct socket *so);
void filt_fifowdetach(struct knote *kn);
intfilt_fifowrite(struct knote *kn, long hint);
+intfilt_fifowritemodify(struct kevent *kev, struct knote *kn);
+intfilt_fifowriteprocess(struct knote *kn, struct kevent *kev);
+intfilt_fifowrite_common(struct knote *kn, struct socket *so);
const struct filterops fiforead_filtops = {
.f_flags= FILTEROP_ISFD,
.f_attach = NULL,
.f_detach = filt_fifordetach,
.f_event= filt_fiforead,
+ .f_modify = filt_fiforeadmodify,
+ .f_process = filt_fiforeadprocess,
};
const struct filterops fifowrite_filtops = {
@@ -119,6 +127,8 @@ const struct filterops fifowrite_filtops
.f_attach = NULL,
.f_detach = filt_fifowdetach,
.f_event= filt_fifowrite,
+ .f_modify = filt_fifowritemodify,
+ .f_process = filt_fifowriteprocess,
};
/*
@@ -546,13 +556,12 @@ filt_fifordetach(struct knote *kn)
}
int
-filt_fiforead(struct knote *kn, long hint)
+filt_fiforead_common(struct knote *kn, struct socket *so)
{
- struct socket *so = (struct socket *)kn->kn_hook;
- int s, rv;
+ int rv;
+
+ soassertlocked(so);
- if ((hint & NOTE_SUBMIT) == 0)
- s = solock(so);
kn->kn_data = so->so_rcv.sb_cc;
if (so->so_state & SS_CANTRCVMORE) {
kn->kn_flags |= EV_EOF;
@@ -565,8 +574,46 @@ filt_fiforead(struct knote *kn, long hin
kn->kn_flags &= ~EV_EOF;
rv = (kn->kn_data > 0);
}
- if ((hint & NOTE_SUBMIT) == 0)
- sounlock(so, s);
+
+ return (rv);
+}
+
+int
+filt_fiforead(struct knote *kn, long hint)
+{
+ struct socket *so = kn->kn_hook;
+
+ return (filt_fiforead_common(kn, so));
+}
+
+int
+filt_fiforeadmodify(struct kevent *kev, struct knote *kn)
+{
+ struct socket *so = kn->kn_hook;
+ int rv, s;
+
+ s = solock(so);
+ knote_modify(kev, kn);
+ rv = filt_fiforead_common(kn, so);
+ sounlock(so, s);
+
+ return (rv);
+}
+
+int
+filt_fiforeadprocess(struct knote *kn, struct kevent *kev)
+{
+ struct socket *so = kn->kn_hook;
+ int rv, s;
+
+ s = solock(so);
+ if (kev != NULL && (kn->kn_flags & EV_ONESHOT))
+ rv = 1;
+ else
+ rv = filt_fiforead_common(kn, so);
+ if (rv != 0)
+ knote_submit(kn, kev);
+ sounlock(so, s);
return (rv);
}
@@ -580,13 +627,12 @@ filt_fifowdetach(struct knote *kn)
}
int
-filt_fifowrite(struct knote *kn, long hint)
+filt_fifowrite_common(struct knote *kn, struct socket *so)
{
- struct socket *so = (struct socket *)kn->kn_hook;
- int s, rv;
+ int rv;
+
+ soassertlocked(so);
- if ((hint & NOTE_SUBMIT) == 0)
- s = solock(so);
kn->kn_data = sbspace(so, >so_snd);
if (so->so_state & SS_CANTSENDMORE) {
kn->kn_flags |= EV_EOF;
@@ -595,8 +641,46 @@ filt_fifowrite(struct knote *kn, long hi
kn->kn_flags &= ~EV_EOF;
rv = (kn->kn_data >= so->so_snd.sb_lowat);
}
- if ((hint & NOTE_SUBMIT) == 0)
- sounlock(so, s);
+
+ return (rv);
+}
+
+int
+filt_fifowrite(struct knote *kn, long hint)
+{
+ struct socket *so = kn->kn_hook;
+
+ return (filt_fifowrite_common(kn, so));
+}
+
+int
+filt_fifowritemodify(struct kevent *kev, struct knote *kn)
+{
+ struct socket *so = kn->kn_hook;
+ int rv, s;
+
+ s = solock(so);
+ knote_modify(kev, kn);
+ rv = filt_fifowrite_common(kn, so);
+ sounlock(so, s);
+
+ return (rv);
+}
+
+int
+filt_fifowriteprocess(struct knote *kn, struct kevent *kev)
+{
+ struct socket *so = kn->kn_hook;
+ int rv, s;
+
+ s = solock(so);
+ if (kev != NULL && (kn->kn_flags & EV_ONESHOT))
+ rv = 1;
+ else
+ rv =
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: v...@cvs.openbsd.org2021/07/09 23:44:14 Added files: devel/vte3/patches: patch-src_missing_hh Log message: Fix devel/vte3 build on mips64. >From Brad
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/26 22:33:40 Modified files: sys/dev/fdt: if_cad.c Log message: Create DMA maps with 64-bit capability when appropriate. OK kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/26 22:32:31 Modified files: sys/dev/fdt: if_cad.c Log message: Use config register to determine if 64-bit DMA is available. Suggested by and OK kettenis@
Re: SiFive Unmatched if_cad fix
On Fri, Jun 25, 2021 at 04:15:43PM +0200, Mark Kettenis wrote: > > Date: Fri, 25 Jun 2021 13:27:28 + > > From: Visa Hankala > > > > On Thu, Jun 24, 2021 at 07:02:11PM +, Mickael Torres wrote: > > > Hello, > > > > > > On the risc-v SiFive Unmatched the internal cad0 ethernet interface stops > > > working randomly after some packets are sent/received. It looks like it's > > > because the bus_dmamap used isn't restricted to lower than 4GB physical > > > addresses, and the interface itself is. > > > > I am surprised that this has not been raised before. I also wonder if > > riscv64's DMA constraints are fully sane. > > There is no DMA constraint on riscv64 yet. We try to avoid having > such a constraint on platforms that don't have a long history, hoping > those platforms are (and remain) 64-bit "clean". And on some modern > platforms (e.g. arm64) there is no memory below 4GB, so we can't have > a DMA constraint on those platforms. The jury is still out where > riscv64 will end up. > > There is infrastructure to have the bootloader set the DMA constraint > based on the device tree. > > > > Configuring the interface for 64 bits DMA fixes the problem, and > > > the machine is now useable with its internal ethernet port. > > > > > > I didn't test very extensively, but it was very easy to run into > > > "cad0: hresp error, interface stopped" before the patch. After the > > > patch it survived a couple hours of tests and ping -f from and to > > > it. > > > > > > It is now depending on being compiled for __riscv64__ or not, would it be > > > better to do it dynamically when matching "sifive,fu740-c000-gem" ? > > > > Hopefully all 64-bit platforms have a 64-bit capable revision of the > > controller. > > So far that seems to be true. The controller on the PolarFire SoC is > also 64-bit capable. > > > However, I would avoid #ifdef'ing and make the selecting of > > the DMA mode happen at runtime. > > > > Below is how I had envisioned how the driver should work. > > > > I have not tested the 64-bit side of the patch. > > Seems to work fine. The diff looks good to me. Your diff does not > set a 4GB boundary in the bus_dmamap_create() call for the rings. It > works without that, but if there really is a hardware constraint in > crossing a 4GB boundary we may need to add this in. So far I have not spotted such a restriction in the documentations of Zynq UltraScale+ and PolarFire SoCs. These SoCs have 64-bit capable GEM controllers. The standalone GEM driver for Zynq in Xilinx embeddedsw library does have comments about not crossing the 0x boundary. However, those comments predate and seem inconsistent with 64-bit code. > The hardware has a register that indicates whether 64-bit DMA is > supported. Maybe we should look at that instead of checking the > compatible string. But let's get this in and tweak it later. The register is undocumented on the Zynq-7000. Reading the register returns a constant (?) value (0x200), but the value probably means something different. However, making the register access conditional to GEM version might work. Xilinx Zynq UltraScale+ and SiFive HiFive Unmatched have GEM version 0x7, whereas MicroSemi PolarFire and Xilinx Versal appear to have GEM version 0x107. In addition, as cad(4) is now able to use 64-bit DMA, the DMA maps could be created with the 64-bit capability turned on. The diff is untested on 64-bit hardware. Index: dev/fdt/if_cad.c === RCS file: src/sys/dev/fdt/if_cad.c,v retrieving revision 1.4 diff -u -p -r1.4 if_cad.c --- dev/fdt/if_cad.c26 Jun 2021 10:47:59 - 1.4 +++ dev/fdt/if_cad.c26 Jun 2021 11:08:36 - @@ -126,6 +126,8 @@ #define GEM_LADDRH(i) (0x008c + (i) * 8) #define GEM_LADDRNUM 4 #define GEM_MID0x00fc +#define GEM_MID_VERSION_MASK (0xfff << 16) +#define GEM_MID_VERSION_SHIFT 16 #define GEM_OCTTXL 0x0100 #define GEM_OCTTXH 0x0104 #define GEM_TXCNT 0x0108 @@ -169,6 +171,8 @@ #define GEM_RXIPCCNT 0x01a8 #define GEM_RXTCPCCNT 0x01ac #define GEM_RXUDPCCNT 0x01b0 +#define GEM_CFG6 0x0294 +#define GEM_CFG6_DMA64(1 << 23) #define GEM_TXQBASEHI 0x04c8 #define GEM_RXQBASEHI 0x04d4 @@ -364,6 +368,7 @@ cad_attach(struct device *parent, struct struct cad_softc *sc = (struct cad_
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/26 04:47:59 Modified files: sys/dev/fdt: if_cad.c Log message: cad: Implement 64-bit DMA mode This lets the driver utilize 64-bit DMA on hardware that supports it. Currently, riscv64 does not constrain DMA-reachable memory to the 32-bit range. This caused memory errors with cad(4) on machines that have RAM above 4GB in the physical address space. Prompted by Mickael Torres OK kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/25 07:29:40 Modified files: sys/dev/fdt: if_cad.c Log message: Remove an unused struct.
Re: SiFive Unmatched if_cad fix
On Thu, Jun 24, 2021 at 07:02:11PM +, Mickael Torres wrote:
> Hello,
>
> On the risc-v SiFive Unmatched the internal cad0 ethernet interface stops
> working randomly after some packets are sent/received. It looks like it's
> because the bus_dmamap used isn't restricted to lower than 4GB physical
> addresses, and the interface itself is.
I am surprised that this has not been raised before. I also wonder if
riscv64's DMA constraints are fully sane.
> Configuring the interface for 64 bits DMA fixes the problem, and the machine
> is now useable with its internal ethernet port.
>
> I didn't test very extensively, but it was very easy to run into
> "cad0: hresp error, interface stopped" before the patch. After the patch it
> survived a couple hours of tests and ping -f from and to it.
>
> It is now depending on being compiled for __riscv64__ or not, would it be
> better to do it dynamically when matching "sifive,fu740-c000-gem" ?
Hopefully all 64-bit platforms have a 64-bit capable revision of the
controller. However, I would avoid #ifdef'ing and make the selecting of
the DMA mode happen at runtime.
Below is how I had envisioned how the driver should work.
I have not tested the 64-bit side of the patch.
Index: dev/fdt/if_cad.c
===
RCS file: src/sys/dev/fdt/if_cad.c,v
retrieving revision 1.2
diff -u -p -r1.2 if_cad.c
--- dev/fdt/if_cad.c13 Jun 2021 02:56:48 - 1.2
+++ dev/fdt/if_cad.c25 Jun 2021 13:18:22 -
@@ -81,6 +81,7 @@
#define GEM_NETSR 0x0008
#define GEM_NETSR_PHY_MGMT_IDLE (1 << 2)
#define GEM_DMACR 0x0010
+#define GEM_DMACR_DMA64 (1 << 30)
#define GEM_DMACR_AHBDISC (1 << 24)
#define GEM_DMACR_RXBUF_MASK (0xff << 16)
#define GEM_DMACR_RXBUF_SHIFT 16
@@ -168,6 +169,8 @@
#define GEM_RXIPCCNT 0x01a8
#define GEM_RXTCPCCNT 0x01ac
#define GEM_RXUDPCCNT 0x01b0
+#define GEM_TXQBASEHI 0x04c8
+#define GEM_RXQBASEHI 0x04d4
#define GEM_CLK_TX "tx_clk"
@@ -183,11 +186,18 @@ struct cad_dmamem {
caddr_t cdm_kva;
};
-struct cad_desc {
+struct cad_desc32 {
uint32_td_addr;
uint32_td_status;
};
+struct cad_desc64 {
+ uint32_td_addrlo;
+ uint32_td_status;
+ uint32_td_addrhi;
+ uint32_td_unused;
+};
+
#define GEM_RXD_ADDR_WRAP (1 << 1)
#define GEM_RXD_ADDR_USED (1 << 0)
@@ -250,6 +260,8 @@ struct cad_softc {
enum cad_phy_mode sc_phy_mode;
unsigned char sc_rxhang_erratum;
unsigned char sc_rxdone;
+ unsigned char sc_dma64;
+ size_t sc_descsize;
struct mii_data sc_mii;
#define sc_media sc_mii.mii_media
@@ -257,14 +269,14 @@ struct cad_softc {
struct cad_dmamem *sc_txring;
struct cad_buf *sc_txbuf;
- struct cad_desc *sc_txdesc;
+ caddr_t sc_txdesc;
unsigned intsc_tx_prod;
unsigned intsc_tx_cons;
struct if_rxringsc_rx_ring;
struct cad_dmamem *sc_rxring;
struct cad_buf *sc_rxbuf;
- struct cad_desc *sc_rxdesc;
+ caddr_t sc_rxdesc;
unsigned intsc_rx_prod;
unsigned intsc_rx_cons;
uint32_tsc_netctl;
@@ -409,6 +421,12 @@ cad_attach(struct device *parent, struct
}
}
+ sc->sc_descsize = sizeof(struct cad_desc32);
+ if (OF_is_compatible(faa->fa_node, "sifive,fu740-c000-gem")) {
+ sc->sc_descsize = sizeof(struct cad_desc64);
+ sc->sc_dma64 = 1;
+ }
+
if (OF_is_compatible(faa->fa_node, "cdns,zynq-gem"))
sc->sc_rxhang_erratum = 1;
@@ -547,6 +565,10 @@ cad_reset(struct cad_softc *sc)
HWRITE4(sc, GEM_IDR, ~0U);
HWRITE4(sc, GEM_RXSR, 0);
HWRITE4(sc, GEM_TXSR, 0);
+ if (sc->sc_dma64) {
+ HWRITE4(sc, GEM_RXQBASEHI, 0);
+ HWRITE4(sc, GEM_TXQBASEHI, 0);
+ }
HWRITE4(sc, GEM_RXQBASE, 0);
HWRITE4(sc, GEM_TXQBASE, 0);
@@ -573,7 +595,9 @@ cad_up(struct cad_softc *sc)
{
struct ifnet *ifp = >sc_ac.ac_if;
struct cad_buf *rxb, *txb;
- struct cad_desc *rxd, *txd;
+ struct cad_desc32 *desc32;
+ struct cad_desc64 *desc64;
+ uint64_t addr;
unsigned int i;
uint32_t val;
@@ -582,8 +606,11 @@ cad_up(struct cad_softc *sc)
*/
sc->sc_txring = cad_dmamem_alloc(sc,
- CAD_NTXDESC * sizeof(struct cad_desc), sizeof(struct
Re: amd64: softintr_dispatch: remove kernel lock
On Wed, Jun 23, 2021 at 05:39:05PM +0200, Mark Kettenis wrote: > > Date: Wed, 23 Jun 2021 15:32:03 + > > From: Visa Hankala > > > > On Wed, Jun 23, 2021 at 05:15:05PM +0200, Mark Kettenis wrote: > > > > Date: Wed, 23 Jun 2021 14:56:45 + > > > > From: Visa Hankala > > > > > > > > On Tue, Jun 22, 2021 at 09:46:22AM -0500, Scott Cheloha wrote: > > > > > On Mon, Jun 21, 2021 at 02:04:30PM +, Visa Hankala wrote: > > > > > > On Thu, May 27, 2021 at 07:40:26PM -0500, Scott Cheloha wrote: > > > > > > > On Sun, May 23, 2021 at 09:05:24AM +, Visa Hankala wrote: > > > > > > > > When a CPU starts processing a soft interrupt, it reserves the > > > > > > > > handler > > > > > > > > to prevent concurrent execution. If the soft interrupt gets > > > > > > > > rescheduled > > > > > > > > during processing, the handler is run again by the same CPU. > > > > > > > > This breaks > > > > > > > > FIFO ordering, though. > > > > > > > > > > > > > > If you want to preserve FIFO you can reinsert the handler at the > > > > > > > queue > > > > > > > tail. That would be more fair. > > > > > > > > > > > > > > If FIFO is the current behavior I think we ought to keep it. > > > > > > > > > > > > I have updated the patch to preserve the FIFO order. > > > > > > > > > > > > > > +STAILQ_HEAD(x86_soft_intr_queue, x86_soft_intrhand); > > > > > > > > + > > > > > > > > +struct x86_soft_intr_queue softintr_queue[X86_NSOFTINTR]; > > > > > > > > > > > > > > Why did we switch to STAILQ? I know we don't have very many > > > > > > > softintr_disestablish() calls but isn't O(1) removal worth the > > > > > > > extra > > > > > > > pointer? > > > > > > > > > > > > I used STAILQ because it avoids the hassle of updating the list > > > > > > nodes' > > > > > > back pointers. softintr_disestablish() with multiple items pending > > > > > > in > > > > > > the queue is very rare in comparison to the normal > > > > > > softintr_schedule() / > > > > > > softintr_dispatch() cycle. > > > > > > > > > > > > However, I have changed the code back to using TAILQ. > > > > > > > > > > This looks good to me. I mean, it looked good before, but it still > > > > > looks good. > > > > > > > > > > I will run with it for a few days. > > > > > > > > > > Assuming I hit no issues I'll come back with an OK. > > > > > > > > > > Is there an easy way to exercise this code from userspace? There > > > > > aren't many softintr users. > > > > > > > > > > Maybe audio drivers? > > > > > > > > audio(4) is one option with a relatively high rate of scheduling. > > > > Serial communications drivers, such as com(4), might be useful for > > > > testing too. > > > > > > > > softintr_disestablish() can be exercised with uaudio(4) and ucom(4) > > > > for example. > > > > > > > > I am still uncertain whether the barrier in softintr_disestablish() > > > > is fully safe. The typical detach-side users are audio_detach(), > > > > com_detach() and usb_detach(). They should be fine because the > > > > surrounding code may sleep. However, sbus(4) worries me because it > > > > invokes softintr_disestablish() from PCMCIA intr_disestablish callback, > > > > and I do not know how wild the usage contexts can be. sbus(4) is > > > > specific to sparc64, though. > > > > > > Suprise-removal is a thing for PCI as well as PCMCIA and USB. And in > > > the PCI case this will call com_detach() and therefore > > > softintr_disestablish() from interrupt context, where you can't sleep. > > > > > > So I don't think that using some sort of barrier that sleeps is an > > > option. > > > > Well, com_detach() does things that may sleep, so then the existing code > > seems wrong. > > Hmm, actually, it seems I misremembered and PCI hotplug remove runs in > a task (see dev/pci/ppb.c). So maybe it is ok. > > > I will revise the diff so that it spins rather than sleeps when a handler > > is active. > > That wouldn't work on non-MP kernels isn't it? Barrier-like removal is not reliable in interrupt context because an interrupt might have preempted the soft interrupt handler that the interrupt handler is about to remove. This applies to both MP and non-MP kernels. On a non-MP kernel, spinning, or sleeping, is not actually needed. Pending soft interrupts should run immediately when the system priority level allows them. If SPL is none on entry to softintr_disestablish(), the handler should have finished already. If SPL blocks soft interrupts on entry, the dequeueing clears any pending soft interrupt.
Re: amd64: softintr_dispatch: remove kernel lock
On Wed, Jun 23, 2021 at 05:15:05PM +0200, Mark Kettenis wrote: > > Date: Wed, 23 Jun 2021 14:56:45 + > > From: Visa Hankala > > > > On Tue, Jun 22, 2021 at 09:46:22AM -0500, Scott Cheloha wrote: > > > On Mon, Jun 21, 2021 at 02:04:30PM +, Visa Hankala wrote: > > > > On Thu, May 27, 2021 at 07:40:26PM -0500, Scott Cheloha wrote: > > > > > On Sun, May 23, 2021 at 09:05:24AM +, Visa Hankala wrote: > > > > > > When a CPU starts processing a soft interrupt, it reserves the > > > > > > handler > > > > > > to prevent concurrent execution. If the soft interrupt gets > > > > > > rescheduled > > > > > > during processing, the handler is run again by the same CPU. This > > > > > > breaks > > > > > > FIFO ordering, though. > > > > > > > > > > If you want to preserve FIFO you can reinsert the handler at the queue > > > > > tail. That would be more fair. > > > > > > > > > > If FIFO is the current behavior I think we ought to keep it. > > > > > > > > I have updated the patch to preserve the FIFO order. > > > > > > > > > > +STAILQ_HEAD(x86_soft_intr_queue, x86_soft_intrhand); > > > > > > + > > > > > > +struct x86_soft_intr_queue softintr_queue[X86_NSOFTINTR]; > > > > > > > > > > Why did we switch to STAILQ? I know we don't have very many > > > > > softintr_disestablish() calls but isn't O(1) removal worth the extra > > > > > pointer? > > > > > > > > I used STAILQ because it avoids the hassle of updating the list nodes' > > > > back pointers. softintr_disestablish() with multiple items pending in > > > > the queue is very rare in comparison to the normal softintr_schedule() / > > > > softintr_dispatch() cycle. > > > > > > > > However, I have changed the code back to using TAILQ. > > > > > > This looks good to me. I mean, it looked good before, but it still > > > looks good. > > > > > > I will run with it for a few days. > > > > > > Assuming I hit no issues I'll come back with an OK. > > > > > > Is there an easy way to exercise this code from userspace? There > > > aren't many softintr users. > > > > > > Maybe audio drivers? > > > > audio(4) is one option with a relatively high rate of scheduling. > > Serial communications drivers, such as com(4), might be useful for > > testing too. > > > > softintr_disestablish() can be exercised with uaudio(4) and ucom(4) > > for example. > > > > I am still uncertain whether the barrier in softintr_disestablish() > > is fully safe. The typical detach-side users are audio_detach(), > > com_detach() and usb_detach(). They should be fine because the > > surrounding code may sleep. However, sbus(4) worries me because it > > invokes softintr_disestablish() from PCMCIA intr_disestablish callback, > > and I do not know how wild the usage contexts can be. sbus(4) is > > specific to sparc64, though. > > Suprise-removal is a thing for PCI as well as PCMCIA and USB. And in > the PCI case this will call com_detach() and therefore > softintr_disestablish() from interrupt context, where you can't sleep. > > So I don't think that using some sort of barrier that sleeps is an > option. Well, com_detach() does things that may sleep, so then the existing code seems wrong. I will revise the diff so that it spins rather than sleeps when a handler is active.
Re: amd64: softintr_dispatch: remove kernel lock
On Tue, Jun 22, 2021 at 09:46:22AM -0500, Scott Cheloha wrote: > On Mon, Jun 21, 2021 at 02:04:30PM +0000, Visa Hankala wrote: > > On Thu, May 27, 2021 at 07:40:26PM -0500, Scott Cheloha wrote: > > > On Sun, May 23, 2021 at 09:05:24AM +, Visa Hankala wrote: > > > > When a CPU starts processing a soft interrupt, it reserves the handler > > > > to prevent concurrent execution. If the soft interrupt gets rescheduled > > > > during processing, the handler is run again by the same CPU. This breaks > > > > FIFO ordering, though. > > > > > > If you want to preserve FIFO you can reinsert the handler at the queue > > > tail. That would be more fair. > > > > > > If FIFO is the current behavior I think we ought to keep it. > > > > I have updated the patch to preserve the FIFO order. > > > > > > +STAILQ_HEAD(x86_soft_intr_queue, x86_soft_intrhand); > > > > + > > > > +struct x86_soft_intr_queue softintr_queue[X86_NSOFTINTR]; > > > > > > Why did we switch to STAILQ? I know we don't have very many > > > softintr_disestablish() calls but isn't O(1) removal worth the extra > > > pointer? > > > > I used STAILQ because it avoids the hassle of updating the list nodes' > > back pointers. softintr_disestablish() with multiple items pending in > > the queue is very rare in comparison to the normal softintr_schedule() / > > softintr_dispatch() cycle. > > > > However, I have changed the code back to using TAILQ. > > This looks good to me. I mean, it looked good before, but it still > looks good. > > I will run with it for a few days. > > Assuming I hit no issues I'll come back with an OK. > > Is there an easy way to exercise this code from userspace? There > aren't many softintr users. > > Maybe audio drivers? audio(4) is one option with a relatively high rate of scheduling. Serial communications drivers, such as com(4), might be useful for testing too. softintr_disestablish() can be exercised with uaudio(4) and ucom(4) for example. I am still uncertain whether the barrier in softintr_disestablish() is fully safe. The typical detach-side users are audio_detach(), com_detach() and usb_detach(). They should be fine because the surrounding code may sleep. However, sbus(4) worries me because it invokes softintr_disestablish() from PCMCIA intr_disestablish callback, and I do not know how wild the usage contexts can be. sbus(4) is specific to sparc64, though.
Re: amd64: softintr_dispatch: remove kernel lock
On Thu, May 27, 2021 at 07:40:26PM -0500, Scott Cheloha wrote:
> On Sun, May 23, 2021 at 09:05:24AM +0000, Visa Hankala wrote:
> > When a CPU starts processing a soft interrupt, it reserves the handler
> > to prevent concurrent execution. If the soft interrupt gets rescheduled
> > during processing, the handler is run again by the same CPU. This breaks
> > FIFO ordering, though.
>
> If you want to preserve FIFO you can reinsert the handler at the queue
> tail. That would be more fair.
>
> If FIFO is the current behavior I think we ought to keep it.
I have updated the patch to preserve the FIFO order.
> > +STAILQ_HEAD(x86_soft_intr_queue, x86_soft_intrhand);
> > +
> > +struct x86_soft_intr_queue softintr_queue[X86_NSOFTINTR];
>
> Why did we switch to STAILQ? I know we don't have very many
> softintr_disestablish() calls but isn't O(1) removal worth the extra
> pointer?
I used STAILQ because it avoids the hassle of updating the list nodes'
back pointers. softintr_disestablish() with multiple items pending in
the queue is very rare in comparison to the normal softintr_schedule() /
softintr_dispatch() cycle.
However, I have changed the code back to using TAILQ.
Index: arch/amd64/amd64/softintr.c
===
RCS file: src/sys/arch/amd64/amd64/softintr.c,v
retrieving revision 1.10
diff -u -p -r1.10 softintr.c
--- arch/amd64/amd64/softintr.c 11 Sep 2020 09:27:09 - 1.10
+++ arch/amd64/amd64/softintr.c 21 Jun 2021 13:32:33 -
@@ -37,12 +37,33 @@
#include
#include
#include
+#include
+#include
#include
#include
-struct x86_soft_intr x86_soft_intrs[X86_NSOFTINTR];
+struct x86_soft_intrhand {
+ TAILQ_ENTRY(x86_soft_intrhand) sih_q;
+ void(*sih_fn)(void *);
+ void*sih_arg;
+ struct cpu_info *sih_runner;
+ int sih_which;
+ unsigned short sih_flags;
+ unsigned short sih_state;
+};
+
+#define SIF_MPSAFE 0x0001
+
+#define SIS_DYING 0x0001
+#define SIS_PENDING0x0002
+#define SIS_RESTART0x0004
+
+TAILQ_HEAD(x86_soft_intr_queue, x86_soft_intrhand);
+
+struct x86_soft_intr_queue softintr_queue[X86_NSOFTINTR];
+struct mutex softintr_lock = MUTEX_INITIALIZER(IPL_HIGH);
const int x86_soft_intr_to_ssir[X86_NSOFTINTR] = {
SIR_CLOCK,
@@ -58,15 +79,10 @@ const int x86_soft_intr_to_ssir[X86_NSOF
void
softintr_init(void)
{
- struct x86_soft_intr *si;
int i;
- for (i = 0; i < X86_NSOFTINTR; i++) {
- si = _soft_intrs[i];
- TAILQ_INIT(>softintr_q);
- mtx_init(>softintr_lock, IPL_HIGH);
- si->softintr_ssir = x86_soft_intr_to_ssir[i];
- }
+ for (i = 0; i < nitems(softintr_queue); i++)
+ TAILQ_INIT(_queue[i]);
}
/*
@@ -78,31 +94,44 @@ void
softintr_dispatch(int which)
{
struct cpu_info *ci = curcpu();
- struct x86_soft_intr *si = _soft_intrs[which];
+ struct x86_soft_intr_queue *queue = _queue[which];
struct x86_soft_intrhand *sih;
int floor;
floor = ci->ci_handled_intr_level;
ci->ci_handled_intr_level = ci->ci_ilevel;
- KERNEL_LOCK();
- for (;;) {
- mtx_enter(>softintr_lock);
- sih = TAILQ_FIRST(>softintr_q);
- if (sih == NULL) {
- mtx_leave(>softintr_lock);
- break;
+ mtx_enter(_lock);
+ while ((sih = TAILQ_FIRST(queue)) != NULL) {
+ KASSERT((sih->sih_state & (SIS_PENDING | SIS_RESTART)) ==
+ SIS_PENDING);
+ KASSERT(sih->sih_runner == NULL);
+
+ sih->sih_state &= ~SIS_PENDING;
+ TAILQ_REMOVE(queue, sih, sih_q);
+ sih->sih_runner = ci;
+ mtx_leave(_lock);
+
+ if (sih->sih_flags & SIF_MPSAFE) {
+ (*sih->sih_fn)(sih->sih_arg);
+ } else {
+ KERNEL_LOCK();
+ (*sih->sih_fn)(sih->sih_arg);
+ KERNEL_UNLOCK();
}
- TAILQ_REMOVE(>softintr_q, sih, sih_q);
- sih->sih_pending = 0;
- uvmexp.softs++;
-
- mtx_leave(>softintr_lock);
+ mtx_enter(_lock);
+ KASSERT((sih->sih_state & SIS_PENDING) == 0);
+ sih->sih_runner = NULL;
+ if (sih->sih_state & SIS_RESTART) {
+ TAILQ_INSERT_TAIL(queue, sih, sih_q);
+ sih->sih_state |= SIS_PENDING;
+ sih->sih_state &= ~SIS_RESTART;
+ }
- (*sih-&g
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Fri Jun 11 15:59:37 UTC 2021 finished at Fri Jun 18 16:46:15 UTC 2021 lasted 08D00h46m done with kern.version=OpenBSD 6.9-current (GENERIC.MP) #597: Fri Jun 11 05:08:47 MDT 2021 built packages:8945 Jun 11:1814 Jun 12:970 Jun 13:551 Jun 14:969 Jun 15:685 Jun 16:701 Jun 17:706 Jun 18:2548 build failures: 40 http://build-failures.rhaalovely.net/mips64/2021-06-11/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2021-06-11/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-06-11/comms/lcdproc.log http://build-failures.rhaalovely.net/mips64/2021-06-11/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2021-06-11/devel/boost.log http://build-failures.rhaalovely.net/mips64/2021-06-11/devel/ccache.log http://build-failures.rhaalovely.net/mips64/2021-06-11/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-06-11/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-06-11/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-06-11/devel/vte3.log http://build-failures.rhaalovely.net/mips64/2021-06-11/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-06-11/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-06-11/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-06-11/games/eduke32.log http://build-failures.rhaalovely.net/mips64/2021-06-11/games/godot.log http://build-failures.rhaalovely.net/mips64/2021-06-11/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-06-11/games/unknown-horizons.log http://build-failures.rhaalovely.net/mips64/2021-06-11/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-06-11/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-06-11/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net/mips64/2021-06-11/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-06-11/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-06-11/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-06-11/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-06-11/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-06-11/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-06-11/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-06-11/math/py-scikit-image,python3.log http://build-failures.rhaalovely.net/mips64/2021-06-11/multimedia/frei0r-plugins.log http://build-failures.rhaalovely.net/mips64/2021-06-11/net/barrier.log http://build-failures.rhaalovely.net/mips64/2021-06-11/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2021-06-11/net/tdlib.log http://build-failures.rhaalovely.net/mips64/2021-06-11/net/utox.log http://build-failures.rhaalovely.net/mips64/2021-06-11/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-06-11/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-06-11/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-06-11/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net/mips64/2021-06-11/x11/gtk+4.log http://build-failures.rhaalovely.net/mips64/2021-06-11/x11/qt5/qtscript,,-main.log http://build-failures.rhaalovely.net/mips64/2021-06-11/x11/qt5/qtwebkit.log
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/16 08:26:30 Modified files: sys/kern : kern_event.c sys/sys: event.h Log message: kqueue: kq_lock is needed when updating kn_status The kn_status field of struct knote is part of kqueue's internal state. When kn_status is being updated, kq_lock has to be locked. This is true even with MP-unsafe event filters. OK mpi@
Re: kq_lock is required when updating kn_status
On Mon, Jun 14, 2021 at 11:44:15PM +0200, Martin Pieuchot wrote:
> On 14/06/21(Mon) 13:45, Visa Hankala wrote:
> > When a knote's kn_status is updated, it is necessary to lock the kqueue
> > that owns the knote, to ensure proper serialization. filt_proc() has
> > a mistake in this, and the following diff fixes it.
>
> The fix is here to ensure `kn_status' cannot be written by two different
> threads at the same time, right?
That is correct. Even though knotes of EVFILT_PROC / proc_filtops are
processed with the kernel locked, the knotes can be knote_acquire()'ed
without the kernel lock once kevent(2) is unlocked.
> > proc_filtops is MP-unsafe and all its callbacks run with the kernel
> > locked. The kernel lock should provide sufficient memory synchronization
> > for filt_procdetach() to check condition (kn->kn_status & KN_DETACHED)
> > without kq_lock; the value of kn_status seen by filt_procdetach() should
> > be at least as recent as seen by the latest filt_proc(NOTE_EXIT) call.
>
> I understand that protecting the read in filt_procdetach() is not
> strictly necessary, but isn't it too clever? I haven't seen any other
> piece of code that access `kn_status' w/o holding `kq_lock'. Unless you
> have pending plans for this, I'd suggest we also grab the lock there.
Well, I don't know if it is too clever. I think that the critical section
is longer than what the mutex covers, and rely on the kernel lock to
provide the serialization between filt_proc() and filt_procdetach().
However, here is an updated diff:
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.166
diff -u -p -r1.166 kern_event.c
--- kern/kern_event.c 11 Jun 2021 04:29:54 - 1.166
+++ kern/kern_event.c 15 Jun 2021 12:51:41 -
@@ -328,10 +328,15 @@ filt_procattach(struct knote *kn)
void
filt_procdetach(struct knote *kn)
{
+ struct kqueue *kq = kn->kn_kq;
struct process *pr = kn->kn_ptr.p_process;
- int s;
+ int s, status;
- if (kn->kn_status & KN_DETACHED)
+ mtx_enter(>kq_lock);
+ status = kn->kn_status;
+ mtx_leave(>kq_lock);
+
+ if (status & KN_DETACHED)
return;
s = splhigh();
@@ -342,6 +347,7 @@ filt_procdetach(struct knote *kn)
int
filt_proc(struct knote *kn, long hint)
{
+ struct kqueue *kq = kn->kn_kq;
u_int event;
/*
@@ -363,8 +369,11 @@ filt_proc(struct knote *kn, long hint)
struct process *pr = kn->kn_ptr.p_process;
int s;
- s = splhigh();
+ mtx_enter(>kq_lock);
kn->kn_status |= KN_DETACHED;
+ mtx_leave(>kq_lock);
+
+ s = splhigh();
kn->kn_flags |= (EV_EOF | EV_ONESHOT);
kn->kn_data = W_EXITCODE(pr->ps_xexit, pr->ps_xsig);
klist_remove_locked(>ps_klist, kn);
@@ -391,7 +400,7 @@ filt_proc(struct knote *kn, long hint)
kev.fflags = kn->kn_sfflags;
kev.data = kn->kn_id; /* parent */
kev.udata = kn->kn_udata; /* preserve udata */
- error = kqueue_register(kn->kn_kq, , NULL);
+ error = kqueue_register(kq, , NULL);
if (error)
kn->kn_fflags |= NOTE_TRACKERR;
}
Index: sys/event.h
===
RCS file: src/sys/sys/event.h,v
retrieving revision 1.55
diff -u -p -r1.55 event.h
--- sys/event.h 2 Jun 2021 13:56:28 - 1.55
+++ sys/event.h 15 Jun 2021 12:51:41 -
@@ -228,6 +228,7 @@ struct filterops {
* Locking:
* I immutable after creation
* o object lock
+ * q kn_kq->kq_lock
*/
struct knote {
SLIST_ENTRY(knote) kn_link;/* for fd */
@@ -235,7 +236,7 @@ struct knote {
TAILQ_ENTRY(knote) kn_tqe;
struct kqueue *kn_kq; /* [I] which queue we are on */
struct kevent kn_kevent;
- int kn_status;
+ int kn_status; /* [q] */
int kn_sfflags; /* [o] saved filter flags */
__int64_t kn_sdata; /* [o] saved data field */
union {
kq_lock is required when updating kn_status
When a knote's kn_status is updated, it is necessary to lock the kqueue
that owns the knote, to ensure proper serialization. filt_proc() has
a mistake in this, and the following diff fixes it.
proc_filtops is MP-unsafe and all its callbacks run with the kernel
locked. The kernel lock should provide sufficient memory synchronization
for filt_procdetach() to check condition (kn->kn_status & KN_DETACHED)
without kq_lock; the value of kn_status seen by filt_procdetach() should
be at least as recent as seen by the latest filt_proc(NOTE_EXIT) call.
Also, the splitting of the splhigh() section in filt_proc() should be
harmless. The KN_DETACHED flag is only checked by filt_procdetach()
which runs in process context.
OK?
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.166
diff -u -p -r1.166 kern_event.c
--- kern/kern_event.c 11 Jun 2021 04:29:54 - 1.166
+++ kern/kern_event.c 14 Jun 2021 13:37:55 -
@@ -331,6 +331,8 @@ filt_procdetach(struct knote *kn)
struct process *pr = kn->kn_ptr.p_process;
int s;
+ KERNEL_ASSERT_LOCKED();
+
if (kn->kn_status & KN_DETACHED)
return;
@@ -342,6 +344,7 @@ filt_procdetach(struct knote *kn)
int
filt_proc(struct knote *kn, long hint)
{
+ struct kqueue *kq = kn->kn_kq;
u_int event;
/*
@@ -363,8 +366,11 @@ filt_proc(struct knote *kn, long hint)
struct process *pr = kn->kn_ptr.p_process;
int s;
- s = splhigh();
+ mtx_enter(>kq_lock);
kn->kn_status |= KN_DETACHED;
+ mtx_leave(>kq_lock);
+
+ s = splhigh();
kn->kn_flags |= (EV_EOF | EV_ONESHOT);
kn->kn_data = W_EXITCODE(pr->ps_xexit, pr->ps_xsig);
klist_remove_locked(>ps_klist, kn);
@@ -391,7 +397,7 @@ filt_proc(struct knote *kn, long hint)
kev.fflags = kn->kn_sfflags;
kev.data = kn->kn_id; /* parent */
kev.udata = kn->kn_udata; /* preserve udata */
- error = kqueue_register(kn->kn_kq, , NULL);
+ error = kqueue_register(kq, , NULL);
if (error)
kn->kn_fflags |= NOTE_TRACKERR;
}
Index: sys/event.h
===
RCS file: src/sys/sys/event.h,v
retrieving revision 1.55
diff -u -p -r1.55 event.h
--- sys/event.h 2 Jun 2021 13:56:28 - 1.55
+++ sys/event.h 14 Jun 2021 13:37:55 -
@@ -228,6 +228,7 @@ struct filterops {
* Locking:
* I immutable after creation
* o object lock
+ * q kn_kq->kq_lock
*/
struct knote {
SLIST_ENTRY(knote) kn_link;/* for fd */
@@ -235,7 +236,7 @@ struct knote {
TAILQ_ENTRY(knote) kn_tqe;
struct kqueue *kn_kq; /* [I] which queue we are on */
struct kevent kn_kevent;
- int kn_status;
+ int kn_status; /* [q] */
int kn_sfflags; /* [o] saved filter flags */
__int64_t kn_sdata; /* [o] saved data field */
union {
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/12 07:30:14 Modified files: regress/sys/kern/kqueue: Makefile kqueue-timer.c main.c main.h Log message: Exercise resetting of expired and unexpired timers.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: v...@cvs.openbsd.org2021/06/11 09:37:15 Modified files: devel/libffi : Makefile Added files: devel/libffi/patches: patch-src_mips_n32_S Log message: Fix devel/libffi build on mips64 after clang 11 upgrade. OK naddy@
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Sat Jun 5 09:30:29 UTC 2021 finished at Thu Jun 10 01:20:32 UTC 2021 lasted 05D15h50m done with kern.version=OpenBSD 6.9-current (GENERIC.MP) #588: Fri Jun 4 13:20:05 MDT 2021 built packages:8187 Jun 5:1635 Jun 6:4419 Jun 7:1136 Jun 8:533 Jun 9:452 Jun 10:11 build failures: 35 http://build-failures.rhaalovely.net/mips64/2021-06-05/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2021-06-05/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2021-06-05/comms/lcdproc.log http://build-failures.rhaalovely.net/mips64/2021-06-05/devel/ccache.log http://build-failures.rhaalovely.net/mips64/2021-06-05/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2021-06-05/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2021-06-05/devel/libexecinfo.log http://build-failures.rhaalovely.net/mips64/2021-06-05/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2021-06-05/devel/vte3.log http://build-failures.rhaalovely.net/mips64/2021-06-05/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2021-06-05/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2021-06-05/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2021-06-05/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2021-06-05/games/unknown-horizons.log http://build-failures.rhaalovely.net/mips64/2021-06-05/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2021-06-05/graphics/asymptote.log http://build-failures.rhaalovely.net/mips64/2021-06-05/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net/mips64/2021-06-05/lang/STk.log http://build-failures.rhaalovely.net/mips64/2021-06-05/lang/gerbil.log http://build-failures.rhaalovely.net/mips64/2021-06-05/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2021-06-05/lang/librep.log http://build-failures.rhaalovely.net/mips64/2021-06-05/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2021-06-05/math/gbc.log http://build-failures.rhaalovely.net/mips64/2021-06-05/math/lrs.log http://build-failures.rhaalovely.net/mips64/2021-06-05/math/ntl.log http://build-failures.rhaalovely.net/mips64/2021-06-05/multimedia/frei0r-plugins.log http://build-failures.rhaalovely.net/mips64/2021-06-05/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2021-06-05/security/botan2.log http://build-failures.rhaalovely.net/mips64/2021-06-05/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2021-06-05/sysutils/menulibre.log http://build-failures.rhaalovely.net/mips64/2021-06-05/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net/mips64/2021-06-05/x11/gnome/libbonobo.log http://build-failures.rhaalovely.net/mips64/2021-06-05/x11/gnome/seahorse.log http://build-failures.rhaalovely.net/mips64/2021-06-05/x11/p5-Tk-ProgressBar-Mac.log http://build-failures.rhaalovely.net/mips64/2021-06-05/x11/p5-Tk-TableMatrix.log
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/10 22:29:54 Modified files: sys/kern : kern_event.c Log message: Remember to lock kqueue mutex in filt_timermodify(). Reported-by: syzbot+c2aba7645a218ce03...@syzkaller.appspotmail.com
Fix devel/libffi on mips64
devel/libffi has been broken on mips64 since base clang was upgraded to version 11. The integrated assembler is now more strict about section flags and throws an error if .eh_frame section is not read-only. The following patch lets devel/libffi build finish. OK? Index: Makefile === RCS file: ports/devel/libffi/Makefile,v retrieving revision 1.42 diff -u -p -r1.42 Makefile --- Makefile10 Feb 2020 18:06:34 - 1.42 +++ Makefile10 Jun 2021 15:30:55 - @@ -3,6 +3,7 @@ COMMENT= Foreign Function Interface DISTNAME= libffi-3.3 +REVISION= 0 SHARED_LIBS += ffi 1.2 # .6.4 CATEGORIES=devel Index: patches/patch-src_mips_n32_S === RCS file: patches/patch-src_mips_n32_S diff -N patches/patch-src_mips_n32_S --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_mips_n32_S10 Jun 2021 15:31:06 - @@ -0,0 +1,21 @@ +$OpenBSD$ + +Use EH_FRAME_FLAGS to get section flags that clang's integrated assembler +expects. This fixes the following build error on mips64: + +../src/mips/n32.S:585:9: error: changed section flags for .eh_frame, expected: 0x2 +.section .eh_frame,"aw",@progbits +^ + +Index: src/mips/n32.S +--- src/mips/n32.S.orig src/mips/n32.S +@@ -582,7 +582,7 @@ cls_epilogue: + .endffi_closure_N32 + + #ifdef __GNUC__ +-.section.eh_frame,"aw",@progbits ++.section.eh_frame,EH_FRAME_FLAGS,@progbits + .Lframe1: + .4byte .LECIE1-.LSCIE1 # length + .LSCIE1:
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/10 09:10:56 Modified files: sys/kern : kern_event.c sys/sys: eventvar.h Log message: Serialize internals of kqueue with a mutex Extend struct kqueue with a mutex and use it to serializes the internals of each kqueue instance. This should make possible to call kqueue's system call interface without the kernel lock. The event source facing side of kqueue should now be MP-safe, too, as long as the event source itself is MP-safe. msleep() with PCATCH still requires the kernel lock. To manage with this, kqueue_scan() locks the kernel temporarily for the section that may sleep. As a consequence of the kqueue mutex, knote_acquire() can lose a wakeup when klist_invalidate() calls it. To preserve proper nesting of mutexes, knote_acquire() has to release the kqueue mutex before it unlocks klist. This early unlocking of the mutex lets badly timed wakeups go unnoticed. However, the system should not hang because the sleep has a timeout. Tested by gnezdo@ and mpi@ OK mpi@
Unify soft interrupt implementations a little
softintr_schedule() is defined either as a function or as a macro.
The patch below turns the macros into proper functions, to reduce the
differences between the soft interrupt implementations.
The patch additionally moves the soft interrupt handle definitions from
the headers to the C modules that implement soft interrupts. The callers
of the softintr interface generally do not need to see the definitions
as softintr_establish() returns opaque handles. This moving eases
changing the structs because of reduced scope of visibility.
Certain arm*-land drivers have taken the liberty to treat the return
type of softintr_establish() as ``struct soft_intrhand *''. Because
of this, the diff forward-declares struct soft_intrhand in the headers
that previously defined a struct with this name.
OK?
Index: arch/alpha/alpha/interrupt.c
===
RCS file: src/sys/arch/alpha/alpha/interrupt.c,v
retrieving revision 1.40
diff -u -p -r1.40 interrupt.c
--- arch/alpha/alpha/interrupt.c21 Jan 2017 05:42:03 - 1.40
+++ arch/alpha/alpha/interrupt.c4 Jun 2021 15:28:38 -
@@ -70,6 +70,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -88,6 +90,22 @@
#include "lca.h"
#include "tcasic.h"
+struct alpha_soft_intrhand {
+ TAILQ_ENTRY(alpha_soft_intrhand)
+ sih_q;
+ struct alpha_soft_intr *sih_intrhead;
+ void(*sih_fn)(void *);
+ void*sih_arg;
+ int sih_pending;
+};
+
+struct alpha_soft_intr {
+ TAILQ_HEAD(, alpha_soft_intrhand)
+ softintr_q;
+ struct mutex softintr_mtx;
+ unsigned long softintr_siq;
+};
+
extern struct evcount clk_count;
struct scbvec scb_iovectab[SCB_VECTOIDX(SCB_SIZE - SCB_IOVECBASE)];
Index: arch/alpha/include/intr.h
===
RCS file: src/sys/arch/alpha/include/intr.h,v
retrieving revision 1.49
diff -u -p -r1.49 intr.h
--- arch/alpha/include/intr.h 24 Mar 2019 06:19:26 - 1.49
+++ arch/alpha/include/intr.h 4 Jun 2021 15:28:38 -
@@ -62,7 +62,6 @@
#define _MACHINE_INTR_H_
#include
-#include
#include
#include
@@ -254,22 +253,6 @@ extern unsigned long ssir;
#definesetsoft(x) atomic_setbits_ulong(, 1 << (x))
-struct alpha_soft_intrhand {
- TAILQ_ENTRY(alpha_soft_intrhand)
- sih_q;
- struct alpha_soft_intr *sih_intrhead;
- void(*sih_fn)(void *);
- void*sih_arg;
- int sih_pending;
-};
-
-struct alpha_soft_intr {
- TAILQ_HEAD(, alpha_soft_intrhand)
- softintr_q;
- struct mutex softintr_mtx;
- unsigned long softintr_siq;
-};
-
voidsoftintr_disestablish(void *);
voidsoftintr_dispatch(void);
void *softintr_establish(int, void (*)(void *), void *);
Index: arch/amd64/amd64/softintr.c
===
RCS file: src/sys/arch/amd64/amd64/softintr.c,v
retrieving revision 1.10
diff -u -p -r1.10 softintr.c
--- arch/amd64/amd64/softintr.c 11 Sep 2020 09:27:09 - 1.10
+++ arch/amd64/amd64/softintr.c 4 Jun 2021 15:28:38 -
@@ -37,11 +37,29 @@
#include
#include
#include
+#include
+#include
#include
#include
+struct x86_soft_intrhand {
+ TAILQ_ENTRY(x86_soft_intrhand)
+ sih_q;
+ struct x86_soft_intr *sih_intrhead;
+ void(*sih_fn)(void *);
+ void*sih_arg;
+ int sih_pending;
+};
+
+struct x86_soft_intr {
+ TAILQ_HEAD(, x86_soft_intrhand)
+ softintr_q;
+ int softintr_ssir;
+ struct mutexsoftintr_lock;
+};
+
struct x86_soft_intr x86_soft_intrs[X86_NSOFTINTR];
const int x86_soft_intr_to_ssir[X86_NSOFTINTR] = {
@@ -169,3 +187,18 @@ softintr_disestablish(void *arg)
free(sih, M_DEVBUF, sizeof(*sih));
}
+
+void
+softintr_schedule(void *arg)
+{
+ struct x86_soft_intrhand *sih = arg;
+ struct x86_soft_intr *si = sih->sih_intrhead;
+
+ mtx_enter(>softintr_lock);
+ if (sih->sih_pending == 0) {
+ TAILQ_INSERT_TAIL(>softintr_q, sih, sih_q);
+ sih->sih_pending = 1;
+ softintr(si->softintr_ssir);
+ }
+ mtx_leave(>softintr_lock);
+}
Index: arch/amd64/include/intr.h
===
RCS file: src/sys/arch/amd64/include/intr.h,v
retrieving revision 1.32
diff -u -p -r1.32 intr.h
--- arch/amd64/include/intr.h 17 Jun 2020 06:14:52 - 1.32
+++ arch/amd64/include/intr.h 4 Jun 2021 15:28:38 -
@@ -231,42 +231,13 @@ extern void (*ipifunc[X86_NIPI])(struct
#defineX86_NSOFTINTR 3
#ifndef _LOCORE
-#include
-
-struct x86_soft_intrhand {
- TAILQ_ENTRY(x86_soft_intrhand)
- sih_q;
- struct x86_soft_intr *sih_intrhead;
- void(*sih_fn)(void
Re: Serialize kqueue's internals with a mutex
On Thu, May 20, 2021 at 01:56:24PM +, Visa Hankala wrote:
> This patch adds a mutex that serializes access to a kqueue. As a result,
> most of kqueue's internals should become safe to run without the kernel
> lock. In principle, the patch should allow unlocking kevent(2).
>
> Some notes:
>
> * The existing uses of splhigh() outline where the mutex should be held.
>
> * The code is a true entanglement of lock operations. There are many
> spots where lock usage is far from optimal. The patch does not attempt
> to fix them, so as to keep the changeset relatively small.
>
> * As msleep() with PCATCH requires the kernel lock, kqueue_scan() locks
> the kernel for the section that might sleep. The lock is released
> before the actual scan of events. An opportunistic implementation
> could do a precheck to determine if the scan could be started right
> away, but this is not part of the diff.
>
> * knote_acquire() has a gap where it might miss a wakeup. This is an
> unlikely situation that may arise with klist_invalidate(). It should
> not happen during normal operation, and the code should recover thanks
> to the one-second timeout. The loss of wakeup could be avoided with
> serial numbering for example.
>
> * The timeout in knote_acquire() makes the function try-lock-like, which
> is essential in klist_invalidate(). The normal sequence of action is
> that knote_acquire() comes before klist_lock(). klist_invalidate() has
> to violate this, and the timeout, and retrying, prevent the system
> from deadlocking.
>
> * At the moment, all event sources still require the kernel lock.
> kqueue will lock the kernel when it invokes the filterops callbacks
> if FILTEROP_MPSAFE is not set.
Here is an updated patch. The changes are:
* Lock kqueue mutex in filt_kqueue() for accessing kq_count, to avoid
an unlocked read.
There still is an unlocked read of kq_count in kqueue_stat(). However,
I think it is good enough as is because the value returned to
userspace is best-effort anyhow (FreeBSD omits it altogether).
* Make callers of knote_activate() lock the mutex. This reduces the
number of lock operations.
* Adjust mutex assertion in knote_release() to avoid an unused variable
when compiling without DIAGNOSTIC.
OK?
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.164
diff -u -p -r1.164 kern_event.c
--- kern/kern_event.c 2 Jun 2021 13:56:28 - 1.164
+++ kern/kern_event.c 3 Jun 2021 14:06:54 -
@@ -123,7 +123,8 @@ voidknote_dequeue(struct knote *kn);
intknote_acquire(struct knote *kn, struct klist *, int);
void knote_release(struct knote *kn);
void knote_activate(struct knote *kn);
-void knote_remove(struct proc *p, struct knlist *list, int purge);
+void knote_remove(struct proc *p, struct kqueue *kq, struct knlist *list,
+ int purge);
void filt_kqdetach(struct knote *kn);
intfilt_kqueue(struct knote *kn, long hint);
@@ -270,7 +271,9 @@ filt_kqueue(struct knote *kn, long hint)
{
struct kqueue *kq = kn->kn_fp->f_data;
+ mtx_enter(>kq_lock);
kn->kn_data = kq->kq_count;
+ mtx_leave(>kq_lock);
return (kn->kn_data > 0);
}
@@ -416,9 +419,12 @@ void
filt_timerexpire(void *knx)
{
struct knote *kn = knx;
+ struct kqueue *kq = kn->kn_kq;
kn->kn_data++;
+ mtx_enter(>kq_lock);
knote_activate(kn);
+ mtx_leave(>kq_lock);
if ((kn->kn_flags & EV_ONESHOT) == 0)
filt_timer_timeout_add(kn);
@@ -744,28 +750,31 @@ kqpoll_dequeue(struct proc *p)
{
struct knote *kn;
struct kqueue *kq = p->p_kq;
- int s;
- s = splhigh();
+ mtx_enter(>kq_lock);
while ((kn = TAILQ_FIRST(>kq_head)) != NULL) {
/* This kqueue should not be scanned by other threads. */
KASSERT(kn->kn_filter != EVFILT_MARKER);
- if (!knote_acquire(kn, NULL, 0))
+ if (!knote_acquire(kn, NULL, 0)) {
+ /* knote_acquire() has released kq_lock. */
+ mtx_enter(>kq_lock);
continue;
+ }
kqueue_check(kq);
TAILQ_REMOVE(>kq_head, kn, kn_tqe);
kn->kn_status &= ~KN_QUEUED;
kq->kq_count--;
+ mtx_leave(>kq_lock);
- splx(s);
- kn->kn_fop->f_detach(kn);
+ filter_detach(kn);
knote_drop(kn, p);
- s = splhigh();
+
+ mtx_enter(>kq_lock);
kqueue_check(kq);
}
- splx(s);
+ mtx_leave(>kq_lock);
}
st
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: v...@cvs.openbsd.org2021/06/02 08:34:13 Modified files: . : octeon.html Log message: Release has passed, remove old note about -current.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/06/02 07:56:28 Modified files: sys/kern : init_main.c kern_event.c sys/sys: event.h Log message: Enable pool cache on knote pool Use the pool cache to reduce the overhead of memory management in function kqueue_register(). When EV_ADD is given, kqueue_register() pre-allocates a knote to avoid potential sleeping in the middle of the critical section that spans from knote lookup to insertion. However, the pre-allocation is useless if the lookup finds a matching knote. The cost of knote allocation will become significant with kqueue-based poll(2) and select(2) because the frequency of allocation will increase. Most of the cost appears to come from the locking inside the pool. The pool cache amortizes it by using CPU-local caches of free knotes as buffers. OK dlg@ mpi@
Re: Enable pool cache on knote_pool
On Tue, Jun 01, 2021 at 08:23:24AM +1000, David Gwynne wrote:
>
> > On 1 Jun 2021, at 02:58, Visa Hankala wrote:
> >
> > This patch enables the pool cache feature on the knote pool to reduce
> > the overhead of knote management.
> >
> > Profiling done by mpi@ and bluhm@ indicate that the potentially needless
> > allocation of knotes in kqueue_register() causes slowdown with
> > kqueue-based poll(2) and select(2).
> >
> > One approach to fix this is to reverse the function's initial guess
> > about knote: Try without allocation first. Then allocate and retry if
> > the knote is missing from the kqueue and EV_ADD is given.
> >
> > Another option is to cache free knotes so that the shared knote pool
> > would be accessed less frequently.
> >
> > The following diff takes the second approach. The caching is implemented
> > simply by enabling the pool cache feature. This makes use of existing
> > code and does not complicate kqueue_register(). The feature also helps
> > if there is heavy knote churn.
> >
> > I think the most substantial part of the diff is that it extends pool
> > cache usage beyond mbufs. Is this change acceptable?
>
> absolutely.
>
> > Note the cache is not particularly useful without kqueue-based poll(2)
> > and select(2). The pool view of systat(1) shows that there are pools
> > that would benefit more than knote_pool from caching, at least in terms
> > of request frequencies. The relative frequencies are dependent on system
> > workload, though. Kqpoll would definitely make knote pool more heavily
> > used.
>
> ok.
>
> separate to this diff, at some point maybe we should have a task list/dohook
> thing for "per cpu init" like mountroot or startup?
At first I fumbled with a deferring version of pool_cache_init() but the
idea felt overly specific. However, a more general dohook might indeed
make sense.
It is a bit unfortunate that the deferring is needed at all, though.
The number of different boot-time deferral options gets larger as well.
The diff below omits a manual page.
Index: kern/init_main.c
===
RCS file: src/sys/kern/init_main.c,v
retrieving revision 1.306
diff -u -p -r1.306 init_main.c
--- kern/init_main.c8 Feb 2021 10:51:01 - 1.306
+++ kern/init_main.c1 Jun 2021 15:29:05 -
@@ -432,6 +432,9 @@ main(void *framep)
prof_init();
#endif
+ /* Run hooks that require the presence of all CPUs. */
+ dopercpuhooks();
+
mbcpuinit();/* enable per cpu mbuf data */
uvm_init_percpu();
Index: kern/kern_subr.c
===
RCS file: src/sys/kern/kern_subr.c,v
retrieving revision 1.50
diff -u -p -r1.50 kern_subr.c
--- kern/kern_subr.c29 Apr 2018 17:26:31 - 1.50
+++ kern/kern_subr.c1 Jun 2021 15:29:05 -
@@ -198,6 +198,8 @@ hashfree(void *hash, int elements, int t
* "startup hook" types, functions, and variables.
*/
+struct hook_desc_head percpuhook_list =
+TAILQ_HEAD_INITIALIZER(percpuhook_list);
struct hook_desc_head startuphook_list =
TAILQ_HEAD_INITIALIZER(startuphook_list);
Index: sys/systm.h
===
RCS file: src/sys/sys/systm.h,v
retrieving revision 1.153
diff -u -p -r1.153 systm.h
--- sys/systm.h 28 Apr 2021 09:42:04 - 1.153
+++ sys/systm.h 1 Jun 2021 15:29:05 -
@@ -283,6 +283,9 @@ voidwdog_register(int (*)(void *, int),
void wdog_shutdown(void *);
/*
+ * Per-CPU hooks are functions that are run after all CPUs have been detected
+ * but before the scheduler has started.
+ *
* Startup hooks are functions running after the scheduler has started
* but before any threads have been created or root has been mounted.
*/
@@ -294,6 +297,7 @@ struct hook_desc {
};
TAILQ_HEAD(hook_desc_head, hook_desc);
+extern struct hook_desc_head percpuhook_list;
extern struct hook_desc_head startuphook_list;
void *hook_establish(struct hook_desc_head *, int, void (*)(void *), void *);
@@ -303,6 +307,12 @@ void dohooks(struct hook_desc_head *, in
#define HOOK_REMOVE0x01
#define HOOK_FREE 0x02
+#define percpuhook_establish(fn, arg) \
+ hook_establish(_list, 1, (fn), (arg))
+#define percpuhook_disestablish(vhook) \
+ hook_disestablish(_list, (vhook))
+#define dopercpuhooks() dohooks(_list, HOOK_REMOVE|HOOK_FREE)
+
#define startuphook_establish(fn, arg) \
hook_establish(_list, 1, (fn), (arg))
#define startuphook_disestablish(vhook) \
Enable pool cache on knote_pool
This patch enables the pool cache feature on the knote pool to reduce
the overhead of knote management.
Profiling done by mpi@ and bluhm@ indicate that the potentially needless
allocation of knotes in kqueue_register() causes slowdown with
kqueue-based poll(2) and select(2).
One approach to fix this is to reverse the function's initial guess
about knote: Try without allocation first. Then allocate and retry if
the knote is missing from the kqueue and EV_ADD is given.
Another option is to cache free knotes so that the shared knote pool
would be accessed less frequently.
The following diff takes the second approach. The caching is implemented
simply by enabling the pool cache feature. This makes use of existing
code and does not complicate kqueue_register(). The feature also helps
if there is heavy knote churn.
I think the most substantial part of the diff is that it extends pool
cache usage beyond mbufs. Is this change acceptable?
Note the cache is not particularly useful without kqueue-based poll(2)
and select(2). The pool view of systat(1) shows that there are pools
that would benefit more than knote_pool from caching, at least in terms
of request frequencies. The relative frequencies are dependent on system
workload, though. Kqpoll would definitely make knote pool more heavily
used.
Index: kern/init_main.c
===
RCS file: src/sys/kern/init_main.c,v
retrieving revision 1.306
diff -u -p -r1.306 init_main.c
--- kern/init_main.c8 Feb 2021 10:51:01 - 1.306
+++ kern/init_main.c31 May 2021 16:50:17 -
@@ -71,6 +71,7 @@
#include
#endif
#include
+#include
#include
#include
#include
@@ -148,7 +149,6 @@ voidcrypto_init(void);
void db_ctf_init(void);
void prof_init(void);
void init_exec(void);
-void kqueue_init(void);
void futex_init(void);
void taskq_init(void);
void timeout_proc_init(void);
@@ -432,7 +432,9 @@ main(void *framep)
prof_init();
#endif
- mbcpuinit();/* enable per cpu mbuf data */
+ /* Enable per-CPU data. */
+ mbcpuinit();
+ kqueue_init_percpu();
uvm_init_percpu();
/* init exec and emul */
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.163
diff -u -p -r1.163 kern_event.c
--- kern/kern_event.c 22 Apr 2021 15:30:12 - 1.163
+++ kern/kern_event.c 31 May 2021 16:50:17 -
@@ -231,6 +231,12 @@ kqueue_init(void)
PR_WAITOK, "knotepl", NULL);
}
+void
+kqueue_init_percpu(void)
+{
+ pool_cache_init(_pool);
+}
+
int
filt_fileattach(struct knote *kn)
{
Index: sys/event.h
===
RCS file: src/sys/sys/event.h,v
retrieving revision 1.54
diff -u -p -r1.54 event.h
--- sys/event.h 24 Feb 2021 14:59:52 - 1.54
+++ sys/event.h 31 May 2021 16:50:18 -
@@ -292,6 +292,8 @@ extern void knote_fdclose(struct proc *p
extern voidknote_processexit(struct proc *);
extern voidknote_modify(const struct kevent *, struct knote *);
extern voidknote_submit(struct knote *, struct kevent *);
+extern voidkqueue_init(void);
+extern voidkqueue_init_percpu(void);
extern int kqueue_register(struct kqueue *kq,
struct kevent *kev, struct proc *p);
extern int kqueue_scan(struct kqueue_scan_state *, int, struct kevent *,
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/31 06:45:33 Modified files: sys/kern : kern_time.c Log message: Redefine ADJFREQ_MIN to avoid undefined behaviour (when not using -fwrapv) Change the definition of ADJFREQ_MIN so that it does not shift a negative value. Such shifting is undefined in standard C. This came up when cross-compiling the kernel using ports clang. The shifting becomes defined when compiling with option -fwrapv. Base clang enables this option by default. OK naddy@ cheloha@
Avoid shifting of a negative value in sys_adjfreq()
When cross-compiling the kernel using ports clang (tsk tsk), the compiler reports the following: src/sys/kern/kern_time.c:418:11: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] if (f < ADJFREQ_MIN || f > ADJFREQ_MAX) ^ src/sys/kern/kern_time.c:399:35: note: expanded from macro 'ADJFREQ_MIN' #define ADJFREQ_MIN (-5LL << 32) ^ Normally this does not occur because of the implicit -fwrapv option with base clang. However, wouldn't it be better if the code avoided the situation, for example by defining ADJFREQ_MIN as the negative of ADJFREQ_MAX? Index: kern/kern_time.c === RCS file: src/sys/kern/kern_time.c,v retrieving revision 1.151 diff -u -p -r1.151 kern_time.c --- kern/kern_time.c23 Dec 2020 20:45:02 - 1.151 +++ kern/kern_time.c30 May 2021 15:38:09 - @@ -396,7 +396,7 @@ sys_settimeofday(struct proc *p, void *v } #define ADJFREQ_MAX (5LL << 32) -#define ADJFREQ_MIN (-5LL << 32) +#define ADJFREQ_MIN (-ADJFREQ_MAX) int sys_adjfreq(struct proc *p, void *v, register_t *retval)
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/30 09:08:08 Modified files: sys/arch/powerpc/include: pmap.h sys/arch/powerpc64/include: pmap.h Log message: Include and earlier in powerpc* pmap.h to avoid hidden header dependencies. OK jsg@ deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/30 09:06:53 Modified files: sys/arch/powerpc64/include: intr.h Log message: Include to avoid a hidden header dependency. OK jsg@ deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/30 09:05:33 Modified files: sys/arch/amd64/amd64: db_interface.c sys/arch/arm64/arm64: db_interface.c sys/arch/arm64/dev: apldart.c sys/arch/mips64/mips64: db_machdep.c sys/arch/powerpc/ddb: db_interface.c sys/arch/powerpc64/powerpc64: db_interface.c sys/arch/sparc64/sparc64: db_interface.c sys/dev/fdt: bcm2835_mbox.c sys/dev/ic : ahcivar.h Log message: Include to avoid a hidden header dependency. OK jsg@ deraadt@
Fix and includes on powerpc*
powerpc and powerpc64's include too late
and accidentally rely on other code to pull in the header. If the mutex
header is removed from the , the build fails:
In file included from src/sys/dev/rnd.c:84:
In file included from src/sys/uvm/uvm_extern.h:180:
In file included from src/sys/uvm/uvm_pmap.h:86:
src/sys/arch/powerpc64/compile/GENERIC/obj/machine/pmap.h:38:16: error: field
has incomplete type 'struct mutex'
struct mutexpm_mtx;
^
The following diff fixes the above. Also, it adds in
powerpc's pmap.h for consistency with powerpc64 (struct vm_page_md uses
LIST_HEAD() after all). powerpc64's appears to have
a hidden dependency on .
OK?
Index: arch/powerpc/include/pmap.h
===
RCS file: src/sys/arch/powerpc/include/pmap.h,v
retrieving revision 1.59
diff -u -p -r1.59 pmap.h
--- arch/powerpc/include/pmap.h 8 Oct 2015 10:20:14 - 1.59
+++ arch/powerpc/include/pmap.h 30 May 2021 04:28:46 -
@@ -77,6 +77,9 @@ typedef u_int sr_t;
#define PMAP_CACHE_WT 2 /* writethru */
#define PMAP_CACHE_WB 3 /* writeback */
+#include
+#include
+
#ifdef _KERNEL
/*
@@ -164,8 +167,6 @@ int reserve_dumppages(caddr_t p);
#endif /* _KERNEL */
-#include
-
struct vm_page_md {
struct mutex pv_mtx;
LIST_HEAD(,pte_desc) pv_list;
Index: arch/powerpc64/include/intr.h
===
RCS file: src/sys/arch/powerpc64/include/intr.h,v
retrieving revision 1.13
diff -u -p -r1.13 intr.h
--- arch/powerpc64/include/intr.h 24 Oct 2020 21:42:10 - 1.13
+++ arch/powerpc64/include/intr.h 30 May 2021 04:28:46 -
@@ -19,6 +19,8 @@
#ifndef _MACHINE_INTR_H_
#define _MACHINE_INTR_H_
+#include
+
struct cpu_info;
struct trapframe;
Index: arch/powerpc64/include/pmap.h
===
RCS file: src/sys/arch/powerpc64/include/pmap.h,v
retrieving revision 1.16
diff -u -p -r1.16 pmap.h
--- arch/powerpc64/include/pmap.h 11 May 2021 18:21:12 - 1.16
+++ arch/powerpc64/include/pmap.h 30 May 2021 04:28:46 -
@@ -19,6 +19,9 @@
#ifndef _MACHINE_PMAP_H_
#define _MACHINE_PMAP_H_
+#include
+#include
+
#ifdef _KERNEL
#include
@@ -80,9 +83,6 @@ struct pte *pmap_get_kernel_pte(vaddr_t)
#endif /* _KERNEL */
-#include
-#include
-
struct vm_page_md {
struct mutex pv_mtx;
LIST_HEAD(,pte_desc) pv_list;
Add missing includes
The kernel has places where mutexes are used but is not included directly. Some of them get exposed when #include is removed from soft interrupt headers. The following diff fixes them. OK? Index: arch/amd64/amd64/db_interface.c === RCS file: src/sys/arch/amd64/amd64/db_interface.c,v retrieving revision 1.35 diff -u -p -r1.35 db_interface.c --- arch/amd64/amd64/db_interface.c 6 Nov 2019 07:34:35 - 1.35 +++ arch/amd64/amd64/db_interface.c 30 May 2021 04:28:45 - @@ -36,6 +36,7 @@ #include #include #include +#include #include Index: arch/arm64/arm64/db_interface.c === RCS file: src/sys/arch/arm64/arm64/db_interface.c,v retrieving revision 1.9 diff -u -p -r1.9 db_interface.c --- arch/arm64/arm64/db_interface.c 11 Mar 2021 11:16:55 - 1.9 +++ arch/arm64/arm64/db_interface.c 30 May 2021 04:28:45 - @@ -39,6 +39,7 @@ #include #include /* just for boothowto */ #include +#include #include Index: arch/arm64/dev/apldart.c === RCS file: src/sys/arch/arm64/dev/apldart.c,v retrieving revision 1.3 diff -u -p -r1.3 apldart.c --- arch/arm64/dev/apldart.c24 May 2021 18:38:29 - 1.3 +++ arch/arm64/dev/apldart.c30 May 2021 04:28:45 - @@ -20,6 +20,7 @@ #include #include #include +#include #include #include Index: arch/mips64/mips64/db_machdep.c === RCS file: src/sys/arch/mips64/mips64/db_machdep.c,v retrieving revision 1.56 diff -u -p -r1.56 db_machdep.c --- arch/mips64/mips64/db_machdep.c 1 May 2021 16:11:11 - 1.56 +++ arch/mips64/mips64/db_machdep.c 30 May 2021 04:28:46 - @@ -28,6 +28,7 @@ #include #include +#include #include #include Index: arch/powerpc/ddb/db_interface.c === RCS file: src/sys/arch/powerpc/ddb/db_interface.c,v retrieving revision 1.6 diff -u -p -r1.6 db_interface.c --- arch/powerpc/ddb/db_interface.c 7 Nov 2019 15:58:39 - 1.6 +++ arch/powerpc/ddb/db_interface.c 30 May 2021 04:28:46 - @@ -32,6 +32,7 @@ #include #include #include +#include #include Index: arch/powerpc64/powerpc64/db_interface.c === RCS file: src/sys/arch/powerpc64/powerpc64/db_interface.c,v retrieving revision 1.3 diff -u -p -r1.3 db_interface.c --- arch/powerpc64/powerpc64/db_interface.c 22 Jul 2020 20:41:26 - 1.3 +++ arch/powerpc64/powerpc64/db_interface.c 30 May 2021 04:28:46 - @@ -31,6 +31,7 @@ #include #include +#include #include #include Index: arch/sparc64/sparc64/db_interface.c === RCS file: src/sys/arch/sparc64/sparc64/db_interface.c,v retrieving revision 1.55 diff -u -p -r1.55 db_interface.c --- arch/sparc64/sparc64/db_interface.c 30 Jan 2020 08:51:27 - 1.55 +++ arch/sparc64/sparc64/db_interface.c 30 May 2021 04:28:46 - @@ -35,6 +35,7 @@ #include #include #include +#include #include Index: dev/fdt/bcm2835_mbox.c === RCS file: src/sys/dev/fdt/bcm2835_mbox.c,v retrieving revision 1.1 diff -u -p -r1.1 bcm2835_mbox.c --- dev/fdt/bcm2835_mbox.c 19 Apr 2020 14:51:52 - 1.1 +++ dev/fdt/bcm2835_mbox.c 30 May 2021 04:28:46 - @@ -48,6 +48,7 @@ #include #include +#include #include #include Index: dev/ic/ahcivar.h === RCS file: src/sys/dev/ic/ahcivar.h,v retrieving revision 1.10 diff -u -p -r1.10 ahcivar.h --- dev/ic/ahcivar.h21 Aug 2017 21:43:46 - 1.10 +++ dev/ic/ahcivar.h30 May 2021 04:28:46 - @@ -18,6 +18,7 @@ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ +#include #include #include #include
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/28 10:33:36 Modified files: sys/arch/mips64/include: cpu.h sys/arch/mips64/mips64: cpu.c Log message: Remove CPU and node id fields that were used with SGI Origin.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/28 10:24:53 Modified files: sys/kern : uipc_socket.c uipc_syscalls.c Log message: Add f_modify and f_process callbacks to socket filterops. This makes kqueue use the extended callback interface with socket event filters. Now one level of nested kernel locking is avoided, and the callbacks run without splhigh(). The filterops no longer check NOTE_SUBMIT, and use a fixed locking pattern instead. The f_event routines are always called with solock(), whereas f_modify and f_process are always called without the lock. OK mpi@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/28 09:52:11 Modified files: share/man/man4 : Makefile sys/arch/armv7/conf: GENERIC RAMDISK sys/dev/fdt: files.fdt Added files: share/man/man4 : cad.4 sys/dev/fdt: if_cad.c Log message: Add cad(4), a driver for Cadence GEM. This initial revision targets the Zynq-7000, where the GEM implements single transmit and receive queues with 32-bit DMA addresses. The driver uses receive checksum offload, but transmit checksum offload is disabled because of a hardware quirk. Also, the hardware's receive path is prone to getting stuck if input cannot be handled quickly enough. The driver attempts to recover by restarting the receiver when no input has been seen for a while. OK kettenis@
Driver for Cadence GEM
Here is an initial driver for Cadence GEM. Revisions of this Ethernet controller are found on various SoCs, including Xilinx Zynq-7000 and Zynq UltraScale+, and SiFive's HiFive Unleashed and Unmatched. I have tested the driver on Zynq-7000. Unfortunately, Zynq-7000 has a bug in its transmit UDP checksum offload capability. It generates wrong checksum if UDP payload size is less than three octets and the checksum field has not been initialized to zero. As tweaking packets in the driver probably is not desired, transmit checksum offload is disabled. There is no way to disable offload with just UDP. On Zynq-7000, the hardware's Rx path is prone to getting stuck when DMA is not able to store incoming frames in memory quickly enough. As suggested by the technical reference manual, the driver toggles the receiver briefly if there is a pause in reception. The driver has been written with just fdt in mind. However, Linux code suggests that there are PCI versions of the hardware as well (but no ACPI, at least yet). Should I separate the glue layer, to allow new attachment types? Index: sys/dev/fdt/files.fdt === RCS file: src/sys/dev/fdt/files.fdt,v retrieving revision 1.151 diff -u -p -r1.151 files.fdt --- sys/dev/fdt/files.fdt 18 May 2021 11:39:37 - 1.151 +++ sys/dev/fdt/files.fdt 27 May 2021 16:15:08 - @@ -276,6 +276,10 @@ device amlusbphy attach amlusbphy at fdt file dev/fdt/amlusbphy.c amlusbphy +device cad: ether, ifnet, mii, ifmedia +attach cad at fdt +file dev/fdt/if_cad.ccad + device cduart attach cduart at fdt file dev/fdt/cduart.ccduart Index: sys/dev/fdt/if_cad.c === RCS file: sys/dev/fdt/if_cad.c diff -N sys/dev/fdt/if_cad.c --- /dev/null 1 Jan 1970 00:00:00 - +++ sys/dev/fdt/if_cad.c27 May 2021 16:15:08 - @@ -0,0 +1,1727 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2021 Visa Hankala + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* + * Driver for Cadence 10/100/Gigabit Ethernet device. + */ + +#include "bpfilter.h" +#include "kstat.h" + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#if NBPFILTER > 0 +#include +#endif + +#include +#include +#include + +#include +#include + +#include +#include +#include + +#define GEM_NETCTL 0x +#define GEM_NETCTL_DPRAM (1 << 18) +#define GEM_NETCTL_STARTTX(1 << 9) +#define GEM_NETCTL_STATCLR(1 << 5) +#define GEM_NETCTL_MDEN (1 << 4) +#define GEM_NETCTL_TXEN (1 << 3) +#define GEM_NETCTL_RXEN (1 << 2) +#define GEM_NETCFG 0x0004 +#define GEM_NETCFG_SGMIIEN(1 << 27) +#define GEM_NETCFG_RXCSUMEN (1 << 24) +#define GEM_NETCFG_MDCCLKDIV_MASK (0x7 << 18) +#define GEM_NETCFG_MDCCLKDIV_SHIFT18 +#define GEM_NETCFG_FCSREM (1 << 17) +#define GEM_NETCFG_RXOFFS_MASK(0x3 << 14) +#define GEM_NETCFG_RXOFFS_SHIFT 14 +#define GEM_NETCFG_PCSSEL (1 << 11) +#define GEM_NETCFG_1000 (1 << 10) +#define GEM_NETCFG_1536RXEN (1 << 8) +#define GEM_NETCFG_UCASTHASHEN(1 << 7) +#define GEM_NETCFG_MCASTHASHEN(1 << 6) +#define GEM_NETCFG_BCASTDI(1 << 5) +#define GEM_NETCFG_COPYALL(1 << 4) +#define GEM_NETCFG_FDEN (1 << 1) +#define GEM_NETCFG_100(1 << 0) +#define GEM_NETSR 0x0008 +#define GEM_NETSR_PHY_MGMT_IDLE (1 << 2) +#define GEM_DMACR 0x0010 +#define GEM_DMACR_AHBDISC (1 << 24) +#define GEM
Re: amd64: softintr_dispatch: remove kernel lock
On Sat, May 22, 2021 at 02:23:57PM +, Visa Hankala wrote: > On Sat, May 22, 2021 at 02:33:47PM +0200, Mark Kettenis wrote: > > > Date: Sat, 22 May 2021 11:11:38 + > > > From: Visa Hankala > > > > > > On Wed, May 19, 2021 at 05:11:09PM -0500, Scott Cheloha wrote: > > > > Hi, > > > > > > > > visa@ says I need to unlock softintr_dispatch() before I can > > > > unlock softclock(), so let's do that. > > > > > > > > Additionally, when we call softintr_disestablish() we want to wait for > > > > the underlying softintr handle to finish running if it is running. > > > > > > > > We can start with amd64. > > > > > > > > I think this approach will work: > > > > > > > > - Keep a pointer to the running softintr, if any, in the queue. NULL > > > > the pointer when we return from sih_func(). > > > > > > > > - Take/release the kernel lock if the SI_MPSAFE flag is present when > > > > we enter/leave sih_func(). > > > > > > > > - If the handle is running when you call softintr_disestablish(), spin > > > > until the handle isn't running anymore and retry. > > > > > > > > There is no softintr manpage but I think it is understood that > > > > softintr_disestablish() is only safe to call from a process context, > > > > otherwise you may deadlock. Maybe we should do splassert(IPL_NONE)? > > > > > > > > We could probably sleep here instead of spinning. We'd have to change > > > > every softintr_disestablish() implementation to do that, though. > > > > Otherwise you'd have different behavior on different platforms. > > > > > > I think your diff does not pay enough attention to the fact that soft > > > interrupts are handled by all CPUs. I think the diff that I posted > > > a while ago [1] is better in that respect. > > > > > > Two biggest things that I do not like in my original diff are > > > synchronization of handler execution, and use of the SMR barrier. > > > > > > [1] https://marc.info/?l=openbsd-tech=162092714911609 > > > > > > The kernel lock has guaranteed that at most one CPU is able to run > > > a given soft interrupt handler at a time. My diff used a mutex to > > > prevent concurrent execution. However, it is wasteful to spin. It would > > > be more economical to let the current runner of the handler re-execute > > > the code. > > > > > > The SMR barrier in softintr_disestablish() was a trick to drain any > > > pending activity. However, it made me feel uneasy because I have not > > > checked every caller of softintr_disestablish(). My main worry is not > > > the latency but unexpected side effects. > > > > > > Below is a revised diff that improves the above two points. > > > > > > When a soft interrupt handler is scheduled, it is assigned to a CPU. > > > That CPU will keep running the handler as long as there are pending > > > requests. Once all pending requests have been drained, the CPU > > > relinquishes its hold of the handler. This provides natural > > > serialization. > > > > > > Now softintr_disestablish() uses spinning for draining activity. > > > I still have slight qualms about this, though, because the feature > > > has not been so explicit before. Integration with witness(4) might be > > > in order. > > > > > > softintr_disestablish() uses READ_ONCE() to enforce reloading of the > > > value in the busy-wait loop. This way the variable does not need to be > > > volatile. (As yet another option, CPU_BUSY_CYCLE() could always > > > imply memory clobbering, which should make an optimizing compiler > > > redo the load.) For consistency with this READ_ONCE(), WRITE_ONCE() is > > > used whenever the variable is written, excluding the initialization. > > > > > > The patch uses a single mutex for access serialization. The old code > > > has used one mutex per each soft IPL level, but I am not sure how > > > useful that has been. I think it would be better to have a separate > > > mutex for each CPU. However, the increased code complexity might not > > > be worthwhile at the moment. Even having the per-CPU queues has > > > a whiff of being somewhat overkill. > > > > A few comments: > > > > * Looking at amd64 in isolation does not make sense. Like a lot of MD > &g
Re: amd64: softintr_dispatch: remove kernel lock
On Sat, May 22, 2021 at 02:33:47PM +0200, Mark Kettenis wrote: > > Date: Sat, 22 May 2021 11:11:38 + > > From: Visa Hankala > > > > On Wed, May 19, 2021 at 05:11:09PM -0500, Scott Cheloha wrote: > > > Hi, > > > > > > visa@ says I need to unlock softintr_dispatch() before I can > > > unlock softclock(), so let's do that. > > > > > > Additionally, when we call softintr_disestablish() we want to wait for > > > the underlying softintr handle to finish running if it is running. > > > > > > We can start with amd64. > > > > > > I think this approach will work: > > > > > > - Keep a pointer to the running softintr, if any, in the queue. NULL > > > the pointer when we return from sih_func(). > > > > > > - Take/release the kernel lock if the SI_MPSAFE flag is present when > > > we enter/leave sih_func(). > > > > > > - If the handle is running when you call softintr_disestablish(), spin > > > until the handle isn't running anymore and retry. > > > > > > There is no softintr manpage but I think it is understood that > > > softintr_disestablish() is only safe to call from a process context, > > > otherwise you may deadlock. Maybe we should do splassert(IPL_NONE)? > > > > > > We could probably sleep here instead of spinning. We'd have to change > > > every softintr_disestablish() implementation to do that, though. > > > Otherwise you'd have different behavior on different platforms. > > > > I think your diff does not pay enough attention to the fact that soft > > interrupts are handled by all CPUs. I think the diff that I posted > > a while ago [1] is better in that respect. > > > > Two biggest things that I do not like in my original diff are > > synchronization of handler execution, and use of the SMR barrier. > > > > [1] https://marc.info/?l=openbsd-tech=162092714911609 > > > > The kernel lock has guaranteed that at most one CPU is able to run > > a given soft interrupt handler at a time. My diff used a mutex to > > prevent concurrent execution. However, it is wasteful to spin. It would > > be more economical to let the current runner of the handler re-execute > > the code. > > > > The SMR barrier in softintr_disestablish() was a trick to drain any > > pending activity. However, it made me feel uneasy because I have not > > checked every caller of softintr_disestablish(). My main worry is not > > the latency but unexpected side effects. > > > > Below is a revised diff that improves the above two points. > > > > When a soft interrupt handler is scheduled, it is assigned to a CPU. > > That CPU will keep running the handler as long as there are pending > > requests. Once all pending requests have been drained, the CPU > > relinquishes its hold of the handler. This provides natural > > serialization. > > > > Now softintr_disestablish() uses spinning for draining activity. > > I still have slight qualms about this, though, because the feature > > has not been so explicit before. Integration with witness(4) might be > > in order. > > > > softintr_disestablish() uses READ_ONCE() to enforce reloading of the > > value in the busy-wait loop. This way the variable does not need to be > > volatile. (As yet another option, CPU_BUSY_CYCLE() could always > > imply memory clobbering, which should make an optimizing compiler > > redo the load.) For consistency with this READ_ONCE(), WRITE_ONCE() is > > used whenever the variable is written, excluding the initialization. > > > > The patch uses a single mutex for access serialization. The old code > > has used one mutex per each soft IPL level, but I am not sure how > > useful that has been. I think it would be better to have a separate > > mutex for each CPU. However, the increased code complexity might not > > be worthwhile at the moment. Even having the per-CPU queues has > > a whiff of being somewhat overkill. > > A few comments: > > * Looking at amd64 in isolation does not make sense. Like a lot of MD > code in OpenBSD the softintr code was copied from whatever > Net/FreeBSD had at the time, with no attempt at unification (it > works, check it in, don't go back to clean it up). However, with > powerpc64 and riscv64 we try to do things a little bit better in > that area. So arm64, powerpc64 and riscv64 share the same softintr > implementation that already implements softintr_establish_flags() > with SOFTINTR_ESTABLISH_MPSAFE. Now we haven't used t
Re: amd64: softintr_dispatch: remove kernel lock
On Wed, May 19, 2021 at 05:11:09PM -0500, Scott Cheloha wrote:
> Hi,
>
> visa@ says I need to unlock softintr_dispatch() before I can
> unlock softclock(), so let's do that.
>
> Additionally, when we call softintr_disestablish() we want to wait for
> the underlying softintr handle to finish running if it is running.
>
> We can start with amd64.
>
> I think this approach will work:
>
> - Keep a pointer to the running softintr, if any, in the queue. NULL
> the pointer when we return from sih_func().
>
> - Take/release the kernel lock if the SI_MPSAFE flag is present when
> we enter/leave sih_func().
>
> - If the handle is running when you call softintr_disestablish(), spin
> until the handle isn't running anymore and retry.
>
> There is no softintr manpage but I think it is understood that
> softintr_disestablish() is only safe to call from a process context,
> otherwise you may deadlock. Maybe we should do splassert(IPL_NONE)?
>
> We could probably sleep here instead of spinning. We'd have to change
> every softintr_disestablish() implementation to do that, though.
> Otherwise you'd have different behavior on different platforms.
I think your diff does not pay enough attention to the fact that soft
interrupts are handled by all CPUs. I think the diff that I posted
a while ago [1] is better in that respect.
Two biggest things that I do not like in my original diff are
synchronization of handler execution, and use of the SMR barrier.
[1] https://marc.info/?l=openbsd-tech=162092714911609
The kernel lock has guaranteed that at most one CPU is able to run
a given soft interrupt handler at a time. My diff used a mutex to
prevent concurrent execution. However, it is wasteful to spin. It would
be more economical to let the current runner of the handler re-execute
the code.
The SMR barrier in softintr_disestablish() was a trick to drain any
pending activity. However, it made me feel uneasy because I have not
checked every caller of softintr_disestablish(). My main worry is not
the latency but unexpected side effects.
Below is a revised diff that improves the above two points.
When a soft interrupt handler is scheduled, it is assigned to a CPU.
That CPU will keep running the handler as long as there are pending
requests. Once all pending requests have been drained, the CPU
relinquishes its hold of the handler. This provides natural
serialization.
Now softintr_disestablish() uses spinning for draining activity.
I still have slight qualms about this, though, because the feature
has not been so explicit before. Integration with witness(4) might be
in order.
softintr_disestablish() uses READ_ONCE() to enforce reloading of the
value in the busy-wait loop. This way the variable does not need to be
volatile. (As yet another option, CPU_BUSY_CYCLE() could always
imply memory clobbering, which should make an optimizing compiler
redo the load.) For consistency with this READ_ONCE(), WRITE_ONCE() is
used whenever the variable is written, excluding the initialization.
The patch uses a single mutex for access serialization. The old code
has used one mutex per each soft IPL level, but I am not sure how
useful that has been. I think it would be better to have a separate
mutex for each CPU. However, the increased code complexity might not
be worthwhile at the moment. Even having the per-CPU queues has
a whiff of being somewhat overkill.
Index: arch/amd64/amd64/softintr.c
===
RCS file: src/sys/arch/amd64/amd64/softintr.c,v
retrieving revision 1.10
diff -u -p -r1.10 softintr.c
--- arch/amd64/amd64/softintr.c 11 Sep 2020 09:27:09 - 1.10
+++ arch/amd64/amd64/softintr.c 22 May 2021 11:07:23 -
@@ -36,13 +36,37 @@
#include
#include
+#include
#include
+#include
+#include
+#include
#include
#include
-struct x86_soft_intr x86_soft_intrs[X86_NSOFTINTR];
+struct x86_soft_intr_percpu;
+
+struct x86_soft_intrhand {
+ TAILQ_ENTRY(x86_soft_intrhand) sih_q;
+ void(*sih_fn)(void *);
+ void*sih_arg;
+ struct x86_soft_intr_percpu *sih_owner;
+ int sih_which;
+ unsigned short sih_flags;
+ unsigned short sih_pending;
+};
+
+#define SIF_DYING 0x0001
+#define SIF_MPSAFE 0x0002
+
+struct x86_soft_intr_percpu {
+ TAILQ_HEAD(, x86_soft_intrhand) sip_queue[X86_NSOFTINTR];
+} __aligned(CACHELINESIZE);
+
+struct x86_soft_intr_percpu x86_soft_intr_percpu[MAXCPUS];
+struct mutex softintr_lock = MUTEX_INITIALIZER(IPL_HIGH);
const int x86_soft_intr_to_ssir[X86_NSOFTINTR] = {
SIR_CLOCK,
@@ -58,14 +82,13 @@ const int x86_soft_intr_to_ssir[X86_NSOF
void
softintr_init(void)
{
- struct x86_soft_intr *si;
- int i;
+ struct x86
[Pkg-tcltk-devel] Instalarse en TEXAS - oportunidad de negocio
Texas, el estado ideal para hacer negocios y GANAR EN DOLARES CÓMO HACER NEGOCIOS EN TEXAS 30 y 31 de JULIO - ONLINE EN VIVO Evento Presencial de Alto Impacto Texas se mantiene como uno de los tres primeros lugares ideales para hacer negocios en Estados Unidos. De acuerdo con la revista Forbes, la mayor migración de la Unión Americana se presenta en ciudades como Dallas, Houston y Austin. Según datos del Federal Reserve Bank de Dallas, casi el 15% de la economía del estado está relacionada con exportaciones. DESEO OBTENER EL TEMARIO AQUÍ Me permite enviarle el PDF informativo para que lo puedan evaluar las personas directamente interesadas dentro de su empresa? Sólo responda este mismo correo con el asunto "TEMARIO-TEXAS-2021" con sus datos de contacto. * Teléfono: * Nombre: * WhatsApp: Correo dirigido a: pkg-tcltk-de...@lists.alioth.debian.org Para dejar de recibir nuestras promociones, reenvíe este correo con el asunto "EXCLUIR". Este proceso podría tomar hasta 48 horas en tomar efecto. Copyright © 2021 QTC., All rights reserved ___ Pkg-tcltk-devel mailing list Pkg-tcltk-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tcltk-devel
Instalarse en TEXAS - oportunidad de negocio
Texas, el estado ideal para hacer negocios y GANAR EN DOLARES CÓMO HACER NEGOCIOS EN TEXAS 30 y 31 de JULIO - ONLINE EN VIVO Evento Presencial de Alto Impacto Texas se mantiene como uno de los tres primeros lugares ideales para hacer negocios en Estados Unidos. De acuerdo con la revista Forbes, la mayor migración de la Unión Americana se presenta en ciudades como Dallas, Houston y Austin. Según datos del Federal Reserve Bank de Dallas, casi el 15% de la economía del estado está relacionada con exportaciones. DESEO OBTENER EL TEMARIO AQUÍ Me permite enviarle el PDF informativo para que lo puedan evaluar las personas directamente interesadas dentro de su empresa? Sólo responda este mismo correo con el asunto "TEMARIO-TEXAS-2021" con sus datos de contacto. * Teléfono: * Nombre: * WhatsApp: Correo dirigido a: pkg-pulseaudio-de...@lists.alioth.debian.org Para dejar de recibir nuestras promociones, reenvíe este correo con el asunto "EXCLUIR". Este proceso podría tomar hasta 48 horas en tomar efecto. Copyright © 2021 QTC., All rights reserved ___ pkg-pulseaudio-devel mailing list pkg-pulseaudio-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pulseaudio-devel
Re: Add f_modify and f_process callbacks to socket filterops
On Thu, May 20, 2021 at 11:35:32AM +0200, Martin Pieuchot wrote:
> On 18/05/21(Tue) 14:22, Visa Hankala wrote:
> > This diff adds f_modify and f_process callbacks to socket event filters.
> > As a result, socket events are handled using the non-legacy paths in
> > filter_modify() and filter_process() of kern_event.c This a step toward
> > MP-safety. However, everything still runs under the kernel lock.
> >
> > The change has three intended effects:
> >
> > * Socket events are handled without raising the system priority level.
> > This makes the activity observable with btrace(8).
> >
> > * kqueue itself no longer calls f_event of socket filterops, which
> > allows replacing the conditional, NOTE_SUBMIT-based locking with
> > a fixed call pattern.
>
> I love this.
>
> > * The state of a socket event is now always rechecked before delivery
> > to user. Before, the recheck was skipped if the event was registered
> > with EV_ONESHOT.
>
> To me this sounds sane. I can't think of a way to rely on the current
> behavior. However if there's an easy way to split these changes in two
> commits, I'd prefer to stay on the safe side.
Below is an updated diff that preserves the current EV_ONESHOT
behaviour. I have just adapted a part of the compatibility logic
from function filter_process().
When f_process is given a non-NULL kev argument, it is known that
the callback is invoked from kqueue_scan(). If kev is NULL,
kqueue_register() is checking if the knote should be activated and
there is no intent to deliver the event right now.
Index: kern/uipc_socket.c
===
RCS file: src/sys/kern/uipc_socket.c,v
retrieving revision 1.261
diff -u -p -r1.261 uipc_socket.c
--- kern/uipc_socket.c 13 May 2021 19:43:11 - 1.261
+++ kern/uipc_socket.c 20 May 2021 14:01:18 -
@@ -70,15 +70,26 @@ voidsorflush(struct socket *);
void filt_sordetach(struct knote *kn);
intfilt_soread(struct knote *kn, long hint);
+intfilt_soreadmodify(struct kevent *kev, struct knote *kn);
+intfilt_soreadprocess(struct knote *kn, struct kevent *kev);
+intfilt_soread_common(struct knote *kn, struct socket *so);
void filt_sowdetach(struct knote *kn);
intfilt_sowrite(struct knote *kn, long hint);
+intfilt_sowritemodify(struct kevent *kev, struct knote *kn);
+intfilt_sowriteprocess(struct knote *kn, struct kevent *kev);
+intfilt_sowrite_common(struct knote *kn, struct socket *so);
intfilt_solisten(struct knote *kn, long hint);
+intfilt_solistenmodify(struct kevent *kev, struct knote *kn);
+intfilt_solistenprocess(struct knote *kn, struct kevent *kev);
+intfilt_solisten_common(struct knote *kn, struct socket *so);
const struct filterops solisten_filtops = {
.f_flags= FILTEROP_ISFD,
.f_attach = NULL,
.f_detach = filt_sordetach,
.f_event= filt_solisten,
+ .f_modify = filt_solistenmodify,
+ .f_process = filt_solistenprocess,
};
const struct filterops soread_filtops = {
@@ -86,6 +97,8 @@ const struct filterops soread_filtops =
.f_attach = NULL,
.f_detach = filt_sordetach,
.f_event= filt_soread,
+ .f_modify = filt_soreadmodify,
+ .f_process = filt_soreadprocess,
};
const struct filterops sowrite_filtops = {
@@ -93,6 +106,8 @@ const struct filterops sowrite_filtops =
.f_attach = NULL,
.f_detach = filt_sowdetach,
.f_event= filt_sowrite,
+ .f_modify = filt_sowritemodify,
+ .f_process = filt_sowriteprocess,
};
const struct filterops soexcept_filtops = {
@@ -100,6 +115,8 @@ const struct filterops soexcept_filtops
.f_attach = NULL,
.f_detach = filt_sordetach,
.f_event= filt_soread,
+ .f_modify = filt_soreadmodify,
+ .f_process = filt_soreadprocess,
};
#ifndef SOMINCONN
@@ -2056,13 +2073,12 @@ filt_sordetach(struct knote *kn)
}
int
-filt_soread(struct knote *kn, long hint)
+filt_soread_common(struct knote *kn, struct socket *so)
{
- struct socket *so = kn->kn_fp->f_data;
- int s, rv = 0;
+ int rv = 0;
+
+ soassertlocked(so);
- if ((hint & NOTE_SUBMIT) == 0)
- s = solock(so);
kn->kn_data = so->so_rcv.sb_cc;
#ifdef SOCKET_SPLICE
if (isspliced(so)) {
@@ -2090,12 +2106,50 @@ filt_soread(struct knote *kn, long hint)
} else {
rv = (kn->kn_data >= so->so_rcv.sb_lowat);
}
- if ((hint & NOTE_SUBMIT) == 0)
- sounlock(so, s);
return rv;
}
+int
+filt_soread(struct knote *kn, long hint)
+{
+ struct socket *so = kn->kn_fp->f_data;
+
+
Serialize kqueue's internals with a mutex
This patch adds a mutex that serializes access to a kqueue. As a result,
most of kqueue's internals should become safe to run without the kernel
lock. In principle, the patch should allow unlocking kevent(2).
Some notes:
* The existing uses of splhigh() outline where the mutex should be held.
* The code is a true entanglement of lock operations. There are many
spots where lock usage is far from optimal. The patch does not attempt
to fix them, so as to keep the changeset relatively small.
* As msleep() with PCATCH requires the kernel lock, kqueue_scan() locks
the kernel for the section that might sleep. The lock is released
before the actual scan of events. An opportunistic implementation
could do a precheck to determine if the scan could be started right
away, but this is not part of the diff.
* knote_acquire() has a gap where it might miss a wakeup. This is an
unlikely situation that may arise with klist_invalidate(). It should
not happen during normal operation, and the code should recover thanks
to the one-second timeout. The loss of wakeup could be avoided with
serial numbering for example.
* The timeout in knote_acquire() makes the function try-lock-like, which
is essential in klist_invalidate(). The normal sequence of action is
that knote_acquire() comes before klist_lock(). klist_invalidate() has
to violate this, and the timeout, and retrying, prevent the system
from deadlocking.
* At the moment, all event sources still require the kernel lock.
kqueue will lock the kernel when it invokes the filterops callbacks
if FILTEROP_MPSAFE is not set.
Please test!
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.163
diff -u -p -r1.163 kern_event.c
--- kern/kern_event.c 22 Apr 2021 15:30:12 - 1.163
+++ kern/kern_event.c 20 May 2021 13:45:32 -
@@ -124,7 +124,8 @@ voidknote_dequeue(struct knote *kn);
intknote_acquire(struct knote *kn, struct klist *, int);
void knote_release(struct knote *kn);
void knote_activate(struct knote *kn);
-void knote_remove(struct proc *p, struct knlist *list, int purge);
+void knote_remove(struct proc *p, struct kqueue *kq, struct knlist *list,
+ int purge);
void filt_kqdetach(struct knote *kn);
intfilt_kqueue(struct knote *kn, long hint);
@@ -265,7 +266,7 @@ filt_kqueue(struct knote *kn, long hint)
{
struct kqueue *kq = kn->kn_fp->f_data;
- kn->kn_data = kq->kq_count;
+ kn->kn_data = kq->kq_count; /* unlocked read */
return (kn->kn_data > 0);
}
@@ -739,28 +740,31 @@ kqpoll_dequeue(struct proc *p)
{
struct knote *kn;
struct kqueue *kq = p->p_kq;
- int s;
- s = splhigh();
+ mtx_enter(>kq_lock);
while ((kn = TAILQ_FIRST(>kq_head)) != NULL) {
/* This kqueue should not be scanned by other threads. */
KASSERT(kn->kn_filter != EVFILT_MARKER);
- if (!knote_acquire(kn, NULL, 0))
+ if (!knote_acquire(kn, NULL, 0)) {
+ /* knote_acquire() has released kq_lock. */
+ mtx_enter(>kq_lock);
continue;
+ }
kqueue_check(kq);
TAILQ_REMOVE(>kq_head, kn, kn_tqe);
kn->kn_status &= ~KN_QUEUED;
kq->kq_count--;
+ mtx_leave(>kq_lock);
- splx(s);
- kn->kn_fop->f_detach(kn);
+ filter_detach(kn);
knote_drop(kn, p);
- s = splhigh();
+
+ mtx_enter(>kq_lock);
kqueue_check(kq);
}
- splx(s);
+ mtx_leave(>kq_lock);
}
struct kqueue *
@@ -772,6 +776,7 @@ kqueue_alloc(struct filedesc *fdp)
kq->kq_refs = 1;
kq->kq_fdp = fdp;
TAILQ_INIT(>kq_head);
+ mtx_init(>kq_lock, IPL_HIGH);
task_set(>kq_task, kqueue_task, kq);
return (kq);
@@ -933,8 +938,7 @@ kqueue_do_check(struct kqueue *kq, const
struct knote *kn;
int count = 0, nmarker = 0;
- KERNEL_ASSERT_LOCKED();
- splassert(IPL_HIGH);
+ MUTEX_ASSERT_LOCKED(>kq_lock);
TAILQ_FOREACH(kn, >kq_head, kn_tqe) {
if (kn->kn_filter == EVFILT_MARKER) {
@@ -973,7 +977,7 @@ kqueue_register(struct kqueue *kq, struc
struct file *fp = NULL;
struct knote *kn = NULL, *newkn = NULL;
struct knlist *list = NULL;
- int s, error = 0;
+ int error = 0;
if (kev->filter < 0) {
if (kev->filter + EVFILT_SYSCOUNT < 0)
@@ -1005,11 +1009,13 @@ again:
error = EBADF;
goto done;
}
+ mtx_enter(>kq_lock);
if (kev->flags & EV_ADD)
kqueue_expand_list(kq, kev->ident);
if (kev->ident <
Add f_modify and f_process callbacks to socket filterops
This diff adds f_modify and f_process callbacks to socket event filters.
As a result, socket events are handled using the non-legacy paths in
filter_modify() and filter_process() of kern_event.c This a step toward
MP-safety. However, everything still runs under the kernel lock.
The change has three intended effects:
* Socket events are handled without raising the system priority level.
This makes the activity observable with btrace(8).
* kqueue itself no longer calls f_event of socket filterops, which
allows replacing the conditional, NOTE_SUBMIT-based locking with
a fixed call pattern.
* The state of a socket event is now always rechecked before delivery
to user. Before, the recheck was skipped if the event was registered
with EV_ONESHOT.
However, the change of behaviour with EV_ONESHOT is questionable.
When an activated event is being processed, the code will acquire the
socket lock anyway. Skipping the state check would only be a minor
optimization. In addition, I think the behaviour becomes more
consistent as now a delivered EV_ONESHOT event really was active at
the time of delivery.
Consider the following program. It creates a socket pair, writes a byte
to the socket, registers an EV_ONESHOT event, and reads the byte from
the socket. Next it checks how kevent(2) behaves.
#include
#include
#include
#include
#include
#include
#include
#include
int
main(void)
{
struct kevent kev[1];
struct timespec ts = {};
int fds[2], flags, kq, n;
char b;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, fds) == -1)
err(1, "socketpair");
flags = fcntl(fds[0], F_GETFL, 0);
fcntl(fds[0], F_SETFL, flags | O_NONBLOCK);
printf("write 1\n");
write(fds[1], "x", 1);
kq = kqueue();
if (kq == -1)
err(1, "kqueue");
EV_SET([0], fds[0], EVFILT_READ, EV_ADD | EV_ONESHOT, 0, 0, NULL);
if (kevent(kq, kev, 1, NULL, 0, NULL) == -1)
err(1, "kevent");
n = read(fds[0], , 1);
printf("read %d\n", n);
n = read(fds[0], , 1);
printf("read %d\n", n);
n = kevent(kq, NULL, 0, kev, 1, );
printf("kevent %d\n", n);
n = read(fds[0], , 1);
printf("read %d\n", n);
n = kevent(kq, NULL, 0, kev, 1, );
printf("kevent %d\n", n);
printf("write 1\n");
write(fds[1], "x", 1);
n = kevent(kq, NULL, 0, kev, 1, );
printf("kevent %d\n", n);
n = read(fds[0], , 1);
printf("read %d\n", n);
return 0;
}
With an unpatched kernel, the EV_ONESHOT event gets activated by the
pending byte when the event is registered. The event remains active
until delivery, and the delivery happens even though it is clear that
reading from the socket will fail. The program prints:
write 1
read 1
read -1
kevent 1
read -1
kevent 0
write 1
kevent 0
read 1
With the patch applied, the event gets delivered only if the socket
has bytes pending.
write 1
read 1
read -1
kevent 0
read -1
kevent 0
write 1
kevent 1
read 1
So, is this EV_ONESHOT change reasonable, or should the implementation
stick with the old way? FreeBSD appears to follow the old way. MacOS
might perform differently, though I am not sure about that.
It is not essential to change EV_ONESHOT, however.
Feedback and tests are welcome.
Index: kern/uipc_socket.c
===
RCS file: src/sys/kern/uipc_socket.c,v
retrieving revision 1.261
diff -u -p -r1.261 uipc_socket.c
--- kern/uipc_socket.c 13 May 2021 19:43:11 - 1.261
+++ kern/uipc_socket.c 18 May 2021 12:56:24 -
@@ -70,15 +70,26 @@ voidsorflush(struct socket *);
void filt_sordetach(struct knote *kn);
intfilt_soread(struct knote *kn, long hint);
+intfilt_soreadmodify(struct kevent *kev, struct knote *kn);
+intfilt_soreadprocess(struct knote *kn, struct kevent *kev);
+intfilt_soread_common(struct knote *kn, struct socket *so);
void filt_sowdetach(struct knote *kn);
intfilt_sowrite(struct knote *kn, long hint);
+intfilt_sowritemodify(struct kevent *kev, struct knote *kn);
+intfilt_sowriteprocess(struct knote *kn, struct kevent *kev);
+intfilt_sowrite_common(struct knote *kn, struct socket *so);
intfilt_solisten(struct knote *kn, long hint);
+intfilt_solistenmodify(struct kevent *kev, struct knote *kn);
+intfilt_solistenprocess(struct knote *kn, struct kevent *kev);
+intfilt_solisten_common(struct knote *kn, struct socket *so);
const struct filterops solisten_filtops = {
.f_flags= FILTEROP_ISFD,
.f_attach = NULL,
.f_detach = filt_sordetach,
.f_event= filt_solisten,
+ .f_modify = filt_solistenmodify,
+ .f_process = filt_solistenprocess,
};
const struct filterops soread_filtops = {
@@ -86,6 +97,8 @@ const struct filterops soread_filtops =
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/17 05:59:53 Modified files: sys/dev/ic : re.c Log message: Fix mbuf leaks after reception error in re_rxeof(). Also, increment the error counter when an unexpected fragment is seen. OK claudio@
Re: panic(9): set panicstr atomically
On Wed, May 12, 2021 at 07:08:39PM -0500, Scott Cheloha wrote: > In a separate mail thread, bluhm@ mentioned that panic(9) does not > cleanly handle multiple CPUs entering it simultaneously: > > https://marc.info/?l=openbsd-tech=161908805925325=2 > > I'm unsure which part of panic(9) is causing the problem he mentions, > but one obvious issue I see is that panicstr is not set atomically, > so two CPUs entering panic(9) simultaneously may clobber panicbuf. > > If we set panicstr atomically only one CPU will write panicbuf. I think most of the clobbering is explained by more than one CPU writing to the console at the same time. The vsnprintf() and setting of panicstr usually happen quickly, so the kind of garbling occasionally seen with nearly simultaneous panicking is not likely to arise there. Console I/O, on the other hand, can be orders of magnitude slower. That, and the fact that mutexes become no-ops once panicstr is set, create a slow phase where multiple CPUs can easily be concurrently even if the initial timings were not so close after all. I feel that panic() should let only the first panicker run the panic code and stop any other CPUs, like NetBSD does. Another option is to serialize panic() in a more proper way. Or maybe secondary panickers should just delay a little at the start of panic()...
Re: timeout(9): add TIMEOUT_MPSAFE flag
On Thu, May 13, 2021 at 11:08:25AM -0500, Scott Cheloha wrote:
> > On May 13, 2021, at 10:57 AM, Visa Hankala wrote:
> >
> > On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
> >> The funky locking dance in softclock() and softclock_thread() is
> >> needed to keep from violating the locking hierarchy. The
> >> timeout_mutex is above the kernel lock, so we need to leave the
> >> timeout_mutex, then drop the kernel lock, and then reenter the
> >> timeout_mutex to start running TIMEOUT_MPSAFE timeouts.
> >
> > Are you sure that dropping the kernel lock in softclock(), in
> > non-process context, is a good idea? That makes assumptions how the
> > layers above work.
>
> I figured it was the most obvious way forward.
>
> When you say "layers above," do you mean softintr_dispatch()?
> Or something else?
I mean softintr_dispatch() and anything else in the dispatch path.
> > At the minimum, I think the soft interrupt code has to be changed so
> > that it is possible to register MP-safe handlers.
>
> Some platforms (e.g. arm64) have softintr_establish_flags(), but this
> is not universally available.
>
> Do I need to unlock all the softintr internals before proceeding
> with this? Or do I just need to bring softrintr_establish_flags()
> to every platform without it?
I think softrintr_establish() could register an MP-safe handler if
IPL_MPSAFE is ORed in the ipl parameter.
Dropping the kernel lock has various implications. At least the code
has to ensure that at most one CPU can run a given handler at a time.
In addition, softintr_disestablish() should probably block until the
handler has stopped (at the moment, this is not guaranteed on the
platforms that have softintr_establish_flags()).
Below is a hasty sketch for amd64 that I am not suggesting to commit.
It is probably wrong in more ways than one.
Index: arch/amd64/amd64/softintr.c
===
RCS file: src/sys/arch/amd64/amd64/softintr.c,v
retrieving revision 1.10
diff -u -p -r1.10 softintr.c
--- arch/amd64/amd64/softintr.c 11 Sep 2020 09:27:09 - 1.10
+++ arch/amd64/amd64/softintr.c 13 May 2021 17:28:51 -
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
@@ -85,7 +86,6 @@ softintr_dispatch(int which)
floor = ci->ci_handled_intr_level;
ci->ci_handled_intr_level = ci->ci_ilevel;
- KERNEL_LOCK();
for (;;) {
mtx_enter(>softintr_lock);
sih = TAILQ_FIRST(>softintr_q);
@@ -95,14 +95,20 @@ softintr_dispatch(int which)
}
TAILQ_REMOVE(>softintr_q, sih, sih_q);
sih->sih_pending = 0;
-
- uvmexp.softs++;
-
mtx_leave(>softintr_lock);
- (*sih->sih_fn)(sih->sih_arg);
+ atomic_inc_int();
+
+ if (sih->sih_flags & IPL_MPSAFE) {
+ mtx_enter(>sih_mtx);
+ (*sih->sih_fn)(sih->sih_arg);
+ mtx_leave(>sih_mtx);
+ } else {
+ KERNEL_LOCK();
+ (*sih->sih_fn)(sih->sih_arg);
+ KERNEL_UNLOCK();
+ }
}
- KERNEL_UNLOCK();
ci->ci_handled_intr_level = floor;
}
@@ -117,7 +123,10 @@ softintr_establish(int ipl, void (*func)
{
struct x86_soft_intr *si;
struct x86_soft_intrhand *sih;
- int which;
+ int flags, which;
+
+ flags = ipl & IPL_MPSAFE;
+ ipl &= ~IPL_MPSAFE;
switch (ipl) {
case IPL_SOFTCLOCK:
@@ -141,9 +150,11 @@ softintr_establish(int ipl, void (*func)
sih = malloc(sizeof(*sih), M_DEVBUF, M_NOWAIT);
if (__predict_true(sih != NULL)) {
+ mtx_init(>sih_mtx, IPL_NONE);
sih->sih_intrhead = si;
sih->sih_fn = func;
sih->sih_arg = arg;
+ sih->sih_flags = flags;
sih->sih_pending = 0;
}
return (sih);
@@ -167,5 +178,8 @@ softintr_disestablish(void *arg)
}
mtx_leave(>softintr_lock);
+ /* Wait for any running handlers to finish. */
+ smr_barrier();
+
free(sih, M_DEVBUF, sizeof(*sih));
}
Index: arch/amd64/include/intr.h
===
RCS file: src/sys/arch/amd64/include/intr.h,v
retrieving revision 1.32
diff -u -p -r1.32 intr.h
--- arch/amd64/include/intr.h 17 Jun 2020 06:14:52 - 1.32
+++ arch/amd64/include/intr.h 13 May 2021 17:28:51 -
@@ -232,13 +232,16 @@ extern void (*ipifunc[X86_NIPI])(struct
#ifndef _LOCORE
#include
+#include
struct x86_soft_intrhand {
TAILQ_ENTRY(x86_soft_intrhand)
sih_q;
+ struct mutex sih_mtx;
struct x86_soft_intr *sih_intrhead;
void(*sih_fn)(void *);
void*sih_arg;
+ int sih_flags;
int sih_pending;
};
Re: timeout(9): add TIMEOUT_MPSAFE flag
On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote: > The funky locking dance in softclock() and softclock_thread() is > needed to keep from violating the locking hierarchy. The > timeout_mutex is above the kernel lock, so we need to leave the > timeout_mutex, then drop the kernel lock, and then reenter the > timeout_mutex to start running TIMEOUT_MPSAFE timeouts. Are you sure that dropping the kernel lock in softclock(), in non-process context, is a good idea? That makes assumptions how the layers above work. At the minimum, I think the soft interrupt code has to be changed so that it is possible to register MP-safe handlers.
Fix mbuf leaks in re_rxeof()
It looks that re_rxeof() might leak mbufs in two cases. The first case
happens if the controller returns an incomplete frame when frames are
expected to be non-fragmented. Note that in this instance the fragment
list sc->rl_head should be empty and does not need clearing.
The second leak happens if a frame has a reception error. The code has
cleared any preceding fragments but leaks the list's final mbuf.
Index: dev/ic/re.c
===
RCS file: src/sys/dev/ic/re.c,v
retrieving revision 1.210
diff -u -p -r1.210 re.c
--- dev/ic/re.c 7 May 2021 09:13:19 - 1.210
+++ dev/ic/re.c 13 May 2021 14:33:20 -
@@ -1280,6 +1280,8 @@ re_rxeof(struct rl_softc *sc)
if ((sc->rl_flags & RL_FLAG_JUMBOV2) != 0 &&
(rxstat & (RL_RDESC_STAT_SOF | RL_RDESC_STAT_EOF)) !=
(RL_RDESC_STAT_SOF | RL_RDESC_STAT_EOF)) {
+ ifp->if_ierrors++;
+ m_freem(m);
continue;
} else if (!(rxstat & RL_RDESC_STAT_EOF)) {
m->m_len = RL_FRAMELEN(sc->rl_max_mtu);
@@ -1328,6 +1330,7 @@ re_rxeof(struct rl_softc *sc)
m_freem(sc->rl_head);
sc->rl_head = sc->rl_tail = NULL;
}
+ m_freem(m);
continue;
}
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/05 09:29:19 Modified files: sys/arch/mips64/include: cpu.h sys/arch/mips64/mips64: pmap.c tlbhandler.S Log message: Remove unneeded tlb_set_gbase() that was used with R8000. Pointed out by miod@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/03 07:11:40 Modified files: sys/dev/fdt: sdhc_fdt.c Log message: Make sdhc(4) attachment work on Zynq-7000. OK kettenis@
Re: sdhc(4) attachment for Zynq-7000
On Sun, May 02, 2021 at 05:28:24PM +0200, Mark Kettenis wrote:
> > Date: Sun, 2 May 2021 14:21:29 +
> > From: Visa Hankala
> >
> > Zynq-7000 has a variant of Arasan SD controller that is not recognized
> > by the fdt glue. The diff below fixes this.
> >
> > The controller's capabilities register lacks the base clock frequency.
> > The attachment glue has to provide this parameter.
> >
> > OK?
> >
> > Index: dev/fdt/sdhc_fdt.c
> > ===
> > RCS file: src/sys/dev/fdt/sdhc_fdt.c,v
> > retrieving revision 1.15
> > diff -u -p -r1.15 sdhc_fdt.c
> > --- dev/fdt/sdhc_fdt.c 5 Apr 2021 09:31:45 - 1.15
> > +++ dev/fdt/sdhc_fdt.c 2 May 2021 14:07:45 -
> > @@ -126,6 +126,7 @@ sdhc_fdt_match(struct device *parent, vo
> > struct fdt_attach_args *faa = aux;
> >
> > return (OF_is_compatible(faa->fa_node, "arasan,sdhci-5.1") ||
> > + OF_is_compatible(faa->fa_node, "arasan,sdhci-8.9a") ||
> > OF_is_compatible(faa->fa_node, "brcm,bcm2711-emmc2") ||
> > OF_is_compatible(faa->fa_node, "brcm,bcm2835-sdhci") ||
> > OF_is_compatible(faa->fa_node, "marvell,armada-3700-sdhci") ||
> > @@ -232,6 +233,11 @@ sdhc_fdt_attach(struct device *parent, s
> > sc->sc.sc_flags |= SDHC_F_NODDR50;
> > }
> >
> > + if (OF_is_compatible(faa->fa_node, "arasan,sdhci-8.9a")) {
> > + freq = clock_get_frequency(faa->fa_node, "clk_xin");
> > + sc->sc.sc_clkbase = (freq + 500) / 1000;
>
> Is there a particular reason why you are trying to round to the
> nearest kHz here? We don't do that for any of the other cases where
> we set sc_clkbase, and I'd prefer not to have any special cases that
> aren't necessary.
In my case, the rounding makes a displayed value look more sensible.
sdhc0 at simplebus0
sdhc0: SDHC 2.0, 100 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
The clock computations use frequency Hz as input. This value
is multiplied and divided, giving 9990 Hz (which already has some
truncation). If this was truncated to MHz, the result would be 99 MHz.
However, if the rounding is not wanted, I can leave it out.
> > + }
> > +
> > if (OF_is_compatible(faa->fa_node, "brcm,bcm2711-emmc2"))
> > sc->sc.sc_flags |= SDHC_F_NOPWR0;
> >
sdhc(4) attachment for Zynq-7000
Zynq-7000 has a variant of Arasan SD controller that is not recognized
by the fdt glue. The diff below fixes this.
The controller's capabilities register lacks the base clock frequency.
The attachment glue has to provide this parameter.
OK?
Index: dev/fdt/sdhc_fdt.c
===
RCS file: src/sys/dev/fdt/sdhc_fdt.c,v
retrieving revision 1.15
diff -u -p -r1.15 sdhc_fdt.c
--- dev/fdt/sdhc_fdt.c 5 Apr 2021 09:31:45 - 1.15
+++ dev/fdt/sdhc_fdt.c 2 May 2021 14:07:45 -
@@ -126,6 +126,7 @@ sdhc_fdt_match(struct device *parent, vo
struct fdt_attach_args *faa = aux;
return (OF_is_compatible(faa->fa_node, "arasan,sdhci-5.1") ||
+ OF_is_compatible(faa->fa_node, "arasan,sdhci-8.9a") ||
OF_is_compatible(faa->fa_node, "brcm,bcm2711-emmc2") ||
OF_is_compatible(faa->fa_node, "brcm,bcm2835-sdhci") ||
OF_is_compatible(faa->fa_node, "marvell,armada-3700-sdhci") ||
@@ -232,6 +233,11 @@ sdhc_fdt_attach(struct device *parent, s
sc->sc.sc_flags |= SDHC_F_NODDR50;
}
+ if (OF_is_compatible(faa->fa_node, "arasan,sdhci-8.9a")) {
+ freq = clock_get_frequency(faa->fa_node, "clk_xin");
+ sc->sc.sc_clkbase = (freq + 500) / 1000;
+ }
+
if (OF_is_compatible(faa->fa_node, "brcm,bcm2711-emmc2"))
sc->sc.sc_flags |= SDHC_F_NOPWR0;
CVS: cvs.openbsd.org: xenocara
CVSROOT:/cvs Module name:xenocara Changes by: v...@cvs.openbsd.org2021/05/01 10:29:52 Removed files: distrib/sets/lists/xbase: md.sgi distrib/sets/lists/xetc: md.sgi distrib/sets/lists/xfont: md.sgi distrib/sets/lists/xserv: md.sgi distrib/sets/lists/xshare: md.sgi Log message: Remove sgi sets.
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: v...@cvs.openbsd.org2021/05/01 10:23:10 Modified files: . : sgi.html Log message: 6.9 was the last release with sgi.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/05/01 10:11:17 Modified files: . : Makefile.cross distrib: Makefile distrib/notes : Makefile distrib/sets/lists/base: mi distrib/sets/lists/comp: md.loongson md.octeon mi distrib/sets/lists/man: mi etc: Makefile etc/mtree : 4.4BSD.dist lib/libarch/mips64: Makefile lib/libc/sys : ptrace.2 lib/libcrypto/arch/mips64: Makefile.inc regress/etc/MAKEDEV: Makefile share/man/man4 : Makefile com.4 onewire.4 pci.4 pckbd.4 pms.4 spdmem.4 share/man/man5 : core.5 share/man/man7 : mdoc.7 share/man/man8 : Makefile diskless.8 share/man/man9 : pci_conf_read.9 pci_intr_map.9 share/mk : bsd.own.mk sys: Makefile sys/arch/mips64/conf: files.mips64 sys/arch/mips64/include: asm.h cpu.h mips_cpu.h pmap.h pte.h sys/arch/mips64/mips64: clock.c context.S cp0access.S cpu.c db_machdep.c exception.S lcore_access.S mips64_machdep.c pmap.c tlbhandler.S trap.c vm_machdep.c sys/dev/ic : aic7xxx.c sys/dev/microcode/atmel: Makefile sys/dev/microcode/bnx: Makefile sys/dev/microcode/fxp: Makefile sys/dev/microcode/kue: Makefile sys/dev/microcode/myx: Makefile sys/dev/microcode/ral: Makefile sys/dev/microcode/rum: Makefile sys/dev/microcode/symbol: Makefile sys/dev/microcode/tht: Makefile sys/dev/microcode/tigon: Makefile sys/dev/microcode/tusb3410: Makefile sys/dev/microcode/typhoon: Makefile sys/dev/microcode/udl: Makefile sys/dev/microcode/yds: Makefile sys/dev/microcode/zydas: Makefile sys/dev/pci: pcivar.h qlw_pci.c sys/dev/pckbc : wskbdmap_mfii.c sys/dev/usb: ukbdmap.c sys/dev/wsfont : wsfont.c sys/kern : Makefile usr.bin/mandoc : arch.c cgi.c usr.sbin/hotplugd: Makefile usr.sbin/pcidump: Makefile Removed files: distrib/notes/sgi: contents features hardware install prep upgrade whatis xfer distrib/sets/lists/base: md.sgi distrib/sets/lists/comp: clang.sgi gcc.sgi md.sgi distrib/sets/lists/etc: md.sgi distrib/sets/lists/game: md.sgi distrib/sets/lists/man: md.sgi distrib/sgi: Makefile distrib/sgi/cdfs: Makefile xfs512.bin.gz.uue distrib/sgi/iso: Makefile distrib/sgi/ramdisk: Makefile install.md list etc/etc.sgi: MAKEDEV MAKEDEV.md Makefile Makefile.inc disktab fbtab login.conf sysctl.conf ttys share/man/man4 : wdsc.4 share/man/man4/man4.sgi: Makefile dpclock.4 dsclock.4 dsrtc.4 gbe.4 gio.4 grtwo.4 hpc.4 iec.4 imc.4 impact.4 intro.4 ioc.4 iockbc.4 iof.4 light.4 macebus.4 mavb.4 mec.4 mkbc.4 newport.4 odyssey.4 owmac.4 owserial.4 panel.4 power.4 sq.4 xbow.4 xbridge.4 xheart.4 zs.4 share/man/man8/man8.sgi: MAKEDEV.8 Makefile sys/arch/mips64/include: arcbios.h sys/arch/mips64/mips64: arcbios.c cache_r10k.c cache_r4k.c cache_r5k.c cache_tfp.c cache_tfp_subr.S exception_tfp.S r4000_errata.c tlb_tfp.S sys/arch/sgi : Makefile sys/arch/sgi/compile: Makefile Makefile.inc sys/arch/sgi/compile/GENERIC-IP22: Makefile sys/arch/sgi/compile/GENERIC-IP26: Makefile sys/arch/sgi/compile/GENERIC-IP27: Makefile sys/arch/sgi/compile/GENERIC-IP27.MP: Makefile sys/arch/sgi/compile/GENERIC-IP28: Makefile sys/arch/sgi/compile/GENERIC-IP30: Makefile sys/arch/sgi/compile/GENERIC-IP30.MP: Makefile sys/arch/sgi/compile/GENERIC-IP32: Makefile sys/arch/sgi/compile/RAMDISK-IP22: Makefile sys/arch/sgi/compile/RAMDISK-IP26: Makefile sys/arch/sgi/compile/RAMDISK-IP27: Makefile sys/arch/sgi/compile/RAMDISK-IP28: Makefile sys/arch/sgi/compile/RAMDISK-IP30: Makefile sys/arch/sgi/compile/RAMDISK-IP32: Makefile sys/arch/sgi/conf: GENERIC-IP22 GENERIC-IP26 GENERIC-IP27 GENERIC-IP27.MP GENERIC-IP28 GENERIC-IP30 GENERIC-IP30.MP GENERIC-IP32 Makefile.sgi RAMDISK-IP22 RAMDISK-IP26 RAMDISK-IP27 RAMDISK-IP28 RAMDISK-IP30 RAMDISK-IP32
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/04/30 07:25:24 Modified files: share/man/man4/man4.armv7: Makefile sys/arch/armv7/conf: GENERIC RAMDISK sys/arch/armv7/xilinx: files.xilinx Added files: share/man/man4/man4.armv7: zqclock.4 sys/arch/armv7/xilinx: zqclock.c Log message: Add zqclock(4), a driver for Zynq-7000 clocks. Input and OK kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2021/04/30 07:20:14 Modified files: share/man/man4/man4.armv7: Makefile sys/arch/armv7/conf: GENERIC RAMDISK files.armv7 Added files: share/man/man4/man4.armv7: zqreset.4 sys/arch/armv7/xilinx: files.xilinx slcreg.h zqreset.c Log message: Add zqreset(4), a driver for Zynq-7000 resets. Input and OK kettenis@
