committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
NNN or rNNN filter by revision.
NNN-MMM or rNNN-rMMM filter by revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|r368014||bcr||Nov. 25, 2020, 10:21 a.m.||Drop superfluous "of" from the systat example.|
|r368011||kevans||Nov. 25, 2020, 3:14 a.m.||kern: cpuset: properly rebase when attaching to a jail
The current logic is a fine choice for a system administrator modifying process cpusets or a process creating a new cpuset(2), but not ideal for processes attaching to a jail. Currently, when a process attaches to a jail, it does exactly what any other process does and loses any mask it might have applied in the process of doing so because cpuset_setproc() is entirely based around the assumption that non-anonymous cpusets in the process can be replaced with the new parent set. This approach slightly improves the jail attach integration by modifying cpuset_setproc() callers to indicate if they should rebase their cpuset to the indicated set or not (i.e. cpuset_setproc_update_set). If we're rebasing and the process currently has a cpuset assigned that is not the containing jail's root set, then we will now create a new base set for it hanging off the jail's root with the existing mask applied instead of using the jail's root set as the new base set. Note that the common case will be that the process doesn't have a cpuset within the jail root, but the system root can freely assign a cpuset from a jail to a process outside of the jail with no restriction. We assume that that may have happened or that it could happen due to a race when we drop the proc lock, so we must recheck both within the loop to gather up sufficient freed cpusets and after the loop. To recap, here's how it worked before in all cases: 0 4 <-- jail 0 4 <-- jail / process | | 1 -> 1 | 3 <-- process Here's how it works now: 0 4 <-- jail 0 4 <-- jail | | | 1 -> 1 5 <-- process | 3 <-- process or 0 4 <-- jail 0 4 <-- jail / process | | 1 <-- process -> 1 More importantly, in both cases, the attaching process still retains the mask it had prior to attaching or the attach fails with EDEADLK if it's left with no CPUs to run on or the domain policy is incompatible. The author of this patch considers this almost a security feature, because a MAC policy could grant PRIV_JAIL_ATTACH to an unprivileged user that's restricted to some subset of available CPUs the ability to attach to a jail, which might lift the user's restrictions if they attach to a jail with a wider mask. In most cases, it's anticipated that admins will use this to be able to, for example, `cpuset -c -l 1 jail -c path=/ command=/long/running/cmd`, and avoid the need for contortions to spawn a command inside a jail with a more limited cpuset than the jail. Reviewed by: jamie MFC after: 1 month (maybe) Differential Revision: https://reviews.freebsd.org/D27298ViewVC
|r368010||kevans||Nov. 25, 2020, 2:12 a.m.||kern: cpuset: rename _cpuset_create() to cpuset_init()
cpuset_init() is better descriptor for what the function actually does. The name was previously taken by a sysinit that setup cpuset_zero's mask from all_cpus, it was removed in r331698 before stable/12 branched. A comment referencing the removed sysinit has now also been removed, since the setup previously done was moved into cpuset_thread0(). Suggested by: markj MFC after: 1 weekViewVC
|r368009||kevans||Nov. 25, 2020, 1:42 a.m.||kern: cpuset: allow cpuset_create() to take an allocated *setp
Currently, it must always allocate a new set to be used for passing to _cpuset_create, but it doesn't have to. This is purely kern_cpuset.c internal and it's sparsely used, so just change it to use *setp if it's not-NULL and modify the two consumers to pass in the address of a NULL cpuset. This paves the way for consumers that want the unr allocation without the possibility of sleeping as long as they've done their due diligence to ensure that the mask will properly apply atop the supplied parent (i.e. avoiding the free_unr() in the last failure path). Reviewed by: jamie, markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D27297ViewVC
|r368008||jhb||Nov. 25, 2020, 1:31 a.m.||Remove uses of CRIOGET in OCF tests after r368005.|
|r368007||jhb||Nov. 25, 2020, 1:09 a.m.||Remove a reference to CRIOGET missed in r368005.|
|r368006||kevans||Nov. 25, 2020, 1:08 a.m.||kern: never restart syscalls calling closefp(), e.g. close(2)
All paths leading into closefp() will either replace or remove the fd from the filedesc table, and closefp() will call fo_close methods that can and do currently sleep without regard for the possibility of an ERESTART. This can be dangerous in multithreaded applications as another thread could have opened another file in its place that is subsequently operated on upon restart. The following are seemingly the only ones that will pass back ERESTART in-tree: - sockets (SO_LINGER) - fusefs - nfsclient Reviewed by: jilles, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D27310ViewVC
|r368005||jhb||Nov. 25, 2020, 12:10 a.m.||Remove the cloned file descriptors for /dev/crypto.
Crypto file descriptors were added in the original OCF import as a way to provide per-open data (specifically the list of symmetric sessions). However, this gives a bit of a confusing API where one has to open /dev/crypto and then invoke an ioctl to obtain a second file descriptor. This also does not match the API used with /dev/crypto on other BSDs or with Linux's /dev/crypto driver. Character devices have gained support for per-open data via cdevpriv since OCF was imported, so use cdevpriv to simplify the userland API by permitting ioctls directly on /dev/crypto descriptors. To provide backwards compatibility, CRIOGET now opens another /dev/crypto descriptor via kern_openat() rather than dup'ing the existing file descriptor. This preserves prior semantics in case CRIOGET is invoked multiple times on a single file descriptor. Reviewed by: markj Relnotes: yes Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D27302ViewVC
|r368004||jhb||Nov. 24, 2020, 11:56 p.m.||Pull the check for VM ownership into ppt_find().
This reduces some code duplication. One behavior change is that ppt_assign_device() will now only succeed if the device is unowned. Previously, a device could be assigned to the same VM multiple times, but each time it was assigned, the device's state was reset. Reviewed by: markj, grehan MFC after: 2 weeks Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D27301ViewVC
|r368003||jhb||Nov. 24, 2020, 11:18 p.m.||Honor the disabled setting for MSI-X interrupts for passthrough devices.
Add a new ioctl to disable all MSI-X interrupts for a PCI passthrough device and invoke it if a write to the MSI-X capability registers disables MSI-X. This avoids leaving MSI-X interrupts enabled on the host if a guest device driver has disabled them (e.g. as part of detaching a guest device driver). This was found by Chelsio QA when testing that a Linux guest could switch from MSI-X to MSI interrupts when using the cxgb4vf driver. While here, explicitly fail requests to enable MSI on a passthrough device if MSI-X is enabled and vice versa. Reported by: Sony Arpita Das @ Chelsio Reviewed by: grehan, markj MFC after: 2 weeks Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D27212ViewVC
|r368002||jhb||Nov. 24, 2020, 10:52 p.m.||Correct entries for manpages removed in r359374.|
|r368001||mav||Nov. 24, 2020, 10:43 p.m.||Remove more legacy of parallel SCSI.|
|r368000||jkim||Nov. 24, 2020, 10:10 p.m.||Remove support for SSLv3 from fetch(3).|
|r367999||sjg||Nov. 24, 2020, 9:45 p.m.||Update dirdeps.mk et al to latest|
|r367998||jkim||Nov. 24, 2020, 9:28 p.m.||Port rtsx(4) driver for Realtek SD card reader from OpenBSD.
This driver provides support for Realtek PCI SD card readers. It attaches mmc(4) bus on card insertion and detaches it on card removal. It has been tested with RTS5209, RTS5227, RTS5229, RTS522A, RTS525A and RTL8411B. It should also work with RTS5249, RTL8402 and RTL8411. PR: 204521 Submitted by: Henri Hennebert (hlh at restart dot be) Reviewed by: imp, jkim Differential Revision: https://reviews.freebsd.org/D26435ViewVC