Commit Graph

274 Commits

Author SHA1 Message Date
Dmitry Chagin
d966efcc08 fusefs tests: Remove an unused variable.
Reviewed by:		asomers
Differential revision:	https://reviews.freebsd.org/D35185
MFC after:		2 weeks
2022-05-13 20:52:14 +03:00
Alan Somers
0bef4927ea fusefs: handle evil servers that return illegal inode numbers
* 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
2022-05-12 14:32:26 -06:00
Alan Somers
8b582b1640 fusefs: make the mknod.cc tests a bit more general.
MFC after:      2 weeks
Reviewed by:    pfg
2022-05-12 14:31:57 -06:00
Alan Somers
4ac4b12699 fusefs: annotate more file descriptor leaks in the tests
The fusefs tests intentionally leak file descriptors.  Annotate all of
the leakages in order to hopefully pacify Coverity.

Reported by:	Coverity (20 different CIDs)
MFC after:	2 weeks
Sponsored by:	Axcient
2022-05-05 09:06:04 -06:00
Alan Somers
2f6362484c fusefs: use the fsname mount option if set
The daemon can specify fsname=XXX in its mount options.  If so, the file
system should report f_mntfromname as XXX during statfs.  This will show
up in the output of commands like mount and df.

Submitted by:	Ali Abdallah <ali.abdallah@suse.com>
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D35090
2022-04-29 11:10:03 -06:00
Alan Somers
616eaa66aa fusefs: add a test for the subtype= option
At mount time server can set, for example, "subtype=xfs", so that
mount(8) will later show the mountpoint's file system as "fusefs.xfs".
fusefs has had this feature ever since the original GSoC commit in 2012,
but there's never been a test for it.

MFC after:	2 weeks
2022-04-29 07:59:29 -06:00
Alan Somers
45825a12f9 fusefs: fix FUSE_CREATE with file handles and fuse protocol < 7.9
Prior to fuse protocol version 7.9, the fuse_entry_out structure had a
smaller size.  But fuse_vnop_create did not take that into account when
working with servers that use older protocols.  The bug does not matter
for servers which don't use file handles or open flags (the only fields
affected).

PR:		263625
Submitted by:	Ali Abdallah <ali.abdallah@suse.com>
MFC after:	2 weeks
2022-04-28 15:13:09 -06:00
Alan Somers
3a1b3c6a1e fusefs: correctly handle servers that report too much data written
During a FUSE_WRITE, the kernel requests the server to write a certain
amount of data, and the server responds with the amount that it actually
did write.  It is obviously an error for the server to write more than
it was provided, and we always treated it as such, but there were two
problems:

* If the server responded with a huge amount, greater than INT_MAX, it
  would trigger an integer overflow which would cause a panic.

* When extending the file, we wrongly set the file's size before
  validing the amount written.

PR:		263263
Reported by:	Robert Morris <rtm@lcs.mit.edu>
MFC after:	2 weeks
Sponsored by:	Axcient
Reviewed by:	emaste
Differential Revision: https://reviews.freebsd.org/D34955
2022-04-18 18:59:10 -06:00
Alan Somers
155ac516c6 fusefs: validate servers' error values
Formerly fusefs would pass up the stack any error value returned by the
fuse server.  However, some values aren't valid for userland, but have
special meanings within the kernel.  One of these, EJUSTRETURN, could
cause a kernel page fault if the server returned it in response to
FUSE_LOOKUP.  Fix by validating all errors returned by the server.

Also, fix a data lifetime bug in the FUSE_DESTROY test.

PR:		263220
Reported by:	Robert Morris <rtm@lcs.mit.edu>
MFC after:	3 weeks
Sponsored by:	Axcient
Reviewed by:	emaste
Differential Revision: https://reviews.freebsd.org/D34931
2022-04-15 13:57:32 -06:00
Alan Somers
3227325366 fusefs: fix two bugs regarding VOP_RECLAIM of the root inode
* We never send FUSE_LOOKUP for the root inode, since its inode number
  is hard-coded to 1.  Therefore, we should not send FUSE_FORGET for it,
  lest the server see its lookup count fall below 0.

* During VOP_RECLAIM, if we are reclaiming the root inode, we must clear
  the file system's vroot pointer.  Otherwise it will be left pointing
  at a reclaimed vnode, which will cause future VOP_LOOKUP operations to
  fail.  Previously we only cleared that pointer during VFS_UMOUNT.  I
  don't know of any real-world way to trigger this bug.

MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D34753
2022-04-06 16:16:52 -06:00
Alan Somers
e8553be9bc fusefs: fix a cached attributes bug during directory rename
When renaming a directory into a different parent directory, invalidate
the cached attributes of the new parent.  Otherwise, stat will show the
wrong st_nlink value.

MFC after:	1 week
Reviewed by:	ngie
Differential Revision: https://reviews.freebsd.org/D34336
2022-02-24 14:07:25 -07:00
Alan Somers
0b6a34acda [skip ci] fusefs: delete a stray comment from 91972cfcdd
MFC after:	3 days
2022-02-12 09:27:56 -07:00
Dimitry Andric
c9cabf9aa6 Explicitly include semaphore.h for struct _sem in fusefs setattr test
In libc++'s __threading_support header the semaphore.h header was
implicitly included, but from version 14 onwards, this is no longer the
case, resulting in compile errors:

tests/sys/fs/fusefs/setattr.cc:740:8: error: variable has incomplete type 'sem_t' (aka '_sem')
        sem_t sem;
              ^
tests/sys/fs/fusefs/utils.hh:33:8: note: forward declaration of '_sem'
struct _sem;
       ^

MFC after:	3 days
2022-02-06 17:07:28 +01:00
Alan Somers
89d57b94d7 fusefs: implement VOP_DEALLOCATE
MFC after:	Never
Reviewed by:	khng
Differential Revision: https://reviews.freebsd.org/D33800
2022-01-18 21:13:02 -07:00
Alan Somers
398c88c758 fusefs: implement VOP_ALLOCATE
Now posix_fallocate will be correctly forwarded to fuse file system
servers, for those that support it.

MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D33389
2021-12-31 21:05:28 -07:00
Alan Somers
1613087a81 fusefs: fix .. lookups when the parent has been reclaimed.
By default, FUSE file systems are assumed not to support lookups for "."
and "..".  They must opt-in to that.  To cope with this limitation, the
fusefs kernel module caches every fuse vnode's parent's inode number,
and uses that during VOP_LOOKUP for "..".  But if the parent's vnode has
been reclaimed that won't be possible.  Previously we paniced in this
situation.  Now, we'll return ESTALE instead.  Or, if the file system
has opted into ".." lookups, we'll just do that instead.

This commit also fixes VOP_LOOKUP to respect the cache timeout for ".."
lookups, if the FUSE file system specified a finite timeout.

PR:		259974
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D33239
2021-12-31 20:38:27 -07:00
Alan Somers
8d99a6b91b fusefs: move common code from forget.cc to utils.cc
MFC after:	2 weeks
2021-12-31 20:38:20 -07:00
Alan Somers
19ab361045 fusefs: in the tests, always assume debug.try_reclaim_vnode is available
In an earlier version of the revision that created that sysctl (D20519)
the sysctl was gated by INVARIANTS, so the test had to check for it.
But in the committed version it is always available.

MFC after:	2 weeks
2021-12-31 18:04:52 -07:00
Alan Somers
5169832c96 fusefs: copy_file_range must update file timestamps
If FUSE_COPY_FILE_RANGE returns successfully, update the atime of the
source and the mtime and ctime of the destination.

MFC after:	2 weeks
Reviewers:	pfg
Differential Revision: https://reviews.freebsd.org/D33159
2021-12-31 17:43:57 -07:00
Alan Somers
13d593a5b0 Fix a race in fusefs that can corrupt a file's size.
VOPs like VOP_SETATTR can change a file's size, with the vnode
exclusively locked.  But VOPs like VOP_LOOKUP look up the file size from
the server without the vnode locked.  So a race is possible.  For
example:

1) One thread calls VOP_SETATTR to truncate a file.  It locks the vnode
   and sends FUSE_SETATTR to the server.
2) A second thread calls VOP_LOOKUP and fetches the file's attributes from
   the server.  Then it blocks trying to acquire the vnode lock.
3) FUSE_SETATTR returns and the first thread releases the vnode lock.
4) The second thread acquires the vnode lock and caches the file's
   attributes, which are now out-of-date.

Fix this race by recording a timestamp in the vnode of the last time
that its filesize was modified.  Check that timestamp during VOP_LOOKUP
and VFS_VGET.  If it's newer than the time at which FUSE_LOOKUP was
issued to the server, ignore the attributes returned by FUSE_LOOKUP.

