Skip to content

NPF routing on interface #60

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: trunk
Choose a base branch
from
Open

NPF routing on interface #60

wants to merge 2 commits into from

Conversation

@Emmankoko
Copy link

@Emmankoko Emmankoko commented Oct 18, 2025

No description provided.

@Emmankoko Emmankoko changed the title routing on interface NPF routing on interface Oct 18, 2025
zoulasc
zoulasc reviewed Oct 18, 2025
View reviewed changes
sys/net/npf/npf_ext_route.c
const char *ifname;

meta = kmem_zalloc(sizeof(*meta), KM_SLEEP);
ifname = nvlist_get_string(params, "route-interface");
Copy link
Contributor

@zoulasc zoulasc Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can return NULL

zoulasc
zoulasc reviewed Oct 18, 2025
View reviewed changes
sys/net/npf/npf_ext_route.c Outdated

if ((m->m_pkthdr.csum_flags & M_CSUM_TSOv4) == 0) {
/*
* Perform any checksums that the hardware can't do
Copy link
Contributor

@zoulasc zoulasc Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

misindented, or misrendered?

zoulasc
zoulasc reviewed Oct 18, 2025
View reviewed changes
sys/net/npf/npf_ext_route.c Outdated
const npf_ext_route_t *route = meta;
npf_t *npf = npf_getkernctx();
struct ifnet *ifp;
int error = 0;
Copy link
Contributor

@zoulasc zoulasc Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to set error to something here because there are cases where you do nothing and fall through (like if INET6 is not defined, or it is not either cached in 4 or 6)

Copy link
Author

@Emmankoko Emmankoko Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right! it must be in bad state from the onset so that it can go to bad and not get routed because your OS or hardware or whatever doesn't have whatever address family support.

netbsd-srcmastr pushed a commit that referenced this pull request Oct 19, 2025
@MartinHusemann
Pull up following revision(s) (requested by riastradh in ticket #60):
389b246 
	sys/arch/sparc/sparc/locore.s: revision 1.287
	share/man/man9/Makefile: revision 1.475
	sys/arch/mips/mips/cpu_subr.c: revision 1.65
	sys/arch/mips/mips/cpu_subr.c: revision 1.66
	sys/arch/amd64/amd64/cpufunc.S: revision 1.70
	sys/arch/hppa/hppa/support.S: revision 1.9
	sys/arch/alpha/alpha/locore.s: revision 1.145
	share/man/man9/paravirt_membar_sync.9: revision 1.1
	sys/arch/sparc64/sparc64/locore.s: revision 1.436
	distrib/sets/lists/comp/mi: revision 1.2499
	sys/arch/i386/i386/cpufunc.S: revision 1.54
	sys/sys/paravirt_membar.h: revision 1.1
	sys/arch/arm/arm/cpu_subr.c: revision 1.6
	(all via patch)

paravirt_membar_sync(9): New memory barrier.

For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.

This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus.  Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.

PR kern/59618: occasional virtio block device lock ups/hangs

mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync.  Fixes:
/tmp/ccxgOmXc.s: Assembler messages:
/tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
--- cpu_subr.o ---
*** Failed target: cpu_subr.o

PR kern/59618: occasional virtio block device lock ups/hangs
netbsd-srcmastr pushed a commit that referenced this pull request Oct 19, 2025
@MartinHusemann
Pull up following revision(s) (requested by riastradh in ticket #60):
f3dabd1 
	sys/arch/sparc/sparc/locore.s: revision 1.287
	share/man/man9/Makefile: revision 1.475
	sys/arch/mips/mips/cpu_subr.c: revision 1.65
	sys/arch/mips/mips/cpu_subr.c: revision 1.66
	sys/arch/amd64/amd64/cpufunc.S: revision 1.70
	common/lib/libc/arch/i386/atomic/atomic.S: revision 1.38
	common/lib/libc/arch/sparc/atomic/membar_ops.S: revision 1.9
	sys/arch/hppa/hppa/support.S: revision 1.9
	sys/arch/alpha/alpha/locore.s: revision 1.145
	share/man/man9/paravirt_membar_sync.9: revision 1.1
	sys/arch/sparc64/sparc64/locore.s: revision 1.436
	distrib/sets/lists/comp/mi: revision 1.2499
	sys/arch/i386/i386/cpufunc.S: revision 1.54
	common/lib/libc/arch/sparc64/atomic/membar_ops.S: revision 1.10
	sys/sys/paravirt_membar.h: revision 1.1
	sys/arch/arm/arm/cpu_subr.c: revision 1.6
	common/lib/libc/arch/x86_64/atomic/atomic.S: revision 1.32
	(all via patch)

paravirt_membar_sync(9): New memory barrier.

For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.

This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus.  Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.

PR kern/59618: occasional virtio block device lock ups/hangs

mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync.  Fixes:
/tmp/ccxgOmXc.s: Assembler messages:
/tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
--- cpu_subr.o ---
*** Failed target: cpu_subr.o

PR kern/59618: occasional virtio block device lock ups/hangs
netbsd-srcmastr pushed a commit that referenced this pull request Oct 19, 2025
@MartinHusemann
Pull up following revision(s) (requested by riastradh in ticket #60):
4570522 
	sys/arch/sparc/sparc/locore.s: revision 1.287
	share/man/man9/Makefile: revision 1.475
	sys/arch/mips/mips/cpu_subr.c: revision 1.65
	sys/arch/riscv/riscv/cpu_subr.c: revision 1.6
	sys/arch/mips/mips/cpu_subr.c: revision 1.66
	sys/arch/amd64/amd64/cpufunc.S: revision 1.70
	common/lib/libc/arch/i386/atomic/atomic.S: revision 1.38
	common/lib/libc/arch/sparc/atomic/membar_ops.S: revision 1.9
	sys/arch/hppa/hppa/support.S: revision 1.9
	sys/arch/alpha/alpha/locore.s: revision 1.145
	share/man/man9/paravirt_membar_sync.9: revision 1.1
	sys/arch/sparc64/sparc64/locore.s: revision 1.436
	distrib/sets/lists/comp/mi: revision 1.2499
	sys/arch/i386/i386/cpufunc.S: revision 1.54
	common/lib/libc/arch/sparc64/atomic/membar_ops.S: revision 1.10
	sys/sys/paravirt_membar.h: revision 1.1
	sys/arch/arm/arm/cpu_subr.c: revision 1.6
	sys/arch/virt68k/virt68k/locore.s: revision 1.17
	common/lib/libc/arch/x86_64/atomic/atomic.S: revision 1.32

paravirt_membar_sync(9): New memory barrier.

For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.

This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus.  Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.

PR kern/59618: occasional virtio block device lock ups/hangs

mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync.  Fixes:
/tmp/ccxgOmXc.s: Assembler messages:
/tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
--- cpu_subr.o ---
*** Failed target: cpu_subr.o

PR kern/59618: occasional virtio block device lock ups/hangs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@zoulasc zoulasc zoulasc left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Emmankoko @zoulasc