amdtemp: adds APU2 support #4
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I believe @loos-br already committed it to FreeBSD, and will MFC it to 10.x soon, then it'll be automatically added to pfSense |
|
This is in FreeBSD, we'll get it when it's MFCed. |
netgate-git-updates
pushed a commit
that referenced
this pull request
Aug 26, 2016
Pull in r265122 from upstream llvm trunk (by James Molloy):
Fix for pr24346: arm asm label calculation error in sub
Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:
add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260
would be assembled to the following, which adds 1 to r0, instead of
260:
e2800104 add r0, r0, #4, 2 ; equivalently 1
The new fixup kind fixup_arm_mod_imm takes care of the encoding:
e2800f41 add r0, r0, #260
Patch by Ting-Yuan Huang!
This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.
Requested by: jkim
netgate-git-updates
pushed a commit
that referenced
this pull request
Sep 25, 2016
Sync libarchive with vendor including important security fixes. Issues fixed (FreeBSD): PR #778: ACL error handling Issue #745: Symlink check prefix optimization is too aggressive Issue #746: Hard links with data can evade sandboxing restrictions This update fixes the vulnerability #3 and vulnerability #4 as reported in "non-cryptanalytic attacks against FreeBSD update components". https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f Fix for vulnerability #2 has already been merged in r305192. Security: http://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f
netgate-git-updates
pushed a commit
that referenced
this pull request
Sep 25, 2016
Sync libarchive with vendor including important security fixes. Issues fixed (FreeBSD): PR #778: ACL error handling Issue #745: Symlink check prefix optimization is too aggressive Issue #746: Hard links with data can evade sandboxing restrictions This update fixes the vulnerability #3 and vulnerability #4 as reported in "non-cryptanalytic attacks against FreeBSD update components". https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f Fix for vulnerability #2 has already been merged in r305188. Security: http://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f
netgate-git-updates
pushed a commit
that referenced
this pull request
Sep 27, 2016
=== bspatch === MFS r306213: bspatch Capsicumization, sanity checks, and other improvements r304691: bspatch: apply style(9) Make style changes (and trivial refactoring of open calls) now in order to reduce noise in diffs for future capsicum changes. r304807 (allanjude): Capsicumize bspatch Move all of the fopen() and open() calls to the top of main() Restrict each FD to least privilege (read/seek only, write only, etc) cap_enter(), and make all except the output FD read/seek only. r304821: bspatch: remove output file in the case of error r305486: bspatch: add sanity checks on sizes to avoid integer overflow Note that this introduces an explicit 2GB limit, but this was already implicit in variable and function argument types. This is based on the "non-cryptanalytic attacks against freebsd update components" anonymous gist. Further refinement is planned. r305737: bspatch: remove superfluous newlines from errx strings r305822: bspatch: use #define for header size instead of magic number r306026: bspatch: Remove backwards-compatibility sys/capability.h support bspatch previously included sys/capability.h or sys/capsicum.h based on __FreeBSD_version, as FreeBSD is the upstream for bsdiff and we may see this file incorporated into other third-party software. The Capsicum header is now installed as sys/capsicum.h in stable/10 and FreeBSD 10.3, so we can just use sys/capsicum.h and simplify the logic. With this change, bspatch is identical between head, stable/11 and releng/11.0. === portsnap === MFS r305648 (delphij): MFC r305469: Ensure that we always open only files that is named by explicitly using shell redirections instead of having gzip(1) to decide what file to open. Issue reported in the "non-cryptanalytic attacks against freebsd update components" anonymous gist. === libarchive === MFS r305754 (mm): MFC r305422: Sync libarchive with vendor Vendor issues fixed: PR #777: Multiple bugfixes for setup_acls() This includes a bugfix for a bug that caused ACLs not to be read properly for files and directories inside subdirectories and as a result not being stored or being incorrectly stored in tar archives. MFS r306321 (mm): MFC r305819: Sync libarchive with vendor including important security fixes. Issues fixed (FreeBSD): PR #778: ACL error handling Issue #745: Symlink check prefix optimization is too aggressive Issue #746: Hard links with data can evade sandboxing restrictions This update fixes the vulnerability #3 and vulnerability #4 as reported in "non-cryptanalytic attacks against FreeBSD update components". https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f Fix for vulnerability #2 has already been merged. Approved by: re (gjb), so (glebius)
netgate-git-updates
pushed a commit
that referenced
this pull request
Jun 7, 2019
Partially revert r271349, which disabled the msun cexp test #4 on i386. Ensure the expected result is stored first in a volatile variable with the desired type. This makes all the tests succeed. Slightly changed from the original pull request, but functionally the same. Obtained from: freebsd/freebsd-src#401 Submitted by: Moritz Buhl <gh@moritzbuhl.de> PR: 191676
netgate-git-updates
pushed a commit
that referenced
this pull request
Jun 7, 2019
Partially revert r271349, which disabled the msun cexp test #4 on i386. Ensure the expected result is stored first in a volatile variable with the desired type. This makes all the tests succeed. Slightly changed from the original pull request, but functionally the same. Approved by: re (gjb) Obtained from: freebsd/freebsd-src#401 Submitted by: Moritz Buhl <gh@moritzbuhl.de> PR: 191676
netgate-git-updates
pushed a commit
that referenced
this pull request
Aug 16, 2019
…two) This commit is mostly a nop, but ends up renumbering #4 clause to #3 in one copy of quad.h... this is OK; stand/ situation in stable/11 is pretty murky and the commit that renumbered the clause got lost somewhere. quad.h will be disappearing in a not-so-distant future MFC. r351078: stand: kick out quad.h Use quad.h from libc instead for the time being. This reduces the number of nearly-identical-quad.h we have in tree to two with only minor changes. Prototypes for some *sh*di3 have been added to match the copy in libkern. The differences between the two are likely few enough that they can perhaps be merged with little additional effort to bring us down to 1. r351085: libc quad.h: one last _STANDALONE correction r351088: Revert r351078, r351085: stand/quad.h eviction It did not go well; further examination is required...
netgate-git-updates
pushed a commit
that referenced
this pull request
Aug 16, 2019
…two) This commit is mostly a nop, but ends up renumbering #4 clause to #3 in one copy of quad.h... this is OK; stand/ situation in stable/11 is pretty murky and the commit that renumbered the clause got lost somewhere. quad.h will be disappearing in a not-so-distant future MFC. r351078: stand: kick out quad.h Use quad.h from libc instead for the time being. This reduces the number of nearly-identical-quad.h we have in tree to two with only minor changes. Prototypes for some *sh*di3 have been added to match the copy in libkern. The differences between the two are likely few enough that they can perhaps be merged with little additional effort to bring us down to 1. r351085: libc quad.h: one last _STANDALONE correction r351088: Revert r351078, r351085: stand/quad.h eviction It did not go well; further examination is required...
netgate-git-updates
pushed a commit
that referenced
this pull request
Oct 31, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
netgate-git-updates
pushed a commit
that referenced
this pull request
Oct 31, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
netgate-git-updates
pushed a commit
that referenced
this pull request
Dec 23, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
netgate-git-updates
pushed a commit
that referenced
this pull request
Jun 22, 2022
Don't change the mbuf chain layout. We've encountered alignment issues in the tcp syncookie code on armv7, which appear to result from the m_pullup() here. eg: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xdbfc4058) locked @ /usr/src/sys/netinet/tcp_syncache.c:534 exclusive rw tcpinp (tcpinp) r = 0 (0xded8ee28) locked @ /usr/src/sys/netinet/in_pcb.c:2436 stack backtrace: #0 0xc0421480 at witness_debugger+0x6c #1 0xc0422514 at witness_warn+0x430 #2 0xc07d8830 at abort_handler+0x1d8 #3 0xc07bb1cc at exception_exit+0 #4 0xc06320bc at syncookie_lookup+0x4c #5 0xc0630cb0 at syncache_expand+0xc4 #6 0xc061be00 at tcp_input+0x11b0 #7 0xc058f8b4 at ip_input+0x264 #8 0xc04f5ca8 at netisr_dispatch_src+0xec #9 0xc04d39e8 at ether_demux+0x204 #10 0xc04d5088 at ether_nh_input+0x3e8 #11 0xc04f5ca8 at netisr_dispatch_src+0xec #12 0xc04d3f10 at ether_input+0xfc #13 0xc07fa750 at mvneta_rxtxth_intr+0x2b4 #14 0xc037f784 at ithread_loop+0x1cc #15 0xc037c4c8 at fork_exit+0xa0 #16 0xc07bb15c at swi_exit+0 Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xc7d28980 FSR=00000001, FAR=dbf7886e, spsr=60000013 r0 =00000025, r1 =00000001, r2 =c7d2894c, r3 =60000013 r4 =c7d28a58, r5 =c7d28bc8, r6 =dbf7886a, r7 =dbfc4058 r8 =dbfc4058, r9 =c7d28b98, r10=c7d28bfc, r11=c7d28a30 r12=20000000, ssp=c7d28a10, slr=c06320bc, pc =c06320bc Redmine: 8287
netgate-git-updates
pushed a commit
that referenced
this pull request
Jul 28, 2023
Avoid locking issues when if_allmulti() calls the driver's if_ioctl, because that may acquire sleepable locks (while we hold a non-sleepable rwlock). Fortunately there's no pressing need to hold the mroute lock while we do this, so we can postpone the call slightly, until after we've released the lock. This avoids the following WITNESS warning (with iflib drivers): lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff82f64960 IPv4 multicast forwarding (IPv4 multicast forwarding, rw) @ /usr/src/sys/netinet/ip_mroute.c:1050 2nd 0xfffff8000480f180 iflib ctx lock (iflib ctx lock, sx) @ /usr/src/sys/net/iflib.c:4525 lock order IPv4 multicast forwarding -> iflib ctx lock attempted at: #0 0xffffffff80bbd6ce at witness_checkorder+0xbbe #1 0xffffffff80b56d10 at _sx_xlock+0x60 #2 0xffffffff80c9ce5c at iflib_if_ioctl+0x2dc #3 0xffffffff80c7c395 at if_setflag+0xe5 #4 0xffffffff82f60a0e at del_vif_locked+0x9e #5 0xffffffff82f5f0d5 at X_ip_mrouter_set+0x265 #6 0xffffffff80bfd402 at sosetopt+0xc2 #7 0xffffffff80c02105 at kern_setsockopt+0xa5 #8 0xffffffff80c02054 at sys_setsockopt+0x24 #9 0xffffffff81046be8 at amd64_syscall+0x138 #10 0xffffffff8101930b at fast_syscall_common+0xf8 See also: https://redmine.pfsense.org/issues/12079 Reviewed by: mjg Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D41209 (cherry picked from commit 680ad06)
netgate-git-updates
pushed a commit
that referenced
this pull request
Aug 2, 2023
Avoid locking issues when if_allmulti() calls the driver's if_ioctl, because that may acquire sleepable locks (while we hold a non-sleepable rwlock). Fortunately there's no pressing need to hold the mroute lock while we do this, so we can postpone the call slightly, until after we've released the lock. This avoids the following WITNESS warning (with iflib drivers): lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff82f64960 IPv4 multicast forwarding (IPv4 multicast forwarding, rw) @ /usr/src/sys/netinet/ip_mroute.c:1050 2nd 0xfffff8000480f180 iflib ctx lock (iflib ctx lock, sx) @ /usr/src/sys/net/iflib.c:4525 lock order IPv4 multicast forwarding -> iflib ctx lock attempted at: #0 0xffffffff80bbd6ce at witness_checkorder+0xbbe #1 0xffffffff80b56d10 at _sx_xlock+0x60 #2 0xffffffff80c9ce5c at iflib_if_ioctl+0x2dc #3 0xffffffff80c7c395 at if_setflag+0xe5 #4 0xffffffff82f60a0e at del_vif_locked+0x9e #5 0xffffffff82f5f0d5 at X_ip_mrouter_set+0x265 #6 0xffffffff80bfd402 at sosetopt+0xc2 #7 0xffffffff80c02105 at kern_setsockopt+0xa5 #8 0xffffffff80c02054 at sys_setsockopt+0x24 #9 0xffffffff81046be8 at amd64_syscall+0x138 #10 0xffffffff8101930b at fast_syscall_common+0xf8 See also: https://redmine.pfsense.org/issues/12079 Reviewed by: mjg Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D41209
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Taken from: http://www.pcengines.info/forums/?page=post&id=6DA3284E-4973-4EC5-921D-A93AB72123DC