src/tests, branch releng/12.3

fusefs: fix intermittency in the dev_fuse_poll test

2021-10-12T05:57:38Z

The DevFusePoll::access/select test would occasionally segfault. The cause was a file descriptor that was shared between two threads. The first thread would kill the second and close the file descriptor. But it was possible that the second would read the file descriptor before it shut down. That did not cause problems for kqueue, poll, or blocking operation, but it triggered segfaults in select's macros. Differential Revision: https://reviews.freebsd.org/D32142 (cherry picked from commit f44a448709d3b77508fd59ee28201ae1666387c2)

fusefs: Fix a bug during VOP_STRATEGY when the server changes file size

2021-10-12T05:41:25Z

If the FUSE server tells the kernel that a file's size has changed, then the kernel must invalidate any portion of that file in cache. But the kernel can't do that during VOP_STRATEGY, because the file's buffers are already locked. Instead, proceed with the write. PR: 256937 Reported by: Agata Tested by: Agata Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D32332 (cherry picked from commit 032a5bd55b3a003d3560435422a95f27f91685fe)

fusefs: fix a recurse-on-non-recursive lockmgr panic

2021-10-12T05:13:58Z

fuse_vnop_bmap needs to know the file's size in order to calculate the optimum amount of readahead. If the file's size is unknown, it must ask the FUSE server. But if the file's data was previously cached and the server reports that its size has shrunk, fusefs must invalidate the cached data. That's not possible during VOP_BMAP because the buffer object is already locked. Fix the panic by not querying the FUSE server for the file's size during VOP_BMAP if we don't need it. That's also a a slight performance optimization. PR: 256937 Reported by: Agata Tested by: Agata (cherry picked from commit 7430017b9978cae054ed99e5160f739e5ca021d5)

fusefs: don't panic if FUSE_GETATTR fails durint VOP_GETPAGES

2021-10-07T19:51:35Z

During VOP_GETPAGES, fusefs needs to determine the file's length, which could require a FUSE_GETATTR operation. If that fails, it's better to SIGBUS than panic. Sponsored by: Axcient Reviewed by: markj, kib Differential Revision: https://reviews.freebsd.org/D31994 (cherry picked from commit 4f917847c9037d9b76de188c03e13b81224431b2) buffer pager: allow get_blksize method to return error Reported and reviewed by: asomers Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D31998 (cherry picked from commit 197a4f29f39e6ae6215a6dbd28ef449d305e6d49)

vinvalbuf: do not panic if we were unable to flush dirty buffers

2021-10-07T19:34:19Z

Return EBUSY instead and let caller to handle the issue. For vgone()/vnode reclamation, caller first does vinvalbuf(V_SAVE), which return EBUSY in case dirty buffers where not flushed. Then caller calls vinvalbuf(0) due to non-zero return, which gets rid of all dirty buffers without dependencies. PR: 238565 Reviewed by: asomers, mckusick Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D30555 (cherry picked from commit 27006229f7a40a18a61a0e8fd270bc583326b690) fusefs: reenable the WriteCluster.cluster_write_err test The underlying panic was just fixed by revision 27006229f7a40a18a61a0e8fd270bc583326b690 PR: 238565 (cherry picked from commit 425bbe9e64f7af6bdb30a099bd90a32885de1ab8)

gmultipath: make physpath distinct from the underlying providers'

2021-10-07T19:27:13Z

zfsd uses a device's physical path attribute to automatically replace a missing ZFS disk when a blank disk is inserted into the same physical slot. Currently gmultipath passes through its underlying providers' physical path attribute. That may cause zfsd to replace a missing gmultipath provider with a newly arrived, single-path disk. That would be bad. This commit fixes that problem by simply appending "/mp" to the underlying providers' physical path, in a manner similar to what geli already does. Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D29941 (cherry picked from commit 420dbe763f15b076751443edfeeb4f676deb3c44)

tests: kqueue: CLOCK_BOOTTIME is an alias of CLOCK_UPTIME

2021-10-06T14:50:32Z

Build-test should be done a buildenv from a newer branch. =-( We don't have this alias in stable/12, so just provide it locally in a way that won't break should 155f15118a77 find its way here. Reported by: Jenkins, naddy Fixes: f9765c9c1acb ("kqueue: don't arbitrarily restrict ...")

pf tests: Basic adaptive mode syncookie test

2021-10-06T08:46:58Z

MFC after: 1 week Sponsored by: Modirum MDPay Differential Revision: https://reviews.freebsd.org/D32139 (cherry picked from commit 2f20d80692ceb584842a7642562fc9f610a5b661)

pf tests: Basic syncookie test

2021-10-06T08:46:58Z

MFC after: 1 week Sponsored by: Modirum MDPay Differential Revision: https://reviews.freebsd.org/D32138 (cherry picked from commit dc0636636bb1937283d4f218732ac2357f4ec4f1)

kqueue: don't arbitrarily restrict long-past values for NOTE_ABSTIME

2021-10-06T07:07:07Z

NOTE_ABSTIME values are converted to values relative to boottime in filt_timervalidate(), and negative values are currently rejected. We don't reject times in the past in general, so clamp this up to 0 as needed such that the timer fires immediately rather than imposing what looks like an arbitrary restriction. Another possible scenario is that the system clock had to be adjusted by ~minutes or ~hours and we have less than that in terms of uptime, making a reasonable short-timeout suddenly invalid. Firing it is still a valid choice in this scenario so that applications can at least expect a consistent behavior. (cherry picked from commit 9c999a259f00b35f0467acd351fea9157ed7e1e4) (cherry picked from commit 2f4dbe279f6b5eb87ec493d96f6943ffdb603ba0)