Skip to content

0001 fix pf divert to.v3.ipfw option1#1

Closed
ihoro wants to merge 13 commits intomainfrom
0001-fix-pf-divert-to.v3.ipfw-option1
Closed

0001 fix pf divert to.v3.ipfw option1#1
ihoro wants to merge 13 commits intomainfrom
0001-fix-pf-divert-to.v3.ipfw-option1

Conversation

@ihoro
Copy link
Copy Markdown
Owner

@ihoro ihoro commented Oct 16, 2023

demo patch

@ihoro ihoro closed this Oct 20, 2023
ihoro pushed a commit that referenced this pull request Jan 8, 2024
Specifically, altering the console list with conscontrol has some weird
behavior:

1. If you remove the first configured console, /dev/console will become
  unconfigured
2. Any console added becomes the /dev/console

In a multicons situation, #1 is clearly a bug and #2 is perhaps slightly
less clear.  If we have ttyu0, ttyv0, then it seems obvious that one
would want ttyv0 to take over the console if ttyu0 is removed.  If we
add ttyu0 back in, then it's debatable whether it should take over the
console or not.

Fix it now to make the /dev/console selection more FIFO-ish, with
respect to how conscontrol affects it.  A `primary` verb for
conscontrol(8) might be a good addition.
ihoro pushed a commit that referenced this pull request Nov 15, 2024
Avoid calling _callout_stop_safe with a non-sleepable lock held when
detaching by initializing callout_init_rw() with CALLOUT_SHAREDLOCK.

It avoids the following WITNESS warning when stopping the service:

    # service ipfilter stop
    calling _callout_stop_safe with the following non-sleepable locks held:
    shared rw ipf filter load/unload mutex (ipf filter load/unload mutex) r = 0 (0xffff0000417c7530) locked @ /usr/src/sys/netpfil/ipfilter/netinet/fil.c:7926
    stack backtrace:
    #0 0xffff00000052d394 at witness_debugger+0x60
    #1 0xffff00000052e620 at witness_warn+0x404
    #2 0xffff0000004d4ffc at _callout_stop_safe+0x8c
    #3 0xffff0000f7236674 at ipfdetach+0x3c
    #4 0xffff0000f723fa4c at ipf_ipf_ioctl+0x788
    #5 0xffff0000f72367e0 at ipfioctl+0x144
    #6 0xffff00000034abd8 at devfs_ioctl+0x100
    #7 0xffff0000005c66a0 at vn_ioctl+0xbc
    #8 0xffff00000034b2cc at devfs_ioctl_f+0x24
    #9 0xffff0000005331ec at kern_ioctl+0x2e0
    #10 0xffff000000532eb4 at sys_ioctl+0x140
    #11 0xffff000000880480 at do_el0_sync+0x604
    #12 0xffff0000008579ac at handle_el0_sync+0x4c

PR:		282478
Suggested by:	markj
Reviewed by:	cy
Approved by:	emaste (mentor)
MFC after:	1 week
ihoro pushed a commit that referenced this pull request Dec 14, 2024
Switch from creating the msr instructions to manage PAN to use the
"msr pan, #1" instruction directly. When this was added clang didn't
have support to assemble the instructions. This appears to have been
added to clang 13 which is sufficiently old enough.

Binutils releases from around the same time appear to have added this
instruction so any modern gcc should also support this instruction.

Sponsored by:	Arm Ltd
Differential Revision:	https://reviews.freebsd.org/D47817
ihoro pushed a commit that referenced this pull request Jul 17, 2025
Multiple issues existed within the powerpc FP/VSX save/restore functionality,
leading to register corruption and loss of register contents in specific
scenarios involving high signal load and use of both floating point and VSX
instructions.

Issue #1

On little endian systems the PCB used the wrong location for the shadowed
FP register within the larger VSX register.  This appears to have been an
attempt to correct issue #2 without understanding how the vector load/store
instructions actually operate.

Issue #2

On little endian systems, the VSX state save/restore routines swapped 32-bit
words within the 64-bit aliased double word for the associated floating point
register.  This was due to the use of a word-oriented load/store vs. doubleword
oriented load/store.

Issue #3

The FPU was turned off in the PCB but not in hardware, leading to a potential
race condition if the same thread was scheduled immediately after sigreturn.

The triggering codebase for this is Go, which makes heavy use of signals and
and generates an unusual mix of floating point and VSX assembler.  As a result,
when combined with th powerpc lazy FPU restore, a condition was repeatedly hit
whereby the thread was interrupted in FP+VSX mode, then restored in FP only
mode, thus reliably triggering the issues above.

Also clean up the associated asm() style issue flagged by GitHub Actions.

Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>

MFC after:	1 week
Pull Request:	freebsd#1756
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant