svn commit: r330686 - head/contrib/llvm/lib/Target/ARM
Author: dim
Date: Fri Mar 9 09:21:22 2018
New Revision: 330686
URL: https://svnweb.freebsd.org/changeset/base/330686
Log:
Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer):
[ARM] Fix for PR36577
Don't PerformSHLSimplify if the given node is used by a node that
also uses a constant because we may get stuck in an infinite combine
loop.
bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577
Patch by Sam Parker.
Differential Revision: https://reviews.llvm.org/D44097
This fixes a hang when compiling one particular file in java/openjdk8
for armv6 and armv7.
Reported by: swills
PR: 226388
Modified:
head/contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp
Modified: head/contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp
==
--- head/contrib/llvm/lib/Target/ARM/ARMISelLowering.cppFri Mar 9
05:55:53 2018(r330685)
+++ head/contrib/llvm/lib/Target/ARM/ARMISelLowering.cppFri Mar 9
09:21:22 2018(r330686)
@@ -10201,7 +10201,14 @@ static SDValue PerformSHLSimplify(SDNode *N,
case ISD::XOR:
case ISD::SETCC:
case ARMISD::CMP:
- // Check that its not already using a shl.
+ // Check that the user isn't already using a constant because there
+ // aren't any instructions that support an immediate operand and a
+ // shifted operand.
+ if (isa(U->getOperand(0)) ||
+ isa(U->getOperand(1)))
+return SDValue();
+
+ // Check that it's not already using a shift.
if (U->getOperand(0).getOpcode() == ISD::SHL ||
U->getOperand(1).getOpcode() == ISD::SHL)
return SDValue();
@@ -10223,8 +10230,6 @@ static SDValue PerformSHLSimplify(SDNode *N,
if (!C1ShlC2 || !C2)
return SDValue();
- DEBUG(dbgs() << "Trying to simplify shl: "; N->dump());
-
APInt C2Int = C2->getAPIntValue();
APInt C1Int = C1ShlC2->getAPIntValue();
@@ -10238,12 +10243,12 @@ static SDValue PerformSHLSimplify(SDNode *N,
C1Int.lshrInPlace(C2Int);
// The immediates are encoded as an 8-bit value that can be rotated.
- unsigned Zeros = C1Int.countLeadingZeros() + C1Int.countTrailingZeros();
- if (C1Int.getBitWidth() - Zeros > 8)
-return SDValue();
+ auto LargeImm = [](const APInt &Imm) {
+unsigned Zeros = Imm.countLeadingZeros() + Imm.countTrailingZeros();
+return Imm.getBitWidth() - Zeros > 8;
+ };
- Zeros = C2Int.countLeadingZeros() + C2Int.countTrailingZeros();
- if (C2Int.getBitWidth() - Zeros > 8)
+ if (LargeImm(C1Int) || LargeImm(C2Int))
return SDValue();
SelectionDAG &DAG = DCI.DAG;
@@ -10253,6 +10258,10 @@ static SDValue PerformSHLSimplify(SDNode *N,
DAG.getConstant(C1Int, dl, MVT::i32));
// Shift left to compensate for the lshr of C1Int.
SDValue Res = DAG.getNode(ISD::SHL, dl, MVT::i32, BinOp, SHL.getOperand(1));
+
+ DEBUG(dbgs() << "Simplify shl use:\n"; SHL.getOperand(0).dump(); SHL.dump();
+N->dump());
+ DEBUG(dbgs() << "Into:\n"; X.dump(); BinOp.dump(); Res.dump());
DAG.ReplaceAllUsesWith(SDValue(N, 0), Res);
return SDValue(N, 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: r330663 - head/sys/kern
On Thu, 8 Mar 2018, Conrad Meyer wrote:
On Thu, Mar 8, 2018 at 8:42 PM, Bruce Evans wrote:
On Thu, 8 Mar 2018, Mark Johnston wrote:
...
+++ head/sys/kern/kern_shutdown.c Thu Mar 8 17:04:36 2018
(r330663)
@@ -1115,6 +1115,12 @@ dump_check_bounds(struct dumperinfo *di, off_t
offset,
if (length != 0 && (offset < di->mediaoffset ||
offset - di->mediaoffset + length > di->mediasize)) {
+ if (di->kdcomp != NULL && offset >= di->mediaoffset) {
+ printf(
+ "Compressed dump failed to fit in device
boundaries.\n");
+ return (E2BIG);
+ }
+
Style bug: extra blank line. Even the outer if statements in this function
are missing this error.
No. Style(9) does not and should not require the complete absence of
blank lines. Committers are free to use their best judgement on how
to separate blocks of code. I think Mark's decision is eminently
reasonable.
style(9) does require this. This is hard to see since the style guide
has been mangled by converting it into a man page, with markup in non
C-code and lots of blank lines to separate the markup. See
/usr/src/admin/style/style in 4.4BSD or /usr/src/share/misc/style in
NetBSD for non-mangled versions. These are pure C code which give
many rules implicitly by example. All versions give 2 or 3 rules for
leaving a blank line between groups of header files. These rules are
somewhat needed since leaving blank lines is so unusual.
It is also the default for indent(1) (indent -sob). indent removes far too
many blank lines by default. I like to have optional blank lines only
before blocks of code headed by a comment (with the blank line before the
comment). But is more common in KNF code to not have a blank line before
a block comment (since the "/*" for the first line of the comment is an
adequate separator).
Blank lines might be used to separate sections of code, but the above
blank line is a very large style bug since it separates related code,
while the style nearby is to not separate even unrelated code.
kern_shutdown.c has very few extra blank lines. indent only wants to
remove 2. I see a few more:
- the include of sys/signalvar.h is separated from all other includes
by a blank line (and more so by not sorting it into the sys includes
section)
- similarly for the include of machine/stdarg.h. This has an attached
comment about K&R support that wasn't needed even when K&R was supported.
- boot() has an extra blank line between initializing waittime() and
calling sync(). These are unrelated, but the code is so simple (just
2 statements) that splitting it up is not useful. Elsewhere, boot()
uses lots of little sections headed by comments with a block line before
the comments except for some block comments.
- panic() has a blank line before a va_start() but no blank line after the
matching va_end(), then blank line after the next statement. The second
blank line is correct for matching the first one since the next statement
is related (it completes printing a message).
- kproc_shutdown() has a bogus blank line after a return statement, and a
nonsense blank line to separate checking of 'error' from setting it.
- kthread() copies the bad style of kproc_shutdown() perfectly.
Dumper code had no extra blank lines. This is easy enough since it is small
(less than 10% of the file).
printf("Attempt to write outside dump device
boundaries.\n"
"offset(%jd), mediaoffset(%jd), length(%ju),
mediasize(%jd).\n",
(intmax_t)offset, (intmax_t)di->mediaoffset,
...
Other style bugs:
- capitalization of error messages
- termination of error messages with a period
Why do you think these are style bugs?
Because they are. Error messages are conventionally not capitalized or
terminated with a period. You snipped my partial explanation by example
that err(3) almost enforces this in userland by not supporting it.
Userland messages look like "foo: bar: Bad style", where 'foo' is the program
name and it would be unUnix-like to capitalize it; 'bar' might be a function
name and it would be Unix-like to capitalize that too, or it might be an
English word and then it is unclear whose style rules apply (IIRC,
capitalization after a colon only depends on style); and "Bad style" is
strerror(ESTYLE) -- for some reason, strings returned by strerror() are
always capitalized so they match some style rules for colons, and then using
different style rules for 'bar' is either a bug or a feature.
There is not much enforcement of this in the kernel. panic() is a bit
like err(). Using device_printf() gives a uniform style for the first
word in device driver messages. It would be unUnix-line to capitalize
device names, so this gives uncapitalized messages if the style rule
used for capitalization after colons is to not capitalize.
Bruce
___
svn-src-he
svn commit: r330687 - head/sys/arm64/arm64
Author: andrew Date: Fri Mar 9 10:34:44 2018 New Revision: 330687 URL: https://svnweb.freebsd.org/changeset/base/330687 Log: Use the correct address to write back to memory in the GICv3 ITS driver. This seems to no be needed on supported hardware as they are cache-coherent, however this may not be the case on all platforms. Sponsored by: DARPA, AFRL Modified: head/sys/arm64/arm64/gicv3_its.c Modified: head/sys/arm64/arm64/gicv3_its.c == --- head/sys/arm64/arm64/gicv3_its.cFri Mar 9 09:21:22 2018 (r330686) +++ head/sys/arm64/arm64/gicv3_its.cFri Mar 9 10:34:44 2018 (r330687) @@ -567,7 +567,7 @@ gicv3_its_pendtables_init(struct gicv3_its_softc *sc) 0, LPI_PENDTAB_MAX_ADDR, LPI_PENDTAB_ALIGN, 0); /* Flush so the ITS can see the memory */ - cpu_dcache_wb_range((vm_offset_t)sc->sc_pend_base, + cpu_dcache_wb_range((vm_offset_t)sc->sc_pend_base[i], LPI_PENDTAB_SIZE); } } ___ 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: r330688 - in head/sys: dev/bwn dev/ral dev/usb/wlan net80211
Author: avos
Date: Fri Mar 9 11:33:56 2018
New Revision: 330688
URL: https://svnweb.freebsd.org/changeset/base/330688
Log:
net80211: wrap protection frame allocation into ieee80211_alloc_prot()
Move copy-pasted code for RTS/CTS frame allocation into net80211.
While here, add stat / debug message for allocation failures
(copied from run(4)) + return error here in bwn(4).
Reviewed by: adrian
Differential Revision:https://reviews.freebsd.org/D14628
Modified:
head/sys/dev/bwn/if_bwn.c
head/sys/dev/ral/rt2560.c
head/sys/dev/ral/rt2661.c
head/sys/dev/usb/wlan/if_rum.c
head/sys/dev/usb/wlan/if_run.c
head/sys/dev/usb/wlan/if_ural.c
head/sys/net80211/ieee80211_output.c
head/sys/net80211/ieee80211_proto.h
Modified: head/sys/dev/bwn/if_bwn.c
==
--- head/sys/dev/bwn/if_bwn.c Fri Mar 9 10:34:44 2018(r330687)
+++ head/sys/dev/bwn/if_bwn.c Fri Mar 9 11:33:56 2018(r330688)
@@ -6401,15 +6401,14 @@ bwn_set_txhdr(struct bwn_mac *mac, struct ieee80211_no
struct bwn_softc *sc = mac->mac_sc;
struct ieee80211_frame *wh;
struct ieee80211_frame *protwh;
- struct ieee80211_frame_cts *cts;
- struct ieee80211_frame_rts *rts;
const struct ieee80211_txparam *tp = ni->ni_txparms;
struct ieee80211vap *vap = ni->ni_vap;
struct ieee80211com *ic = &sc->sc_ic;
struct mbuf *mprot;
+ uint8_t *prot_ptr;
unsigned int len;
uint32_t macctl = 0;
- int protdur, rts_rate, rts_rate_fb, ismcast, isshort, rix, type;
+ int rts_rate, rts_rate_fb, ismcast, isshort, rix, type;
uint16_t phyctl = 0;
uint8_t rate, rate_fb;
int fill_phy_ctl1 = 0;
@@ -6528,7 +6527,8 @@ bwn_set_txhdr(struct bwn_mac *mac, struct ieee80211_no
m->m_pkthdr.len + IEEE80211_CRC_LEN > vap->iv_rtsthreshold)
macctl |= BWN_TX_MAC_LONGFRAME;
- if (ic->ic_flags & IEEE80211_F_USEPROT) {
+ if ((ic->ic_flags & IEEE80211_F_USEPROT) &&
+ ic->ic_protmode != IEEE80211_PROT_NONE) {
/* Note: don't fall back to CCK rates for 5G */
if (phy->gmode)
rts_rate = BWN_CCK_RATE_1MB;
@@ -6537,60 +6537,34 @@ bwn_set_txhdr(struct bwn_mac *mac, struct ieee80211_no
rts_rate_fb = bwn_get_fbrate(rts_rate);
/* XXX 'rate' here is hardware rate now, not the net80211 rate
*/
- protdur = ieee80211_compute_duration(ic->ic_rt,
- m->m_pkthdr.len, rate, isshort) +
- + ieee80211_ack_duration(ic->ic_rt, rate, isshort);
+ mprot = ieee80211_alloc_prot(ni, m, rate, ic->ic_protmode);
+ if (mprot == NULL) {
+ if_inc_counter(vap->iv_ifp, IFCOUNTER_OERRORS, 1);
+ device_printf(sc->sc_dev,
+ "could not allocate mbuf for protection mode %d\n",
+ ic->ic_protmode);
+ return (ENOBUFS);
+ }
- if (ic->ic_protmode == IEEE80211_PROT_CTSONLY) {
+ switch (mac->mac_fw.fw_hdr_format) {
+ case BWN_FW_HDR_351:
+ prot_ptr = txhdr->body.r351.rts_frame;
+ break;
+ case BWN_FW_HDR_410:
+ prot_ptr = txhdr->body.r410.rts_frame;
+ break;
+ case BWN_FW_HDR_598:
+ prot_ptr = txhdr->body.r598.rts_frame;
+ break;
+ }
- switch (mac->mac_fw.fw_hdr_format) {
- case BWN_FW_HDR_351:
- cts = (struct ieee80211_frame_cts *)
- txhdr->body.r351.rts_frame;
- break;
- case BWN_FW_HDR_410:
- cts = (struct ieee80211_frame_cts *)
- txhdr->body.r410.rts_frame;
- break;
- case BWN_FW_HDR_598:
- cts = (struct ieee80211_frame_cts *)
- txhdr->body.r598.rts_frame;
- break;
- }
+ bcopy(mtod(mprot, uint8_t *), prot_ptr, mprot->m_pkthdr.len);
+ m_freem(mprot);
- mprot = ieee80211_alloc_cts(ic, ni->ni_vap->iv_myaddr,
- protdur);
- KASSERT(mprot != NULL, ("failed to alloc mbuf\n"));
- bcopy(mtod(mprot, uint8_t *), (uint8_t *)cts,
- mprot->m_pkthdr.len);
- m_freem(mprot);
+ if (ic->ic_protmode == IEEE80211_PROT_CTSONLY) {
macctl |= BWN_TX_MAC_SEND_CTSTOSELF;
svn commit: r330689 - head/sys/compat/linuxkpi/common/src
Author: hselasky
Date: Fri Mar 9 12:16:55 2018
New Revision: 330689
URL: https://svnweb.freebsd.org/changeset/base/330689
Log:
Implement proper support for complete_all() in the LinuxKPI.
When complete_all() is called there might be multiple waiters. The
current implementation could only handle one waiter. Make sure the
completion is sticky when complete_all() is called to be compatible
with Linux.
Found by: Johannes Lundberg
MFC after:1 week
Sponsored by: Mellanox Technologies
Sponsored by: Limelight Networks
Modified:
head/sys/compat/linuxkpi/common/src/linux_compat.c
Modified: head/sys/compat/linuxkpi/common/src/linux_compat.c
==
--- head/sys/compat/linuxkpi/common/src/linux_compat.c Fri Mar 9 11:33:56
2018(r330688)
+++ head/sys/compat/linuxkpi/common/src/linux_compat.c Fri Mar 9 12:16:55
2018(r330689)
@@ -1779,11 +1779,14 @@ linux_complete_common(struct completion *c, int all)
int wakeup_swapper;
sleepq_lock(c);
- c->done++;
- if (all)
+ if (all) {
+ c->done = UINT_MAX;
wakeup_swapper = sleepq_broadcast(c, SLEEPQ_SLEEP, 0, 0);
- else
+ } else {
+ if (c->done != UINT_MAX)
+ c->done++;
wakeup_swapper = sleepq_signal(c, SLEEPQ_SLEEP, 0, 0);
+ }
sleepq_release(c);
if (wakeup_swapper)
kick_proc0();
@@ -1825,7 +1828,8 @@ linux_wait_for_common(struct completion *c, int flags)
} else
sleepq_wait(c, 0);
}
- c->done--;
+ if (c->done != UINT_MAX)
+ c->done--;
sleepq_release(c);
intr:
@@ -1878,7 +1882,8 @@ linux_wait_for_timeout_common(struct completion *c, in
goto done;
}
}
- c->done--;
+ if (c->done != UINT_MAX)
+ c->done--;
sleepq_release(c);
/* return how many jiffies are left */
@@ -1894,12 +1899,10 @@ linux_try_wait_for_completion(struct completion *c)
{
int isdone;
- isdone = 1;
sleepq_lock(c);
- if (c->done)
+ isdone = (c->done != 0);
+ if (c->done != 0 && c->done != UINT_MAX)
c->done--;
- else
- isdone = 0;
sleepq_release(c);
return (isdone);
}
@@ -1909,10 +1912,8 @@ linux_completion_done(struct completion *c)
{
int isdone;
- isdone = 1;
sleepq_lock(c);
- if (c->done == 0)
- isdone = 0;
+ isdone = (c->done != 0);
sleepq_release(c);
return (isdone);
}
___
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: r330690 - head/stand
Author: kevans
Date: Fri Mar 9 14:16:33 2018
New Revision: 330690
URL: https://svnweb.freebsd.org/changeset/base/330690
Log:
stand: Fix copy-paste-o, unbreaks libi386 lualoader build
The 32-bit version of liblua is, in fact, NOT libficl. =)
Reported by: emaste
Modified:
head/stand/loader.mk
Modified: head/stand/loader.mk
==
--- head/stand/loader.mkFri Mar 9 12:16:55 2018(r330689)
+++ head/stand/loader.mkFri Mar 9 14:16:33 2018(r330690)
@@ -149,7 +149,7 @@ LIBFICL32= ${BOOTOBJ}/ficl32/libficl.a
LIBLUA=${BOOTOBJ}/liblua/liblua.a
.if ${MACHINE} == "i386"
-LIBLUA32= ${LIBFICL}
+LIBLUA32= ${LIBLUA}
.else
LIBLUA32= ${BOOTOBJ}/liblua32/liblua.a
.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: r328011 - in head/sys/amd64/vmm: amd intel
On 8 March 2018 at 21:57, Kubilay Kocak wrote: > On 9/03/2018 8:57 am, Ed Maste wrote: >> On 15 January 2018 at 13:37, Tycho Nightingale wrote: >>> Author: tychon >>> Date: Mon Jan 15 18:37:03 2018 >>> New Revision: 328011 >>> URL: https://svnweb.freebsd.org/changeset/base/328011 >>> >>> Log: >>> Provide some mitigation against CVE-2017-5715 by clearing registers >>> upon returning from the guest which aren't immediately clobbered by >>> the host. This eradicates any remaining guest contents limiting their >>> usefulness in an exploit gadget. >> >> Will you MFC this to stable/11? > > Mitigations and related MFC's and SA's, etc for vulnerabilities, are > presumably all being coordinated and handled by secteam, with associated > (explicit) messaging when fixes don't apply to particular > branches/versions, no? Embargoed patches to address specific security vulnerabilities are handled by secteam, and are committed to all branches simultaneously. For cases like this, where it's a mitigation or other improvement that is already committed to CURRENT, it's best if the domain expert / original committer handles the merge. That said, I'm happy to take care of the merge if desired. ___ 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: r328011 - in head/sys/amd64/vmm: amd intel
> On Mar 9, 2018, at 9:26 AM, Ed Maste wrote: > > On 8 March 2018 at 21:57, Kubilay Kocak wrote: >> On 9/03/2018 8:57 am, Ed Maste wrote: >>> On 15 January 2018 at 13:37, Tycho Nightingale wrote: Author: tychon Date: Mon Jan 15 18:37:03 2018 New Revision: 328011 URL: https://svnweb.freebsd.org/changeset/base/328011 Log: Provide some mitigation against CVE-2017-5715 by clearing registers upon returning from the guest which aren't immediately clobbered by the host. This eradicates any remaining guest contents limiting their usefulness in an exploit gadget. >>> >>> Will you MFC this to stable/11? >> >> Mitigations and related MFC's and SA's, etc for vulnerabilities, are >> presumably all being coordinated and handled by secteam, with associated >> (explicit) messaging when fixes don't apply to particular >> branches/versions, no? > > Embargoed patches to address specific security vulnerabilities are > handled by secteam, and are committed to all branches simultaneously. > > For cases like this, where it's a mitigation or other improvement that > is already committed to CURRENT, it's best if the domain expert / > original committer handles the merge. That said, I'm happy to take > care of the merge if desired. No worries, I will merge this and r329162 too. Tycho ___ 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: r330696 - in head/libexec/tftpd: . tests
Author: asomers
Date: Fri Mar 9 15:30:20 2018
New Revision: 330696
URL: https://svnweb.freebsd.org/changeset/base/330696
Log:
Add some functional tests for tftpd(8)
tftpd(8) is difficult to test in isolation due to its relationship with
inetd. Create a test program that mimics the behavior of tftp(1) and
inetd(8) and verifies tftpd's response in several different scenarios.
These test cases cover all of the basic TFTP protocol, but not the optional
parts.
PR: 157700
PR: 225996
PR: 226004
PR: 226005
MFC after:3 weeks
Differential Revision:https://reviews.freebsd.org/D14310
Added:
head/libexec/tftpd/tests/
head/libexec/tftpd/tests/Makefile (contents, props changed)
head/libexec/tftpd/tests/functional.c (contents, props changed)
Modified:
head/libexec/tftpd/Makefile
Modified: head/libexec/tftpd/Makefile
==
--- head/libexec/tftpd/Makefile Fri Mar 9 14:45:47 2018(r330695)
+++ head/libexec/tftpd/Makefile Fri Mar 9 15:30:20 2018(r330696)
@@ -14,4 +14,7 @@ CFLAGS+= -DLIBWRAP
LIBADD=wrap
.endif
+HAS_TESTS=
+SUBDIR.${MK_TESTS}+= tests
+
.include
Added: head/libexec/tftpd/tests/Makefile
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/libexec/tftpd/tests/Makefile Fri Mar 9 15:30:20 2018
(r330696)
@@ -0,0 +1,14 @@
+# $FreeBSD$
+
+.include
+
+# Skip on GCC 4.2, because it lacks __COUNTER__
+.if ${COMPILER_TYPE} != "gcc" || ${COMPILER_VERSION} >= 40300
+ATF_TESTS_C= functional
+TEST_METADATA.functional+= timeout=15
+.endif
+
+LIBADD=util
+WARNS?=6
+
+.include
Added: head/libexec/tftpd/tests/functional.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/libexec/tftpd/tests/functional.c Fri Mar 9 15:30:20 2018
(r330696)
@@ -0,0 +1,1006 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2018 Alan Somers. 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, 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 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 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.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static const uint16_t BASEPORT = 6969;
+static const char pidfile[] = "tftpd.pid";
+static int protocol = PF_UNSPEC;
+static int s = -1; /* tftp client socket */
+static struct sockaddr_storage addr; /* Destination address for the client */
+static bool s_flag = false;/* Pass -s to tftpd */
+static bool w_flag = false;/* Pass -w to tftpd */
+
+/* Helper functions*/
+static void require_bufeq(const char *expected, ssize_t expected_len,
+const char *actual, ssize_t len);
+
+/*
+ * Receive a response from tftpd
+ * @param hdr The reply's expected header, as a char array
+ * @param contentsThe reply's expected contents, as a char array
+ * @param contents_lenLength of contents
+ */
+#define RECV(hdr, contents, contents_len) do { \
+ char buffer[1024]; \
+ struct sockaddr_storage from; \
+ socklen_t fromlen = sizeof(from); \
+ ssize_t r = recvfrom(s, buffer, sizeof(buffer), 0, \
+ (struct sockaddr*)&from, &fromlen); \
+ ATF_REQUIRE(r > 0); \
+ require_bufeq((hdr), sizeof(hdr), buffer, \
+ MIN(r, (ssize_t)sizeof(hdr))); \
+ require_bufeq((const char*) (contents), (contents_len), \
+ &buffer[sizeof(hdr)], r - sizeof(hdr)); \
+
Re: svn commit: r330696 - in head/libexec/tftpd: . tests
> Author: asomers > Date: Fri Mar 9 15:30:20 2018 > New Revision: 330696 > URL: https://svnweb.freebsd.org/changeset/base/330696 > > Log: > Add some functional tests for tftpd(8) > > tftpd(8) is difficult to test in isolation due to its relationship with > inetd. Create a test program that mimics the behavior of tftp(1) and > inetd(8) and verifies tftpd's response in several different scenarios. At one time I thought it was possible to run all of the external "inetd" daemons as standalone daemons without inetd involved. I do not recall if tftpd was included in that, but believe it was. I am sure that telnetd and ftpd would run standalone. Have we lost some useful functionality here that maybe we want back? > These test cases cover all of the basic TFTP protocol, but not the optional > parts. > > PR: 157700 > PR: 225996 > PR: 226004 > PR: 226005 > MFC after: 3 weeks > Differential Revision: https://reviews.freebsd.org/D14310 ... -- Rod Grimes rgri...@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"
Re: svn commit: r330696 - in head/libexec/tftpd: . tests
On Fri, Mar 9, 2018 at 8:52 AM, Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > Author: asomers > > Date: Fri Mar 9 15:30:20 2018 > > New Revision: 330696 > > URL: https://svnweb.freebsd.org/changeset/base/330696 > > > > Log: > > Add some functional tests for tftpd(8) > > > > tftpd(8) is difficult to test in isolation due to its relationship with > > inetd. Create a test program that mimics the behavior of tftp(1) and > > inetd(8) and verifies tftpd's response in several different scenarios. > > At one time I thought it was possible to run all of the external "inetd" > daemons as standalone daemons without inetd involved. > I do not recall if tftpd was included in that, but believe it was. > I am sure that telnetd and ftpd would run standalone. > > Have we lost some useful functionality here that maybe we want back? > Some daemons support that, but others don't. It's not in common code. sprayd and ftpd can do it. It looks like telnetd cannot. I'm not sure which others can. -Alan ___ 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: r330663 - head/sys/kern
On Fri, Mar 09, 2018 at 03:42:05PM +1100, Bruce Evans wrote:
> On Thu, 8 Mar 2018, Mark Johnston wrote:
>
> > Log:
> > Return E2BIG if we run out of space writing a compressed kernel dump.
>
> E2BIG a very wrong errno. It means "Argment list too long". It is broken
> as designed, with "too" encrypted as "2" and no indication of what is too
> big. EFBIG is not so wrong. It means "File too large".
There is explicit handling for E2BIG most of the (mini)dumpsys()
implementations, which is why I chose it. In particular, amd64's
minidumpsys() retries the dump upon receiving ENOSPC from the MI code,
but E2BIG simply causes the dump to fail:
443 else if (error == E2BIG)
444 printf("Dump failed. Partition too small.\n");
> > ENOSPC causes the MD kernel dump code to retry the dump, but this is
> > undesirable in the case where we legitimately ran out of space.
>
> ENOSPC is the correct errno. It means "[really] No space left on device".
> The bug was either retrying or possibly abusing ENOSPC instead of EAGAIN
> to mean "transiently out of space for something".
When writing an uncompressed dump, the starting offset is chosen so
that the end of the dump lines up with the end of the dump device. If we
attempt to write past the end of the dump, the presumption is that
something caused pages to be added to the dump map during the dump, and
we should retry with a different starting offset. EAGAIN seems like a
reasonable error number for this case, but it's somewhat unsatisfying
since these checks were originally meant to stop programming errors from
scribbling over a filesystem.
I wonder if the retry logic in amd64's minidumpsys() is really useful at
all. It was added in r215133 and copied to arm64, but isn't present in
any other MD dump code. I've never seen a kernel dump succeed after a
retry; for instance, the problem addressed in r329521 simply caused us
to retry a number of times before giving up. The description for
Differential D8254 also suggests that the retry logic is of questionable
value.
___
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: r330663 - head/sys/kern
On Fri, 2018-03-09 at 20:50 +1100, Bruce Evans wrote: > style(9) does require this. This is hard to see since the style > guide > has been mangled by converting it into a man page, with markup in non > C-code and lots of blank lines to separate the markup. See > /usr/src/admin/style/style in 4.4BSD or /usr/src/share/misc/style in > NetBSD for non-mangled versions. These are pure C code which give > many rules implicitly by example. All versions give 2 or 3 rules for > leaving a blank line between groups of header files. These rules are > somewhat needed since leaving blank lines is so unusual. I feel pretty certain that freebsd code does not have to conform to the style document in 4.4BSD, so I intend to waste absolutely none of my life reading it. If you feel that the 4.4BSD rules about blank lines need to be part of freebsd's style(9), then submit patches to make it so, and we'll run it through the voting process like we do other style changes. -- Ian ___ 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: r330699 - head/share/man/man9
Author: imp
Date: Fri Mar 9 17:54:14 2018
New Revision: 330699
URL: https://svnweb.freebsd.org/changeset/base/330699
Log:
Remove K&R stuff: never use it in new code.
Remove how to format K&R stuff. The project hasn't been using it in
new code for a long time. It's so obsolete, we don't need a statement
to never use it. Add a statement requesting that comments about
parameters be preserved when converting to ASNI style, per Kirk.
Differential Revision: https://reviews.freebsd.org/D14051
Modified:
head/share/man/man9/style.9
Modified: head/share/man/man9/style.9
==
--- head/share/man/man9/style.9 Fri Mar 9 16:35:49 2018(r330698)
+++ head/share/man/man9/style.9 Fri Mar 9 17:54:14 2018(r330699)
@@ -763,17 +763,9 @@ do not roll your own.
}
.Ed
.Pp
-Old-style function declarations look like this:
-.Bd -literal
-static char *
-function(a1, a2, fl, a4)
- int a1, a2; /* Declare ints, too, do not default them. */
- float fl; /* Beware double vs. float prototype differences. */
- int a4; /* List in order declared. */
-{
-.Ed
+When converting K&R style declarations to ANSI style, preserve
+any comments about parameters.
.Pp
-Use ANSI function declarations unless you explicitly need K&R compatibility.
Long parameter lists are wrapped with a normal four space indent.
.Pp
Variable numbers of arguments should look like this:
___
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: r330701 - head/stand/lua
Author: kevans
Date: Fri Mar 9 18:45:13 2018
New Revision: 330701
URL: https://svnweb.freebsd.org/changeset/base/330701
Log:
lualoader: Don't redraw the autoboot message every .05s
Modified:
head/stand/lua/menu.lua
Modified: head/stand/lua/menu.lua
==
--- head/stand/lua/menu.lua Fri Mar 9 17:59:22 2018(r330700)
+++ head/stand/lua/menu.lua Fri Mar 9 18:45:13 2018(r330701)
@@ -425,14 +425,17 @@ function menu.autoboot()
local endtime = loader.time() + ab
local time
-
+ local last
repeat
time = endtime - loader.time()
- screen.setcursor(x, y)
- print("Autoboot in " .. time ..
- " seconds, hit [Enter] to boot" ..
- " or any other key to stop ")
- screen.defcursor()
+ if last == nil or last ~= time then
+ last = time
+ screen.setcursor(x, y)
+ print("Autoboot in " .. time ..
+ " seconds, hit [Enter] to boot" ..
+ " or any other key to stop ")
+ screen.defcursor()
+ end
if io.ischar() then
local ch = io.getchar()
if ch == core.KEY_ENTER then
___
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: r330702 - head/lib/libmagic
Author: bdrewery
Date: Fri Mar 9 18:51:24 2018
New Revision: 330702
URL: https://svnweb.freebsd.org/changeset/base/330702
Log:
LIB32: Avoid linking in unneeded (and invalid lib32) libz for libmagic build
tool.
Usually this is just ignored:
/usr/bin/ld: skipping incompatible
/scratch/obj/root/git/freebsd/amd64.amd64/obj-lib32/lib/libz/libz.so when
searching for -lz
/usr/bin/ld: skipping incompatible
/scratch/obj/root/git/freebsd/amd64.amd64/obj-lib32/lib/libz/libz.a when
searching for -lz
However some combination of newer toolchains simply fail here instead:
/usr/bin/ld: error:
/home/dstolfa/obj/home/dstolfa/cadets/amd64.amd64/obj-lib32/lib/libz/libz.so is
incompatible with /usr/lib/crt1.o
Libz is not needed for mkmagic so just exclude it.
Reported by: Domagoj Stolfa
MFC after:2 weeks
Sponsored by: Dell EMC
Modified:
head/lib/libmagic/Makefile
Modified: head/lib/libmagic/Makefile
==
--- head/lib/libmagic/Makefile Fri Mar 9 18:45:13 2018(r330701)
+++ head/lib/libmagic/Makefile Fri Mar 9 18:51:24 2018(r330702)
@@ -8,7 +8,9 @@ CONTRDIR= ${SRCTOP}/contrib/file
LIB= magic
SHLIB_MAJOR= 4
+.if !make(build-tools)
LIBADD=z
+.endif
MAN= libmagic.3 magic.5
SRCS= apprentice.c apptype.c ascmagic.c cdf.c cdf_time.c compress.c \
___
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: r330703 - head/stand/lua
Author: kevans
Date: Fri Mar 9 19:04:06 2018
New Revision: 330703
URL: https://svnweb.freebsd.org/changeset/base/330703
Log:
lualoader: Cache kernel list
With autodetection turned on, hitting the filesystem everytime we need to
calculate choices for the kernel carousel is kind of slow. Cache once on the
first listing and reload it anytime the config is reloaded in case any of
the loader.conf(5) changes that affect this (kernel, kernels,
kernels_autodetect) have changed. This also picks up the case where we've
changed currdev and the autodetected kernels could change.
Modified:
head/stand/lua/config.lua
head/stand/lua/core.lua
Modified: head/stand/lua/config.lua
==
--- head/stand/lua/config.lua Fri Mar 9 18:51:24 2018(r330702)
+++ head/stand/lua/config.lua Fri Mar 9 19:04:06 2018(r330703)
@@ -497,6 +497,7 @@ function config.reload(file)
modules = {}
config.restoreEnv()
config.load(file)
+ core.configReloaded()
end
function config.loadelf()
Modified: head/stand/lua/core.lua
==
--- head/stand/lua/core.lua Fri Mar 9 18:51:24 2018(r330702)
+++ head/stand/lua/core.lua Fri Mar 9 19:04:06 2018(r330703)
@@ -138,7 +138,18 @@ function core.setSafeMode(safe_mode)
core.sm = safe_mode
end
+function core.configReloaded()
+ -- Clear the kernel cache on config changes, autodetect might have
+ -- changed or if we've switched boot environments then we could have
+ -- a new kernel set.
+ core.cached_kernels = nil
+end
+
function core.kernelList()
+ if core.cached_kernels ~= nil then
+ return core.cached_kernels
+ end
+
local k = loader.getenv("kernel")
local v = loader.getenv("kernels")
local autodetect = loader.getenv("kernels_autodetect") or ""
@@ -166,7 +177,8 @@ function core.kernelList()
-- setting, kernels_autodetect. If it's set to 'yes', we'll add
-- any kernels we detect based on the criteria described.
if autodetect:lower() ~= "yes" then
- return kernels
+ core.cached_kernels = kernels
+ return core.cached_kernels
end
-- Automatically detect other bootable kernel directories using a
@@ -195,7 +207,8 @@ function core.kernelList()
::continue::
end
- return kernels
+ core.cached_kernels = kernels
+ return core.cached_kernels
end
function core.bootenvDefault()
___
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: r330338 - head/sys/amd64/amd64
On Saturday, March 03, 2018 03:10:37 PM Andriy Gapon wrote: > Author: avg > Date: Sat Mar 3 15:10:37 2018 > New Revision: 330338 > URL: https://svnweb.freebsd.org/changeset/base/330338 > > Log: > db_nextframe/amd64: catch up with r328083 to recognize fast_syscall_common > > Since that change the system call stack traces look like this: > ... > sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0028e13ac0 > amd64_syscall() at amd64_syscall+0x79b/frame 0xfe0028e13bf0 > fast_syscall_common() at fast_syscall_common+0x101/frame > 0xfe0028e13bf0 > So, db_nextframe() stopped recognizing the system call frame. > This commit should fix that. > > Reviewed by:kib > MFC after: 4 days > > Modified: > head/sys/amd64/amd64/db_trace.c > > Modified: head/sys/amd64/amd64/db_trace.c > == > --- head/sys/amd64/amd64/db_trace.c Sat Mar 3 13:20:44 2018 > (r330337) > +++ head/sys/amd64/amd64/db_trace.c Sat Mar 3 15:10:37 2018 > (r330338) > @@ -212,7 +212,9 @@ db_nextframe(struct amd64_frame **fp, db_addr_t *ip, s > strcmp(name, "Xcpususpend") == 0 || > strcmp(name, "Xrendezvous") == 0) > frame_type = INTERRUPT; > - else if (strcmp(name, "Xfast_syscall") == 0) > + else if (strcmp(name, "Xfast_syscall") == 0 || > + strcmp(name, "Xfast_syscall_pti") == 0 || > + strcmp(name, "fast_syscall_common") == 0) > frame_type = SYSCALL; I think you actually just want to replace Xfast_syscall with fast_syscall_common. Neither Xfast_syscall nor Xfast_syscall_pti call any functions before jumping to the common label, so when unwinding from a system call you should always get the common label. (That is, I think we should remove Xfast_syscall and Xfast_syscall_pti here. Any stack trace that happens to find those symbols during unwinding won't have a valid SYSCALL frame to unwind.) -- 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: r330338 - head/sys/amd64/amd64
On Fri, 9 Mar 2018, John Baldwin wrote: On Saturday, March 03, 2018 03:10:37 PM Andriy Gapon wrote: Author: avg Date: Sat Mar 3 15:10:37 2018 New Revision: 330338 URL: https://svnweb.freebsd.org/changeset/base/330338 Log: db_nextframe/amd64: catch up with r328083 to recognize fast_syscall_common Since that change the system call stack traces look like this: ... sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0028e13ac0 amd64_syscall() at amd64_syscall+0x79b/frame 0xfe0028e13bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0028e13bf0 So, db_nextframe() stopped recognizing the system call frame. This commit should fix that. Reviewed by: kib MFC after:4 days Modified: head/sys/amd64/amd64/db_trace.c Modified: head/sys/amd64/amd64/db_trace.c == --- head/sys/amd64/amd64/db_trace.c Sat Mar 3 13:20:44 2018 (r330337) +++ head/sys/amd64/amd64/db_trace.c Sat Mar 3 15:10:37 2018 (r330338) @@ -212,7 +212,9 @@ db_nextframe(struct amd64_frame **fp, db_addr_t *ip, s strcmp(name, "Xcpususpend") == 0 || strcmp(name, "Xrendezvous") == 0) frame_type = INTERRUPT; - else if (strcmp(name, "Xfast_syscall") == 0) + else if (strcmp(name, "Xfast_syscall") == 0 || + strcmp(name, "Xfast_syscall_pti") == 0 || + strcmp(name, "fast_syscall_common") == 0) frame_type = SYSCALL; I think you actually just want to replace Xfast_syscall with fast_syscall_common. Neither Xfast_syscall nor Xfast_syscall_pti call any functions before jumping to the common label, so when unwinding from a system call you should always get the common label. (That is, I think we should remove Xfast_syscall and Xfast_syscall_pti here. Any stack trace that happens to find those symbols during unwinding won't have a valid SYSCALL frame to unwind.) No, it needs these symbols to decode the frame after reaching a point where the frame is actually set up. Also, in uncommitted fixes I add some decoding of the non-frame between the entry point and when the frame is set up. Then the frame register is still the user's for the syscall case, so should not even be accessed. The i386 output looks like this: current: XX12: Breakpoint at Xint0x80_syscall: pushl $0x2 XX12: db> t XX12: Tracing pid 1 tid 11 td 0xc6fad000 XX12: Xint0x80_syscall(33,282,bfbfee0c,3b,0,...) at Xint0x80_syscall/frame 0xd1d05bd8 XX12: kernload(2,bfbfeec4,bfbfeed0,804812b,80a3d64,...) at 0x805188f/frame 0xbfbfee7c fixed: XX12F: Breakpoint at Xint0x80_syscall: pushl $0x2 XX12F: db> t XX12F: Tracing pid 1 tid 11 td 0xd4c23000 XX12F: Xint0x80_syscall(2,bfbfeec4,bfbfeed0,804812b,80a3d64,...) at Xint0x80_syscall/frame 0xbfbfee7c XX12F: --- unknown trap, ebp = 0xbfbfee7c, sp = 0xd3399bdc, ks = 0xd3398000, kse = 0xd339a000 --- where most of the values on the last line are for debugging (ebp is the user stack pointer which will become inaccessible, sp is the local variable sp and [ks, kse - 1] is the thread's kernel stack range (sp must be in this else the backtrace stops). Jumps and labels with names inside functions complicate things. I think fast_syscall_common needs to be in the list too, and the many alltraps labels should have been there. This will be more useful with my fix. The label calltrap has always been in the list. This works right since the frame has been set up then -- IIRC it is the first place where the frame has been set up, and label it more for gdb than for ddb, and decode the frame for ddb (presumably gdb decodes the frame too). Bruce ___ 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: r330338 - head/sys/amd64/amd64
On Sat, 10 Mar 2018, Bruce Evans wrote: On Fri, 9 Mar 2018, John Baldwin wrote: I think you actually just want to replace Xfast_syscall with fast_syscall_common. Neither Xfast_syscall nor Xfast_syscall_pti call any functions before jumping to the common label, so when unwinding from a system call you should always get the common label. (That is, I think we should remove Xfast_syscall and Xfast_syscall_pti here. Any stack trace that happens to find those symbols during unwinding won't have a valid SYSCALL frame to unwind.) No, it needs these symbols to decode the frame after reaching a point where the frame is actually set up. Also, in uncommitted fixes I add some decoding of the non-frame between the entry point and when the frame is set up. Then the frame register ... Jumps and labels with names inside functions complicate things. I think fast_syscall_common needs to be in the list too, and the many alltraps labels should have been there. This will be more useful with my fix. The label calltrap has always been in the list. This works right since the frame has been set up then -- IIRC it is the first place where the frame has been set up, and label it more for gdb than for ddb, and decode the frame for ddb (presumably gdb decodes the frame too). Actually, internal labels like alltraps just break finding the entry point. Cross-jumping to such labels also breaks finding the entry point. The calltrap label is a work around for this problem -- it is too hard to trace back to the entry point (e.g., Xpage) or even to alltraps, so the single fake entry point calltrap is used. Syscalls and interrupts are more important, or at least easier to handle, so the problem was avoided for them by not using cross jumps or too many internal labels (though I don't like unnamed labels). This is quite broken for amd64 now. Cross-jumps also complicate mcounting. (The non-traps are easier to handle since they are not multiplexed through trap(). The multiplexing can be thought of as making all traps enter at trap() with a trap code giving the trap number, so no label for the entry point is needed. The trap code is an arg, so it is printed in the stack trace on i386.) Bruce ___ 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: r330705 - head/sbin/mount
Author: imp
Date: Fri Mar 9 21:32:07 2018
New Revision: 330705
URL: https://svnweb.freebsd.org/changeset/base/330705
Log:
Remove decade's old whine about msdos vs msdosfs.
Retain the compatibility silently though.
Reviewed by: cem@, kevans@, emaste@ (and many others in the past)
Modified:
head/sbin/mount/mount.c
Modified: head/sbin/mount/mount.c
==
--- head/sbin/mount/mount.c Fri Mar 9 19:39:08 2018(r330704)
+++ head/sbin/mount/mount.c Fri Mar 9 21:32:07 2018(r330705)
@@ -589,11 +589,8 @@ mountfs(const char *vfstype, const char *spec, const c
optbuf = catopt(optbuf, "update");
/* Compatibility glue. */
- if (strcmp(vfstype, "msdos") == 0) {
- warnx(
- "Using \"-t msdosfs\", since \"-t msdos\" is deprecated.");
+ if (strcmp(vfstype, "msdos") == 0)
vfstype = "msdosfs";
- }
/* Construct the name of the appropriate mount command */
(void)snprintf(execname, sizeof(execname), "mount_%s", vfstype);
___
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: r328013 - head/sbin/fsck_ffs
On Mon, Jan 15, 2018 at 07:25:11PM +, David Bright wrote:
> Author: dab
> Date: Mon Jan 15 19:25:11 2018
> New Revision: 328013
> URL: https://svnweb.freebsd.org/changeset/base/328013
>
> Log:
> Exit fsck_ffs with non-zero status when file system is not repaired.
>
> When the fsck_ffs program cannot fully repair a file system, it will
> output the message PLEASE RERUN FSCK. However, it does not exit with a
> non-zero status in this case (contradicting the man page claim that it
> "exits with 0 on success, and >0 if an error occurs." The fsck
> rc-script (when running "fsck -y") tests the status from fsck (which
> passes along the exit status from fsck_ffs) and issues a "stop_boot"
> if the status fails. However, this is not effective since fsck_ffs can
> return zero even on (some) errors. Effectively, it is left to a later
> step in the boot process when the file systems are mounted to detect
> the still-unclean file system and stop the boot.
>
> This change modifies fsck_ffs so that when it cannot fully repair the
> file system and issues the PLEASE RERUN FSCK message it also exits
> with a non-zero status.
>
> While here, the fsck_ffs man page has also been updated to document
> the failing exit status codes used by fsck_ffs. Previously, only exit
> status 7 was documented. Some of these exit statuses are tested for in
> the fsck rc-script, so they are clearly depended upon and deserve
> documentation.
etc/rc.d/fsck doesn't know how to interpret the new exit code and now
just drops to a single-user shell when it is encountered. This is
happening to me semi-regularly when my test systems crash, especially
when I test kernel panic handling. :)
Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to
some configurable number of retries) when the new error code is seen?
The patch below seems to do the trick for me:
diff --git a/etc/defaults/rc.conf b/etc/defaults/rc.conf
index 584e842bba2c..63d2fcc0be8d 100644
--- a/etc/defaults/rc.conf
+++ b/etc/defaults/rc.conf
@@ -95,6 +95,7 @@ root_rw_mount="YES" # Set to NO to inhibit remounting root
read-write.
root_hold_delay="30" # Time to wait for root mount hold release.
fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y
+fsck_retries="3"# Number of times to retry fsck before giving up.
background_fsck="YES" # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
growfs_enable="NO" # Set to YES to attempt to grow the root filesystem on
boot
diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck
index bd3122a20110..708d92228e3d 100755
--- a/etc/rc.d/fsck
+++ b/etc/rc.d/fsck
@@ -14,8 +14,82 @@ desc="Run file system checks"
start_cmd="fsck_start"
stop_cmd=":"
+_fsck_run()
+{
+ local err
+
+ if checkyesno background_fsck; then
+ fsck -F -p
+ else
+ fsck -p
+ fi
+
+ err=$?
+ if [ ${err} -eq 3 ]; then
+ echo "Warning! Some of the devices might not be" \
+ "available; retrying"
+ root_hold_wait
+ check_startmsgs && echo "Restarting file system checks:"
+ if checkyesno background_fsck; then
+ fsck -F -p
+ else
+ fsck -p
+ fi
+ err=$?
+ fi
+
+ case ${err} in
+ 0)
+ ;;
+ 2)
+ stop_boot
+ ;;
+ 4)
+ echo "Rebooting..."
+ reboot
+ echo "Reboot failed; help!"
+ stop_boot
+ ;;
+ 8)
+ if checkyesno fsck_y_enable; then
+ echo "File system preen failed, trying fsck -y
${fsck_y_flags}"
+ fsck -y ${fsck_y_flags}
+ case $? in
+ 0)
+ ;;
+ *)
+ echo "Automatic file system check failed; help!"
+ stop_boot
+ ;;
+ esac
+ else
+ echo "Automatic file system check failed; help!"
+ stop_boot
+ fi
+ ;;
+ 12)
+ echo "Boot interrupted."
+ stop_boot
+ ;;
+ 16)
+ echo "File system check retry requested."
+ ;;
+ 130)
+ stop_boot
+ ;;
+ *)
+ echo "Unknown error ${err}; help!"
+ stop_boot
+ ;;
+ esac
+
+ return $err
+}
+
fsck_start()
{
+ local err tries
+
if [ "$autoboot" = no ]; then
echo "Fast boot: skipping disk checks."
elif [
Re: svn commit: r328013 - head/sbin/fsck_ffs
On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > On Mon, Jan 15, 2018 at 07:25:11PM +, David Bright wrote: > > > > Author: dab > > Date: Mon Jan 15 19:25:11 2018 > > New Revision: 328013 > > URL: https://svnweb.freebsd.org/changeset/base/328013 > > > > Log: > > Exit fsck_ffs with non-zero status when file system is not repaired. > > > > [...] > etc/rc.d/fsck doesn't know how to interpret the new exit code and now > just drops to a single-user shell when it is encountered. This is > happening to me semi-regularly when my test systems crash, especially > when I test kernel panic handling. :) > > Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > some configurable number of retries) when the new error code is seen? > The patch below seems to do the trick for me: > fsck_ffs already has a -R flag to automatically retry, wouldn't that be a better mechanism for handling this new type of retry? -- Ian ___ 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: r330708 - head/gnu/usr.bin/gdb/kgdb
Author: jhb Date: Fri Mar 9 22:58:05 2018 New Revision: 330708 URL: https://svnweb.freebsd.org/changeset/base/330708 Log: Use the trapframe unwinder for "fast_syscall_common". MFC after:3 days Modified: head/gnu/usr.bin/gdb/kgdb/trgt_amd64.c Modified: head/gnu/usr.bin/gdb/kgdb/trgt_amd64.c == --- head/gnu/usr.bin/gdb/kgdb/trgt_amd64.c Fri Mar 9 22:52:52 2018 (r330707) +++ head/gnu/usr.bin/gdb/kgdb/trgt_amd64.c Fri Mar 9 22:58:05 2018 (r330708) @@ -189,6 +189,7 @@ kgdb_trgt_trapframe_sniffer(struct frame_info *next_fr if (pname == NULL) return (NULL); if (strcmp(pname, "calltrap") == 0 || + strcmp(pname, "fast_syscall_common") == 0 || strcmp(pname, "mchk_calltrap") == 0 || strcmp(pname, "nmi_calltrap") == 0 || (pname[0] == 'X' && pname[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: r330709 - head/etc/mtree
Author: asomers Date: Fri Mar 9 23:17:29 2018 New Revision: 330709 URL: https://svnweb.freebsd.org/changeset/base/330709 Log: Commit missing file from r330696 MFC after:3 weeks X-MFC-With: 330696 Modified: head/etc/mtree/BSD.tests.dist Modified: head/etc/mtree/BSD.tests.dist == --- head/etc/mtree/BSD.tests.dist Fri Mar 9 22:58:05 2018 (r330708) +++ head/etc/mtree/BSD.tests.dist Fri Mar 9 23:17:29 2018 (r330709) @@ -382,6 +382,8 @@ .. rtld-elf .. +tftpd +.. .. sbin dhclient ___ 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: r330710 - in head: libexec/tftpd libexec/tftpd/tests usr.bin/tftp
Author: asomers
Date: Fri Mar 9 23:25:18 2018
New Revision: 330710
URL: https://svnweb.freebsd.org/changeset/base/330710
Log:
tftpd: Flush files as soon as they are fully received
On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
Instead, it waits five seconds just in case the client didn't receive the
server's last ACK and decides to resend the final DATA packet.
Unfortunately, this created a 5 second delay from when the client thinks
it's done sending the file, and when the file is available for other
processes.
Fix this bug by closing the file as soon as receipt is finished.
PR: 157700
Reported by: Barry Mishler
MFC after:3 weeks
Modified:
head/libexec/tftpd/tests/functional.c
head/libexec/tftpd/tftp-transfer.c
head/libexec/tftpd/tftpd.c
head/usr.bin/tftp/tftp.c
Modified: head/libexec/tftpd/tests/functional.c
==
--- head/libexec/tftpd/tests/functional.c Fri Mar 9 23:17:29 2018
(r330709)
+++ head/libexec/tftpd/tests/functional.c Fri Mar 9 23:25:18 2018
(r330710)
@@ -694,7 +694,6 @@ TFTPD_TC_DEFINE(w_flag,, w_flag = 1;)
send_data(1, contents, contents_len);
recv_ack(1);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("small.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
@@ -731,7 +730,6 @@ TFTPD_TC_DEFINE(wrq_dropped_ack,)
send_data(2, (const char*)&contents[128], 256);
recv_ack(2);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("medium.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
@@ -764,7 +762,6 @@ TFTPD_TC_DEFINE(wrq_dropped_data,)
send_data(1, contents, contents_len);
recv_ack(1);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("small.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
@@ -798,7 +795,6 @@ TFTPD_TC_DEFINE(wrq_duped_data,)
send_data(2, (const char*)&contents[128], 256);
recv_ack(2);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("medium.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
@@ -865,7 +861,6 @@ TFTPD_TC_DEFINE(wrq_medium,)
send_data(2, (const char*)&contents[128], 256);
recv_ack(2);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("medium.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
@@ -891,14 +886,13 @@ TFTPD_TC_DEFINE(wrq_netascii,)
fd = open("unix.txt", O_RDWR | O_CREAT, 0666);
ATF_REQUIRE(fd >= 0);
close(fd);
- contents_len = strlen(contents) + 1;
+ contents_len = sizeof(contents);
SEND_WRQ("unix.txt", "netascii");
recv_ack(0);
send_data(1, contents, contents_len);
recv_ack(1);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("unix.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
@@ -938,7 +932,6 @@ TFTPD_TC_DEFINE(wrq_small,)
send_data(1, contents, contents_len);
recv_ack(1);
- atf_tc_expect_fail("PR 157700 tftpd expects more data after EOF");
fd = open("small.txt", O_RDONLY);
r = read(fd, buffer, sizeof(buffer));
close(fd);
Modified: head/libexec/tftpd/tftp-transfer.c
==
--- head/libexec/tftpd/tftp-transfer.c Fri Mar 9 23:17:29 2018
(r330709)
+++ head/libexec/tftpd/tftp-transfer.c Fri Mar 9 23:25:18 2018
(r330710)
@@ -304,6 +304,8 @@ send_ack:
gettimeofday(&(ts->tstop), NULL);
} while (n_data == segsize);
+ write_close();
+
/* Don't do late packet management for the client implementation */
if (acting_as_client)
return;
Modified: head/libexec/tftpd/tftpd.c
==
--- head/libexec/tftpd/tftpd.c Fri Mar 9 23:17:29 2018(r330709)
+++ head/libexec/tftpd/tftpd.c Fri Mar 9 23:25:18 2018(r330710)
@@ -823,7 +823,6 @@ tftp_recvfile(int peer, const char *mode)
block = 0;
tftp_receive(peer, &block, &ts, NULL, 0);
- write_close();
gettimeofday(&now2, NULL);
if (debug&DEBUG_SIMPLE) {
Modified: head/usr.bin/tftp/tftp.c
==
--- head/usr.bin/tftp/tftp.cFri Mar 9 23:17:29 2018(r330709)
+++ head/usr.bin/tftp/tftp.cFri Mar 9 23:25:18 2018(r330710)
@@ -265,7 +265,6 @@ recvfile(int peer, char *port, int fd, char *name, cha
svn commit: r330711 - head/sbin/sysctl
Author: jhb
Date: Fri Mar 9 23:37:19 2018
New Revision: 330711
URL: https://svnweb.freebsd.org/changeset/base/330711
Log:
Permit sysctl(8) to set an array of numeric values for a single node.
Most sysctl nodes only return a single value, but some nodes return an
array of values (e.g. kern.cp_time). sysctl(8) understand how to display
the values of a node that returns multiple values (it prints out each
numeric value separated by spaces). However, until now sysctl(8) has
only been able to set sysctl nodes to a single value. This change
allows sysctl to accept a new value for a numeric sysctl node that contains
multiple values separated by either spaces or commas. sysctl(8) parses
this list into an array of values and passes the array as the "new" value
to sysctl(2).
Reviewed by: rpokala
MFC after:1 week
Sponsored by: Chelsio Communications
Differential Revision:https://reviews.freebsd.org/D14569
Modified:
head/sbin/sysctl/sysctl.8
head/sbin/sysctl/sysctl.c
Modified: head/sbin/sysctl/sysctl.8
==
--- head/sbin/sysctl/sysctl.8 Fri Mar 9 23:25:18 2018(r330710)
+++ head/sbin/sysctl/sysctl.8 Fri Mar 9 23:37:19 2018(r330711)
@@ -28,7 +28,7 @@
.\"From: @(#)sysctl.8 8.1 (Berkeley) 6/6/93
.\" $FreeBSD$
.\"
-.Dd December 10, 2015
+.Dd March 9, 2018
.Dt SYSCTL 8
.Os
.Sh NAME
@@ -39,7 +39,7 @@
.Op Fl bdehiNnoRTtqx
.Op Fl B Ar bufsize
.Op Fl f Ar filename
-.Ar name Ns Op = Ns Ar value
+.Ar name Ns Op = Ns Ar value Ns Op , Ns Ar value
.Ar ...
.Nm
.Op Fl bdehNnoRTtqx
Modified: head/sbin/sysctl/sysctl.c
==
--- head/sbin/sysctl/sysctl.c Fri Mar 9 23:25:18 2018(r330710)
+++ head/sbin/sysctl/sysctl.c Fri Mar 9 23:37:19 2018(r330711)
@@ -65,6 +65,7 @@ static const char rcsid[] =
#include
#include
#include
+#include
#include
#include
#include
@@ -234,16 +235,17 @@ main(int argc, char **argv)
}
/*
- * Parse a name into a MIB entry.
- * Lookup and print out the MIB entry if it exists.
- * Set a new value if requested.
+ * Parse a single numeric value, append it to 'newbuf', and update
+ * 'newsize'. Returns true if the value was parsed and false if the
+ * value was invalid. Non-numeric types (strings) are handled
+ * directly in parse().
*/
-static int
-parse(const char *string, int lineno)
+static bool
+parse_numeric(const char *newvalstr, const char *fmt, u_int kind,
+void **newbufp, size_t *newsizep)
{
- int len, i, j;
+ void *newbuf;
const void *newval;
- const char *newvalstr = NULL;
int8_t i8val;
uint8_t u8val;
int16_t i16val;
@@ -254,11 +256,111 @@ parse(const char *string, int lineno)
unsigned int uintval;
long longval;
unsigned long ulongval;
- size_t newsize = Bflag;
int64_t i64val;
uint64_t u64val;
+ size_t valsize;
+ char *endptr = NULL;
+
+ errno = 0;
+
+ switch (kind & CTLTYPE) {
+ case CTLTYPE_INT:
+ if (strncmp(fmt, "IK", 2) == 0)
+ intval = strIKtoi(newvalstr, &endptr, fmt);
+ else
+ intval = (int)strtol(newvalstr, &endptr, 0);
+ newval = &intval;
+ valsize = sizeof(intval);
+ break;
+ case CTLTYPE_UINT:
+ uintval = (int) strtoul(newvalstr, &endptr, 0);
+ newval = &uintval;
+ valsize = sizeof(uintval);
+ break;
+ case CTLTYPE_LONG:
+ longval = strtol(newvalstr, &endptr, 0);
+ newval = &longval;
+ valsize = sizeof(longval);
+ break;
+ case CTLTYPE_ULONG:
+ ulongval = strtoul(newvalstr, &endptr, 0);
+ newval = &ulongval;
+ valsize = sizeof(ulongval);
+ break;
+ case CTLTYPE_S8:
+ i8val = (int8_t)strtol(newvalstr, &endptr, 0);
+ newval = &i8val;
+ valsize = sizeof(i8val);
+ break;
+ case CTLTYPE_S16:
+ i16val = (int16_t)strtol(newvalstr, &endptr, 0);
+ newval = &i16val;
+ valsize = sizeof(i16val);
+ break;
+ case CTLTYPE_S32:
+ i32val = (int32_t)strtol(newvalstr, &endptr, 0);
+ newval = &i32val;
+ valsize = sizeof(i32val);
+ break;
+ case CTLTYPE_S64:
+ i64val = strtoimax(newvalstr, &endptr, 0);
+ newval = &i64val;
+ valsize = sizeof(i64val);
+ break;
+ case CTLTYPE_U8:
+ u8val = (uint8_t)strtoul(newvalstr, &endptr, 0);
+ newval = &u8val;
+ valsize = sizeof(u8val);
+ break;
+ case CTL
svn commit: r330712 - head/bin/ps
Author: karels
Date: Sat Mar 10 00:10:47 2018
New Revision: 330712
URL: https://svnweb.freebsd.org/changeset/base/330712
Log:
Change ps(1) output width to unlimited if not interactive
Apply patch submitted with PR 217159 to make ps use unlimited
width when not associated with a terminal (i.e., none of stdout, stdin,
or stderr is a tty). Update comments and man page correspondingly.
This change was requested to work around lack of -ww in scripts from
third-party packages, including Hadoop, and adds a small measure of
Linux compatibility. Hopefully few if any non-interactive scripts
depend on the old default of 79.
PR: 217159
Submitted by: n.deepak at gmail.com
Reviewed by: vangyzen jhb
Differential Revision:https://reviews.freebsd.org/D14614
Modified:
head/bin/ps/ps.1
head/bin/ps/ps.c
Modified: head/bin/ps/ps.1
==
--- head/bin/ps/ps.1Fri Mar 9 23:37:19 2018(r330711)
+++ head/bin/ps/ps.1Sat Mar 10 00:10:47 2018(r330712)
@@ -101,6 +101,14 @@ The default output format includes, for each process,
controlling terminal, state, CPU time (including both user and system time)
and associated command.
.Pp
+If the
+.Nm
+process is associated with a terminal, the default output width is that of the
+terminal; otherwise the output width is unlimited.
+See also the
+.Fl w
+option.
+.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl -libxo
@@ -257,13 +265,15 @@ option implies the
.Fl m
option.
.It Fl w
-Use 132 columns to display information, instead of the default which
-is your window size.
+Use at least 132 columns to display information, instead of the default which
+is the window size if
+.Nm
+is associated with a terminal.
If the
.Fl w
option is specified more than once,
.Nm
-will use as many columns as necessary without regard for your window size.
+will use as many columns as necessary without regard for the window size.
Note that this option has no effect if the
.Dq command
column is not the last column displayed.
Modified: head/bin/ps/ps.c
==
--- head/bin/ps/ps.cFri Mar 9 23:37:19 2018(r330711)
+++ head/bin/ps/ps.cSat Mar 10 00:10:47 2018(r330712)
@@ -202,6 +202,11 @@ main(int argc, char *argv[])
* any of stdout, stderr, or stdin is a terminal. The intent
* is that "ps", "ps | more", and "ps | grep" all use the same
* default line length unless -w is specified.
+*
+* If not interactive, the default length was traditionally 79.
+* It has been changed to unlimited. This is mostly for the
+* benefit of non-interactive scripts, which arguably should
+* use -ww, but is compatible with Linux.
*/
if ((cols = getenv("COLUMNS")) != NULL && *cols != '\0')
termwidth = atoi(cols);
@@ -209,7 +214,7 @@ main(int argc, char *argv[])
ioctl(STDERR_FILENO, TIOCGWINSZ, (char *)&ws) == -1 &&
ioctl(STDIN_FILENO, TIOCGWINSZ, (char *)&ws) == -1) ||
ws.ws_col == 0)
- termwidth = 79;
+ termwidth = UNLIMITED;
else
termwidth = ws.ws_col - 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"
Re: svn commit: r328625 - in head/sys: amd64/amd64 amd64/ia32 amd64/include dev/cpuctl i386/i386 x86/include x86/x86
Hi, In my FreeBSD 11.1 VM, I'm getting this build failure and it looks this revision causes the failure: cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/root/bsd.git/amd64.amd64/tmp -B/usr/obj/root/bsd.git/amd64.amd64/tmp/usr/bin -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/root/bsd.git/sys -I/root/bsd.git/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.support.o -MTsupport.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -Werror /root/bsd.git/sys/amd64/amd64/support.S --- ptrace_machdep.o --- ctfconvert -L VERSION -g ptrace_machdep.o --- support.o --- /root/bsd.git/sys/amd64/amd64/support.S:855:2: error: unknown directive .altmacro ^ Should I upgrade my cc/as? [root@bsd11-39 ~/bsd.git]# cc --version FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin [root@bsd11-39 ~/bsd.git]# as --version GNU assembler 2.17.50 [FreeBSD] 2007-07-03 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-unknown-freebsd'. It looks -fno-integrated-as might fix the failure for me according to: https://stackoverflow.com/questions/47938599/unknown-directive-altmacro-error-happens-when-using-android-ndk-standalone-tool But when I tried: export CC="clang -no-integrated-as" make I got a different error: --- all_subdir_accf_data --- /tmp/accf_data-013c70.s: Assembler messages: /tmp/accf_data-013c70.s:33: Error: unknown pseudo-op: `.cfi_sections' clang: error: assembler command failed with exit code 1 (use -v to see invocation) *** [accf_data.o] Error code 1 Any insight? Thanks! -- Dexuan On Wed, Jan 31, 2018 at 6:36 AM, Konstantin Belousov wrote: > Author: kib > Date: Wed Jan 31 14:36:27 2018 > New Revision: 328625 > URL: https://svnweb.freebsd.org/changeset/base/328625 > > Log: > IBRS support, AKA Spectre hardware mitigation. > > It is coded according to the Intel document 336996-001, reading of the > patches posted on lkml, and some additional consultations with Intel. > > For existing processors, you need a microcode update which adds IBRS > CPU features, and to manually enable it by setting the tunable/sysctl > hw.ibrs_disable to 0. Current status can be checked in sysctl > hw.ibrs_active. The mitigation might be inactive if the CPU feature > is not patched in, or if CPU reports that IBRS use is not required, by > IA32_ARCH_CAP_IBRS_ALL bit. > > Sponsored by: The FreeBSD Foundation > MFC after:1 week > Differential revision:https://reviews.freebsd.org/D14029 > > Modified: > head/sys/amd64/amd64/exception.S > head/sys/amd64/amd64/genassym.c > head/sys/amd64/amd64/initcpu.c > head/sys/amd64/amd64/machdep.c > head/sys/amd64/amd64/support.S > head/sys/amd64/ia32/ia32_exception.S > head/sys/amd64/include/md_var.h > head/sys/amd64/include/pcpu.h > head/sys/dev/cpuctl/cpuctl.c > head/sys/i386/i386/support.s > head/sys/x86/include/specialreg.h > head/sys/x86/include/x86_var.h > head/sys/x86/x86/cpu_machdep.c > > Modified: head/sys/amd64/amd64/exception.S > == > --- head/sys/amd64/amd64/exception.SWed Jan 31 14:25:42 2018 > (r328624) > +++ head/sys/amd64/amd64/exception.SWed Jan 31 14:36:27 2018 > (r328625) > @@ -171,21 +171,22 @@ X\l: > alltraps: > movq%rdi,TF_RDI(%rsp) > testb $SEL_RPL_MASK,TF_CS(%rsp) /* Did we come from kernel? */ > - jz alltraps_segs /* already running with kernel > GS.base */ > + jz 1f /* already running with kernel GS.base */ > swapgs > movqPCPU(CURPCB),%rdi > andl$~PCB_FULL_IRET,PCB_FLAGS(%rdi) > -alltraps_segs: > - SAVE_SEGS > - testl $PSL_I,TF_RFLAGS(%rsp) > - jz alltraps_pushregs_no_rdi > - sti > -alltraps_pushregs_no_rdi: > +1: SAVE_SEGS > movq%rdx,TF_RDX(%rsp) > movq%rax,TF_RAX(%rsp) > + movq%rcx,TF_RCX(%rsp) > + testb $SEL_RPL_MASK,T
svn commit: r330714 - head/sys/dev/mlx5
Author: cem Date: Sat Mar 10 00:59:48 2018 New Revision: 330714 URL: https://svnweb.freebsd.org/changeset/base/330714 Log: mlx5(4): Remove redundant declaration of mlx5_enter_error_state Broken in r330644. Sponsored by: Dell EMC Isilon Modified: head/sys/dev/mlx5/driver.h Modified: head/sys/dev/mlx5/driver.h == --- head/sys/dev/mlx5/driver.h Sat Mar 10 00:44:33 2018(r330713) +++ head/sys/dev/mlx5/driver.h Sat Mar 10 00:59:48 2018(r330714) @@ -865,7 +865,6 @@ static inline u32 mlx5_base_mkey(const u32 key) return key & 0xff00u; } -void mlx5_enter_error_state(struct mlx5_core_dev *dev); int mlx5_cmd_init(struct mlx5_core_dev *dev); void mlx5_cmd_cleanup(struct mlx5_core_dev *dev); void mlx5_cmd_use_events(struct mlx5_core_dev *dev); ___ 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: r330715 - head/sys/kern
Author: cem
Date: Sat Mar 10 01:01:01 2018
New Revision: 330715
URL: https://svnweb.freebsd.org/changeset/base/330715
Log:
subr_gtaskqueue: Fix minor leak of tq_name in error case
Reported by: cppcheck
Sponsored by: Dell EMC Isilon
Modified:
head/sys/kern/subr_gtaskqueue.c
Modified: head/sys/kern/subr_gtaskqueue.c
==
--- head/sys/kern/subr_gtaskqueue.c Sat Mar 10 00:59:48 2018
(r330714)
+++ head/sys/kern/subr_gtaskqueue.c Sat Mar 10 01:01:01 2018
(r330715)
@@ -134,8 +134,10 @@ _gtaskqueue_create(const char *name, int mflags,
snprintf(tq_name, TASKQUEUE_NAMELEN, "%s", (name) ? name : "taskqueue");
queue = malloc(sizeof(struct gtaskqueue), M_GTASKQUEUE, mflags |
M_ZERO);
- if (!queue)
+ if (!queue) {
+ free(queue->tq_name, M_GTASKQUEUE);
return (NULL);
+ }
STAILQ_INIT(&queue->tq_queue);
TAILQ_INIT(&queue->tq_active);
___
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: r330716 - head/sys/sys
Author: brooks Date: Sat Mar 10 01:07:30 2018 New Revision: 330716 URL: https://svnweb.freebsd.org/changeset/base/330716 Log: Remove obsolete dataacq.h. Nothing includes this file, lists it in a Makefile, or uses any of the ioctl definitions. Deleted: head/sys/sys/dataacq.h ___ 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: r330717 - head/sys/cam/nvme
Author: cem
Date: Sat Mar 10 01:28:55 2018
New Revision: 330717
URL: https://svnweb.freebsd.org/changeset/base/330717
Log:
nvme_da: Fix minor memory leak in error case
Reported by: cppcheck
Sponsored by: Dell EMC Isilon
Modified:
head/sys/cam/nvme/nvme_da.c
Modified: head/sys/cam/nvme/nvme_da.c
==
--- head/sys/cam/nvme/nvme_da.c Sat Mar 10 01:07:30 2018(r330716)
+++ head/sys/cam/nvme/nvme_da.c Sat Mar 10 01:28:55 2018(r330717)
@@ -695,6 +695,7 @@ ndaregister(struct cam_periph *periph, void *arg)
if (cam_iosched_init(&softc->cam_iosched, periph) != 0) {
printf("ndaregister: Unable to probe new device. "
"Unable to allocate iosched memory\n");
+ free(softc, M_DEVBUF);
return(CAM_REQ_CMP_ERR);
}
___
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: r330718 - in head/libexec/tftpd: . tests
Author: asomers
Date: Sat Mar 10 01:35:26 2018
New Revision: 330718
URL: https://svnweb.freebsd.org/changeset/base/330718
Log:
tftpd: Verify world-writability for WRQ when using relative paths
tftpd(8) says that files may only be written if they already exist and are
publicly writable. tftpd.c verifies that a file is publicly writable if it
uses an absolute pathname. However, if the pathname is relative, that check
is skipped. Fix it.
Note that this is not a security vulnerability, because the transfer
ultimately doesn't work unless the file already exists and is owned by user
nobody. Also, this bug does not affect the default configuration, because
the default uses the "-s" option which makes all pathnames absolute.
PR: 226004
MFC after:3 weeks
Modified:
head/libexec/tftpd/tests/functional.c
head/libexec/tftpd/tftpd.c
Modified: head/libexec/tftpd/tests/functional.c
==
--- head/libexec/tftpd/tests/functional.c Sat Mar 10 01:28:55 2018
(r330717)
+++ head/libexec/tftpd/tests/functional.c Sat Mar 10 01:35:26 2018
(r330718)
@@ -350,6 +350,10 @@ setup(struct sockaddr_storage *to, uint16_t idx)
ATF_REQUIRE((client_s = socket(protocol, SOCK_DGRAM, 0)) > 0);
break;
}
+
+ /* Clear the client's umask. Test cases will specify exact modes */
+ umask();
+
return (client_s);
}
@@ -714,7 +718,7 @@ TFTPD_TC_DEFINE(wrq_dropped_ack,)
for (i = 0; i < nitems(contents); i++)
contents[i] = i;
- fd = open("medium.txt", O_RDWR | O_CREAT, 0644);
+ fd = open("medium.txt", O_RDWR | O_CREAT, 0666);
ATF_REQUIRE(fd >= 0);
close(fd);
@@ -747,7 +751,7 @@ TFTPD_TC_DEFINE(wrq_dropped_data,)
size_t contents_len;
char buffer[1024];
- fd = open("small.txt", O_RDWR | O_CREAT, 0644);
+ fd = open("small.txt", O_RDWR | O_CREAT, 0666);
ATF_REQUIRE(fd >= 0);
close(fd);
contents_len = strlen(contents) + 1;
@@ -782,7 +786,7 @@ TFTPD_TC_DEFINE(wrq_duped_data,)
for (i = 0; i < nitems(contents); i++)
contents[i] = i;
- fd = open("medium.txt", O_RDWR | O_CREAT, 0644);
+ fd = open("medium.txt", O_RDWR | O_CREAT, 0666);
ATF_REQUIRE(fd >= 0);
close(fd);
@@ -831,7 +835,8 @@ TFTPD_TC_DEFINE(wrq_eaccess_world_readable,)
close(fd);
SEND_WRQ("empty.txt", "octet");
- atf_tc_expect_fail("PR 226004 with relative pathnames, tftpd doesn't
validate world writability");
+ atf_tc_expect_fail("PR 225996 tftpd doesn't abort on a WRQ access "
+ "violation");
RECV_ERROR(2, "Access violation");
}
Modified: head/libexec/tftpd/tftpd.c
==
--- head/libexec/tftpd/tftpd.c Sat Mar 10 01:28:55 2018(r330717)
+++ head/libexec/tftpd/tftpd.c Sat Mar 10 01:35:26 2018(r330718)
@@ -743,8 +743,12 @@ validate_access(int peer, char **filep, int mode)
dirp->name, filename);
if (stat(pathname, &stbuf) == 0 &&
(stbuf.st_mode & S_IFMT) == S_IFREG) {
- if ((stbuf.st_mode & S_IROTH) != 0) {
- break;
+ if (mode == RRQ) {
+ if ((stbuf.st_mode & S_IROTH) != 0)
+ break;
+ } else {
+ if ((stbuf.st_mode & S_IWOTH) != 0)
+ break;
}
err = EACCESS;
}
@@ -752,6 +756,8 @@ validate_access(int peer, char **filep, int mode)
if (dirp->name != NULL)
*filep = filename = pathname;
else if (mode == RRQ)
+ return (err);
+ else if (err != ENOTFOUND || !create_new)
return (err);
}
___
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: r330338 - head/sys/amd64/amd64
On Saturday, March 10, 2018 07:41:30 AM Bruce Evans wrote: > On Fri, 9 Mar 2018, John Baldwin wrote: > > > On Saturday, March 03, 2018 03:10:37 PM Andriy Gapon wrote: > >> Author: avg > >> Date: Sat Mar 3 15:10:37 2018 > >> New Revision: 330338 > >> URL: https://svnweb.freebsd.org/changeset/base/330338 > >> > >> Log: > >> db_nextframe/amd64: catch up with r328083 to recognize > >> fast_syscall_common > >> > >> Since that change the system call stack traces look like this: > >> ... > >> sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0028e13ac0 > >> amd64_syscall() at amd64_syscall+0x79b/frame 0xfe0028e13bf0 > >> fast_syscall_common() at fast_syscall_common+0x101/frame > >> 0xfe0028e13bf0 > >> So, db_nextframe() stopped recognizing the system call frame. > >> This commit should fix that. > >> > >> Reviewed by: kib > >> MFC after: 4 days > >> > >> Modified: > >> head/sys/amd64/amd64/db_trace.c > >> > >> Modified: head/sys/amd64/amd64/db_trace.c > >> == > >> --- head/sys/amd64/amd64/db_trace.cSat Mar 3 13:20:44 2018 > >> (r330337) > >> +++ head/sys/amd64/amd64/db_trace.cSat Mar 3 15:10:37 2018 > >> (r330338) > >> @@ -212,7 +212,9 @@ db_nextframe(struct amd64_frame **fp, db_addr_t *ip, s > >>strcmp(name, "Xcpususpend") == 0 || > >>strcmp(name, "Xrendezvous") == 0) > >>frame_type = INTERRUPT; > >> - else if (strcmp(name, "Xfast_syscall") == 0) > >> + else if (strcmp(name, "Xfast_syscall") == 0 || > >> + strcmp(name, "Xfast_syscall_pti") == 0 || > >> + strcmp(name, "fast_syscall_common") == 0) > >>frame_type = SYSCALL; > > > > I think you actually just want to replace Xfast_syscall with > > fast_syscall_common. Neither Xfast_syscall nor Xfast_syscall_pti call any > > functions before jumping to the common label, so when unwinding from a > > system > > call you should always get the common label. (That is, I think we should > > remove Xfast_syscall and Xfast_syscall_pti here. Any stack trace that > > happens to find those symbols during unwinding won't have a valid SYSCALL > > frame to unwind.) > > No, it needs these symbols to decode the frame after reaching a point where > the frame is actually set up. My point is that during the instructions from Xfast_syscall to fast_syscall_common there isn't a valid frame. Xfast_syscall has two instructions and hasn't yet decremented %rsp to create room for the trapframe for example. If you wanted to handle the special case of stepping through those functions you'd have to create a new type of frame that used register values from the saved frame for the debug trap. You can't assume that there's a 'struct trapframe' at 'rbp + 16'. > Also, in uncommitted fixes I add some decoding of the non-frame between > the entry point and when the frame is set up. Then the frame register > is still the user's for the syscall case, so should not even be accessed. > The i386 output looks like this: > > current: > XX12: Breakpoint at Xint0x80_syscall: pushl $0x2 > XX12: db> t > XX12: Tracing pid 1 tid 11 td 0xc6fad000 > XX12: Xint0x80_syscall(33,282,bfbfee0c,3b,0,...) at Xint0x80_syscall/frame > 0xd1d05bd8 > XX12: kernload(2,bfbfeec4,bfbfeed0,804812b,80a3d64,...) at 0x805188f/frame > 0xbfbfee7c > > fixed: > XX12F: Breakpoint at Xint0x80_syscall: pushl $0x2 > XX12F: db> t > XX12F: Tracing pid 1 tid 11 td 0xd4c23000 > XX12F: Xint0x80_syscall(2,bfbfeec4,bfbfeed0,804812b,80a3d64,...) at > Xint0x80_syscall/frame 0xbfbfee7c > XX12F: --- unknown trap, ebp = 0xbfbfee7c, sp = 0xd3399bdc, ks = 0xd3398000, > kse = 0xd339a000 --- > > where most of the values on the last line are for debugging (ebp is the user > stack pointer which will become inaccessible, sp is the local variable sp > and [ks, kse - 1] is the thread's kernel stack range (sp must be in this > else the backtrace stops). Yes, both of these symbols would only be found instructions for this type of special frame. Using the 'SYSCALL' frame type for the Xfast_syscall* symbols would always be wrong. Until such time as we have the new frame type we should just ignore them. > Jumps and labels with names inside functions complicate things. I think > fast_syscall_common needs to be in the list too, and the many alltraps > labels should have been there. This will be more useful with my fix. > The label calltrap has always been in the list. This works right since > the frame has been set up then -- IIRC it is the first place where the > frame has been set up, and label it more for gdb than for ddb, and decode > the frame for ddb (presumably gdb decodes the frame too). gdb does depend on the names, and I was looking at this commit again to see if I needed to update gdb. I thought I didn't, but now I see that gdb was dep
svn commit: r330719 - in head/libexec/tftpd: . tests
Author: asomers
Date: Sat Mar 10 01:43:55 2018
New Revision: 330719
URL: https://svnweb.freebsd.org/changeset/base/330719
Log:
tftpd: Abort on an WRQ access violation
On a WRQ (write request) tftpd checks whether the client has access
permission for the file in question. If not, then the write is prevented.
However, tftpd doesn't reply with an ERROR packet, nor does it abort.
Instead, it tries to receive the packet anyway.
The symptom is slightly different depending on the nature of the error. If
the target file is nonexistent and tftpd lacks permission to create it, then
tftpd will willingly receive the file, but not write it anywhere. If the
file exists but is not writable, then tftpd will fail to ACK to WRQ.
PR: 225996
MFC after:3 weeks
Modified:
head/libexec/tftpd/tests/functional.c
head/libexec/tftpd/tftpd.c
Modified: head/libexec/tftpd/tests/functional.c
==
--- head/libexec/tftpd/tests/functional.c Sat Mar 10 01:35:26 2018
(r330718)
+++ head/libexec/tftpd/tests/functional.c Sat Mar 10 01:43:55 2018
(r330719)
@@ -817,8 +817,6 @@ TFTPD_TC_DEFINE(wrq_eaccess,)
close(fd);
SEND_WRQ("empty.txt", "octet");
- atf_tc_expect_fail("PR 225996 tftpd doesn't abort on a WRQ access "
- "violation");
RECV_ERROR(2, "Access violation");
}
@@ -835,8 +833,6 @@ TFTPD_TC_DEFINE(wrq_eaccess_world_readable,)
close(fd);
SEND_WRQ("empty.txt", "octet");
- atf_tc_expect_fail("PR 225996 tftpd doesn't abort on a WRQ access "
- "violation");
RECV_ERROR(2, "Access violation");
}
@@ -911,8 +907,6 @@ TFTPD_TC_DEFINE(wrq_netascii,)
TFTPD_TC_DEFINE(wrq_nonexistent,)
{
SEND_WRQ("nonexistent.txt", "octet");
- atf_tc_expect_fail("PR 225996 tftpd doesn't abort on a WRQ access "
- "violation");
RECV_ERROR(1, "File not found");
}
Modified: head/libexec/tftpd/tftpd.c
==
--- head/libexec/tftpd/tftpd.c Sat Mar 10 01:35:26 2018(r330718)
+++ head/libexec/tftpd/tftpd.c Sat Mar 10 01:43:55 2018(r330719)
@@ -545,6 +545,10 @@ tftp_wrq(int peer, char *recvbuffer, ssize_t size)
filename, errtomsg(ecode));
}
+ if (ecode) {
+ send_error(peer, ecode);
+ exit(1);
+ }
tftp_recvfile(peer, mode);
exit(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: r330720 - in head/libexec/tftpd: . tests
Author: asomers
Date: Sat Mar 10 01:50:43 2018
New Revision: 330720
URL: https://svnweb.freebsd.org/changeset/base/330720
Log:
tftpd: reject unknown opcodes
If tftpd receives a command with an unknown opcode, it simply exits 1. It
doesn't send an ERROR packet, and the client will hang waiting for one. Fix
it.
PR: 226005
MFC after:3 weeks
Modified:
head/libexec/tftpd/tests/functional.c
head/libexec/tftpd/tftpd.c
Modified: head/libexec/tftpd/tests/functional.c
==
--- head/libexec/tftpd/tests/functional.c Sat Mar 10 01:43:55 2018
(r330719)
+++ head/libexec/tftpd/tests/functional.c Sat Mar 10 01:50:43 2018
(r330720)
@@ -677,7 +677,6 @@ TFTPD_TC_DEFINE(unknown_opcode,)
{
/* Looks like an RRQ or WRQ request, but with a bad opcode */
SEND_STR("\0\007foo.txt\0octet\0");
- atf_tc_expect_timeout("PR 226005 tftpd ignores bad opcodes but doesn't
reject them");
RECV_ERROR(4, "Illegal TFTP operation");
}
Modified: head/libexec/tftpd/tftpd.c
==
--- head/libexec/tftpd/tftpd.c Sat Mar 10 01:43:55 2018(r330719)
+++ head/libexec/tftpd/tftpd.c Sat Mar 10 01:50:43 2018(r330720)
@@ -421,8 +421,7 @@ main(int argc, char *argv[])
"%s read access denied", peername);
exit(1);
}
- }
- if (tp->th_opcode == WRQ) {
+ } else if (tp->th_opcode == WRQ) {
if (allow_wo)
tftp_wrq(peer, tp->th_stuff, n - 1);
else {
@@ -430,7 +429,8 @@ main(int argc, char *argv[])
"%s write access denied", peername);
exit(1);
}
- }
+ } else
+ send_error(peer, EBADOP);
exit(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: r330721 - head/sys/kern
Author: cem
Date: Sat Mar 10 01:53:42 2018
New Revision: 330721
URL: https://svnweb.freebsd.org/changeset/base/330721
Log:
subr_gtaskqueue: Fix braino from r330715
Submitted by: markj
Sponsored by: Dell EMC Isilon
Modified:
head/sys/kern/subr_gtaskqueue.c
Modified: head/sys/kern/subr_gtaskqueue.c
==
--- head/sys/kern/subr_gtaskqueue.c Sat Mar 10 01:50:43 2018
(r330720)
+++ head/sys/kern/subr_gtaskqueue.c Sat Mar 10 01:53:42 2018
(r330721)
@@ -135,7 +135,7 @@ _gtaskqueue_create(const char *name, int mflags,
queue = malloc(sizeof(struct gtaskqueue), M_GTASKQUEUE, mflags |
M_ZERO);
if (!queue) {
- free(queue->tq_name, M_GTASKQUEUE);
+ free(tq_name, M_GTASKQUEUE);
return (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: r328625 - in head/sys: amd64/amd64 amd64/ia32 amd64/include dev/cpuctl i386/i386 x86/include x86/x86
On 9 March 2018 at 19:41, Dexuan-BSD Cui wrote:
> Hi,
>
> In my FreeBSD 11.1 VM, I'm getting this build failure and it looks
> this revision causes the failure:
>
> /root/bsd.git/sys/amd64/amd64/support.S:855:2: error: unknown directive
> .altmacro
> ^
Are you trying to build a head kernel using the toolchain in 11.1?
That won't work (because of missing .altmacro support). Building
kernel-toolchain first should get a working toolchain.
> It looks -fno-integrated-as might fix the failure for me according to:
Avoiding the integrated assembler is indeed the workaround for this
issue, but you'll want to apply it only to the affected file.
Kostik's 11.1 merge candidate patch adds to sys/conf/Makefile.amd64
ASM_CFLAGS.support.S= ${CLANG_NO_IAS}
___
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: r330722 - head/sys/conf
Author: bdrewery
Date: Sat Mar 10 02:09:36 2018
New Revision: 330722
URL: https://svnweb.freebsd.org/changeset/base/330722
Log:
Reduce overhead for simple 'make -V' lookups by avoiding 'find sys/'.
Setting -DNO_SKIP_MPATH can be used for debugging.
Reported by: bde
MFC after:2 weeks
Sponsored by: Dell EMC
Modified:
head/sys/conf/config.mk
head/sys/conf/kern.pre.mk
Modified: head/sys/conf/config.mk
==
--- head/sys/conf/config.mk Sat Mar 10 01:53:42 2018(r330721)
+++ head/sys/conf/config.mk Sat Mar 10 02:09:36 2018(r330722)
@@ -50,7 +50,8 @@ KERN_OPTS!=cat ${KERNBUILDDIR}/opt*.h | awk '{print $$
.export KERN_OPTS
.endif
-.if !defined(NO_MODULES) && !defined(__MPATH)
+.if !defined(NO_MODULES) && !defined(__MPATH) && !make(install) && \
+(empty(.MAKEFLAGS:M-V) || defined(NO_SKIP_MPATH))
__MPATH!=find ${SYSDIR:tA}/ -name \*_if.m
.export __MPATH
.endif
Modified: head/sys/conf/kern.pre.mk
==
--- head/sys/conf/kern.pre.mk Sat Mar 10 01:53:42 2018(r330721)
+++ head/sys/conf/kern.pre.mk Sat Mar 10 02:09:36 2018(r330722)
@@ -214,7 +214,8 @@ SYSTEM_LD_TAIL= @${OBJCOPY} --strip-symbol gcc2_compil
SYSTEM_DEP+= ${LDSCRIPT}
# Calculate path for .m files early, if needed.
-.if !defined(NO_MODULES) && !defined(__MPATH) && !make(install)
+.if !defined(NO_MODULES) && !defined(__MPATH) && !make(install) && \
+(empty(.MAKEFLAGS:M-V) || defined(NO_SKIP_MPATH))
__MPATH!=find ${S:tA}/ -name \*_if.m
.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"
svn commit: r330723 - head/sys/conf
Author: bdrewery
Date: Sat Mar 10 02:10:19 2018
New Revision: 330723
URL: https://svnweb.freebsd.org/changeset/base/330723
Log:
Skip reading depend files with -V unless looking up a depend variable.
This speeds up some simple -V lookups significantly.
Reported by: bde
MFC after:2 weeks
Sponsored by: Dell EMC
Modified:
head/sys/conf/kern.post.mk
Modified: head/sys/conf/kern.post.mk
==
--- head/sys/conf/kern.post.mk Sat Mar 10 02:09:36 2018(r330722)
+++ head/sys/conf/kern.post.mk Sat Mar 10 02:10:19 2018(r330723)
@@ -201,6 +201,7 @@ _meta_filemon= 1
# since it will track dependencies itself. OBJS_DEPEND_GUESS is still used
# for _meta_filemon but not for _SKIP_DEPEND.
.if !defined(NO_SKIP_DEPEND) && (make(*obj) || \
+(!empty(.MAKEFLAGS:M-V) && empty(.MAKEFLAGS:M*DEP*)) || \
${.TARGETS:M*clean*} == ${.TARGETS} || \
${.TARGETS:M*install*} == ${.TARGETS})
_SKIP_DEPEND= 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: r330724 - head/sys/conf
Author: bdrewery
Date: Sat Mar 10 02:10:26 2018
New Revision: 330724
URL: https://svnweb.freebsd.org/changeset/base/330724
Log:
Don't skip reading depend for 'make obj' unless it is alone.
This was effectively done in bsd.dep.mk quite some time ago.
MFC after:2 weeks
Sponsored by: Dell EMC
Modified:
head/sys/conf/kern.post.mk
Modified: head/sys/conf/kern.post.mk
==
--- head/sys/conf/kern.post.mk Sat Mar 10 02:10:19 2018(r330723)
+++ head/sys/conf/kern.post.mk Sat Mar 10 02:10:26 2018(r330724)
@@ -200,8 +200,9 @@ _meta_filemon= 1
# Also skip generating or including .depend.* files if in meta+filemon mode
# since it will track dependencies itself. OBJS_DEPEND_GUESS is still used
# for _meta_filemon but not for _SKIP_DEPEND.
-.if !defined(NO_SKIP_DEPEND) && (make(*obj) || \
+.if !defined(NO_SKIP_DEPEND) && \
(!empty(.MAKEFLAGS:M-V) && empty(.MAKEFLAGS:M*DEP*)) || \
+(${.TARGETS:M*obj} == ${.TARGETS} || \
${.TARGETS:M*clean*} == ${.TARGETS} || \
${.TARGETS:M*install*} == ${.TARGETS})
_SKIP_DEPEND= 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: r330725 - head/sys/conf
Author: bdrewery
Date: Sat Mar 10 02:13:48 2018
New Revision: 330725
URL: https://svnweb.freebsd.org/changeset/base/330725
Log:
Fix rebase mismerge in r330724.
X-MFC-With: r330724
MFC after:2 weeks
Sponsored by: Dell EMC
Modified:
head/sys/conf/kern.post.mk
Modified: head/sys/conf/kern.post.mk
==
--- head/sys/conf/kern.post.mk Sat Mar 10 02:10:26 2018(r330724)
+++ head/sys/conf/kern.post.mk Sat Mar 10 02:13:48 2018(r330725)
@@ -201,8 +201,8 @@ _meta_filemon= 1
# since it will track dependencies itself. OBJS_DEPEND_GUESS is still used
# for _meta_filemon but not for _SKIP_DEPEND.
.if !defined(NO_SKIP_DEPEND) && \
-(!empty(.MAKEFLAGS:M-V) && empty(.MAKEFLAGS:M*DEP*)) || \
-(${.TARGETS:M*obj} == ${.TARGETS} || \
+((!empty(.MAKEFLAGS:M-V) && empty(.MAKEFLAGS:M*DEP*)) || \
+${.TARGETS:M*obj} == ${.TARGETS} || \
${.TARGETS:M*clean*} == ${.TARGETS} || \
${.TARGETS:M*install*} == ${.TARGETS})
_SKIP_DEPEND= 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: r330727 - in head/sys: arm/broadcom/bcm2835 dts/arm
Author: gonzo
Date: Sat Mar 10 02:49:58 2018
New Revision: 330727
URL: https://svnweb.freebsd.org/changeset/base/330727
Log:
[rpi] remove IRQ support for BCM233x RNG
Upstream DTBs don't provide IRQ lines for the RNG. Moreover, harvesting
bytes as often as the RNG interrupt is triggered (87 times per sec) is an
overkill.
For these reasons, get rid of the interrupt mode and make callout mode the
default, with random bits harvested every 4 seconds.
Submitted by: Sylvain Garrigues
Reviewed by: ian, imp, manu, mmel
Approved by: emaste
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D14541
Modified:
head/sys/arm/broadcom/bcm2835/bcm2835_rng.c
head/sys/dts/arm/rpi.dts
head/sys/dts/arm/rpi2.dts
Modified: head/sys/arm/broadcom/bcm2835/bcm2835_rng.c
==
--- head/sys/arm/broadcom/bcm2835/bcm2835_rng.c Sat Mar 10 02:15:45 2018
(r330726)
+++ head/sys/arm/broadcom/bcm2835/bcm2835_rng.c Sat Mar 10 02:49:58 2018
(r330727)
@@ -51,10 +51,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-#if !defined(BCM2835_RNG_USE_CALLOUT)
-#defineBCM2835_RNG_USE_INTERRUPT
-#endif
-
static device_attach_t bcm2835_rng_attach;
static device_detach_t bcm2835_rng_detach;
static device_probe_t bcm2835_rng_probe;
@@ -92,18 +88,15 @@ static device_probe_t bcm2835_rng_probe;
#defineRNG_NUM_OSCILLATORS 6
#defineRNG_STALL_COUNT_DEFAULT 10
+#defineRNG_CALLOUT_TICKS (hz * 4)
+
struct bcm2835_rng_softc {
device_tsc_dev;
struct resource * sc_mem_res;
struct resource * sc_irq_res;
void * sc_intr_hdl;
-#if defined(BCM2835_RNG_USE_CALLOUT) || defined(BCM2835_RNG_USE_INTERRUPT)
uint32_tsc_buf[RNG_FIFO_WORDS];
-#endif
-#if defined(BCM2835_RNG_USE_CALLOUT)
struct callout sc_rngto;
- int sc_rnghz;
-#endif
int sc_stall_count;
int sc_rbg2x;
longsc_underrun;
@@ -214,20 +207,7 @@ bcm2835_rng_disable_intr(struct bcm2835_rng_softc *sc)
bcm2835_rng_write4(sc, RNG_INT_MASK, mask);
}
-#if defined(BCM2835_RNG_USE_INTERRUPT)
static void
-bcm2835_rng_enable_intr(struct bcm2835_rng_softc *sc)
-{
- uint32_t mask;
-
- /* Clear the interrupt off bit in the interrupt mask register */
- mask = bcm2835_rng_read4(sc, RNG_INT_MASK);
- mask &= ~RNG_INT_OFF_BIT;
-bcm2835_rng_write4(sc, RNG_INT_MASK, mask);
-}
-#endif
-
-static void
bcm2835_rng_start(struct bcm2835_rng_softc *sc)
{
uint32_t ctrl;
@@ -244,11 +224,6 @@ bcm2835_rng_start(struct bcm2835_rng_softc *sc)
if (sc->sc_rbg2x)
ctrl |= RNG_RBG2X;
bcm2835_rng_write4(sc, RNG_CTRL, ctrl);
-
-#if defined(BCM2835_RNG_USE_INTERRUPT)
- /* Enable the interrupt */
- bcm2835_rng_enable_intr(sc);
-#endif
}
static void
@@ -263,12 +238,13 @@ bcm2835_rng_stop(struct bcm2835_rng_softc *sc)
}
static void
-bcm2835_rng_harvest(struct bcm2835_rng_softc *sc)
+bcm2835_rng_harvest(void *arg)
{
uint32_t *dest;
uint32_t status;
u_int cnt, nread, num_avail, num_words;
int seen_underrun, num_stalls;
+ struct bcm2835_rng_softc *sc = arg;
dest = sc->sc_buf;
nread = num_words = 0;
@@ -316,9 +292,7 @@ bcm2835_rng_harvest(struct bcm2835_rng_softc *sc)
random_harvest_queue(sc->sc_buf, cnt, cnt * NBBY / 2,
RANDOM_PURE_BROADCOM);
-#if defined(BCM2835_RNG_USE_CALLOUT)
- callout_reset(&sc->sc_rngto, sc->sc_rnghz, bcm2835_rng_harvest, sc);
-#endif
+ callout_reset(&sc->sc_rngto, RNG_CALLOUT_TICKS, bcm2835_rng_harvest,
sc);
}
static int
@@ -390,10 +364,10 @@ bcm2835_rng_attach(device_t dev)
sc = device_get_softc(dev);
sc->sc_dev = dev;
sc->sc_stall_count = RNG_STALL_COUNT_DEFAULT;
-#ifdef BCM2835_RNG_USE_CALLOUT
+
/* Initialize callout */
callout_init(&sc->sc_rngto, CALLOUT_MPSAFE);
-#endif
+
TUNABLE_INT_FETCH("bcmrng.2xspeed", &sc->sc_rbg2x);
TUNABLE_INT_FETCH("bcmrng.stall_count", &sc->sc_stall_count);
@@ -406,27 +380,6 @@ bcm2835_rng_attach(device_t dev)
return (ENXIO);
}
-#if defined(BCM2835_RNG_USE_INTERRUPT)
- /* Allocate interrupt resource */
- rid = 0;
- sc->sc_irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid,
- RF_SHAREABLE | RF_ACTIVE);
- if (sc->sc_irq_res == NULL) {
- bcm2835_rng_detach(dev);
- return (ENXIO);
- }
-
- /* Set up the interrupt handler */
- error = bus_setup_intr(dev, sc->sc_irq_res, INTR_TYPE_BIO | INTR_MPSAFE,
- NULL, (driver_intr_t *)bcm2835_rng_harvest, sc, &sc->sc_intr_hdl);
- if (error) {
-
Re: svn commit: r328013 - head/sbin/fsck_ffs
On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: >> >> etc/rc.d/fsck doesn't know how to interpret the new exit code and now >> just drops to a single-user shell when it is encountered. […] >> >> Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to This is, in fact, the reason that I made the change I did. I was trying to put in a retry loop to rc.d/fsck, but found that I couldn’t get it to work because fsck and fsck_ffs were not exiting with non-zero status. The drop to single user is not really due to the specific (new) error code of 16, it is due to the fact that fsck_ffs is now exiting with a non-zero status when it hasn’t completely cleaned the file system; /any/ non-zero status would cause the current rc.d/fsck script to go to single user. Prior to my change, fsck_ffs was exiting with a zero status even though it had not completely cleaned the filesystem and told the user to run it again. > > fsck_ffs already has a -R flag to automatically retry, wouldn't that be > a better mechanism for handling this new type of retry? That’s true; however, there is currently no way to pass that flag through the filesystem-agnostic fsck wrapper called from rc.d/fsck to the filesystem-specific fsck_ffs program that it calls. One could implement a similar flag on the fsck wrapper to be passed along to the filesystem-specific checker, but I think fsck_ffs is the only one that currently implements such a flag. -- David Bright d...@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"
Re: svn commit: r330644 - in head/sys/dev/mlx5: . mlx5_core
On Thu, Mar 8, 2018 at 2:47 AM, Hans Petter Selasky wrote: > Author: hselasky > Date: Thu Mar 8 09:47:09 2018 > New Revision: 330644 > URL: https://svnweb.freebsd.org/changeset/base/330644 > > Log: > Updates for PCI and health monitor recovery in mlx5core. > This patch accumulates the following Linux commits: > > mlx5_health.c > - 78ccb25861d76a8fc5c678d762180e6918834200 > mlx5_core: Fix wrong name in struct > - 171bb2c560f45c0427ca3776a4c8f4e26e559400 > mlx5_core: Update health syndromes > - 0144a95e2ad53a40c62148f44fb0c1f9d2a0d1e9 > mlx5_core: Use accessor functions to read from device memory > - ac6ea6e81a80172612e0c9ef93720f371b198918 > mlx5_core: Use private health thread for each device > - fd76ee4da55abb21babfc69310d321b9cb9a32e0 > mlx5_core: Fix internal error detection conditions > - 2241007b3d783cbdbaa78c30bdb1994278b6f9b9 > mlx5: Clear health sick bit when starting health poll > - 712bfef60912d91033cb25739f7444d5b8d8c59f > mlx5: Fix version printout in case of health issue > - 89d44f0a6c732db23b219be708e2fe1e03ee4842 > mlx5_core: Add pci error handlers to mlx5_core driver > > mlx5_cmd.c > - be87544de8df2b1eb34bcb5e32691287d96f9ec4 > mlx5_core: Fix async commands return code > - a31208b1e11df334d443ec8cace7636150bb8ce2 > mlx5_core: New init and exit flow for mlx5_core > - 020446e01eebc9dbe7eda038e570ab9c7ab13586 > mlx5_core: Prepare cmd interface to system errors handling > - 89d44f0a6c732db23b219be708e2fe1e03ee4842 > mlx5_core: Add pci error handlers to mlx5_core driver > - 0d834442cc247c7b3f3bd6019512ae03e96dd99a > mlx5: Fix teardown errors that happen in pci error handler > > mlx5_main.c > - 5fc7197d3a256d9c5de3134870304b24892a4908 > mlx5: Add pci shutdown callback > > Submitted by: Matthew Finlay > MFC after:1 week > Sponsored by: Mellanox Technologies > > Modified: > > It looks like this commit broke the build with GCC6. Could you please take a look? https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/4790/ ___ 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: r330644 - in head/sys/dev/mlx5: . mlx5_core
Hi Alan, I think I fixed it in r330714, if you want to update to that revision. Best, Conrad On Fri, Mar 9, 2018 at 7:14 PM, Alan Somers wrote: > On Thu, Mar 8, 2018 at 2:47 AM, Hans Petter Selasky > wrote: >> >> Author: hselasky >> Date: Thu Mar 8 09:47:09 2018 >> New Revision: 330644 >> URL: https://svnweb.freebsd.org/changeset/base/330644 >> >> Log: >> Updates for PCI and health monitor recovery in mlx5core. >> This patch accumulates the following Linux commits: >> >> mlx5_health.c >> - 78ccb25861d76a8fc5c678d762180e6918834200 >> mlx5_core: Fix wrong name in struct >> - 171bb2c560f45c0427ca3776a4c8f4e26e559400 >> mlx5_core: Update health syndromes >> - 0144a95e2ad53a40c62148f44fb0c1f9d2a0d1e9 >> mlx5_core: Use accessor functions to read from device memory >> - ac6ea6e81a80172612e0c9ef93720f371b198918 >> mlx5_core: Use private health thread for each device >> - fd76ee4da55abb21babfc69310d321b9cb9a32e0 >> mlx5_core: Fix internal error detection conditions >> - 2241007b3d783cbdbaa78c30bdb1994278b6f9b9 >> mlx5: Clear health sick bit when starting health poll >> - 712bfef60912d91033cb25739f7444d5b8d8c59f >> mlx5: Fix version printout in case of health issue >> - 89d44f0a6c732db23b219be708e2fe1e03ee4842 >> mlx5_core: Add pci error handlers to mlx5_core driver >> >> mlx5_cmd.c >> - be87544de8df2b1eb34bcb5e32691287d96f9ec4 >> mlx5_core: Fix async commands return code >> - a31208b1e11df334d443ec8cace7636150bb8ce2 >> mlx5_core: New init and exit flow for mlx5_core >> - 020446e01eebc9dbe7eda038e570ab9c7ab13586 >> mlx5_core: Prepare cmd interface to system errors handling >> - 89d44f0a6c732db23b219be708e2fe1e03ee4842 >> mlx5_core: Add pci error handlers to mlx5_core driver >> - 0d834442cc247c7b3f3bd6019512ae03e96dd99a >> mlx5: Fix teardown errors that happen in pci error handler >> >> mlx5_main.c >> - 5fc7197d3a256d9c5de3134870304b24892a4908 >> mlx5: Add pci shutdown callback >> >> Submitted by: Matthew Finlay >> MFC after:1 week >> Sponsored by: Mellanox Technologies >> >> Modified: >> > > It looks like this commit broke the build with GCC6. Could you please take > a look? > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/4790/ > ___ 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: r330644 - in head/sys/dev/mlx5: . mlx5_core
Yeah, looks like it's working now. Thanks. On Fri, Mar 9, 2018 at 8:25 PM, Conrad Meyer wrote: > Hi Alan, > > I think I fixed it in r330714, if you want to update to that revision. > > Best, > Conrad > > On Fri, Mar 9, 2018 at 7:14 PM, Alan Somers wrote: > > On Thu, Mar 8, 2018 at 2:47 AM, Hans Petter Selasky < > hsela...@freebsd.org> > > wrote: > >> > >> Author: hselasky > >> Date: Thu Mar 8 09:47:09 2018 > >> New Revision: 330644 > >> URL: https://svnweb.freebsd.org/changeset/base/330644 > >> > >> Log: > >> Updates for PCI and health monitor recovery in mlx5core. > >> This patch accumulates the following Linux commits: > >> > >> mlx5_health.c > >> - 78ccb25861d76a8fc5c678d762180e6918834200 > >> mlx5_core: Fix wrong name in struct > >> - 171bb2c560f45c0427ca3776a4c8f4e26e559400 > >> mlx5_core: Update health syndromes > >> - 0144a95e2ad53a40c62148f44fb0c1f9d2a0d1e9 > >> mlx5_core: Use accessor functions to read from device memory > >> - ac6ea6e81a80172612e0c9ef93720f371b198918 > >> mlx5_core: Use private health thread for each device > >> - fd76ee4da55abb21babfc69310d321b9cb9a32e0 > >> mlx5_core: Fix internal error detection conditions > >> - 2241007b3d783cbdbaa78c30bdb1994278b6f9b9 > >> mlx5: Clear health sick bit when starting health poll > >> - 712bfef60912d91033cb25739f7444d5b8d8c59f > >> mlx5: Fix version printout in case of health issue > >> - 89d44f0a6c732db23b219be708e2fe1e03ee4842 > >> mlx5_core: Add pci error handlers to mlx5_core driver > >> > >> mlx5_cmd.c > >> - be87544de8df2b1eb34bcb5e32691287d96f9ec4 > >> mlx5_core: Fix async commands return code > >> - a31208b1e11df334d443ec8cace7636150bb8ce2 > >> mlx5_core: New init and exit flow for mlx5_core > >> - 020446e01eebc9dbe7eda038e570ab9c7ab13586 > >> mlx5_core: Prepare cmd interface to system errors handling > >> - 89d44f0a6c732db23b219be708e2fe1e03ee4842 > >> mlx5_core: Add pci error handlers to mlx5_core driver > >> - 0d834442cc247c7b3f3bd6019512ae03e96dd99a > >> mlx5: Fix teardown errors that happen in pci error handler > >> > >> mlx5_main.c > >> - 5fc7197d3a256d9c5de3134870304b24892a4908 > >> mlx5: Add pci shutdown callback > >> > >> Submitted by: Matthew Finlay > >> MFC after:1 week > >> Sponsored by: Mellanox Technologies > >> > >> Modified: > >> > > > > It looks like this commit broke the build with GCC6. Could you please > take > > a look? > > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/4790/ > > > ___ 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: r330711 - head/sbin/sysctl
10.03.2018 6:37, John Baldwin wrote: > Author: jhb > Date: Fri Mar 9 23:37:19 2018 > New Revision: 330711 > URL: https://svnweb.freebsd.org/changeset/base/330711 > > Log: > Permit sysctl(8) to set an array of numeric values for a single node. > > Most sysctl nodes only return a single value, but some nodes return an > array of values (e.g. kern.cp_time). sysctl(8) understand how to display > the values of a node that returns multiple values (it prints out each > numeric value separated by spaces). However, until now sysctl(8) has > only been able to set sysctl nodes to a single value. This change > allows sysctl to accept a new value for a numeric sysctl node that contains > multiple values separated by either spaces or commas. sysctl(8) parses > this list into an array of values and passes the array as the "new" value > to sysctl(2). Note well: we already have some examples of complex sysctl comma-separated "list" values such as: security.mac.portacl.rules=uid:53:tcp:53,uid:53:udp:53 ___ 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: r330338 - head/sys/amd64/amd64
On Fri, 9 Mar 2018, John Baldwin wrote: On Saturday, March 10, 2018 07:41:30 AM Bruce Evans wrote: On Fri, 9 Mar 2018, John Baldwin wrote: On Saturday, March 03, 2018 03:10:37 PM Andriy Gapon wrote: Author: avg Date: Sat Mar 3 15:10:37 2018 New Revision: 330338 URL: https://svnweb.freebsd.org/changeset/base/330338 Log: db_nextframe/amd64: catch up with r328083 to recognize fast_syscall_common Since that change the system call stack traces look like this: ... sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0028e13ac0 amd64_syscall() at amd64_syscall+0x79b/frame 0xfe0028e13bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0028e13bf0 So, db_nextframe() stopped recognizing the system call frame. This commit should fix that. Reviewed by: kib MFC after:4 days Modified: head/sys/amd64/amd64/db_trace.c Modified: head/sys/amd64/amd64/db_trace.c == --- head/sys/amd64/amd64/db_trace.c Sat Mar 3 13:20:44 2018 (r330337) +++ head/sys/amd64/amd64/db_trace.c Sat Mar 3 15:10:37 2018 (r330338) @@ -212,7 +212,9 @@ db_nextframe(struct amd64_frame **fp, db_addr_t *ip, s strcmp(name, "Xcpususpend") == 0 || strcmp(name, "Xrendezvous") == 0) frame_type = INTERRUPT; - else if (strcmp(name, "Xfast_syscall") == 0) + else if (strcmp(name, "Xfast_syscall") == 0 || + strcmp(name, "Xfast_syscall_pti") == 0 || + strcmp(name, "fast_syscall_common") == 0) frame_type = SYSCALL; I think you actually just want to replace Xfast_syscall with fast_syscall_common. Neither Xfast_syscall nor Xfast_syscall_pti call any functions before jumping to the common label, so when unwinding from a system call you should always get the common label. (That is, I think we should remove Xfast_syscall and Xfast_syscall_pti here. Any stack trace that happens to find those symbols during unwinding won't have a valid SYSCALL frame to unwind.) No, it needs these symbols to decode the frame after reaching a point where the frame is actually set up. My point is that during the instructions from Xfast_syscall to fast_syscall_common there isn't a valid frame. I know. Xfast_syscall has two instructions and hasn't yet decremented %rsp to create room for the trapframe for example. If you wanted to handle the special case of stepping through those functions you'd have to create a new type of frame that used register values from the saved frame for the debug trap. You can't assume that there's a 'struct trapframe' at 'rbp + 16'. In my version (only written for i386 so far), the strcmp()s are not even reached for syscalls since t is known and discovered that there is no trapframe at [er]bp + 16 (since that is not in the kernel stack). For nested exceptions, [er]bp + 16 is on the kernel stack and the trap printing for the reentry is bogus before the frame is set up, but ebp is now a usually-good frame for the interrupted context and the backtrace continues (as in -current) back to the top frame with no further problems except for a wrong name at the top level caused by cross-jumping. Also, in uncommitted fixes I add some decoding of the non-frame between the entry point and when the frame is set up. Then the frame register is still the user's for the syscall case, so should not even be accessed. The i386 output looks like this: current: XX12: Breakpoint at Xint0x80_syscall: pushl $0x2 XX12: db> t XX12: Tracing pid 1 tid 11 td 0xc6fad000 XX12: Xint0x80_syscall(33,282,bfbfee0c,3b,0,...) at Xint0x80_syscall/frame 0xd1d05bd8 XX12: kernload(2,bfbfeec4,bfbfeed0,804812b,80a3d64,...) at 0x805188f/frame 0xbfbfee7c fixed: XX12F: Breakpoint at Xint0x80_syscall: pushl $0x2 XX12F: db> t XX12F: Tracing pid 1 tid 11 td 0xd4c23000 XX12F: Xint0x80_syscall(2,bfbfeec4,bfbfeed0,804812b,80a3d64,...) at Xint0x80_syscall/frame 0xbfbfee7c XX12F: --- unknown trap, ebp = 0xbfbfee7c, sp = 0xd3399bdc, ks = 0xd3398000, kse = 0xd339a000 --- where most of the values on the last line are for debugging (ebp is the user stack pointer which will become inaccessible, sp is the local variable sp and [ks, kse - 1] is the thread's kernel stack range (sp must be in this else the backtrace stops). Yes, both of these symbols would only be found instructions for this type of special frame. Using the 'SYSCALL' frame type for the Xfast_syscall* symbols would always be wrong. Until such time as we have the new frame type we should just ignore them. It's to have to have a new frame type. Setting up the frame takes 20-50 or more instructions and there is a different frame type at every instruction, possibly multiplied by different setups for different entries (similarly for doreti except it clearly has only one exit). (i386 is still optimiz
Re: svn commit: r330712 - head/bin/ps
On Sat, 10 Mar 2018, Mike Karels wrote: ... Log: Change ps(1) output width to unlimited if not interactive ... Modified: head/bin/ps/ps.1 == --- head/bin/ps/ps.1Fri Mar 9 23:37:19 2018(r330711) +++ head/bin/ps/ps.1Sat Mar 10 00:10:47 2018(r330712) @@ -101,6 +101,14 @@ The default output format includes, for each process, controlling terminal, state, CPU time (including both user and system time) and associated command. .Pp +If the +.Nm +process is associated with a terminal, the default output width is that of the +terminal; otherwise the output width is unlimited. It is unclear how a process is assocated with a terminal and thus what this width is. For ps, unlike for most programs, a process is associated with a terminal iff any of the 3 standard file descriptors is a terminal that supports the TIOCGWINSZ ioctl, and the width of the preferred one is not 0. The preferred one is the first of STDOUT_FILENO, STDERR_FILENO and STDIN_FILENO that supports the ioctl. BUGS: if the first one somehow has width 0, then the process is considered as not being associated with a terminal even of a later one has a nonzero width. ... Modified: head/bin/ps/ps.c == --- head/bin/ps/ps.cFri Mar 9 23:37:19 2018(r330711) +++ head/bin/ps/ps.cSat Mar 10 00:10:47 2018(r330712) @@ -202,6 +202,11 @@ main(int argc, char *argv[]) * any of stdout, stderr, or stdin is a terminal. The intent * is that "ps", "ps | more", and "ps | grep" all use the same * default line length unless -w is specified. +* +* If not interactive, the default length was traditionally 79. +* It has been changed to unlimited. This is mostly for the +* benefit of non-interactive scripts, which arguably should +* use -ww, but is compatible with Linux. */ This belongs in the HOSTORY section of the man page, with version info for the change. Bruce ___ 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: r330696 - in head/libexec/tftpd: . tests
This broke build for at least ARM.
Fix:
diff --git a/libexec/tftpd/tests/functional.c
b/libexec/tftpd/tests/functional.c
index fea6870cac59..c467dfee3ba0 100644
--- a/libexec/tftpd/tests/functional.c
+++ b/libexec/tftpd/tests/functional.c
@@ -248,10 +248,10 @@ require_bufeq(const char *expected, ssize_t
expected_len, const char *actual,
ssize_t i;
ATF_REQUIRE_EQ_MSG(expected_len, len,
- "Expected %ld bytes but got %ld", expected_len, len);
+ "Expected %zd bytes but got %zd", expected_len, len);
for (i = 0; i < len; i++) {
ATF_REQUIRE_EQ_MSG(actual[i], expected[i],
- "Expected %#hhx at position %ld; got %hhx instead",
+ "Expected %#hhx at position %zd; got %hhx instead",
expected[i], i, actual[i]);
}
}
On Sat, Mar 10, 2018 at 12:30 AM Alan Somers wrote:
> Author: asomers
> Date: Fri Mar 9 15:30:20 2018
> New Revision: 330696
> URL: https://svnweb.freebsd.org/changeset/base/330696
>
> Log:
> Add some functional tests for tftpd(8)
>
> tftpd(8) is difficult to test in isolation due to its relationship with
> inetd. Create a test program that mimics the behavior of tftp(1) and
> inetd(8) and verifies tftpd's response in several different scenarios.
>
> These test cases cover all of the basic TFTP protocol, but not the
> optional
> parts.
>
> PR: 157700
> PR: 225996
> PR: 226004
> PR: 226005
> MFC after:3 weeks
> Differential Revision:https://reviews.freebsd.org/D14310
>
> Added:
> head/libexec/tftpd/tests/
> head/libexec/tftpd/tests/Makefile (contents, props changed)
> head/libexec/tftpd/tests/functional.c (contents, props changed)
> Modified:
> head/libexec/tftpd/Makefile
>
> Modified: head/libexec/tftpd/Makefile
>
> ==
> --- head/libexec/tftpd/Makefile Fri Mar 9 14:45:47 2018(r330695)
> +++ head/libexec/tftpd/Makefile Fri Mar 9 15:30:20 2018(r330696)
> @@ -14,4 +14,7 @@ CFLAGS+= -DLIBWRAP
> LIBADD=wrap
> .endif
>
> +HAS_TESTS=
> +SUBDIR.${MK_TESTS}+= tests
> +
> .include
>
> Added: head/libexec/tftpd/tests/Makefile
>
> ==
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ head/libexec/tftpd/tests/Makefile Fri Mar 9 15:30:20 2018
> (r330696)
> @@ -0,0 +1,14 @@
> +# $FreeBSD$
> +
> +.include
> +
> +# Skip on GCC 4.2, because it lacks __COUNTER__
> +.if ${COMPILER_TYPE} != "gcc" || ${COMPILER_VERSION} >= 40300
> +ATF_TESTS_C= functional
> +TEST_METADATA.functional+= timeout=15
> +.endif
> +
> +LIBADD=util
> +WARNS?=6
> +
> +.include
>
> Added: head/libexec/tftpd/tests/functional.c
>
> ==
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ head/libexec/tftpd/tests/functional.c Fri Mar 9 15:30:20 2018
> (r330696)
> @@ -0,0 +1,1006 @@
> +/*-
> + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
> + *
> + * Copyright (c) 2018 Alan Somers. 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, 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 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 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.
> + */
> +
> +#include
> +__FBSDID("$FreeBSD$");
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +static const uint16_t BASEPORT = 6969;
> +static const char pidfile[] = "tftpd.pid";
> +static int protocol = PF_UNSPEC;
> +static int s = -1; /* tftp cl
Re: svn commit: r330722 - head/sys/conf
On Sat, 10 Mar 2018, Bryan Drewery wrote: Log: Reduce overhead for simple 'make -V' lookups by avoiding 'find sys/'. Setting -DNO_SKIP_MPATH can be used for debugging. Reported by: bde Thanks. Bruce ___ 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: r328013 - head/sbin/fsck_ffs
On 9 March 2018 at 18:36, David Bright wrote: > On Mar 9, 2018, at 17:31, Ian Lepore wrote: >> >> On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: >>> >>> etc/rc.d/fsck doesn't know how to interpret the new exit code and now >>> just drops to a single-user shell when it is encountered. […] >>> >>> Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > > This is, in fact, the reason that I made the change I did. I was trying to > put in a retry loop to rc.d/fsck, but found that I couldn’t get it to work > because fsck and fsck_ffs were not exiting with non-zero status. The drop to > single user is not really due to the specific (new) error code of 16, it is > due to the fact that fsck_ffs is now exiting with a non-zero status when it > hasn’t completely cleaned the file system; /any/ non-zero status would cause > the current rc.d/fsck script to go to single user. Prior to my change, > fsck_ffs was exiting with a zero status even though it had not completely > cleaned the filesystem and told the user to run it again. > >> >> fsck_ffs already has a -R flag to automatically retry, wouldn't that be >> a better mechanism for handling this new type of retry? > > That’s true; however, there is currently no way to pass that flag through the > filesystem-agnostic fsck wrapper called from rc.d/fsck to the > filesystem-specific fsck_ffs program that it calls. One could implement a > similar flag on the fsck wrapper to be passed along to the > filesystem-specific checker, but I think fsck_ffs is the only one that > currently implements such a flag. Why does it need to be filesystem specific? Can't the retry happen in the wrapper itself? -- Eitan Adler ___ 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"
