r354485 glebius Nov. 7, 2019, 9:28 p.m.
also does.  This allows to simplify tcp_tw_2msl_scan() and
always require the network epoch in it.
ViewVC
r354484 glebius Nov. 7, 2019, 9:27 p.m.
handlers can be greatly simplified.  All the previous double
cycling and complex locking was added to avoid these functions
holding global PCB locks for extended period of time, preventing
addition of new entries.
ViewVC
r354483 glebius Nov. 7, 2019, 9:23 p.m.
in the network epoch, we can greatly simplify synchronization.
Remove all unneccesary epoch enters hidden under INP_INFO_RLOCK macro.
Remove some unneccesary assertions and convert necessary ones into the
NET_EPOCH_ASSERT macro.
ViewVC
r354482 avg Nov. 7, 2019, 9:14 p.m.
x86 stack_save_td_running() can work safely only if IPI_TRACE is a
non-maskable interrupt.  But at the moment FreeBSD/Xen does not provide
support for the NMI delivery mode.  So, mark the functionality as
unsupported similarly to other platforms without NMI.
Maybe there is a way to provide a Xen-specific working
stack_save_td_running(), but I couldn't figure it out.

MFC after:	3 weeks
Sponsored by:	Panzura
ViewVC
r354481 glebius Nov. 7, 2019, 9:08 p.m.
macro in udp_input().  It shall always run in the network epoch.
ViewVC
r354480 glebius Nov. 7, 2019, 9:03 p.m.
r354479 glebius Nov. 7, 2019, 9:01 p.m.
locking in udp_output() and udp6_output().

First, we select if we need read or write lock in PCB itself, we take
the lock and enter network epoch.  Then, we proceed for the rest of
the function.  In case if we need to modify PCB hash, we would take
write lock on it for a short piece of code.

We could exit the epoch before allocating an mbuf, but with this
patch we are keeping it all the way into ip_output()/ip6_output().
Today this creates an epoch recursion, since ip_output() enters epoch
itself.  However, once all protocols are reviewed, ip_output() and
ip6_output() would require epoch instead of entering it.

Note: I'm not 100% sure that in udp6_output() the epoch is required.
We don't do PCB hash lookup for a bound socket.  And all branches of
in6_select_src() don't require epoch, at least they lack assertions.
Today inet6 address list is protected by rmlock, although it is CKLIST.
AFAIU, the future plan is to protect it by network epoch.  That would
require epoch in in6_select_src().  Anyway, in future ip6_output()
would require epoch, udp6_output() would need to enter it.
ViewVC
r354478 glebius Nov. 7, 2019, 8:57 p.m.
r354477 glebius Nov. 7, 2019, 8:49 p.m.
we lookup PCBs.  Thus, do not enter epoch recursively in
in_pcblookup_hash() and in6_pcblookup_hash().  Same applies to
tcp_ctlinput() and tcp6_ctlinput().

This leaves several sysctl(9) handlers that return PCB credentials
unprotected.  Add epoch enter/exit to all of them.

Differential Revision:	https://reviews.freebsd.org/D22197
ViewVC
r354476 glebius Nov. 7, 2019, 8:44 p.m.
macro in divert_packet().  This function is called only from
pfil(9) filters, which in their place always run in the
network epoch.
ViewVC
r354475 glebius Nov. 7, 2019, 8:43 p.m.
macro in icmp6_rip6_input().  It shall always run in the
network epoch.
ViewVC
r354474 glebius Nov. 7, 2019, 8:40 p.m.
macro in raw input functions for IPv4 and IPv6.  They shall
always run in the network epoch.
ViewVC
r354473 glebius Nov. 7, 2019, 8:38 p.m.
macro in udp6_input().  It shall always run in the network epoch.
ViewVC
r354470 gallatin Nov. 7, 2019, 7:54 p.m.
- amd_intr() does not account for the offset (0x200) in the counter
MSR address and ends up accessing invalid regions while reading
counter value after the 4th counter (0xC001000[8,9,..]) and
erroneously updates the counter values for counters [1-4].

- amd_intr() should only check core pmcs for interrupts since
 other types of pmcs (L3,DF) cannot generate interrupts.

