svn commit: r350830 - head/sys/sparc64/conf
Author: imp Date: Sat Aug 10 04:15:36 2019 New Revision: 350830 URL: https://svnweb.freebsd.org/changeset/base/350830 Log: These are no longer a thing, remove them. We don't need to omit ep and ex from LINT since they have been removed from the tree. Modified: head/sys/sparc64/conf/NOTES Modified: head/sys/sparc64/conf/NOTES == --- head/sys/sparc64/conf/NOTES Sat Aug 10 00:02:45 2019(r350829) +++ head/sys/sparc64/conf/NOTES Sat Aug 10 04:15:36 2019(r350830) @@ -119,8 +119,6 @@ nodevicesnd_via8233 nodevice snd_via82c686 nodevice snd_vibes nodevice snd_uaudio -nodevice ep -nodevice ex # ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 9, 2019 at 3:05 PM Konstantin Belousov wrote: > On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > > wrote: > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff > wrote: > > > > > > > > > Hi, > > > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > > application that would require this compatibility. > > > > > > > > > > A more general question is how far in the future are we going > > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and > kernel > > > > behavior modifications. Before we thinned the ABIs we supported, it > was > > > > necessary for them as well. The biggest behavior change is around > > > signals. > > > > It is weird to sort out and nobody has done the deep analysis to see > what > > > > is truly unused and what is there for compat with Linux and other > SysV > > > > systems... > > > I am not aware of any changes that COMPAT_43 provides for the signal > > > handling semantic, except a minor adjustment for interpretation of > > > zero-sized stack for sigaltstack(2). > > > > > > > The onstack stuff was what I was thinking about, but we also have code in > > sys_getpid() that returns the ppid in the second retval register, and > > similar things for getuid and getgid, It also allows ioctl numbers that > > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > > compat bits are set, but in one place it allows a shorter unix domain > > socket path length to be compatible unconditionally. The compatibility > TTY > > stuff, at least is under COMPAT_43TTY, but that's purely ioctl > translation > > code. > I only reacted to the note about changing the signals syscalls behavior. > But the point is valid, we should not change the syscalls ABI for new > binaries when COMPAT_43 is enabled. I propose the following > https://reviews.freebsd.org/D21200 Glad I did the dumpster-diving grep then. I like your proposal for the same reasons you stated. WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > 5, and we always enable these for GENERIC. So effectively this ioctl > permissive mode is always there. > Yes. I also agree. And I honestly think it's OK. > > > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on > amd64 > > > kernel in chroot this way. Since sometimes I get bug reports about > this > > > stuff, there are some users of it. I believe it is important to be > able > > > to run any FreeBSD binary for PR purposes, to wave the flag of > excellent > > > binary compatibility we offer. > > > > > > COMPAT_43 is there to stay as far as there are people willing to > maintain > > > it. There are more than one. > > > > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > > lean yes. > I believe amd64 is required since you have less and less chances to > usefully > run i386 kernel on modern hardware. > True. With your changes, enabling the option is much safer, and only drags in a minor amount of extra code. All but the most space starved users won't care at all about the delta in size. Warner > > All the other platforms I'd agree with gleb: why do we need it in > > the kernels by default (and maybe why do we need to support it at all)? > > > > Warner > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350829 - stable/11/sys/kern
Author: jtl
Date: Sat Aug 10 00:02:45 2019
New Revision: 350829
URL: https://svnweb.freebsd.org/changeset/base/350829
Log:
MFC r350815:
In m_pulldown(), before trying to prepend bytes to the subsequent mbuf,
ensure that the subsequent mbuf contains the remainder of the bytes
the caller sought. If this is not the case, fall through to the code
which gathers the bytes in a new mbuf.
This fixes a bug where m_pulldown() could fail to gather all the desired
bytes into consecutive memory.
PR: 238787
Approved by: so (emaste)
Modified:
stable/11/sys/kern/uipc_mbuf2.c
Directory Properties:
stable/11/ (props changed)
Modified: stable/11/sys/kern/uipc_mbuf2.c
==
--- stable/11/sys/kern/uipc_mbuf2.c Sat Aug 10 00:01:25 2019
(r350828)
+++ stable/11/sys/kern/uipc_mbuf2.c Sat Aug 10 00:02:45 2019
(r350829)
@@ -214,7 +214,7 @@ m_pulldown(struct mbuf *m, int off, int len, int *offp
goto ok;
}
if ((off == 0 || offp) && M_LEADINGSPACE(n->m_next) >= hlen
-&& writable) {
+&& writable && n->m_next->m_len >= tlen) {
n->m_next->m_data -= hlen;
n->m_next->m_len += hlen;
bcopy(mtod(n, caddr_t) + off, mtod(n->m_next, caddr_t), hlen);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350828 - stable/12/sys/kern
Author: jtl
Date: Sat Aug 10 00:01:25 2019
New Revision: 350828
URL: https://svnweb.freebsd.org/changeset/base/350828
Log:
MFC r350815:
In m_pulldown(), before trying to prepend bytes to the subsequent mbuf,
ensure that the subsequent mbuf contains the remainder of the bytes
the caller sought. If this is not the case, fall through to the code
which gathers the bytes in a new mbuf.
This fixes a bug where m_pulldown() could fail to gather all the desired
bytes into consecutive memory.
PR: 238787
Approved by: so (emaste)
Modified:
stable/12/sys/kern/uipc_mbuf2.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/kern/uipc_mbuf2.c
==
--- stable/12/sys/kern/uipc_mbuf2.c Fri Aug 9 23:50:57 2019
(r350827)
+++ stable/12/sys/kern/uipc_mbuf2.c Sat Aug 10 00:01:25 2019
(r350828)
@@ -216,7 +216,7 @@ m_pulldown(struct mbuf *m, int off, int len, int *offp
goto ok;
}
if ((off == 0 || offp) && M_LEADINGSPACE(n->m_next) >= hlen
-&& writable) {
+&& writable && n->m_next->m_len >= tlen) {
n->m_next->m_data -= hlen;
n->m_next->m_len += hlen;
bcopy(mtod(n, caddr_t) + off, mtod(n->m_next, caddr_t), hlen);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350827 - head/tests/sys/fs/fusefs
Author: brooks
Date: Fri Aug 9 23:50:57 2019
New Revision: 350827
URL: https://svnweb.freebsd.org/changeset/base/350827
Log:
Don't add -Wno-class-memaccess with older gcc.
This is a gcc 8.0+ warning which needed to be silenced on for the riscv
build. amd64-xtoolchain-gcc still uses gcc 6.4.0 and does not understand
this flag.
Reviewed by: asomers
Feedback from:imp
Differential Revision:https://reviews.freebsd.org/D21195
Modified:
head/tests/sys/fs/fusefs/Makefile
Modified: head/tests/sys/fs/fusefs/Makefile
==
--- head/tests/sys/fs/fusefs/Makefile Fri Aug 9 20:16:38 2019
(r350826)
+++ head/tests/sys/fs/fusefs/Makefile Fri Aug 9 23:50:57 2019
(r350827)
@@ -1,5 +1,7 @@
# $FreeBSD$
+.include
+
PACKAGE= tests
TESTSDIR= ${TESTSBASE}/sys/fs/fusefs
@@ -65,7 +67,10 @@ TEST_METADATA+= timeout=10
FUSEFS=${SRCTOP}/sys/fs/fuse
MOUNT= ${SRCTOP}/sbin/mount
# Suppress warnings that GCC generates for the libc++ and gtest headers.
-CXXWARNFLAGS.gcc+= -Wno-placement-new -Wno-attributes -Wno-class-memaccess
+CXXWARNFLAGS.gcc+= -Wno-placement-new -Wno-attributes
+.if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 8
+CXXWARNFLAGS+= -Wno-class-memaccess
+.endif
CXXFLAGS+= -I${SRCTOP}/tests
CXXFLAGS+= -I${FUSEFS}
CXXFLAGS+= -I${MOUNT}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 09, 2019 at 02:29:49PM -0700, Rodney W. Grimes wrote: > > On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > > wrote: > > > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > > > application that would require this compatibility. > > > > > > > > > > > > A more general question is how far in the future are we going > > > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > > > > behavior modifications. Before we thinned the ABIs we supported, it > > > > > was > > > > > necessary for them as well. The biggest behavior change is around > > > > signals. > > > > > It is weird to sort out and nobody has done the deep analysis to see > > > > > what > > > > > is truly unused and what is there for compat with Linux and other SysV > > > > > systems... > > > > I am not aware of any changes that COMPAT_43 provides for the signal > > > > handling semantic, except a minor adjustment for interpretation of > > > > zero-sized stack for sigaltstack(2). > > > > > > > > > > The onstack stuff was what I was thinking about, but we also have code in > > > sys_getpid() that returns the ppid in the second retval register, and > > > similar things for getuid and getgid, It also allows ioctl numbers that > > > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > > > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > > > compat bits are set, but in one place it allows a shorter unix domain > > > socket path length to be compatible unconditionally. The compatibility TTY > > > stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation > > > code. > > I only reacted to the note about changing the signals syscalls behavior. > > But the point is valid, we should not change the syscalls ABI for new > > binaries when COMPAT_43 is enabled. I propose the following > > https://reviews.freebsd.org/D21200 > > > > WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > > 5, and we always enable these for GENERIC. So effectively this ioctl > > permissive mode is always there. > > > > > > > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on > > > > amd64 > > > > kernel in chroot this way. Since sometimes I get bug reports about this > > > > stuff, there are some users of it. I believe it is important to be able > > > > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > > > > binary compatibility we offer. > > > > > > > > COMPAT_43 is there to stay as far as there are people willing to > > > > maintain > > > > it. There are more than one. > > > > > > > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > > > lean yes. > > I believe amd64 is required since you have less and less chances to usefully > > run i386 kernel on modern hardware. > > Would this also be required for running i386 binaries on amd64 using lib32 > that expect the COMPAT_43 behavior? I do not quite understand the question. My proposed change would mostly limit effect of COMPAT_43 to a.out binaries. /usr/lib32 are ELF. I would not expect any modern (as in, ELF) binaries to require changes to the syscalls behavior from COMPAT_43. > > > > All the other platforms I'd agree with gleb: why do we need it in > > > the kernels by default (and maybe why do we need to support it at all)? > > > > > > Warner > > -- > Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
> On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > wrote: > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > > > > > > > Hi, > > > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > > application that would require this compatibility. > > > > > > > > > > A more general question is how far in the future are we going > > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > > > behavior modifications. Before we thinned the ABIs we supported, it was > > > > necessary for them as well. The biggest behavior change is around > > > signals. > > > > It is weird to sort out and nobody has done the deep analysis to see > > > > what > > > > is truly unused and what is there for compat with Linux and other SysV > > > > systems... > > > I am not aware of any changes that COMPAT_43 provides for the signal > > > handling semantic, except a minor adjustment for interpretation of > > > zero-sized stack for sigaltstack(2). > > > > > > > The onstack stuff was what I was thinking about, but we also have code in > > sys_getpid() that returns the ppid in the second retval register, and > > similar things for getuid and getgid, It also allows ioctl numbers that > > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > > compat bits are set, but in one place it allows a shorter unix domain > > socket path length to be compatible unconditionally. The compatibility TTY > > stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation > > code. > I only reacted to the note about changing the signals syscalls behavior. > But the point is valid, we should not change the syscalls ABI for new > binaries when COMPAT_43 is enabled. I propose the following > https://reviews.freebsd.org/D21200 > > WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > 5, and we always enable these for GENERIC. So effectively this ioctl > permissive mode is always there. > > > > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > > > kernel in chroot this way. Since sometimes I get bug reports about this > > > stuff, there are some users of it. I believe it is important to be able > > > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > > > binary compatibility we offer. > > > > > > COMPAT_43 is there to stay as far as there are people willing to maintain > > > it. There are more than one. > > > > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > > lean yes. > I believe amd64 is required since you have less and less chances to usefully > run i386 kernel on modern hardware. Would this also be required for running i386 binaries on amd64 using lib32 that expect the COMPAT_43 behavior? > > All the other platforms I'd agree with gleb: why do we need it in > > the kernels by default (and maybe why do we need to support it at all)? > > > > Warner -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > wrote: > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > > > > > Hi, > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > application that would require this compatibility. > > > > > > > > A more general question is how far in the future are we going > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > > behavior modifications. Before we thinned the ABIs we supported, it was > > > necessary for them as well. The biggest behavior change is around > > signals. > > > It is weird to sort out and nobody has done the deep analysis to see what > > > is truly unused and what is there for compat with Linux and other SysV > > > systems... > > I am not aware of any changes that COMPAT_43 provides for the signal > > handling semantic, except a minor adjustment for interpretation of > > zero-sized stack for sigaltstack(2). > > > > The onstack stuff was what I was thinking about, but we also have code in > sys_getpid() that returns the ppid in the second retval register, and > similar things for getuid and getgid, It also allows ioctl numbers that > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > compat bits are set, but in one place it allows a shorter unix domain > socket path length to be compatible unconditionally. The compatibility TTY > stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation > code. I only reacted to the note about changing the signals syscalls behavior. But the point is valid, we should not change the syscalls ABI for new binaries when COMPAT_43 is enabled. I propose the following https://reviews.freebsd.org/D21200 WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and 5, and we always enable these for GENERIC. So effectively this ioctl permissive mode is always there. > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > > kernel in chroot this way. Since sometimes I get bug reports about this > > stuff, there are some users of it. I believe it is important to be able > > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > > binary compatibility we offer. > > > > COMPAT_43 is there to stay as far as there are people willing to maintain > > it. There are more than one. > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > lean yes. I believe amd64 is required since you have less and less chances to usefully run i386 kernel on modern hardware. > All the other platforms I'd agree with gleb: why do we need it in > the kernels by default (and maybe why do we need to support it at all)? > > Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350826 - in head/lib/libthr/arch/powerpc: . include powerpc
Author: bdragon Date: Fri Aug 9 20:16:38 2019 New Revision: 350826 URL: https://svnweb.freebsd.org/changeset/base/350826 Log: Implement _umtx_op_err.S on powerpc / powerpc64. As per r177853, we need to avoid using errno inside user mutex code, since signal handlers can interfere with it and mess up libthr internal state. So, implement _umtx_op_err() instead, which makes a raw syscall and returns the error value directly instead of using errno. Approved by: jhibbits (mentor) Differential Revision: https://reviews.freebsd.org/D20946 Added: head/lib/libthr/arch/powerpc/Makefile.inc (contents, props changed) head/lib/libthr/arch/powerpc/powerpc/ head/lib/libthr/arch/powerpc/powerpc/_umtx_op_err.S (contents, props changed) Modified: head/lib/libthr/arch/powerpc/include/pthread_md.h Added: head/lib/libthr/arch/powerpc/Makefile.inc == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/lib/libthr/arch/powerpc/Makefile.inc Fri Aug 9 20:16:38 2019 (r350826) @@ -0,0 +1,3 @@ +# $FreeBSD$ + +SRCS+= _umtx_op_err.S Modified: head/lib/libthr/arch/powerpc/include/pthread_md.h == --- head/lib/libthr/arch/powerpc/include/pthread_md.h Fri Aug 9 19:09:05 2019(r350825) +++ head/lib/libthr/arch/powerpc/include/pthread_md.h Fri Aug 9 20:16:38 2019(r350826) @@ -91,4 +91,6 @@ _get_curthread(void) return (NULL); } +#defineHAS__UMTX_OP_ERR1 + #endif /* _PTHREAD_MD_H_ */ Added: head/lib/libthr/arch/powerpc/powerpc/_umtx_op_err.S == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/lib/libthr/arch/powerpc/powerpc/_umtx_op_err.S Fri Aug 9 20:16:38 2019(r350826) @@ -0,0 +1,41 @@ +/*- + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD + * + * Copyright (c) 2019 Brandon Bergren + * + * 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, 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 AND CONTRIBUTORS ``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 OR CONTRIBUTORS 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$ + */ + +#include +#include + + .text + .align 2 +ENTRY(_umtx_op_err) + li %r0, SYS__umtx_op + sc + blr +END(_umtx_op_err) + + .section .note.GNU-stack,"",%progbits ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350825 - head/stand/libsa/zfs
Author: tsoome
Date: Fri Aug 9 19:09:05 2019
New Revision: 350825
URL: https://svnweb.freebsd.org/changeset/base/350825
Log:
loader: add error check for vdev_indirect calls
We can error out due to memory allocation errors, we can not recover from
those and need to get out.
Modified:
head/stand/libsa/zfs/zfsimpl.c
Modified: head/stand/libsa/zfs/zfsimpl.c
==
--- head/stand/libsa/zfs/zfsimpl.c Fri Aug 9 12:15:23 2019
(r350824)
+++ head/stand/libsa/zfs/zfsimpl.c Fri Aug 9 19:09:05 2019
(r350825)
@@ -839,6 +839,7 @@ vdev_indirect_remap(vdev_t *vd, uint64_t offset, uint6
{
list_t stack;
spa_t *spa = vd->spa;
+ zio_t *zio = arg;
list_create(, sizeof (remap_segment_t),
offsetof(remap_segment_t, rs_node));
@@ -872,6 +873,13 @@ vdev_indirect_remap(vdev_t *vd, uint64_t offset, uint6
dst_offset + inner_offset,
inner_size, arg);
+ /*
+* vdev_indirect_gather_splits can have memory
+* allocation error, we can not recover from it.
+*/
+ if (zio->io_error != 0)
+ break;
+
rs->rs_offset += inner_size;
rs->rs_asize -= inner_size;
rs->rs_split_offset += inner_size;
@@ -879,6 +887,8 @@ vdev_indirect_remap(vdev_t *vd, uint64_t offset, uint6
free(mapping);
free(rs);
+ if (zio->io_error != 0)
+ break;
}
list_destroy();
@@ -935,6 +945,8 @@ vdev_indirect_read(vdev_t *vdev, const blkptr_t *bp, v
}
vdev_indirect_remap(vdev, offset, bytes, );
+ if (zio.io_error != 0)
+ return (zio.io_error);
first = list_head(>iv_splits);
if (first->is_size == zio.io_size) {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov wrote: > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > > > Hi, > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > application that would require this compatibility. > > > > > > A more general question is how far in the future are we going > > > to carry COMPAT_43 for i386/amd64? > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > behavior modifications. Before we thinned the ABIs we supported, it was > > necessary for them as well. The biggest behavior change is around > signals. > > It is weird to sort out and nobody has done the deep analysis to see what > > is truly unused and what is there for compat with Linux and other SysV > > systems... > I am not aware of any changes that COMPAT_43 provides for the signal > handling semantic, except a minor adjustment for interpretation of > zero-sized stack for sigaltstack(2). > The onstack stuff was what I was thinking about, but we also have code in sys_getpid() that returns the ppid in the second retval register, and similar things for getuid and getgid, It also allows ioctl numbers that have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It also turns on the COMPAT_OLDSOCK code which generally only kicks in when compat bits are set, but in one place it allows a shorter unix domain socket path length to be compatible unconditionally. The compatibility TTY stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation code. The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > kernel in chroot this way. Since sometimes I get bug reports about this > stuff, there are some users of it. I believe it is important to be able > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > binary compatibility we offer. > > COMPAT_43 is there to stay as far as there are people willing to maintain > it. There are more than one. > I think it's safe to retain on i386. amd64 is less clear to me, but I'd lean yes. All the other platforms I'd agree with gleb: why do we need it in the kernels by default (and maybe why do we need to support it at all)? Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350824 - stable/12/sys/dev/psci
Author: mmel
Date: Fri Aug 9 12:15:23 2019
New Revision: 350824
URL: https://svnweb.freebsd.org/changeset/base/350824
Log:
MFC r345299:
PSCI: Don't take missing implementation of psci get_version() as fatal.
Minimalistic PSCI implementation in U-Boot doesn't implement get_version()
method for some SoC. In this case, use PSCI version declared by 'psci' node
in DT as fallback.
Modified:
stable/12/sys/dev/psci/psci.c
stable/12/sys/dev/psci/psci.h
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/dev/psci/psci.c
==
--- stable/12/sys/dev/psci/psci.c Fri Aug 9 11:21:42 2019
(r350823)
+++ stable/12/sys/dev/psci/psci.c Fri Aug 9 12:15:23 2019
(r350824)
@@ -79,9 +79,9 @@ struct psci_softc {
};
#ifdef FDT
-static int psci_v0_1_init(device_t dev);
+static int psci_v0_1_init(device_t dev, int default_version);
#endif
-static int psci_v0_2_init(device_t dev);
+static int psci_v0_2_init(device_t dev, int default_version);
struct psci_softc *psci_softc = NULL;
@@ -96,15 +96,35 @@ struct psci_softc *psci_softc = NULL;
#endif
#ifdef FDT
+struct psci_init_def {
+ int default_version;
+ psci_initfn_t psci_init;
+};
+
+static struct psci_init_def psci_v1_0_init_def = {
+ .default_version = (1 << 16) | 0,
+ .psci_init = psci_v0_2_init
+};
+
+static struct psci_init_def psci_v0_2_init_def = {
+ .default_version = (0 << 16) | 2,
+ .psci_init = psci_v0_2_init
+};
+
+static struct psci_init_def psci_v0_1_init_def = {
+ .default_version = (0 << 16) | 1,
+ .psci_init = psci_v0_1_init
+};
+
static struct ofw_compat_data compat_data[] = {
- {"arm,psci-1.0",(uintptr_t)psci_v0_2_init},
- {"arm,psci-0.2",(uintptr_t)psci_v0_2_init},
- {"arm,psci",(uintptr_t)psci_v0_1_init},
+ {"arm,psci-1.0",(uintptr_t)_v1_0_init_def},
+ {"arm,psci-0.2",(uintptr_t)_v0_2_init_def},
+ {"arm,psci",(uintptr_t)_v0_1_init_def},
{NULL, 0}
};
#endif
-static int psci_attach(device_t, psci_initfn_t);
+static int psci_attach(device_t, psci_initfn_t, int);
static void psci_shutdown(void *, int);
static int psci_find_callfn(psci_callfn_t *);
@@ -198,12 +218,13 @@ static int
psci_fdt_attach(device_t dev)
{
const struct ofw_compat_data *ocd;
- psci_initfn_t psci_init;
+ struct psci_init_def *psci_init_def;
ocd = ofw_bus_search_compatible(dev, compat_data);
- psci_init = (psci_initfn_t)ocd->ocd_data;
+ psci_init_def = (struct psci_init_def *)ocd->ocd_data;
- return (psci_attach(dev, psci_init));
+ return (psci_attach(dev, psci_init_def->psci_init,
+ psci_init_def->default_version));
}
#endif
@@ -304,12 +325,12 @@ static int
psci_acpi_attach(device_t dev)
{
- return (psci_attach(dev, psci_v0_2_init));
+ return (psci_attach(dev, psci_v0_2_init, PSCI_RETVAL_NOT_SUPPORTED));
}
#endif
static int
-psci_attach(device_t dev, psci_initfn_t psci_init)
+psci_attach(device_t dev, psci_initfn_t psci_init, int default_version)
{
struct psci_softc *sc = device_get_softc(dev);
@@ -317,7 +338,7 @@ psci_attach(device_t dev, psci_initfn_t psci_init)
return (ENXIO);
KASSERT(psci_init != NULL, ("PSCI init function cannot be NULL"));
- if (psci_init(dev))
+ if (psci_init(dev, default_version))
return (ENXIO);
psci_softc = sc;
@@ -464,7 +485,7 @@ psci_reset(void)
#ifdef FDT
/* Only support PSCI 0.1 on FDT */
static int
-psci_v0_1_init(device_t dev)
+psci_v0_1_init(device_t dev, int default_version __unused)
{
struct psci_softc *sc = device_get_softc(dev);
int psci_fn;
@@ -510,7 +531,7 @@ psci_v0_1_init(device_t dev)
#endif
static int
-psci_v0_2_init(device_t dev)
+psci_v0_2_init(device_t dev, int default_version)
{
struct psci_softc *sc = device_get_softc(dev);
int version;
@@ -529,8 +550,20 @@ psci_v0_2_init(device_t dev)
version = _psci_get_version(sc);
- if (version == PSCI_RETVAL_NOT_SUPPORTED)
- return (1);
+ /*
+* U-Boot PSCI implementation doesn't have psci_get_version()
+* method implemented for many boards. In this case, use the version
+* readed from FDT as fallback. No fallback method for ACPI.
+*/
+ if (version == PSCI_RETVAL_NOT_SUPPORTED) {
+ if (default_version == PSCI_RETVAL_NOT_SUPPORTED)
+ return (1);
+
+ version = default_version;
+ printf("PSCI get_version() function is not implemented, "
+ " assuming v%d.%d\n", PSCI_VER_MAJOR(version),
+ PSCI_VER_MINOR(version));
+ }
sc->psci_version = version;
if
svn commit: r350823 - stable/12/sys/dev/cpufreq
Author: mmel
Date: Fri Aug 9 11:21:42 2019
New Revision: 350823
URL: https://svnweb.freebsd.org/changeset/base/350823
Log:
MFC r345297:
Improve cpufreq_dt.
- older DT can use 'cpu0-supply' property for power supply binding. -
don't
expect that actual CPU frequency is contained in CPU
operational point table, but read current CPU voltage directly from
reguator. Typically, u-boot can set starting CPU frequency to any value.
Modified:
stable/12/sys/dev/cpufreq/cpufreq_dt.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/dev/cpufreq/cpufreq_dt.c
==
--- stable/12/sys/dev/cpufreq/cpufreq_dt.c Fri Aug 9 11:20:05 2019
(r350822)
+++ stable/12/sys/dev/cpufreq/cpufreq_dt.c Fri Aug 9 11:21:42 2019
(r350823)
@@ -166,7 +166,7 @@ cpufreq_dt_set(device_t dev, const struct cf_setting *
struct cpufreq_dt_softc *sc;
const struct cpufreq_dt_opp *opp, *copp;
uint64_t freq;
- int error = 0;
+ int uvolt, error;
sc = device_get_softc(dev);
@@ -174,23 +174,38 @@ cpufreq_dt_set(device_t dev, const struct cf_setting *
device_printf(dev, "Can't get current clk freq\n");
return (ENXIO);
}
+ /* Try to get current valtage by using regulator first. */
+ error = regulator_get_voltage(sc->reg, );
+ if (error != 0) {
+ /*
+* Try oppoints table as backup way. However,
+* this is insufficient because the actual processor
+* frequency may not be in the table. PLL frequency
+* granularity can be different that granularity of
+* oppoint table.
+*/
+ copp = cpufreq_dt_find_opp(sc->dev, freq);
+ if (copp == NULL) {
+ device_printf(dev,
+ "Can't find the current freq in opp\n");
+ return (ENOENT);
+ }
+ uvolt = copp->uvolt_target;
- DEBUG(sc->dev, "Current freq %ju\n", freq);
- DEBUG(sc->dev, "Target freq %ju\n", (uint64_t)set->freq * 100);
- copp = cpufreq_dt_find_opp(sc->dev, freq);
- if (copp == NULL) {
- device_printf(dev, "Can't find the current freq in opp\n");
- return (ENOENT);
}
+
opp = cpufreq_dt_find_opp(sc->dev, set->freq * 100);
if (opp == NULL) {
device_printf(dev, "Couldn't find an opp for this freq\n");
return (EINVAL);
}
+ DEBUG(sc->dev, "Current freq %ju, uvolt: %d\n", freq, uvolt);
+ DEBUG(sc->dev, "Target freq %ju, , uvolt: %d\n",
+ opp->freq, opp->uvolt_target);
- if (copp->uvolt_target < opp->uvolt_target) {
+ if (uvolt < opp->uvolt_target) {
DEBUG(dev, "Changing regulator from %u to %u\n",
- copp->uvolt_target, opp->uvolt_target);
+ uvolt, opp->uvolt_target);
error = regulator_set_voltage(sc->reg,
opp->uvolt_min,
opp->uvolt_max);
@@ -201,7 +216,7 @@ cpufreq_dt_set(device_t dev, const struct cf_setting *
}
DEBUG(dev, "Setting clk to %ju\n", opp->freq);
- error = clk_set_freq(sc->clk, opp->freq, 0);
+ error = clk_set_freq(sc->clk, opp->freq, CLK_SET_ROUND_DOWN);
if (error != 0) {
DEBUG(dev, "Failed, backout\n");
/* Restore previous voltage (best effort) */
@@ -211,7 +226,9 @@ cpufreq_dt_set(device_t dev, const struct cf_setting *
return (ENXIO);
}
- if (copp->uvolt_target > opp->uvolt_target) {
+ if (uvolt > opp->uvolt_target) {
+ DEBUG(dev, "Changing regulator from %u to %u\n",
+ uvolt, opp->uvolt_target);
error = regulator_set_voltage(sc->reg,
opp->uvolt_min,
opp->uvolt_max);
@@ -219,8 +236,7 @@ cpufreq_dt_set(device_t dev, const struct cf_setting *
DEBUG(dev, "Failed to switch regulator to %d\n",
opp->uvolt_target);
/* Restore previous CPU frequency (best effort) */
- (void)clk_set_freq(sc->clk,
- copp->freq, 0);
+ (void)clk_set_freq(sc->clk, copp->freq, 0);
return (ENXIO);
}
}
@@ -277,7 +293,8 @@ cpufreq_dt_identify(driver_t *driver, device_t parent)
/* The cpu@0 node must have the following properties */
if (!OF_hasprop(node, "clocks") ||
- !OF_hasprop(node, "cpu-supply"))
+ (!OF_hasprop(node, "cpu-supply") &&
+ !OF_hasprop(node, "cpu0-supply")))
return;
if (!OF_hasprop(node, "operating-points")
svn commit: r350822 - stable/12/sys/arm/include
Author: mmel
Date: Fri Aug 9 11:20:05 2019
New Revision: 350822
URL: https://svnweb.freebsd.org/changeset/base/350822
Log:
MFC r345296:
Use named field's initializer when constructing _platform structure.
In
current code, the delay argument in FDT_PLATFORM_DEF(2) improperly
initialize
refs field from kobj_class structure instead of delay_count field. This
causes not working DELAY() function (due to never initialized delay_count)
in
earlier boot stages, until the first timer was attached.
Modified:
stable/12/sys/arm/include/platformvar.h
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/arm/include/platformvar.h
==
--- stable/12/sys/arm/include/platformvar.h Fri Aug 9 10:33:23 2019
(r350821)
+++ stable/12/sys/arm/include/platformvar.h Fri Aug 9 11:20:05 2019
(r350822)
@@ -90,22 +90,22 @@ typedef struct fdt_platform_class fdt_platform_def_t;
extern platform_method_t fdt_platform_methods[];
-#define FDT_PLATFORM_DEF2(NAME, VAR_NAME, NAME_STR, size, compatible, \
-delay) \
-CTASSERT(delay > 0); \
+#define FDT_PLATFORM_DEF2(NAME, VAR_NAME, NAME_STR, _size, _compatible,
\
+_delay)\
+CTASSERT(_delay > 0); \
static fdt_platform_def_t VAR_NAME ## _fdt_platform = {
\
.name = NAME_STR, \
.methods = fdt_platform_methods,\
- .fdt_compatible = compatible, \
+ .fdt_compatible = _compatible, \
}; \
static kobj_class_t VAR_NAME ## _baseclasses[] = \
{ (kobj_class_t)_NAME ## _fdt_platform, NULL }; \
static platform_def_t VAR_NAME ## _platform = {
\
- NAME_STR, \
- NAME ## _methods, \
- size, \
- VAR_NAME ## _baseclasses, \
- delay, \
+ .name = NAME_STR, \
+ .methods = NAME ## _methods,\
+ .size = _size, \
+ .baseclasses = VAR_NAME ## _baseclasses,\
+ .delay_count = _delay, \
}; \
DATA_SET(platform_set, VAR_NAME ## _platform)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350821 - in stable/12/sys/dev/extres: phy regulator syscon
Author: mmel Date: Fri Aug 9 10:33:23 2019 New Revision: 350821 URL: https://svnweb.freebsd.org/changeset/base/350821 Log: MFC r345295: extres: Unify error codes for _get_by_ofw_property() methods. Return: - ENOENT if requested property doesn't exist - ENODEV if producer device is not (yet) attached - ENXIO otherwise Modified: stable/12/sys/dev/extres/phy/phy.c stable/12/sys/dev/extres/regulator/regulator.c stable/12/sys/dev/extres/syscon/syscon.c Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/dev/extres/phy/phy.c == --- stable/12/sys/dev/extres/phy/phy.c Fri Aug 9 10:31:53 2019 (r350820) +++ stable/12/sys/dev/extres/phy/phy.c Fri Aug 9 10:33:23 2019 (r350821) @@ -517,7 +517,7 @@ phy_get_by_ofw_property(device_t consumer_dev, phandle ncells = OF_getencprop_alloc_multi(cnode, name, sizeof(pcell_t), (void **)); if (ncells < 1) - return (ENXIO); + return (ENOENT); /* Tranlate provider to device. */ phydev = OF_device_from_xref(cells[0]); Modified: stable/12/sys/dev/extres/regulator/regulator.c == --- stable/12/sys/dev/extres/regulator/regulator.c Fri Aug 9 10:31:53 2019(r350820) +++ stable/12/sys/dev/extres/regulator/regulator.c Fri Aug 9 10:33:23 2019(r350821) @@ -1091,7 +1091,7 @@ regulator_get_by_ofw_property(device_t cdev, phandle_t ncells = OF_getencprop_alloc_multi(cnode, name, sizeof(*cells), (void **)); if (ncells <= 0) - return (ENXIO); + return (ENOENT); /* Translate xref to device */ regdev = OF_device_from_xref(cells[0]); Modified: stable/12/sys/dev/extres/syscon/syscon.c == --- stable/12/sys/dev/extres/syscon/syscon.cFri Aug 9 10:31:53 2019 (r350820) +++ stable/12/sys/dev/extres/syscon/syscon.cFri Aug 9 10:33:23 2019 (r350821) @@ -238,7 +238,7 @@ syscon_get_by_ofw_property(device_t cdev, phandle_t cn ncells = OF_getencprop_alloc_multi(cnode, name, sizeof(pcell_t), (void **)); if (ncells < 1) - return (ENXIO); + return (ENOENT); /* Translate to syscon node. */ SYSCON_TOPO_SLOCK(); ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350820 - stable/12/sys/arm/nvidia
Author: mmel
Date: Fri Aug 9 10:31:53 2019
New Revision: 350820
URL: https://svnweb.freebsd.org/changeset/base/350820
Log:
MFC r343963:
Don't allocate same clock twice..
Modified:
stable/12/sys/arm/nvidia/tegra_sdhci.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/arm/nvidia/tegra_sdhci.c
==
--- stable/12/sys/arm/nvidia/tegra_sdhci.c Fri Aug 9 10:28:20 2019
(r350819)
+++ stable/12/sys/arm/nvidia/tegra_sdhci.c Fri Aug 9 10:31:53 2019
(r350820)
@@ -313,13 +313,6 @@ tegra_sdhci_attach(device_t dev)
rv = clk_get_by_ofw_index(dev, 0, 0, >clk);
if (rv != 0) {
-
- device_printf(dev, "Cannot get clock\n");
- goto fail;
- }
-
- rv = clk_get_by_ofw_index(dev, 0, 0, >clk);
- if (rv != 0) {
device_printf(dev, "Cannot get clock\n");
goto fail;
}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350819 - stable/12/sys/arm/arm
Author: mmel
Date: Fri Aug 9 10:28:20 2019
New Revision: 350819
URL: https://svnweb.freebsd.org/changeset/base/350819
Log:
MFC r343962,r343965:
r343962:
Properly handle alignment requests bigger that page size.
- for now, alignments bigger that page size is allowed only for buffers
allocated by bus_dmamem_alloc(), cover this fact by KASSERT.
- never bounce buffers allocated by bus_dmamem_alloc(), these always
comply
with the required rules (alignment, boundary, address range).
r343965:
Fix bug introduced by r343962. DMAMAP_DMAMEM_ALLOC is property of dmamap,
not dmatag.
Modified:
stable/12/sys/arm/arm/busdma_machdep-v6.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/arm/arm/busdma_machdep-v6.c
==
--- stable/12/sys/arm/arm/busdma_machdep-v6.c Fri Aug 9 10:00:11 2019
(r350818)
+++ stable/12/sys/arm/arm/busdma_machdep-v6.c Fri Aug 9 10:28:20 2019
(r350819)
@@ -339,16 +339,27 @@ cacheline_bounce(bus_dmamap_t map, bus_addr_t addr, bu
*
* Note that the addr argument might be either virtual or physical. It doesn't
* matter because we only look at the low-order bits, which are the same in
both
- * address spaces.
+ * address spaces and maximum alignment of generic buffer is limited up to page
+ * size.
+ * Bouncing of buffers allocated by bus_dmamem_alloc()is not necessary, these
+ * always comply with the required rules (alignment, boundary, and address
+ * range).
*/
static __inline int
might_bounce(bus_dma_tag_t dmat, bus_dmamap_t map, bus_addr_t addr,
bus_size_t size)
{
- return ((dmat->flags & BUS_DMA_EXCL_BOUNCE) ||
+ KASSERT(map->flags & DMAMAP_DMAMEM_ALLOC ||
+ dmat->alignment <= PAGE_SIZE,
+ ("%s: unsupported alignment (0x%08lx) for buffer not "
+ "allocated by bus_dmamem_alloc()",
+ __func__, dmat->alignment));
+
+ return (!(map->flags & DMAMAP_DMAMEM_ALLOC) &&
+ ((dmat->flags & BUS_DMA_EXCL_BOUNCE) ||
alignment_bounce(dmat, addr) ||
- cacheline_bounce(map, addr, size));
+ cacheline_bounce(map, addr, size)));
}
/*
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350818 - stable/12/sys/dts/arm
Author: mmel
Date: Fri Aug 9 10:00:11 2019
New Revision: 350818
URL: https://svnweb.freebsd.org/changeset/base/350818
Log:
MFC r343828:
Adapt FreeBSD specific DT stub for Jetson TK1 board to be consistent with
update of devicetree to 4.19 in r340337. Our build system doesn't provide
dependencies for included DTS files, so nobody noticed this issue for long
time.
Modified:
stable/12/sys/dts/arm/tegra124-jetson-tk1-fbsd.dts
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/dts/arm/tegra124-jetson-tk1-fbsd.dts
==
--- stable/12/sys/dts/arm/tegra124-jetson-tk1-fbsd.dts Fri Aug 9 09:57:04
2019(r350817)
+++ stable/12/sys/dts/arm/tegra124-jetson-tk1-fbsd.dts Fri Aug 9 10:00:11
2019(r350818)
@@ -38,7 +38,7 @@
stdout =
};
- memory {
+ memory@8000 {
/* reg = <0x0 0x8000 0x0 0x8000>; */
reg = <0x0 0x8000 0x0 0x7000>;
};
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350817 - stable/12/sys/dev/extres/phy
Author: mmel
Date: Fri Aug 9 09:57:04 2019
New Revision: 350817
URL: https://svnweb.freebsd.org/changeset/base/350817
Log:
MFC r343498:
Properly define and declare phynode_topo_lock, it should be single global
variable.
Modified:
stable/12/sys/dev/extres/phy/phy.c
stable/12/sys/dev/extres/phy/phy_internal.h
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/dev/extres/phy/phy.c
==
--- stable/12/sys/dev/extres/phy/phy.c Fri Aug 9 08:58:09 2019
(r350816)
+++ stable/12/sys/dev/extres/phy/phy.c Fri Aug 9 09:57:04 2019
(r350817)
@@ -68,7 +68,7 @@ static phynode_method_t phynode_methods[] = {
DEFINE_CLASS_0(phynode, phynode_class, phynode_methods, 0);
static phynode_list_t phynode_list = TAILQ_HEAD_INITIALIZER(phynode_list);
-
+struct sx phynode_topo_lock;
SX_SYSINIT(phy_topology, _topo_lock, "Phy topology lock");
/*
Modified: stable/12/sys/dev/extres/phy/phy_internal.h
==
--- stable/12/sys/dev/extres/phy/phy_internal.h Fri Aug 9 08:58:09 2019
(r350816)
+++ stable/12/sys/dev/extres/phy/phy_internal.h Fri Aug 9 09:57:04 2019
(r350817)
@@ -78,6 +78,6 @@ struct phy {
#define PHYNODE_XLOCK(_sc) sx_xlock(&((_sc)->lock))
#define PHYNODE_UNLOCK(_sc)sx_unlock(&((_sc)->lock))
-struct sx phynode_topo_lock;
+extern struct sx phynode_topo_lock;
#endif /* DEV_EXTRES_PHY_INTERNAL_H */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r350816 - head/sys/netipsec
Author: ae
Date: Fri Aug 9 08:58:09 2019
New Revision: 350816
URL: https://svnweb.freebsd.org/changeset/base/350816
Log:
Add missing new line in several log messages.
PR: 239694
MFC after:1 week
Modified:
head/sys/netipsec/key.c
Modified: head/sys/netipsec/key.c
==
--- head/sys/netipsec/key.c Fri Aug 9 05:18:59 2019(r350815)
+++ head/sys/netipsec/key.c Fri Aug 9 08:58:09 2019(r350816)
@@ -284,7 +284,7 @@ key_addrprotohash(const union sockaddr_union *src,
#endif
default:
hval = 0;
- ipseclog((LOG_DEBUG, "%s: unknown address family %d",
+ ipseclog((LOG_DEBUG, "%s: unknown address family %d\n",
__func__, dst->sa.sa_family));
}
return (hval);
@@ -2039,8 +2039,8 @@ key_spdadd(struct socket *so, struct mbuf *m, const st
key_freesp();
} else {
key_freesp();
- ipseclog((LOG_DEBUG, "%s: a SP entry exists already.",
- __func__));
+ ipseclog((LOG_DEBUG,
+ "%s: a SP entry exists already.\n", __func__));
return (key_senderror(so, m, EEXIST));
}
}
@@ -5409,7 +5409,7 @@ key_update(struct socket *so, struct mbuf *m, const st
}
/* saidx should match with SA. */
if (key_cmpsaidx(>sah->saidx, , CMP_MODE_REQID) == 0) {
- ipseclog((LOG_DEBUG, "%s: saidx mismatched for SPI %u",
+ ipseclog((LOG_DEBUG, "%s: saidx mismatched for SPI %u\n",
__func__, ntohl(sav->spi)));
key_freesav();
return key_senderror(so, m, ESRCH);
@@ -6885,14 +6885,14 @@ key_acqdone(const struct secasindex *saidx, uint32_t s
if (acq != NULL) {
if (key_cmpsaidx(>saidx, saidx, CMP_EXACTLY) == 0) {
ipseclog((LOG_DEBUG,
- "%s: Mismatched saidx for ACQ %u", __func__, seq));
+ "%s: Mismatched saidx for ACQ %u\n", __func__,
seq));
acq = NULL;
} else {
acq->created = 0;
}
} else {
ipseclog((LOG_DEBUG,
- "%s: ACQ %u is not found.", __func__, seq));
+ "%s: ACQ %u is not found.\n", __func__, seq));
}
ACQ_UNLOCK();
if (acq == NULL)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > Hi, > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > application that would require this compatibility. > > > > A more general question is how far in the future are we going > > to carry COMPAT_43 for i386/amd64? > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > behavior modifications. Before we thinned the ABIs we supported, it was > necessary for them as well. The biggest behavior change is around signals. > It is weird to sort out and nobody has done the deep analysis to see what > is truly unused and what is there for compat with Linux and other SysV > systems... I am not aware of any changes that COMPAT_43 provides for the signal handling semantic, except a minor adjustment for interpretation of zero-sized stack for sigaltstack(2). The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 kernel in chroot this way. Since sometimes I get bug reports about this stuff, there are some users of it. I believe it is important to be able to run any FreeBSD binary for PR purposes, to wave the flag of excellent binary compatibility we offer. COMPAT_43 is there to stay as far as there are people willing to maintain it. There are more than one. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