PR:		259071
Reported by:	Agata <chogata@moosefs.pro>
Reviewed by:	pfg
MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D33158
2021-12-31 17:38:42 -07:00
Alan Somers
41ae9f9e64 fusefs: invalidate the cache during copy_file_range
FUSE_COPY_FILE_RANGE instructs the server to write data to a file.
fusefs must invalidate any cached data within the written range.

PR:		260242
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D33280
2021-12-06 21:41:50 -07:00
Alan Somers
25927e068f fusefs: correctly handle an inode that changes file types
Correctly handle the situation where a FUSE server unlinks a file, then
creates a new file of a different type but with the same inode number.
Previously fuse_vnop_lookup in this situation would return EAGAIN.  But
since it didn't call vgone(), the vnode couldn't be reused right away.
Fix this by immediately calling vgone() and reallocating a new vnode.

This problem can occur in three code paths, during VOP_LOOKUP,
VOP_SETATTR, or following FUSE_GETATTR, which usually happens during
VOP_GETATTR but can occur during other vops, too.  Note that the correct
response actually doesn't depend on whether the entry cache has expired.
In fact, during VOP_LOOKUP, we can't even tell.  Either it has expired
already, or else the vnode got reclaimed by vnlru.

Also, correct the error code during the VOP_SETATTR path.

PR:		258022
Reported by:	chogata@moosefs.pro
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D33283
2021-12-06 21:36:46 -07:00
Alan Somers
c2d342c509 fusefs: better debugging for FUSE_RENAME in the tests
MFC after:	2 weeks
2021-12-02 20:26:27 -07:00
Alan Somers
d109559ddb fusefs: fix 32-bit build of the tests after 91972cfcdd
MFC after:	2 weeks
MFC with:	91972cfcdd
2021-11-28 20:35:42 -07:00
Alan Somers
91972cfcdd fusefs: update atime on reads when using cached attributes
When using cached attributes, whether or not the data cache is enabled,
fusefs must update a file's atime whenever it reads from it, so long as
it wasn't mounted with -o noatime.  Update it in-kernel, and flush it to
the server on close or during the next setattr operation.

The downside is that close() will now frequently trigger a FUSE_SETATTR
upcall.  But if you care about performance, you should be using
-o noatime anyway.

MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D33145
2021-11-28 18:53:31 -07:00
Alan Somers
65d70b3bae fusefs: fix copy_file_range when extending a file
When copy_file_range extends a file, it must update the cached file
size.

MFC after:	2 weeks
Reviewed by:	rmacklem, pfg
Differential Revision: https://reviews.freebsd.org/D33151
2021-11-28 18:35:58 -07:00
Alan Somers
f44a448709 fusefs: fix intermittency in the dev_fuse_poll test
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.

MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D32142
2021-10-06 14:28:48 -06:00
Alan Somers
032a5bd55b fusefs: Fix a bug during VOP_STRATEGY when the server changes file size
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 <chogata@moosefs.pro>
Tested by:	Agata <chogata@moosefs.pro>
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D32332
2021-10-06 14:07:33 -06:00
Alan Somers
7430017b99 fusefs: fix a recurse-on-non-recursive lockmgr panic
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 <chogata@moosefs.pro>
Tested by:	Agata <chogata@moosefs.pro>
MFC after:	2 weeks
2021-10-06 14:07:33 -06:00
Alan Somers
7124d2bc3a fusefs: implement FUSE_NO_OPEN_SUPPORT and FUSE_NO_OPENDIR_SUPPORT
For file systems that allow it, fusefs will skip FUSE_OPEN,
FUSE_RELEASE, FUSE_OPENDIR, and FUSE_RELEASEDIR operations, a minor
optimization.

MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D32141
2021-09-26 21:57:29 -06:00
Konstantin Belousov
3fcbde5e88 tests/sys/fs/fusefs/read.cc: fix build on powerpc64
There sig_atomic_t is shorter than void *.
As result, it cannot keep pointer.

Assigning to void * is actually safe for us in a signal handler.

Reviewed by:	asomers
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Fixes:	4f917847c9
Differential revision:	https://reviews.freebsd.org/D32064
2021-09-23 03:51:10 +03:00
Alan Somers
4f917847c9 fusefs: don't panic if FUSE_GETATTR fails durint VOP_GETPAGES
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.

