svn commit: r364901 - head/stand/libsa
Author: imp Date: Fri Aug 28 05:40:02 2020 New Revision: 364901 URL: https://svnweb.freebsd.org/changeset/base/364901 Log: Declare time() Time is used and was accidentally brought in through header pollution. Declare it in stand.h directly instead. Modified: head/stand/libsa/stand.h Modified: head/stand/libsa/stand.h == --- head/stand/libsa/stand.hFri Aug 28 02:20:25 2020(r364900) +++ head/stand/libsa/stand.hFri Aug 28 05:40:02 2020(r364901) @@ -409,6 +409,11 @@ extern struct fs_ops *exclusive_file_system; extern struct devsw*devsw[]; /* + * Time routines + */ +time_t time(time_t *); + +/* * Expose byteorder(3) functions. */ #ifndef _BYTEORDER_PROTOTYPED ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364899 - head/release
Author: gjb
Date: Fri Aug 28 02:09:10 2020
New Revision: 364899
URL: https://svnweb.freebsd.org/changeset/base/364899
Log:
Add a new line to force a commit to verify if lwhsu did indeed
fix the jenkins build by adding git to the dependency list.
Sponsored by: Rubicon Communications, LLC (netgate.com)
Modified:
head/release/Makefile.inc1
Modified: head/release/Makefile.inc1
==
--- head/release/Makefile.inc1 Fri Aug 28 01:55:35 2020(r364898)
+++ head/release/Makefile.inc1 Fri Aug 28 02:09:10 2020(r364899)
@@ -29,3 +29,4 @@ GITREV!= ${GIT_CMD} -C ${.CURDIR} rev-parse --verify -
BUILDDATE!=date +%Y%m%d
.export BUILDDATE
.endif
+
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364091 - head/lib/libc/gen
{snip}
and for completeness sake, bsearch_b.c has the same issue but isn't
included in lib/Makefile; thus why it's not tripping the compiler error.
-adrian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364091 - head/lib/libc/gen
Hi!
This breaks when compiling FreeBSD-mips on GCC-9. :(
In file included from
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/gen/scandir.c:50,
from
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/gen/scandir_b.c:29:
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/include/block_abi.h:45:2:
error: anonymous struct declared inside parameter list will not be visible
outside of this definition or declarati
45 | struct {\
| ^~
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/gen/scandir.c:67:5:
note: in expansion of macro 'DECLARE_BLOCK'
67 | DECLARE_BLOCK(int, dcomp, const struct dirent **, const struct
dirent **))
| ^
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/include/block_abi.h:45:2:
error: anonymous struct declared inside parameter list will not be visible
outside of this definition or declarati
45 | struct {\
| ^~
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/gen/scandir.c:66:5:
note: in expansion of macro 'DECLARE_BLOCK'
66 | DECLARE_BLOCK(int, select, const struct dirent *),
| ^
cc1: all warnings being treated as errors
--- scandir_b.o ---
*** [scandir_b.o] Error code 1
-adrian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364896 - in head/sys/fs: nfs nfsclient nfsserver
Author: rmacklem
Date: Thu Aug 27 23:57:30 2020
New Revision: 364896
URL: https://svnweb.freebsd.org/changeset/base/364896
Log:
Add flags to enable NFS over TLS to the NFS client and server.
An Internet Draft titled "Towards Remote Procedure Call Encryption By Default"
(soon to be an RFC I think) describes how Sun RPC is to use TLS with NFS
as a specific application case.
Various commits prepared the NFS code to use KERN_TLS, mainly enabling use
of ext_pgs mbufs for large RPC messages.
r364475 added TLS support to the kernel RPC.
This commit (which is the final one for kernel changes required to do
NFS over TLS) adds support for three export flags:
MNT_EXTLS - Requires a TLS connection.
MNT_EXTLSCERT - Requires a TLS connection where the client presents a valid
X.509 certificate during TLS handshake.
MNT_EXTLSCERTUSER - Requires a TLS connection where the client presents a
valid X.509 certificate with "user@domain" in the otherName
field of the SubjectAltName during TLS handshake.
Without these export options, clients are permitted, but not required, to
use TLS.
For the client, a new nmount(2) option called "tls" makes the client do
a STARTTLS Null RPC and TLS handshake for all TCP connections used for the
mount. The CLSET_TLS client control option is used to indicate to the kernel
RPC
that this should be done.
Unless the above export flags or "tls" option is used, semantics should
not change for the NFS client nor server.
For NFS over TLS to work, the userspace daemons rpctlscd(8) { for client }
or rpctlssd(8) daemon { for server } must be running.
Modified:
head/sys/fs/nfs/nfs_commonkrpc.c
head/sys/fs/nfs/nfsdport.h
head/sys/fs/nfs/nfsport.h
head/sys/fs/nfsclient/nfs_clkrpc.c
head/sys/fs/nfsclient/nfs_clvfsops.c
head/sys/fs/nfsclient/nfsmount.h
head/sys/fs/nfsserver/nfs_nfsdkrpc.c
head/sys/fs/nfsserver/nfs_nfsdport.c
head/sys/fs/nfsserver/nfs_nfsdserv.c
head/sys/fs/nfsserver/nfs_nfsdsubs.c
Modified: head/sys/fs/nfs/nfs_commonkrpc.c
==
--- head/sys/fs/nfs/nfs_commonkrpc.cThu Aug 27 22:14:58 2020
(r364895)
+++ head/sys/fs/nfs/nfs_commonkrpc.cThu Aug 27 23:57:30 2020
(r364896)
@@ -281,6 +281,8 @@ newnfs_connect(struct nfsmount *nmp, struct nfssockreq
CLNT_CONTROL(client, CLSET_INTERRUPTIBLE, );
if ((nmp->nm_flag & NFSMNT_RESVPORT))
CLNT_CONTROL(client, CLSET_PRIVPORT, );
+ if (NFSHASTLS(nmp))
+ CLNT_CONTROL(client, CLSET_TLS, );
if (NFSHASSOFT(nmp)) {
if (nmp->nm_sotype == SOCK_DGRAM)
/*
Modified: head/sys/fs/nfs/nfsdport.h
==
--- head/sys/fs/nfs/nfsdport.h Thu Aug 27 22:14:58 2020(r364895)
+++ head/sys/fs/nfs/nfsdport.h Thu Aug 27 23:57:30 2020(r364896)
@@ -81,6 +81,9 @@ struct nfsexstuff {
#defineNFSVNO_EXPORTANON(e)((e)->nes_exflag &
MNT_EXPORTANON)
#defineNFSVNO_EXSTRICTACCESS(e)((e)->nes_exflag &
MNT_EXSTRICTACCESS)
#defineNFSVNO_EXV4ONLY(e) ((e)->nes_exflag & MNT_EXV4ONLY)
+#defineNFSVNO_EXTLS(e) ((e)->nes_exflag & MNT_EXTLS)
+#defineNFSVNO_EXTLSCERT(e) ((e)->nes_exflag &
MNT_EXTLSCERT)
+#defineNFSVNO_EXTLSCERTUSER(e) ((e)->nes_exflag &
MNT_EXTLSCERTUSER)
#defineNFSVNO_SETEXRDONLY(e) ((e)->nes_exflag =
(MNT_EXPORTED|MNT_EXRDONLY))
Modified: head/sys/fs/nfs/nfsport.h
==
--- head/sys/fs/nfs/nfsport.h Thu Aug 27 22:14:58 2020(r364895)
+++ head/sys/fs/nfs/nfsport.h Thu Aug 27 23:57:30 2020(r364896)
@@ -1055,6 +1055,7 @@ bool ncl_pager_setsize(struct vnode *vp, u_quad_t *nsi
#defineNFSHASOPENMODE(n) ((n)->nm_state & NFSSTA_OPENMODE)
#defineNFSHASONEOPENOWN(n) (((n)->nm_flag & NFSMNT_ONEOPENOWN) !=
0 && \
(n)->nm_minorvers > 0)
+#defineNFSHASTLS(n)(((n)->nm_newflag & NFSMNT_TLS) != 0)
/*
* Set boottime.
Modified: head/sys/fs/nfsclient/nfs_clkrpc.c
==
--- head/sys/fs/nfsclient/nfs_clkrpc.c Thu Aug 27 22:14:58 2020
(r364895)
+++ head/sys/fs/nfsclient/nfs_clkrpc.c Thu Aug 27 23:57:30 2020
(r364896)
@@ -37,12 +37,14 @@
__FBSDID("$FreeBSD$");
#include "opt_kgssapi.h"
+#include "opt_kern_tls.h"
#include
#include
-#include
#include
+#include
+#include
NFSDLOCKMUTEX;
@@ -67,6 +69,9 @@ nfscb_program(struct svc_req *rqst, SVCXPRT *xprt)
{
struct nfsrv_descript nd;
int cacherep,
svn commit: r364895 - head/sys/kern
Author: mckusick
Date: Thu Aug 27 22:14:58 2020
New Revision: 364895
URL: https://svnweb.freebsd.org/changeset/base/364895
Log:
Add a comment to clarify when and why cached names are deleted
during pathname lookup.
Reviewed by: kib
MFC after:3 days
Sponsored by: Netflix
Modified:
head/sys/kern/vfs_lookup.c
Modified: head/sys/kern/vfs_lookup.c
==
--- head/sys/kern/vfs_lookup.c Thu Aug 27 21:47:43 2020(r364894)
+++ head/sys/kern/vfs_lookup.c Thu Aug 27 22:14:58 2020(r364895)
@@ -785,6 +785,16 @@ lookup(struct nameidata *ndp)
wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT);
KASSERT(cnp->cn_nameiop == LOOKUP || wantparent,
("CREATE, DELETE, RENAME require LOCKPARENT or WANTPARENT."));
+ /*
+* When set to zero, docache causes the last component of the
+* pathname to be deleted from the cache and the full lookup
+* of the name to be done (via VOP_CACHEDLOOKUP()). Often
+* filesystems need some pre-computed values that are made
+* during the full lookup, for instance UFS sets dp->i_offset.
+*
+* The docache variable is set to zero when requested by the
+* NOCACHE flag and for all modifying operations except CREATE.
+*/
docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE;
if (cnp->cn_nameiop == DELETE ||
(wantparent && cnp->cn_nameiop != CREATE &&
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364891 - in head: . release release/scripts
On Thu, Aug 27, 2020 at 11:37:26PM +0200, Gordon Bergling wrote: > On Thu, Aug 27, 2020 at 09:19:16PM +, Glen Barber wrote: > > Author: gjb > > Date: Thu Aug 27 21:19:16 2020 > > New Revision: 364891 > > URL: https://svnweb.freebsd.org/changeset/base/364891 > > > > Log: > > Merge the projects/release-git branch to head. > > This allows building 13.x from Git instead of Subversion. > > > > No MFC to stable branches is planned at this time. [1] > > > > Discussed with: git working group [1] > > Sponsored by: Rubicon Communications, LLC (netgate.com) > > Thanks for accomplishing this! > Thank you. > Is there any difference on building -CURRENT using the github.com > mirror compared to FreeBSD's own git sources? > The only difference is the project branches are not in the FreeBSD git repository (as far as I know, that is the only thing). Otherwise, head builds just fine(tm) using either. Oh, and the github mirror still uses the 'master' branch, whereas the FreeBSD repo uses 'main'. I think that's the only noticeable thing. Glen signature.asc Description: PGP signature
svn commit: r364893 - head/stand/libsa/zfs
Author: mmacy
Date: Thu Aug 27 21:37:35 2020
New Revision: 364893
URL: https://svnweb.freebsd.org/changeset/base/364893
Log:
ZFS: remove duplicate "com.datto:encryption" from loader
Modified:
head/stand/libsa/zfs/zfsimpl.c
Modified: head/stand/libsa/zfs/zfsimpl.c
==
--- head/stand/libsa/zfs/zfsimpl.c Thu Aug 27 21:25:21 2020
(r364892)
+++ head/stand/libsa/zfs/zfsimpl.c Thu Aug 27 21:37:35 2020
(r364893)
@@ -128,7 +128,6 @@ static const char *features_for_read[] = {
"com.delphix:obsolete_counts",
"com.intel:allocation_classes",
"org.freebsd:zstd_compress",
- "com.datto:encryption",
NULL
};
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364891 - in head: . release release/scripts
On Thu, Aug 27, 2020 at 09:19:16PM +, Glen Barber wrote: > Author: gjb > Date: Thu Aug 27 21:19:16 2020 > New Revision: 364891 > URL: https://svnweb.freebsd.org/changeset/base/364891 > > Log: > Merge the projects/release-git branch to head. > This allows building 13.x from Git instead of Subversion. > > No MFC to stable branches is planned at this time. [1] > > Discussed with: git working group [1] > Sponsored by: Rubicon Communications, LLC (netgate.com) Thanks for accomplishing this! Is there any difference on building -CURRENT using the github.com mirror compared to FreeBSD's own git sources? --Gordon signature.asc Description: PGP signature
svn commit: r364891 - in head: . release release/scripts
Author: gjb
Date: Thu Aug 27 21:19:16 2020
New Revision: 364891
URL: https://svnweb.freebsd.org/changeset/base/364891
Log:
Merge the projects/release-git branch to head.
This allows building 13.x from Git instead of Subversion.
No MFC to stable branches is planned at this time. [1]
Discussed with: git working group [1]
Sponsored by: Rubicon Communications, LLC (netgate.com)
Added:
head/release/Makefile.inc1
- copied unchanged from r364890, projects/release-git/release/Makefile.inc1
Deleted:
head/release/scripts/relnotes-search.sh
Modified:
head/Makefile.inc1
head/release/Makefile
head/release/Makefile.azure
head/release/Makefile.ec2
head/release/Makefile.gce
head/release/Makefile.mirrors
head/release/Makefile.vagrant
head/release/release.conf.sample
head/release/release.sh
Directory Properties:
head/ (props changed)
head/cddl/ (props changed)
head/cddl/contrib/opensolaris/ (props changed)
head/contrib/bc/ (props changed)
head/contrib/byacc/ (props changed)
head/contrib/elftoolchain/ (props changed)
head/contrib/ipfilter/ (props changed)
head/contrib/llvm-project/ (props changed)
head/contrib/llvm-project/clang/ (props changed)
head/contrib/llvm-project/compiler-rt/ (props changed)
head/contrib/llvm-project/libcxx/ (props changed)
head/contrib/llvm-project/libunwind/ (props changed)
head/contrib/llvm-project/lld/ (props changed)
head/contrib/llvm-project/lldb/ (props changed)
head/contrib/llvm-project/llvm/ (props changed)
head/contrib/llvm-project/openmp/ (props changed)
head/contrib/lua/ (props changed)
head/contrib/mtree/ (props changed)
head/contrib/netbsd-tests/ (props changed)
head/contrib/openbsm/ (props changed)
head/contrib/sendmail/ (props changed)
head/contrib/sqlite3/ (props changed)
head/contrib/unbound/ (props changed)
head/crypto/openssh/ (props changed)
head/crypto/openssl/ (props changed)
head/sys/cddl/contrib/opensolaris/ (props changed)
head/sys/contrib/dev/acpica/ (props changed)
head/sys/contrib/ipfilter/ (props changed)
head/sys/gnu/dts/arm/ (props changed)
head/sys/gnu/dts/arm64/ (props changed)
head/sys/gnu/dts/include/ (props changed)
head/sys/gnu/dts/riscv/ (props changed)
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Thu Aug 27 21:09:17 2020(r364890)
+++ head/Makefile.inc1 Thu Aug 27 21:19:16 2020(r364891)
@@ -510,6 +510,15 @@ VCS_REVISION= $$(echo r${_VCS_REVISION})
.export VCS_REVISION
.endif
+.if !defined(GIT_CMD) || empty(GIT_CMD)
+. for _P in /usr/bin /usr/local/bin
+. if exists(${_P}/git)
+GIT_CMD= ${_P}/git
+. endif
+. endfor
+.export GIT_CMD
+.endif
+
.if !defined(OSRELDATE)
.if exists(/usr/include/osreldate.h)
OSRELDATE!=awk '/^\#define[[:space:]]*__FreeBSD_version/ { print $$3 }' \
Modified: head/release/Makefile
==
--- head/release/Makefile Thu Aug 27 21:09:17 2020(r364890)
+++ head/release/Makefile Thu Aug 27 21:19:16 2020(r364891)
@@ -90,15 +90,6 @@ EXTRA_PACKAGES+= src.txz
.endif
.if !defined(NODOC)
EXTRA_PACKAGES+= reldoc
-. if !defined(SVN) || empty(SVN)
-. for S in svn svnlite
-. for D in /usr/local/bin /usr/bin
-.if(exists(${D}/${S}))
-SVN?= ${D}/${S}
-.endif
-. endfor
-. endfor
-. endif
.endif
RELEASE_TARGETS= ftp
@@ -173,7 +164,6 @@ ports.txz:
reldoc:
cd ${DOCDIR}/en_US.ISO8859-1/htdocs/releases/${REVISION}R && \
env MAN4DIR=${WORLDDIR}/share/man/man4 \
- SVN=${SVN} \
_BRANCH=${BRANCH} \
${MAKE} all install clean "FORMATS=html txt" \
INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES DOCDIR=${.OBJDIR}/rdoc \
@@ -336,4 +326,5 @@ release-install:
cd ${DESTDIR} && sha512 ${OSRELEASE}* > ${DESTDIR}/CHECKSUM.SHA512
cd ${DESTDIR} && sha256 ${OSRELEASE}* > ${DESTDIR}/CHECKSUM.SHA256
+.include "${.CURDIR}/Makefile.inc1"
.include "${.CURDIR}/Makefile.vm"
Modified: head/release/Makefile.azure
==
--- head/release/Makefile.azure Thu Aug 27 21:09:17 2020(r364890)
+++ head/release/Makefile.azure Thu Aug 27 21:19:16 2020(r364891)
@@ -17,7 +17,7 @@ AZURE${VAR}!= grep -E ^AZURE${VAR} ${AZURE_UPLOAD_CONF
.endif
.if ${BRANCH} == "STABLE" || ${BRANCH} == "CURRENT" || ${BRANCH} ==
"PRERELEASE"
-SNAPSHOT_DATE!=date +-%Y-%m-%d
+SNAPSHOT_DATE!=date +-${BUILDDATE}
.endif
AZURE_TARGET:= ${OSRELEASE}${SNAPSHOT_DATE}.vhd
Modified: head/release/Makefile.ec2
==
--- head/release/Makefile.ec2 Thu Aug 27 21:09:17 2020(r364890)
+++ head/release/Makefile.ec2 Thu Aug 27
Re: svn commit: r364822 - in head/crypto/openssl/crypto: aes/asm bn/asm chacha/asm ec/asm modes/asm poly1305/asm sha/asm
On 8/27/20 1:28 PM, Benjamin Kaduk wrote: > On Thu, Aug 27, 2020 at 1:25 PM John Baldwin wrote: > >> On 8/26/20 9:55 AM, Jung-uk Kim wrote: >>> Author: jkim >>> Date: Wed Aug 26 16:55:28 2020 >>> New Revision: 364822 >>> URL: https://svnweb.freebsd.org/changeset/base/364822 >>> >>> Log: >>> Fix Clang version detection. >>> >>> We prepend "FreeBSD" to Clang version string. This broke compiler >> test for >>> AVX instruction support. >> >> Have you opened a PR upstream to fix this? They should be willing to >> accept it since it probably affects clang on OS X as well? >> >> > https://github.com/openssl/openssl/pull/12725 should land in a few hours. Yes, mail failure on my part as I missed another place where I'd already asked this (and subsequently forgot :( ). -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364822 - in head/crypto/openssl/crypto: aes/asm bn/asm chacha/asm ec/asm modes/asm poly1305/asm sha/asm
On Thu, Aug 27, 2020 at 1:25 PM John Baldwin wrote: > On 8/26/20 9:55 AM, Jung-uk Kim wrote: > > Author: jkim > > Date: Wed Aug 26 16:55:28 2020 > > New Revision: 364822 > > URL: https://svnweb.freebsd.org/changeset/base/364822 > > > > Log: > > Fix Clang version detection. > > > > We prepend "FreeBSD" to Clang version string. This broke compiler > test for > > AVX instruction support. > > Have you opened a PR upstream to fix this? They should be willing to > accept it since it probably affects clang on OS X as well? > > https://github.com/openssl/openssl/pull/12725 should land in a few hours. -Ben ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364822 - in head/crypto/openssl/crypto: aes/asm bn/asm chacha/asm ec/asm modes/asm poly1305/asm sha/asm
On 8/26/20 9:55 AM, Jung-uk Kim wrote: > Author: jkim > Date: Wed Aug 26 16:55:28 2020 > New Revision: 364822 > URL: https://svnweb.freebsd.org/changeset/base/364822 > > Log: > Fix Clang version detection. > > We prepend "FreeBSD" to Clang version string. This broke compiler test for > AVX instruction support. Have you opened a PR upstream to fix this? They should be willing to accept it since it probably affects clang on OS X as well? -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
In message , Andriy Gapon wri tes: > On 27/08/2020 19:51, Brandon Bergren wrote: > > FWIW, on powerpc64, using /etc/zfs/zpool.cache is great because it avoids t > he problem of having to unmount /boot (which is an msdos filesystem because p > eitiboot doesn't understand ufs or zfs) to update the copy of zpool.cache tha > t is on the root filesystem in /boot instead of only changing the one in the > runtime /boot (which was mounted on top, and is never useful because it's not > mounted at the time that zpool.cache is actually needed to import pools.) > > > > In any case, the correct way on ZFS to control where the cachefile is writt > en is to set the cachefile property on the zpool to the specific path. The co > rrect behavior regarding boot time auto import of pools is to honor that prop > erty as found on the pool the boot filesystem was on, so that other pools sha > ring the same cachefile path will be imported. Multiple cache files and pools > not actually listed in a cachefile are valid scenarios for pools. > > > Just want to express my complete agreement. Agreed with the above, however: I still think that using a zpool import in rc.d is a regression. I understand why the OpenZFS folks did what they did. Linux with it's filesystem agnostic grub and initramfs monstrosity requires that they externalize this. I'm not happy about the regression but understand why they did it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 27/08/2020 19:51, Brandon Bergren wrote: > FWIW, on powerpc64, using /etc/zfs/zpool.cache is great because it avoids the > problem of having to unmount /boot (which is an msdos filesystem because > peitiboot doesn't understand ufs or zfs) to update the copy of zpool.cache > that is on the root filesystem in /boot instead of only changing the one in > the runtime /boot (which was mounted on top, and is never useful because it's > not mounted at the time that zpool.cache is actually needed to import pools.) > > In any case, the correct way on ZFS to control where the cachefile is written > is to set the cachefile property on the zpool to the specific path. The > correct behavior regarding boot time auto import of pools is to honor that > property as found on the pool the boot filesystem was on, so that other pools > sharing the same cachefile path will be imported. Multiple cache files and > pools not actually listed in a cachefile are valid scenarios for pools. Just want to express my complete agreement. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364877 - head/sys/cam
Author: imp
Date: Thu Aug 27 17:46:13 2020
New Revision: 364877
URL: https://svnweb.freebsd.org/changeset/base/364877
Log:
Fix tiny style nit.
Modified:
head/sys/cam/cam_xpt_internal.h
Modified: head/sys/cam/cam_xpt_internal.h
==
--- head/sys/cam/cam_xpt_internal.h Thu Aug 27 17:36:06 2020
(r364876)
+++ head/sys/cam/cam_xpt_internal.h Thu Aug 27 17:46:13 2020
(r364877)
@@ -107,7 +107,7 @@ struct cam_ed {
struct cam_ccbq ccbq; /* Queue of pending ccbs */
struct async_list asyncs; /* Async callback info for this B/T/L */
struct periph_list periphs;/* All attached devices */
- u_int generation; /* Generation number */
+ u_intgeneration;/* Generation number */
void *quirk;/* Oddities about this device */
u_intmaxtags;
u_intmintags;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364850 - head/usr.sbin/jail
On Wed, Aug 26, 2020 at 7:17 PM Jamie Gritton wrote: > > Author: jamie > Date: Thu Aug 27 00:17:17 2020 > New Revision: 364850 > URL: https://svnweb.freebsd.org/changeset/base/364850 > > Log: > Don't allow jail.conf variables to have the same names as jail parameters. > It was already not allowed in many cases, but crashed instead of giving an > error. > > PR: 248444 > Thanks for the quick backout and fix! ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364876 - head/sys/kern
Author: markj
Date: Thu Aug 27 17:36:06 2020
New Revision: 364876
URL: https://svnweb.freebsd.org/changeset/base/364876
Log:
Fix writing of the final block of encrypted, compressed kernel dumps.
Previously any residual data in the final block of a compressed kernel
dump would be written unencrypted. Note, such a configuration already
does not work properly when using AES-CBC since the compressed data is
typically not a multiple of the AES block length in size and EKCD does
not implement any padding scheme. However, EKCD more recently gained
support for using the ChaCha20 cipher, which being a stream cipher does
not have this problem.
Submitted by: sig...@gmail.com
Reviewed by: cem
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D26188
Modified:
head/sys/kern/kern_shutdown.c
Modified: head/sys/kern/kern_shutdown.c
==
--- head/sys/kern/kern_shutdown.c Thu Aug 27 17:30:57 2020
(r364875)
+++ head/sys/kern/kern_shutdown.c Thu Aug 27 17:36:06 2020
(r364876)
@@ -1464,6 +1464,7 @@ kerneldumpcomp_write_cb(void *base, size_t length, off
}
resid = length - rlength;
memmove(di->blockbuf, (uint8_t *)base + rlength, resid);
+ bzero((uint8_t *)di->blockbuf + resid, di->blocksize - resid);
di->kdcomp->kdc_resid = resid;
return (EAGAIN);
}
@@ -1680,9 +1681,10 @@ dump_finish(struct dumperinfo *di, struct kerneldumphe
error = compressor_flush(di->kdcomp->kdc_stream);
if (error == EAGAIN) {
/* We have residual data in di->blockbuf. */
- error = dump_write(di, di->blockbuf, 0, di->dumpoff,
- di->blocksize);
- di->dumpoff += di->kdcomp->kdc_resid;
+ error = _dump_append(di, di->blockbuf, 0,
di->blocksize);
+ if (error == 0)
+ /* Compensate for _dump_append()'s adjustment.
*/
+ di->dumpoff -= di->blocksize -
di->kdcomp->kdc_resid;
di->kdcomp->kdc_resid = 0;
}
if (error != 0)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364875 - head
Author: imp Date: Thu Aug 27 17:30:57 2020 New Revision: 364875 URL: https://svnweb.freebsd.org/changeset/base/364875 Log: Add note about NO_CLEAN build. NO_CLEAN doesn't quite work for some scenarios when rebuilding older kernels, but the kernels build w/o NO_CLEAN. Modified: head/UPDATING Modified: head/UPDATING == --- head/UPDATING Thu Aug 27 17:04:55 2020(r364874) +++ head/UPDATING Thu Aug 27 17:30:57 2020(r364875) @@ -32,6 +32,10 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: 'zpool upgrade' for the next few weeks. The change should be transparent unless you want to use new features. + Not all "NO_CLEAN" build scenarios work across these changes. Many + scenarios have been tested and fixed, but rebuilding kernels without + rebuilding world may fail. + 20200824: The resume code now notifies devd with the 'kernel' system rather than the old 'kern' subsystem to be consistent with ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364874 - head/usr.sbin/jail
Author: jamie
Date: Thu Aug 27 17:04:55 2020
New Revision: 364874
URL: https://svnweb.freebsd.org/changeset/base/364874
Log:
Disregard jails in jail.conf that have bad parameters (parameter/variable
clash, or redefining name/jid). The current behvaior, of merely warning
and moving on, can lead to unexpected behavior when a jail is created
without the offending parameter defined at all.
Modified:
head/usr.sbin/jail/config.c
Modified: head/usr.sbin/jail/config.c
==
--- head/usr.sbin/jail/config.c Thu Aug 27 16:36:07 2020(r364873)
+++ head/usr.sbin/jail/config.c Thu Aug 27 17:04:55 2020(r364874)
@@ -369,11 +369,13 @@ add_param(struct cfjail *j, const struct cfparam *p, e
if ((flags ^ dp->flags) & PF_VAR) {
jail_warnx(j, "variable \"$%s\" cannot have the same "
"name as a parameter.", name);
+ j->flags |= JF_FAILED;
return;
}
if (dp->flags & PF_IMMUTABLE) {
jail_warnx(j, "cannot redefine parameter \"%s\".",
dp->name);
+ j->flags |= JF_FAILED;
return;
}
if (strcmp(dp->name, name)) {
@@ -405,6 +407,7 @@ add_param(struct cfjail *j, const struct cfparam *p, e
"cannot have the same "
"name as a parameter.",
name);
+ j->flags |= JF_FAILED;
return;
}
j->intparams[ipnum] = np;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020, at 11:19 AM, Kyle Evans wrote: > On Thu, Aug 27, 2020 at 10:59 AM Andriy Gapon wrote: > > > > On 2020-08-27 17:06, Kyle Evans wrote: > > > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: > > >> > > >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert > > >> wrote: > > >>> > > >>> What would you suggest in this case, where /etc/zfs/zpool.cache is newer > > >>> than /boot/zfs/zpool.cache? > > >>> > > >>> slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache > > >>> -rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache > > >>> -rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache > > >>> slippy$ > > >>> > > >>> Something like, for I in $(ls -t /etc/zfs/zpool.cache > > >>> /boot/zfs/zpool.cache) with the break? > > >>> > > >> > > >> /etc/zfs/zpool.cache is the new location and should generally be > > >> favored if it exists, I reckon. > > > > > > I retract the above. :-) ls -t makes sense. > > > > > > > I actually was about to agree with your first suggestion. > > > > I think it's the correct long-term solution, but it kind of depends on > what we're thinking now- if we expect one might test-boot a disk on an > older FreeBSD/ZFS that's still using /boot, there's a chance it will > contain the more recent data. > FWIW, on powerpc64, using /etc/zfs/zpool.cache is great because it avoids the problem of having to unmount /boot (which is an msdos filesystem because peitiboot doesn't understand ufs or zfs) to update the copy of zpool.cache that is on the root filesystem in /boot instead of only changing the one in the runtime /boot (which was mounted on top, and is never useful because it's not mounted at the time that zpool.cache is actually needed to import pools.) In any case, the correct way on ZFS to control where the cachefile is written is to set the cachefile property on the zpool to the specific path. The correct behavior regarding boot time auto import of pools is to honor that property as found on the pool the boot filesystem was on, so that other pools sharing the same cachefile path will be imported. Multiple cache files and pools not actually listed in a cachefile are valid scenarios for pools. -- Brandon Bergren bdra...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364873 - head/sys/dev/sound/pci
Author: markj
Date: Thu Aug 27 16:36:07 2020
New Revision: 364873
URL: https://svnweb.freebsd.org/changeset/base/364873
Log:
snd_ich(4): Handle errors from ich_init() properly during resume.
ich_init() returns an errno value or 0, but ich_pci_resume() was
comparing the return value with -1 to determine whether an error had
occurred.
PR: 248941
Submitted by: Tong Zhang
MFC after:1 week
Modified:
head/sys/dev/sound/pci/ich.c
Modified: head/sys/dev/sound/pci/ich.c
==
--- head/sys/dev/sound/pci/ich.cThu Aug 27 16:34:33 2020
(r364872)
+++ head/sys/dev/sound/pci/ich.cThu Aug 27 16:36:07 2020
(r364873)
@@ -1190,16 +1190,17 @@ static int
ich_pci_resume(device_t dev)
{
struct sc_info *sc;
- int i;
+ int err, i;
sc = pcm_getdevinfo(dev);
ICH_LOCK(sc);
/* Reinit audio device */
- if (ich_init(sc) == -1) {
+ err = ich_init(sc);
+ if (err != 0) {
device_printf(dev, "unable to reinitialize the card\n");
ICH_UNLOCK(sc);
- return (ENXIO);
+ return (err);
}
/* Reinit mixer */
ich_pci_codec_reset(sc);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364872 - head/sys/dev/fdc
Author: markj
Date: Thu Aug 27 16:34:33 2020
New Revision: 364872
URL: https://svnweb.freebsd.org/changeset/base/364872
Log:
fdc(4): Handle errors from fdc_in() properly.
fdc_in() returns only 0 and 1, some callers were checking incorrectly
for failure.
PR: 248940
Submitted by: Tong Zhang
MFC after:1 week
Modified:
head/sys/dev/fdc/fdc.c
Modified: head/sys/dev/fdc/fdc.c
==
--- head/sys/dev/fdc/fdc.c Thu Aug 27 16:34:20 2020(r364871)
+++ head/sys/dev/fdc/fdc.c Thu Aug 27 16:34:33 2020(r364872)
@@ -492,7 +492,7 @@ fdc_cmd(struct fdc_data *fdc, int n_out, ...)
n_in = va_arg(ap, int);
for (n = 0; n < n_in; n++) {
int *ptr = va_arg(ap, int *);
- if (fdc_in(fdc, ptr) < 0) {
+ if (fdc_in(fdc, ptr) != 0) {
char msg[50];
snprintf(msg, sizeof(msg),
"cmd %02x failed at in byte %d of %d\n",
@@ -587,7 +587,7 @@ fdc_sense_int(struct fdc_data *fdc, int *st0p, int *cy
return (FD_NOT_VALID);
}
- if (fdc_in(fdc, ) < 0)
+ if (fdc_in(fdc, ) != 0)
return fdc_err(fdc, "can't get cyl num\n");
if (cylp)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364871 - head/sys/dev/asmc
Author: markj
Date: Thu Aug 27 16:34:20 2020
New Revision: 364871
URL: https://svnweb.freebsd.org/changeset/base/364871
Log:
asmc(4): Handle errors from asmc_key_read() properly.
asmc_key_read() returns only 0 and 1, some callers were checking
incorrectly for failure.
PR: 248939
Submitted by: Tong Zhang
MFC after:1 week
Modified:
head/sys/dev/asmc/asmc.c
Modified: head/sys/dev/asmc/asmc.c
==
--- head/sys/dev/asmc/asmc.cThu Aug 27 14:51:44 2020(r364870)
+++ head/sys/dev/asmc/asmc.cThu Aug 27 16:34:20 2020(r364871)
@@ -1073,7 +1073,7 @@ asmc_fan_count(device_t dev)
{
uint8_t buf[1];
- if (asmc_key_read(dev, ASMC_KEY_FANCOUNT, buf, sizeof buf) < 0)
+ if (asmc_key_read(dev, ASMC_KEY_FANCOUNT, buf, sizeof buf) != 0)
return (-1);
return (buf[0]);
@@ -1087,7 +1087,7 @@ asmc_fan_getvalue(device_t dev, const char *key, int f
char fankey[5];
snprintf(fankey, sizeof(fankey), key, fan);
- if (asmc_key_read(dev, fankey, buf, sizeof buf) < 0)
+ if (asmc_key_read(dev, fankey, buf, sizeof buf) != 0)
return (-1);
speed = (buf[0] << 6) | (buf[1] >> 2);
@@ -1101,7 +1101,7 @@ asmc_fan_getstring(device_t dev, const char *key, int
char* desc;
snprintf(fankey, sizeof(fankey), key, fan);
- if (asmc_key_read(dev, fankey, buf, buflen) < 0)
+ if (asmc_key_read(dev, fankey, buf, buflen) != 0)
return (NULL);
desc = buf+4;
@@ -1240,7 +1240,7 @@ asmc_temp_getvalue(device_t dev, const char *key)
/*
* Check for invalid temperatures.
*/
- if (asmc_key_read(dev, key, buf, sizeof buf) < 0)
+ if (asmc_key_read(dev, key, buf, sizeof buf) != 0)
return (-1);
return (buf[0]);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020 at 10:59 AM Andriy Gapon wrote: > > On 2020-08-27 17:06, Kyle Evans wrote: > > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: > >> > >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert > >> wrote: > >>> > >>> What would you suggest in this case, where /etc/zfs/zpool.cache is newer > >>> than /boot/zfs/zpool.cache? > >>> > >>> slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache > >>> -rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache > >>> -rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache > >>> slippy$ > >>> > >>> Something like, for I in $(ls -t /etc/zfs/zpool.cache > >>> /boot/zfs/zpool.cache) with the break? > >>> > >> > >> /etc/zfs/zpool.cache is the new location and should generally be > >> favored if it exists, I reckon. > > > > I retract the above. :-) ls -t makes sense. > > > > I actually was about to agree with your first suggestion. > I think it's the correct long-term solution, but it kind of depends on what we're thinking now- if we expect one might test-boot a disk on an older FreeBSD/ZFS that's still using /boot, there's a chance it will contain the more recent data. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 2020-08-27 16:54, Cy Schubert wrote: > In message <202008271350.07rdogqn055...@slippy.cwsent.com>, Cy Schubert > writes: >> In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon >> wri >> tes: >>> On 26/08/2020 16:13, Cy Schubert wrote: Author: cy Date: Wed Aug 26 13:13:57 2020 New Revision: 364817 URL: https://svnweb.freebsd.org/changeset/base/364817 Log: As of r364746 (OpenZFS import) existing ZPOOLs are not imported prior to zvol and mountcritlocal resulting in ZVOLs (swap and >>> >>> I probably missed some discussion, so I am curious why that is. >> >> This is because r364746 added the code below to rc.d/zfs and by then it was >> too late. I simply moved it to a new file that allowed rc.d/zvol and >> rc.d/mountcritlocal with legacy mounts to work again. This was copied from >> rc.d/zfs, which was added by r364746. There was no need for a zpool import >> under the previous version of ZFS, whereas it appears that OpenZFS requires >> it. > > Let me add, one could say this is a regression. Yes, I was actually curious about this change in ZFS driver behavior. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 2020-08-27 17:06, Kyle Evans wrote: > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: >> >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert >> wrote: >>> >>> What would you suggest in this case, where /etc/zfs/zpool.cache is newer >>> than /boot/zfs/zpool.cache? >>> >>> slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache >>> -rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache >>> -rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache >>> slippy$ >>> >>> Something like, for I in $(ls -t /etc/zfs/zpool.cache >>> /boot/zfs/zpool.cache) with the break? >>> >> >> /etc/zfs/zpool.cache is the new location and should generally be >> favored if it exists, I reckon. > > I retract the above. :-) ls -t makes sense. > I actually was about to agree with your first suggestion. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364867 - head/libexec/rc/rc.d
Author: cy
Date: Thu Aug 27 14:33:46 2020
New Revision: 364867
URL: https://svnweb.freebsd.org/changeset/base/364867
Log:
/etc/zfs/zpool.cache is the preferred (and new) location of zpool.cache.
Check for it first. Only use /boot/zfs/zpool.cache if the /etc/zfs
version is not found and good.
Reported by: avg
Suggested by: avg, kevans
Modified:
head/libexec/rc/rc.d/zpool
Modified: head/libexec/rc/rc.d/zpool
==
--- head/libexec/rc/rc.d/zpool Thu Aug 27 14:29:06 2020(r364866)
+++ head/libexec/rc/rc.d/zpool Thu Aug 27 14:33:46 2020(r364867)
@@ -20,9 +20,9 @@ zpool_start()
{
local cachefile
- for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
+ for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
if [ -r $cachefile ]; then
- zpool import -c $cachefile -a -N
+ zpool import -c $cachefile -a -N && break
fi
done
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: > > On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert wrote: > > > > What would you suggest in this case, where /etc/zfs/zpool.cache is newer > > than /boot/zfs/zpool.cache? > > > > slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache > > -rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache > > -rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache > > slippy$ > > > > Something like, for I in $(ls -t /etc/zfs/zpool.cache > > /boot/zfs/zpool.cache) with the break? > > > > /etc/zfs/zpool.cache is the new location and should generally be > favored if it exists, I reckon. I retract the above. :-) ls -t makes sense. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert wrote: > > What would you suggest in this case, where /etc/zfs/zpool.cache is newer > than /boot/zfs/zpool.cache? > > slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache > -rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache > -rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache > slippy$ > > Something like, for I in $(ls -t /etc/zfs/zpool.cache > /boot/zfs/zpool.cache) with the break? > /etc/zfs/zpool.cache is the new location and should generally be favored if it exists, I reckon. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
What would you suggest in this case, where /etc/zfs/zpool.cache is newer
than /boot/zfs/zpool.cache?
slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache
-rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache
slippy$
Something like, for I in $(ls -t /etc/zfs/zpool.cache
/boot/zfs/zpool.cache) with the break?
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
In message <202008271354.07rdstew084...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <202008271350.07rdogqn055...@slippy.cwsent.com>, Cy Schubert
> writes:
> > In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon
>
> > wri
> > tes:
> > > On 26/08/2020 16:13, Cy Schubert wrote:
> > > > Author: cy
> > > > Date: Wed Aug 26 13:13:57 2020
> > > > New Revision: 364817
> > > > URL: https://svnweb.freebsd.org/changeset/base/364817
> > > >
> > > > Log:
> > > > As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> > > > prior to zvol and mountcritlocal resulting in ZVOLs (swap and
> > >
> > > I probably missed some discussion, so I am curious why that is.
> >
> > This is because r364746 added the code below to rc.d/zfs and by then it was
>
> > too late. I simply moved it to a new file that allowed rc.d/zvol and
> > rc.d/mountcritlocal with legacy mounts to work again. This was copied from
> > rc.d/zfs, which was added by r364746. There was no need for a zpool import
> > under the previous version of ZFS, whereas it appears that OpenZFS requires
>
> > it.
>
> Let me add, one could say this is a regression.
>
> >
> > >
> > > > virtual machine UFS filesystems) being unavailable, leading to
> > > > boot failures.
> > > > We move the zpool import from zfs to a new zpool script, with the
> > > > -N option to avoid mounting datasets while making the ZPOOL's
> > > > datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> > > > available for subsequent use for swap (in the zvol rc sript) or
> > > > for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
> > > >
> > > > Reviewed by: freqlabs (previous version)
> > > > Differential Revision:https://reviews.freebsd.org/D26185
> > > >
> > > > Added:
> > > > head/libexec/rc/rc.d/zpool (contents, props changed)
> > > [snip]
> > > > +zpool_start()
> > > > +{
> > > > + local cachefile
> > > > +
> > > > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > > > + if [ -r $cachefile ]; then
> > > > + zpool import -c $cachefile -a -N
> > >
> > > I would add a break here, so that pools are imported either from one cach
> e
> > fi
> > > le
> > > or the other but not both. It makes sense to have two cache file definit
> io
> > ns
> > > for migration, but I think that it does not make sense to split pools bet
> we
> > en
> > > the cache files.
> >
> > Agreed.
> >
> > >
> > > > + fi
> > > > + done
> > > > +}
> > >
> > >
> > > --
> > > Andriy Gapon
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: https://FreeBSD.org
> NTP: Web: https://nwtime.org
>
> The need of the many outweighs the greed of the few.
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
In message <202008271350.07rdogqn055...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon
> wri
> tes:
> > On 26/08/2020 16:13, Cy Schubert wrote:
> > > Author: cy
> > > Date: Wed Aug 26 13:13:57 2020
> > > New Revision: 364817
> > > URL: https://svnweb.freebsd.org/changeset/base/364817
> > >
> > > Log:
> > > As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> > > prior to zvol and mountcritlocal resulting in ZVOLs (swap and
> >
> > I probably missed some discussion, so I am curious why that is.
>
> This is because r364746 added the code below to rc.d/zfs and by then it was
> too late. I simply moved it to a new file that allowed rc.d/zvol and
> rc.d/mountcritlocal with legacy mounts to work again. This was copied from
> rc.d/zfs, which was added by r364746. There was no need for a zpool import
> under the previous version of ZFS, whereas it appears that OpenZFS requires
> it.
Let me add, one could say this is a regression.
>
> >
> > > virtual machine UFS filesystems) being unavailable, leading to
> > > boot failures.
> > > We move the zpool import from zfs to a new zpool script, with the
> > > -N option to avoid mounting datasets while making the ZPOOL's
> > > datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> > > available for subsequent use for swap (in the zvol rc sript) or
> > > for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
> > >
> > > Reviewed by:freqlabs (previous version)
> > > Differential Revision: https://reviews.freebsd.org/D26185
> > >
> > > Added:
> > > head/libexec/rc/rc.d/zpool (contents, props changed)
> > [snip]
> > > +zpool_start()
> > > +{
> > > + local cachefile
> > > +
> > > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > > + if [ -r $cachefile ]; then
> > > + zpool import -c $cachefile -a -N
> >
> > I would add a break here, so that pools are imported either from one cache
> fi
> > le
> > or the other but not both. It makes sense to have two cache file definitio
> ns
> > for migration, but I think that it does not make sense to split pools betwe
> en
> > the cache files.
>
> Agreed.
>
> >
> > > + fi
> > > + done
> > > +}
> >
> >
> > --
> > Andriy Gapon
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon
wri
tes:
> On 26/08/2020 16:13, Cy Schubert wrote:
> > Author: cy
> > Date: Wed Aug 26 13:13:57 2020
> > New Revision: 364817
> > URL: https://svnweb.freebsd.org/changeset/base/364817
> >
> > Log:
> > As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> > prior to zvol and mountcritlocal resulting in ZVOLs (swap and
>
> I probably missed some discussion, so I am curious why that is.
This is because r364746 added the code below to rc.d/zfs and by then it was
too late. I simply moved it to a new file that allowed rc.d/zvol and
rc.d/mountcritlocal with legacy mounts to work again. This was copied from
rc.d/zfs, which was added by r364746. There was no need for a zpool import
under the previous version of ZFS, whereas it appears that OpenZFS requires
it.
>
> > virtual machine UFS filesystems) being unavailable, leading to
> > boot failures.
> > We move the zpool import from zfs to a new zpool script, with the
> > -N option to avoid mounting datasets while making the ZPOOL's
> > datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> > available for subsequent use for swap (in the zvol rc sript) or
> > for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
> >
> > Reviewed by: freqlabs (previous version)
> > Differential Revision:https://reviews.freebsd.org/D26185
> >
> > Added:
> > head/libexec/rc/rc.d/zpool (contents, props changed)
> [snip]
> > +zpool_start()
> > +{
> > + local cachefile
> > +
> > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > + if [ -r $cachefile ]; then
> > + zpool import -c $cachefile -a -N
>
> I would add a break here, so that pools are imported either from one cache fi
> le
> or the other but not both. It makes sense to have two cache file definitions
> for migration, but I think that it does not make sense to split pools between
> the cache files.
Agreed.
>
> > + fi
> > + done
> > +}
>
>
> --
> Andriy Gapon
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364863 - head
Author: freqlabs Date: Thu Aug 27 13:26:36 2020 New Revision: 364863 URL: https://svnweb.freebsd.org/changeset/base/364863 Log: libzfs: Also add the crypto dependency to Makefile.inc1 Reported by: kevans Discussed with: kevans Sponsored by: iXsystems, Inc. Modified: head/Makefile.inc1 Modified: head/Makefile.inc1 == --- head/Makefile.inc1 Thu Aug 27 13:25:24 2020(r364862) +++ head/Makefile.inc1 Thu Aug 27 13:26:36 2020(r364863) @@ -2929,6 +2929,7 @@ cddl/lib/libzfs__L: cddl/lib/libzfs_core__L lib/msun__ cddl/lib/libzfs__L: lib/libthr__L lib/libmd__L lib/libz__L cddl/lib/libumem__L cddl/lib/libzfs__L: cddl/lib/libuutil__L cddl/lib/libavl__L lib/libgeom__L cddl/lib/libzfs__L: cddl/lib/libnvpair__L cddl/lib/libzutil__L +cddl/lib/libzfs__L: secure/lib/libcrypto__L lib/libbe__L: cddl/lib/libzfs__L .endif ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364449 - head/bin/ls
On Tue, Aug 25, 2020 at 11:21:47PM +0900, Hiroki Sato wrote:
> Gordon Bergling wrote
> in <20200824085223.ga28...@lion.0xfce3.net>:
>
> gb> thanks for your feedback. I can only define POSIX.1-200{1,8} or -susv4.
> So what
> gb> do you think about the following STANDARDS section?
> gb>
> gb> For the options that are non-existing I could correct them to -2001 and
> mention
> gb> also -susv4.
> gb>
> gb> STANDARDS
> gb> With the exception of options -g, -n and -o, the ls utility conforms
> to
> gb> IEEE Std 1003.1-2001 (“POSIX.1”) and Version 4 of the Single UNIX
> gb> Specification (“SUSv4”). The options -B, -D, -G, -I, -T, -U, -W,
> -Z, -b,
> gb> -h, -w, -y and -, are compatible extensions not defined in IEEE Std
> gb> 1003.1-2001 (“POSIX.1”).
>
> It might be a bit tedious, but just adding -2008 looks good to me
> like the following:
>
> |.St -p1003.1-2001
> |and
> |.St -p1003.1-2008 .
>
> p1003.1-2004 is a subset of SUSv3 (and -2008 is one of SUSv4), so
> using p1003.1- consistently sounds less confusing when describing
> the conformance within the subsets.
>
> Regarding the non-standard extensions, I am not sure what
> "compatible" means. Some of them are extensions commonly seen on
> other BSD-derived OSes, some are available only on FreeBSD, and some
> have the same names with GNU's counterpart but different meanings.
> Is just mentioning "...are non-standard extensions" with no
> specification name sufficient and easier? I have no strong opinion
> on that part, but this is just my two cents.
>
> -- Hiroki
I followed your suggestions and created the following differential for
further discussions.
https://reviews.freebsd.org/D26210
--Gordon
signature.asc
Description: PGP signature
Re: svn commit: r364861 - in head: cddl/lib/libzfs share/mk
On Thu, Aug 27, 2020 at 8:05 AM Ryan Moeller wrote: > > Author: freqlabs > Date: Thu Aug 27 13:05:41 2020 > New Revision: 364861 > URL: https://svnweb.freebsd.org/changeset/base/364861 > > Log: > libzfs: Add missing crypto dependency > > libzfs_crypto.c uses PKCS5_PBKDF2_HMAC_SHA1 from libcrypto. > Hmm, interesting; I think this needs an __L dependency in ^/Makefile.inc1 as well, since they're both part of _prebuild_libs if MK_CRYPT+MK_OPENSSL+MK_ZFS. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364861 - in head: cddl/lib/libzfs share/mk
Author: freqlabs Date: Thu Aug 27 13:05:41 2020 New Revision: 364861 URL: https://svnweb.freebsd.org/changeset/base/364861 Log: libzfs: Add missing crypto dependency libzfs_crypto.c uses PKCS5_PBKDF2_HMAC_SHA1 from libcrypto. Reported by: John Kennedy Sponsored by: iXsystems, Inc. Modified: head/cddl/lib/libzfs/Makefile head/share/mk/src.libnames.mk Modified: head/cddl/lib/libzfs/Makefile == --- head/cddl/lib/libzfs/Makefile Thu Aug 27 10:28:12 2020 (r364860) +++ head/cddl/lib/libzfs/Makefile Thu Aug 27 13:05:41 2020 (r364861) @@ -12,7 +12,21 @@ PACKAGE= runtime LIB= zfs -LIBADD=md pthread umem util uutil m avl bsdxml geom nvpair z zfs_core zutil +LIBADD= \ + avl \ + bsdxml \ + crypto \ + geom \ + m \ + md \ + nvpair \ + pthread \ + umem \ + util \ + uutil \ + z \ + zfs_core \ + zutil INCS= libzfs.h USER_C = \ Modified: head/share/mk/src.libnames.mk == --- head/share/mk/src.libnames.mk Thu Aug 27 10:28:12 2020 (r364860) +++ head/share/mk/src.libnames.mk Thu Aug 27 13:05:41 2020 (r364861) @@ -382,7 +382,7 @@ _DP_fifolog=z _DP_ipf= kvm _DP_tpool= spl _DP_uutil= avl spl -_DP_zfs= md pthread umem util uutil m avl bsdxml geom nvpair \ +_DP_zfs= md pthread umem util uutil m avl bsdxml crypto geom nvpair \ z zfs_core zutil _DP_zfs_core= nvpair _DP_zpool= md pthread z icp spl nvpair avl umem ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364860 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src conf modules/linuxkpi
Author: hselasky
Date: Thu Aug 27 10:28:12 2020
New Revision: 364860
URL: https://svnweb.freebsd.org/changeset/base/364860
Log:
Implement extensible arrays API using the existing radix tree implementation
in the LinuxKPI.
Differential Revision:https://reviews.freebsd.org/D25101
Reviewed by: kib @
MFC after:1 week
Sponsored by: Mellanox Technologies
Added:
head/sys/compat/linuxkpi/common/include/linux/xarray.h (contents, props
changed)
head/sys/compat/linuxkpi/common/src/linux_xarray.c (contents, props changed)
Modified:
head/sys/conf/files
head/sys/modules/linuxkpi/Makefile
Added: head/sys/compat/linuxkpi/common/include/linux/xarray.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/compat/linuxkpi/common/include/linux/xarray.h Thu Aug 27
10:28:12 2020(r364860)
@@ -0,0 +1,94 @@
+/*-
+ * Copyright (c) 2020 Mellanox Technologies, Ltd.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice unmodified, this list of conditions, and the following
+ *disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+#ifndef_LINUX_XARRAY_H_
+#define_LINUX_XARRAY_H_
+
+#include
+#include
+#include
+
+#include
+#include
+
+#defineXA_LIMIT(min, max) \
+({ CTASSERT((min) == 0); (uint32_t)(max); })
+
+#defineXA_FLAGS_ALLOC (1U << 0)
+#defineXA_FLAGS_LOCK_IRQ (1U << 1)
+
+#defineXA_ERROR(x) \
+ ERR_PTR(x)
+
+#definexa_limit_32b XA_LIMIT(0, 0x)
+
+#defineXA_ASSERT_LOCKED(xa) mtx_assert(&(xa)->mtx, MA_OWNED)
+#definexa_lock(xa) mtx_lock(&(xa)->mtx)
+#definexa_unlock(xa) mtx_unlock(&(xa)->mtx)
+
+struct xarray {
+ struct radix_tree_root root;
+ struct mtx mtx; /* internal mutex */
+};
+
+/*
+ * Extensible arrays API implemented as a wrapper
+ * around the radix tree implementation.
+ */
+void *xa_erase(struct xarray *, uint32_t);
+void *xa_load(struct xarray *, uint32_t);
+int xa_alloc(struct xarray *, uint32_t *, void *, uint32_t, gfp_t);
+int xa_alloc_cyclic(struct xarray *, uint32_t *, void *, uint32_t, uint32_t *,
gfp_t);
+int xa_insert(struct xarray *, uint32_t, void *, gfp_t);
+void *xa_store(struct xarray *, uint32_t, void *, gfp_t);
+void xa_init_flags(struct xarray *, uint32_t);
+bool xa_empty(struct xarray *);
+void xa_destroy(struct xarray *);
+void *xa_next(struct xarray *, unsigned long *, bool);
+
+#definexa_for_each(xa, index, entry) \
+ for ((entry) = NULL, (index) = 0; \
+((entry) = xa_next(xa, , (entry) != NULL)) != NULL; )
+
+/*
+ * Unlocked version of functions above.
+ */
+void *__xa_erase(struct xarray *, uint32_t);
+int __xa_alloc(struct xarray *, uint32_t *, void *, uint32_t, gfp_t);
+int __xa_alloc_cyclic(struct xarray *, uint32_t *, void *, uint32_t, uint32_t
*, gfp_t);
+int __xa_insert(struct xarray *, uint32_t, void *, gfp_t);
+void *__xa_store(struct xarray *, uint32_t, void *, gfp_t);
+bool __xa_empty(struct xarray *);
+void *__xa_next(struct xarray *, unsigned long *, bool);
+
+static inline int
+xa_err(void *ptr)
+{
+ return (PTR_ERR_OR_ZERO(ptr));
+}
+
+#endif /* _LINUX_XARRAY_H_ */
Added: head/sys/compat/linuxkpi/common/src/linux_xarray.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/compat/linuxkpi/common/src/linux_xarray.c Thu Aug 27 10:28:12
2020(r364860)
@@ -0,0 +1,391 @@
+/*-
+ * Copyright (c) 2020 Mellanox Technologies, Ltd.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 26/08/2020 16:13, Cy Schubert wrote:
> Author: cy
> Date: Wed Aug 26 13:13:57 2020
> New Revision: 364817
> URL: https://svnweb.freebsd.org/changeset/base/364817
>
> Log:
> As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> prior to zvol and mountcritlocal resulting in ZVOLs (swap and
I probably missed some discussion, so I am curious why that is.
> virtual machine UFS filesystems) being unavailable, leading to
> boot failures.
> We move the zpool import from zfs to a new zpool script, with the
> -N option to avoid mounting datasets while making the ZPOOL's
> datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> available for subsequent use for swap (in the zvol rc sript) or
> for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
>
> Reviewed by:freqlabs (previous version)
> Differential Revision: https://reviews.freebsd.org/D26185
>
> Added:
> head/libexec/rc/rc.d/zpool (contents, props changed)
[snip]
> +zpool_start()
> +{
> + local cachefile
> +
> + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> + if [ -r $cachefile ]; then
> + zpool import -c $cachefile -a -N
I would add a break here, so that pools are imported either from one cache file
or the other but not both. It makes sense to have two cache file definitions
for migration, but I think that it does not make sense to split pools between
the cache files.
> + fi
> + done
> +}
--
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364859 - head/sys/arm/ti
On Thu, 27 Aug 2020 08:08:49 + (UTC)
Emmanuel Vadot wrote:
> Author: manu
> Date: Thu Aug 27 08:08:49 2020
> New Revision: 364859
> URL: https://svnweb.freebsd.org/changeset/base/364859
>
> Log:
> arm: ti: Fix Beaglebone black MMC after DTS update
>
> After DTS sync with Linux kernel 5.8 this patch was included:
> "ARM: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver"
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx-l4.dtsi?h=v5.9-rc2=0b4edf111870b83ea77b1d7e16b8ceac29f9f388
>
> Current will not load any driver for MMC and not mount the rootfs.
> Simple patch add "ti,am335-sdhci" to compability strings in ti_sdhci.c
>
> Submitted by: oskar.holml...@ohdata.se
> Reported by:phk
> X-MFC-With: 363853
Differential Revision: https://reviews.freebsd.org/D26194
>
> Modified:
> head/sys/arm/ti/ti_sdhci.c
>
> Modified: head/sys/arm/ti/ti_sdhci.c
> ==
> --- head/sys/arm/ti/ti_sdhci.cThu Aug 27 06:31:55 2020
> (r364858)
> +++ head/sys/arm/ti/ti_sdhci.cThu Aug 27 08:08:49 2020
> (r364859)
> @@ -93,6 +93,7 @@ struct ti_sdhci_softc {
> * Note that vendor Beaglebone dtsi files use "ti,omap3-hsmmc" for the
> am335x.
> */
> static struct ofw_compat_data compat_data[] = {
> + {"ti,am335-sdhci", 1},
> {"ti,omap3-hsmmc", 1},
> {"ti,omap4-hsmmc", 1},
> {"ti,mmchs",1},
--
Emmanuel Vadot
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364859 - head/sys/arm/ti
Author: manu
Date: Thu Aug 27 08:08:49 2020
New Revision: 364859
URL: https://svnweb.freebsd.org/changeset/base/364859
Log:
arm: ti: Fix Beaglebone black MMC after DTS update
After DTS sync with Linux kernel 5.8 this patch was included:
"ARM: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx-l4.dtsi?h=v5.9-rc2=0b4edf111870b83ea77b1d7e16b8ceac29f9f388
Current will not load any driver for MMC and not mount the rootfs.
Simple patch add "ti,am335-sdhci" to compability strings in ti_sdhci.c
Submitted by: oskar.holml...@ohdata.se
Reported by: phk
X-MFC-With: 363853
Modified:
head/sys/arm/ti/ti_sdhci.c
Modified: head/sys/arm/ti/ti_sdhci.c
==
--- head/sys/arm/ti/ti_sdhci.c Thu Aug 27 06:31:55 2020(r364858)
+++ head/sys/arm/ti/ti_sdhci.c Thu Aug 27 08:08:49 2020(r364859)
@@ -93,6 +93,7 @@ struct ti_sdhci_softc {
* Note that vendor Beaglebone dtsi files use "ti,omap3-hsmmc" for the am335x.
*/
static struct ofw_compat_data compat_data[] = {
+ {"ti,am335-sdhci", 1},
{"ti,omap3-hsmmc", 1},
{"ti,omap4-hsmmc", 1},
{"ti,mmchs",1},
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364857 - head/sys/kern
Author: mjg
Date: Thu Aug 27 06:31:27 2020
New Revision: 364857
URL: https://svnweb.freebsd.org/changeset/base/364857
Log:
cache: assorted clean ups
In particular remove spurious comments, duplicate assertions and the
inconsistently done KTR support.
Modified:
head/sys/kern/vfs_cache.c
Modified: head/sys/kern/vfs_cache.c
==
--- head/sys/kern/vfs_cache.c Thu Aug 27 06:30:40 2020(r364856)
+++ head/sys/kern/vfs_cache.c Thu Aug 27 06:31:27 2020(r364857)
@@ -999,9 +999,6 @@ cache_zap_locked(struct namecache *ncp)
cache_assert_vnode_locked(ncp->nc_dvp);
cache_assert_bucket_locked(ncp);
- CTR2(KTR_VFS, "cache_zap(%p) vp %p", ncp,
- (ncp->nc_flag & NCF_NEGATIVE) ? NULL : ncp->nc_vp);
-
cache_ncp_invalidate(ncp);
ncpp = NCP2BUCKET(ncp);
@@ -1260,6 +1257,83 @@ cache_zap_locked_bucket_kl(struct namecache *ncp, stru
return (EAGAIN);
}
+static __noinline int
+cache_remove_cnp(struct vnode *dvp, struct componentname *cnp)
+{
+ struct namecache *ncp;
+ struct mtx *blp;
+ struct mtx *dvlp, *dvlp2;
+ uint32_t hash;
+ int error;
+
+ if (cnp->cn_namelen == 2 &&
+ cnp->cn_nameptr[0] == '.' && cnp->cn_nameptr[1] == '.') {
+ dvlp = VP2VNODELOCK(dvp);
+ dvlp2 = NULL;
+ mtx_lock(dvlp);
+retry_dotdot:
+ ncp = dvp->v_cache_dd;
+ if (ncp == NULL) {
+ mtx_unlock(dvlp);
+ if (dvlp2 != NULL)
+ mtx_unlock(dvlp2);
+ SDT_PROBE2(vfs, namecache, removecnp, miss, dvp, cnp);
+ return (0);
+ }
+ if ((ncp->nc_flag & NCF_ISDOTDOT) != 0) {
+ if (!cache_zap_locked_vnode_kl2(ncp, dvp, ))
+ goto retry_dotdot;
+ MPASS(dvp->v_cache_dd == NULL);
+ mtx_unlock(dvlp);
+ if (dvlp2 != NULL)
+ mtx_unlock(dvlp2);
+ cache_free(ncp);
+ } else {
+ vn_seqc_write_begin(dvp);
+ dvp->v_cache_dd = NULL;
+ vn_seqc_write_end(dvp);
+ mtx_unlock(dvlp);
+ if (dvlp2 != NULL)
+ mtx_unlock(dvlp2);
+ }
+ SDT_PROBE2(vfs, namecache, removecnp, hit, dvp, cnp);
+ return (1);
+ }
+
+ hash = cache_get_hash(cnp->cn_nameptr, cnp->cn_namelen, dvp);
+ blp = HASH2BUCKETLOCK(hash);
+retry:
+ if (CK_SLIST_EMPTY(NCHHASH(hash)))
+ goto out_no_entry;
+
+ mtx_lock(blp);
+
+ CK_SLIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) {
+ if (ncp->nc_dvp == dvp && ncp->nc_nlen == cnp->cn_namelen &&
+ !bcmp(ncp->nc_name, cnp->cn_nameptr, ncp->nc_nlen))
+ break;
+ }
+
+ if (ncp == NULL) {
+ mtx_unlock(blp);
+ goto out_no_entry;
+ }
+
+ error = cache_zap_locked_bucket(ncp, cnp, hash, blp);
+ if (__predict_false(error != 0)) {
+ zap_and_exit_bucket_fail++;
+ goto retry;
+ }
+ counter_u64_add(numposzaps, 1);
+ SDT_PROBE2(vfs, namecache, removecnp, hit, dvp, cnp);
+ cache_free(ncp);
+ return (1);
+out_no_entry:
+ counter_u64_add(nummisszap, 1);
+ SDT_PROBE2(vfs, namecache, removecnp, miss, dvp, cnp);
+ return (0);
+}
+
static int __noinline
cache_lookup_dot(struct vnode *dvp, struct vnode **vpp, struct componentname
*cnp,
struct timespec *tsp, int *ticksp)
@@ -1267,8 +1341,6 @@ cache_lookup_dot(struct vnode *dvp, struct vnode **vpp
int ltype;
*vpp = dvp;
- CTR2(KTR_VFS, "cache_lookup(%p, %s) found via .",
- dvp, cnp->cn_nameptr);
counter_u64_add(dothits, 1);
SDT_PROBE3(vfs, namecache, lookup, hit, dvp, ".", *vpp);
if (tsp != NULL)
@@ -1296,10 +1368,6 @@ cache_lookup_dot(struct vnode *dvp, struct vnode **vpp
return (-1);
}
-static __noinline int
-cache_remove_cnp(struct vnode *dvp, struct componentname *cnp);
-
-
static int __noinline
cache_lookup_dotdot(struct vnode *dvp, struct vnode **vpp, struct
componentname *cnp,
struct timespec *tsp, int *ticksp)
@@ -1324,8 +1392,7 @@ retry:
mtx_lock(dvlp);
ncp = dvp->v_cache_dd;
if (ncp == NULL) {
- SDT_PROBE3(vfs, namecache, lookup, miss, dvp,
- "..", NULL);
+ SDT_PROBE3(vfs, namecache, lookup, miss, dvp, "..", NULL);
mtx_unlock(dvlp);
return (0);
}
@@ -1336,13 +1403,9 @@ retry:
*vpp = ncp->nc_vp;
} else
svn commit: r364858 - head/sys/kern
Author: mjg
Date: Thu Aug 27 06:31:55 2020
New Revision: 364858
URL: https://svnweb.freebsd.org/changeset/base/364858
Log:
cache: don't update timestmaps on found entry
Modified:
head/sys/kern/vfs_cache.c
Modified: head/sys/kern/vfs_cache.c
==
--- head/sys/kern/vfs_cache.c Thu Aug 27 06:31:27 2020(r364857)
+++ head/sys/kern/vfs_cache.c Thu Aug 27 06:31:55 2020(r364858)
@@ -1925,7 +1925,7 @@ cache_enter_time(struct vnode *dvp, struct vnode *vp,
{
struct celockstate cel;
struct namecache *ncp, *n2, *ndd;
- struct namecache_ts *ncp_ts, *n2_ts;
+ struct namecache_ts *ncp_ts;
struct nchashhead *ncpp;
uint32_t hash;
int flag;
@@ -2013,6 +2013,17 @@ cache_enter_time(struct vnode *dvp, struct vnode *vp,
KASSERT(n2->nc_vp == vp,
("%s: found entry pointing to a different
vnode (%p != %p)",
__func__, n2->nc_vp, vp));
+ /*
+* Entries are supposed to be immutable unless in the
+* process of getting destroyed. Accommodating for
+* changing timestamps is possible but not worth it.
+* This should be harmless in terms of correctness, in
+* the worst case resulting in an earlier expiration.
+* Alternatively, the found entry can be replaced
+* altogether.
+*/
+ MPASS((n2->nc_flag & (NCF_TS | NCF_DTS)) ==
(ncp->nc_flag & (NCF_TS | NCF_DTS)));
+#if 0
if (tsp != NULL) {
KASSERT((n2->nc_flag & NCF_TS) != 0,
("no NCF_TS"));
@@ -2024,6 +2035,7 @@ cache_enter_time(struct vnode *dvp, struct vnode *vp,
n2_ts->nc_nc.nc_flag |= NCF_DTS;
}
}
+#endif
goto out_unlock_free;
}
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364856 - head/sys/kern
Author: mjg
Date: Thu Aug 27 06:30:40 2020
New Revision: 364856
URL: https://svnweb.freebsd.org/changeset/base/364856
Log:
cache: ncp = NULL early to account for sdt probes in ailure path
CID: 1432106
Modified:
head/sys/kern/vfs_cache.c
Modified: head/sys/kern/vfs_cache.c
==
--- head/sys/kern/vfs_cache.c Thu Aug 27 05:11:15 2020(r364855)
+++ head/sys/kern/vfs_cache.c Thu Aug 27 06:30:40 2020(r364856)
@@ -2938,6 +2938,7 @@ vn_fullpath_any_smr(struct vnode *vp, struct vnode *rd
i = 0;
#endif
error = -1;
+ ncp = NULL; /* for sdt probe down below */
vp_seqc = vn_seqc_read_any(vp);
if (seqc_in_modify(vp_seqc)) {
cache_rev_failed();
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
