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.
|r356828||mjg||Jan. 17, 2020, 2:39 p.m.||vfs: shorten lock hold time in vdbatch_process|
|r356827||bdrewery||Jan. 17, 2020, 2:29 p.m.||META_MODE: Allow 'make all install' to work with filemon.
Filemon will add the ability to ignore the cookie if the installed file is missing. Without filemon that's not possible though so if the cookie is present an the command unchanged then the install wouldn't run. Sponsored by: DellEMC MFC after: 2 weeksViewVC
|r356826||glebius||Jan. 17, 2020, 6:10 a.m.||Change argument order of epoch_call() to more natural, first function,
then its argument. Reviewed by: imp, cem, jhbViewVC
|r356822||jeff||Jan. 17, 2020, 3:44 a.m.||Fix a long standing bug that was made worse in r355765. When we are cowing a
page that was previously mapped read-only it exists in pmap until pmap_enter() returns. However, we held no reference to the original page after the copy was complete. This allowed vm_object_scan_all_shadowed() to collapse an object that still had pages mapped. To resolve this, add another page pointer to the faultstate so we can keep the page xbusy until we're done with pmap_enter(). Handle busy pages in scan_all_shadowed. This is already done in vm_object_collapse_scan(). Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D23155ViewVC
|r356821||imp||Jan. 17, 2020, 1:20 a.m.||Small tweak to the default behavior of shutdown -c
'shutdown -c' is supposed to power cycle the system rather than doing a normal reboot. However, when that fails, it halts the system. This is not quite right since the intent isn't to halt the system but to restart. Make the default init behavior be to restart the system. The halt(8) interface can be used if you'd like to powercycle or halt. MFC After: 1 week Differential Revision: https://reviews.freebsd.org/D23129ViewVC
|r356820||imp||Jan. 17, 2020, 1:16 a.m.||We only want to send the speedup to the lower layers when there's a shortage.
Only send a speedup when there's a shortage. While this is a little racy, lost races aren't a big deal for this function. If there's a shorage just popping up after we check these values, then we'll catch it next time. If there's a shortage that's just clearing up, we may do some work at the lower layers a little sooner than we otherwise would have. Sicne shortages are relatively rare events, both races are acceptable. Reviewed by: chs Differential Revision: https://reviews.freebsd.org/D23182ViewVC
|r356819||imp||Jan. 17, 2020, 1:16 a.m.||Use buf to send speedup
It turns out there's a problem with using g_io to send the speedup. It leads to a race when there's a resource shortage when a disk fails. Instead, send BIO_SPEEDUP via struct buf. This is pretty straight forward, except we need to transfer the bio_flags from b_ioflags for BIO_SPEEDUP commands in g_vfs_strategy. Reviewed by: kirk, chs Differential Revision: https://reviews.freebsd.org/D23117ViewVC
|r356818||imp||Jan. 17, 2020, 1:15 a.m.||Pass BIO_SPEEDUP through all the geom layers
While some geom layers pass unknown commands down, not all do. For the ones that don't, pass BIO_SPEEDUP down to the providers that constittue the geom, as applicable. No changes to vinum or virstor because I was unsure how to add this support, and I'm also unsure how to test these. gvinum doesn't implement BIO_FLUSH either, so it may just be poorly maintained. gvirstor is for testing and not supportig BIO_SPEEDUP is fine. Reviewed by: chs Differential Revision: https://reviews.freebsd.org/D23183ViewVC
|r356817||mjg||Jan. 16, 2020, 10:45 p.m.||unionfs: use MNTK_NOMSYNC|
|r356816||kp||Jan. 16, 2020, 10:08 p.m.||Fix pfdenied not returning any results|
|r356813||manu||Jan. 16, 2020, 9:50 p.m.||dwmmc: Remove max_hz from the softc
We never use it so directly set the value to the mmc host structure.ViewVC
|r356812||mjg||Jan. 16, 2020, 9:45 p.m.||vfs: increment numvnodes without the vnode list lock unless under pressure
The vnode list lock is only needed to reclaim free vnodes or kick the vnlru thread (or to block and not miss a wake up (but note the sleep has a timeout so this would not be a correctness issue)). Try to get away without the lock by just doing an atomic increment. The lock is contended e.g., during poudriere -j 104 where about half of all acquires come from vnode allocation code. Note the entire scheme needs a rewrite, the above just reduces it's SMP impact. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D23140ViewVC
|r356811||mjg||Jan. 16, 2020, 9:43 p.m.||vfs: refcator vnode allocation|
|r356810||cem||Jan. 16, 2020, 9:38 p.m.||random(6): Fix off-by-one
After r355693, random(6) -f sometimes fail to output all the lines of the input file. This is because the range from which random indices are chosen is too big, so occasionally the random selection doesn't correspond to any line and nothing gets printed. (Ed. note: Mea culpa. Working on r355693, I was confused by the sometime use of 1-indexing, sometimes 0-indexing in randomize_fd().) Submitted by: Ryan Moeller <ryan AT freqlabs.com> X-MFC-With: r355693 Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D23199ViewVC
|r356809||asomers||Jan. 16, 2020, 9:31 p.m.||setextattr: Increase stdin buffer size to 4096
Extended attribute values can potentially be quite large. One test for ZFS is supposed to set a 200MB xattr. However, the buffer size for reading values from stdin with setextattr -i is so small that the test times out waiting for tiny chunks of data to be buffered and appended to an sbuf. Increasing the buffer size should help alleviate some of the burden of reallocating larger sbufs when writing large extended attributes. Submitted by: Ryan Moeller <email@example.com> MFC after: 2 weeks Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D23211ViewVC