MFC after:	1 week
Sponsored by:	Axcient
Reviewed by: 	markj, kib
Differential Revision: https://reviews.freebsd.org/D31994
2021-09-21 14:01:06 -06:00
Dimitry Andric
5a3a8cb01a Silence more gtest warnings, now in fusefs tests
Follow-up d396c67f26 by also silencing warnings about deprecated
implicit copy constructors in the fusefs tests, which use googletest.

Fixes:		d396c67f26
MFC after:	3 days
2021-08-27 23:39:36 +02:00
Alan Somers
18b19f8c6e fusefs: correctly set lock owner during FUSE_SETLK
During FUSE_SETLK, the owner field should uniquely identify the calling
process.  The fusefs module now sets it to the process's pid.
Previously, it expected the calling process to set it directly, which
was wrong.

libfuse also apparently expects the owner field to be set during
FUSE_GETLK, though I'm not sure why.

PR:		256005
Reported by:	Agata <chogata@moosefs.pro>
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D30622
2021-06-25 20:40:08 -06:00
Alan Somers
5403f2c163 fusefs: ensure that FUSE ops' headers' unique values are actually unique
Every FUSE operation has a unique value in its header.  As the name
implies, these values are supposed to be unique among all outstanding
operations.  And since FUSE_INTERRUPT is asynchronous and racy, it is
desirable that the unique values be unique among all operations that are
"close in time".

Ensure that they are actually unique by incrementing them whenever we
reuse a fuse_dispatcher object, for example during fsync, write, and
listextattr.

PR:		244686
MFC after:	2 weeks
Reviewed by:	pfg
Differential Revision: https://reviews.freebsd.org/D30810
2021-06-19 14:45:29 -06:00
Alan Somers
77b040c993 fusefs: also debug INIT operations in the test suite
MFC after:	2 weeks
Reviewed by:	pfg
2021-06-19 14:45:21 -06:00
Alan Somers
7b8622fa22 fusefs: support EVFILT_WRITE on /dev/fuse
/dev/fuse is always ready for writing, so it's kind of dumb to poll it.
But some applications do it anyway.  Better to return ready than EINVAL.

MFC after:	2 weeks
Reviewed by:	emaste, pfg
Differential Revision: https://reviews.freebsd.org/D30784
2021-06-16 13:34:14 -06:00
Alan Somers
425bbe9e64 fusefs: reenable the WriteCluster.cluster_write_err test
The underlying panic was just fixed by
revision 27006229f7

PR:		238565
MFC after:	1 week
MFC with:	27006229f7
2021-05-30 16:51:56 -06:00
Alan Somers
929acdb19a fusefs: fix two bugs regarding fcntl file locks
1) F_SETLKW (blocking) operations would be sent to the FUSE server as
   F_SETLK (non-blocking).

2) Release operations, F_SETLK with lk_type = F_UNLCK, would simply
   return EINVAL.

PR:		253500
Reported by:	John Millikin <jmillikin@gmail.com>
MFC after:	2 weeks
2021-03-18 17:09:10 -06:00
Alan Somers
71befc3506 fusefs: set d_off during VOP_READDIR
This allows d_off to be used with lseek to position the file so that
getdirentries(2) will return the next entry.  It is not used by
readdir(3).

PR:		253411
Reported by:	John Millikin <jmillikin@gmail.com>
Reviewed by:	cem
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D28605
2021-02-12 21:50:52 -07:00
Alan Somers
92bbfe1f0d fusefs: implement FUSE_COPY_FILE_RANGE.
This updates the FUSE protocol to 7.28, though most of the new features
are optional and are not yet implemented.

MFC after:	2 weeks
Relnotes:	yes
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D27818
2021-01-01 10:18:23 -07:00
Alan Somers
ae39db7406 fusefs: fix an expectation in one of the tests
An order-of-operations problem caused an expectation intended for
FUSE_READ to instead match FUSE_ACCESS.  Surprisingly, only one test
case was affected.

MFC after:	2 weeks
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D27818
2021-01-01 10:18:22 -07:00
Cy Schubert
1d010cd31c Fix i386 build following 37df9d3bba.
MFC after:	2 weeks
X-MFC with:	37df9d3bba
2021-01-01 08:48:14 -08:00
Alan Somers
37df9d3bba fusefs: update FUSE protocol to 7.24 and implement FUSE_LSEEK
FUSE_LSEEK reports holes on fuse file systems, and is used for example
by bsdtar.

