2c4499dc brd May 13, 2022, 3:06 p.m.
Missed breaking this commit into smaller pieces

Approved by:		kp
cgit
964ad27f brd May 13, 2022, 2:33 p.m.
Devices that cannot be opened are most likely the install media and
should not be listed as destinations.

Reviewed by:		allanjude
Approved by:		allanjude
Differential Revision:	https://reviews.freebsd.org/D34879
Sponsored by:		Rubicon Communications, LLC ("Netgate")
cgit
db71383b mhorne May 13, 2022, 1:43 p.m.
It is unused, especially now that the underlying d_dumper methods do not
accept the argument.

Reviewed by:	markj
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D35174
cgit
489ba222 mhorne May 13, 2022, 1:42 p.m.
The physical address argument is essentially ignored by every dumper
method. In addition, the dump routines don't actually pass a real
address; every call to dump_append() passes a value of zero for
physical.

Reviewed by:	markj
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D35173
cgit
0f50da2e mhorne May 13, 2022, 1:42 p.m.
It appears to be unused. These days struct disk has a d_dump member,
which is what gets passed to the kernel dump framework.

Reviewed by:	markj
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D35172
cgit
51adf913 kevans May 13, 2022, 3:04 a.m.
An earlier stage may have set HCR_EL2.E2H, the clearing of which may
break address translation.  We don't need the EL2 MMU at this point, so
we can avoid re-enabling it for now and just drop to EL1 as usual.

Suggested by:	andrew
Reviewed by:	andrew
Differential Revision:	https://reviews.freebsd.org/D34644
cgit
4581cffb glebius May 12, 2022, 9:29 p.m.
Fixes:	4328318445ae
cgit
0bef4927 asomers May 12, 2022, 8:32 p.m.
* If during FUSE_CREATE, FUSE_MKDIR, etc the server returns the same
  inode number for the new file as for its parent directory, reject it.
  Previously this would triggers a recurse-on-non-recursive lock panic.

* If during FUSE_LINK the server returns a different inode number for
  the new name as for the old one, reject it.  Obviously, that can't be
  a hard link.

* If during FUSE_LOOKUP the server returns the same inode number for the
  new file as for its parent directory, reject it.  Nothing good can
  come of this.

PR:		263662
Reported by:	Robert Morris <rtm@lcs.mit.edu>
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D35128
cgit
8b582b16 asomers May 12, 2022, 8:31 p.m.
MFC after:      2 weeks
Reviewed by:    pfg
cgit
bb35a4e1 glebius May 12, 2022, 8:22 p.m.
This change is also a preparation for further optimization to
allow locked return on success.

Reviewed by:		markj
Differential revision:	https://reviews.freebsd.org/D35182
cgit
08f17d14 glebius May 12, 2022, 8:22 p.m.
Assert that sockets are of the same type.  unp_connectat() already did
this check.  Add the check to uipc_connect2().

Reviewed by:		markj
Differential revision:	https://reviews.freebsd.org/D35181
cgit
43283184 glebius May 12, 2022, 8:22 p.m.
Since c67f3b8b78e the sockbuf mutexes belong to the containing socket,
and socket buffers just point to it.  In 74a68313b50 macros that access
this mutex directly were added.  Go over the core socket code and
eliminate code that reaches the mutex by dereferencing the sockbuf
compatibility pointer.

This change requires a KPI change, as some functions were given the
sockbuf pointer only without any hint if it is a receive or send buffer.

This change doesn't cover the whole kernel, many protocols still use
compatibility pointers internally.  However, it allows operation of a
protocol that doesn't use them.

Reviewed by:		markj
Differential revision:	https://reviews.freebsd.org/D35152
cgit
009e8f0a kp May 12, 2022, 7:50 p.m.
If we already had a pipe set in the actions struct we need to take care
to clear the flag if we're overwriting it with a queue.

This can happen if we've got Ethernet rules setting a dummynet pipe.
It does this indirectly, by adding the dummynet information to a pf_mtag
associated with the mbuf.

Sponsored by:	Rubicon Communications, LLC ("Netgate")
cgit
920c3410 kp May 12, 2022, 7:50 p.m.
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D35161
cgit
1977d9a3 kp May 12, 2022, 7:50 p.m.
Reviewed by:	glebius
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D35160
cgit