- fix pmc NMI's being ignored due to NMI latency on newer AMD processors

Note that this fixes a kernel panic due to GPFs accessing MSRs on
higher core count AMD cpus (seen on both Rome 7502P, and
Threadripper 2990WX 32-core CPUs)

Discussed with: markj

Submitted by:	Shreyank Amartya
Differential Revision:	https://reviews.freebsd.org/D21553
ViewVC
r354469 dim Nov. 7, 2019, 7:54 p.m.
[RISCV] Add Custom Parser for Atomic Memory Operands

  Summary:
  GCC Accepts both (reg) and 0(reg) for atomic instruction memory
  operands. These instructions do not allow for an offset in their
  encoding, so in the latter case, the 0 is silently dropped.

  Due to how we have structured the RISCVAsmParser, the easiest way to
  add support for parsing this offset is to add a custom AsmOperand and
  parser. This parser drops all the parens, and just keeps the
  register.

  This commit also adds a custom printer for these operands, which
  matches the GCC canonical printer, printing both `(a0)` and `0(a0)`
  as `(a0)`.

  Reviewers: asb, lewis-revill

  Reviewed By: asb

  Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook,
  apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay,
  zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
  rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits

  Tags: #llvm

  Differential Revision: https://reviews.llvm.org/D65205

  llvm-svn: 367553

Merge commit f596f4507 from llvm git (by Sam Elliott):

  [RISCV] Add FreeBSD targets

  Reviewers: asb

  Reviewed By: asb

  Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne,
  emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits

  Tags: #clang

  Differential Revision: https://reviews.llvm.org/D57795

  Patch by James Clarke (jrtc27)

  llvm-svn: 367557

Merge commit f596f4507 from llvm git (by Hsiangkai Wang):

  [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.

  It is necessary to generate fixups in .debug_frame or .eh_frame as
  relaxation is enabled due to the address delta may be changed after
  relaxation.

  There is an opcode with 6-bits data in debug frame encoding. So, we
  also need 6-bits fixup types.

  Differential Revision: https://reviews.llvm.org/D58335

  llvm-svn: 366524

Merge commit f596f4507 from llvm git (by Hsiangkai Wang):

  [DebugInfo] Some fields do not need relocations even relax is enabled.

  In debug frame information, some fields, e.g., Length in CIE/FDE and
  Offset in FDE are attributes to describe the structure of CIE/FDE.
  They are not related to the relaxed code. However, these attributes
  are symbol differences. So, in current design, these attributes will
  be filled as zero and LLVM generates relocations for them.

  We only need to generate relocations for symbols in executable
  sections.  So, if the symbols are not located in executable sections,
  we still evaluate their values under relaxation.

  Differential Revision: https://reviews.llvm.org/D61584

  llvm-svn: 366531

Merge commit f596f4507 from llvm git (by Alex Bradbury):

  [RISCV] Don't force absolute FK_Data_X fixups to relocs

  The current behavior of shouldForceRelocation forces relocations for
  the majority of fixups when relaxation is enabled. This makes sense
  for fixups which incorporate symbols but is unnecessary for simple
  data fixups where the fixup target is already resolved to an absolute
  value.

  Differential Revision: https://reviews.llvm.org/D63404
  Patch by Edward Jones.

  llvm-svn: 369257

Merge commit f596f4507 from llvm git (by Alex Bradbury):

  [RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is
  used for the FDE location

  Follow binutils in using RISCV_32_PCREL for the FDE initial location.
  As explained in the relevant binutils commit
  <https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>,
  the ADD/SUB pair of relocations is problematic in the presence of
  linker relaxation.

  This patch has the same end goal as D64715 but includes test changes
  and avoids adding a new global VariantKind to MCExpr.h (preferring
  RISCVMCExpr VKs like the rest of the RISC-V backend).

  Differential Revision: https://reviews.llvm.org/D66419

  llvm-svn: 369375

This series of merges will permit riscv64 kernels and riscv64sf worlds
to build with clang instead of gcc (but still using the bfd linker).

Requested by:	jhb
Obtained from:	https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang
MFC after:	1 month
X-MFC-With:	r353358
ViewVC