MFC after:	2 weeks
Relnotes:	yes
Reviewed by:	cem
Differential Revision: https://reviews.freebsd.org/D27804
2020-12-31 08:51:47 -07:00
Alan Somers
f928dbcb16 fusefs: fix the tests for a wider range of maxphys
maxphys is now a tunable, ever since r368124.  The default value is also
larger than it used to be.  That broke several fusefs tests that made
assumptions about maxphys.

* WriteCluster.clustering used the MAXPHYS compile-time constant.

* WriteBackAsync.direct_io_partially_overlaps_cached_block implicitly
  depended on the default value of maxphys.  Fix it by making the
  dependency explicit.

* Write.write_large implicitly assumed that maxphys would be no more
  than twice maxbcachebuf.  Fix it by explicitly setting m_max_write.

* WriteCluster.clustering and several others failed because the MockFS
  module did not work for max_write > 128KB (which most tests would set
  when maxphys > 256KB).  Limit max_write accordingly.  This is the same
  as fusefs-libs's behavior.

* Bmap's tests were originally written for MAXPHYS=128KB.  With larger
  values, the simulated file size was too small.

PR:		252096
Reviewed by:	emaste
Differential Revision:	https://reviews.freebsd.org/D27769
2020-12-28 18:56:17 +00:00
Alan Somers
d262168916 fusefs tests: quell Coverity "Argument cannot be negative" warnings
Must abort tests early if open(2) fails.

Reported by:	Coverity
Coverity CID:	1432810 and many others
Reviewed by:	kevans
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D26635
2020-10-02 17:06:05 +00:00
Kyle Evans
7cc42f6d25 Do a sweep and remove most WARNS=6 settings
Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.

Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.
2020-10-01 01:10:51 +00:00
Alan Somers
a62772a78e fusefs: fix mmap'd writes in direct_io mode
If a FUSE server returns FOPEN_DIRECT_IO in response to FUSE_OPEN, that
instructs the kernel to bypass the page cache for that file. This feature
is also known by libfuse's name: "direct_io".

However, when accessing a file via mmap, there is no possible way to bypass
the cache completely. This change fixes a deadlock that would happen when
an mmap'd write tried to invalidate a portion of the cache, wrongly assuming
that a write couldn't possibly come from cache if direct_io were set.

Arguably, we could instead disable mmap for files with FOPEN_DIRECT_IO set.
But allowing it is less likely to cause user complaints, and is more in
keeping with the spirit of open(2), where O_DIRECT instructs the kernel to
"reduce", not "eliminate" cache effects.

PR:		247276
Reported by:	trapexit@spawn.link
Reviewed by:	cem
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D26485
2020-09-24 16:27:53 +00:00
Alan Somers
8d2105da16 fusefs: fix the FUSE_FORGET unit test after r364064
Thanks to r364064, the name cache now returns a hit where previously it
would miss.  Adjust the expectations accordingly.

PR:		248583
Reported by:	lwhsu
MFC with:	r364064
2020-08-11 01:09:06 +00:00
Alan Somers
bfcb817bcd Fix issues with FUSE_ACCESS when default_permissions is disabled
This patch fixes two issues relating to FUSE_ACCESS when the
default_permissions mount option is disabled:

* VOP_ACCESS() calls with VADMIN set should never be sent to a fuse server
  in the form of FUSE_ACCESS operations. The FUSE protocol has no equivalent
  of VADMIN, so we must evaluate such things kernel-side, regardless of the
  default_permissions setting.

* The FUSE protocol only requires FUSE_ACCESS to be sent for two purposes:
  for the access(2) syscall and to check directory permissions for
  searchability during lookup. FreeBSD sends it much more frequently, due to
  differences between our VFS and Linux's, for which FUSE was designed. But
  this patch does eliminate several cases not required by the FUSE protocol:

  * for any FUSE_*XATTR operation
  * when creating a new file
  * when deleting a file
  * when setting timestamps, such as by utimensat(2).

* Additionally, when default_permissions is disabled, this patch removes one
  FUSE_GETATTR operation when deleting a file.

PR:		245689
Reported by:	MooseFS FreeBSD Team <freebsd@moosefs.pro>
Reviewed by:	cem
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D24777
2020-05-22 18:11:17 +00:00