svn commit: r368056 - in head: .github/workflows tools/build
Author: uqs Date: Thu Nov 26 14:42:16 2020 New Revision: 368056 URL: https://svnweb.freebsd.org/changeset/base/368056 Log: GH Actions: Use pre-installed clang packages Also fix the run by setting up the environment in non-deprecated way. Always run with --debug to understand better what sort of stuff is happening in the background. Also split out the bmake bootstrap stage (takes about 31s on ubuntu, but 1m14 on macOS?) Drops the dependency on coreutils (realpath, nproc) and thus (?) fixes macOS to be just as fast (4 logical cores vs 2 physical cores before, go figure.) Reviewed by: arichardson Modified: head/.github/workflows/cross-bootstrap-tools.yml head/tools/build/make.py Modified: head/.github/workflows/cross-bootstrap-tools.yml == --- head/.github/workflows/cross-bootstrap-tools.ymlThu Nov 26 13:31:57 2020(r368055) +++ head/.github/workflows/cross-bootstrap-tools.ymlThu Nov 26 14:42:16 2020(r368056) @@ -1,4 +1,4 @@ -name: Cross-build CI +name: Cross-build Kernel on: push: @@ -8,28 +8,51 @@ on: jobs: build: -name: ${{ matrix.os }} +name: ${{ matrix.os }} (${{ matrix.compiler }}) runs-on: ${{ matrix.os }} strategy: + fail-fast: false matrix: -os: [ubuntu-18.04, ubuntu-20.04, macOS-latest] +include: + # TODO: both Ubuntu and macOS have bmake packages, we should try them instead of bootstrapping our own copy. + - os: ubuntu-20.04 +compiler: clang-9 +cross-bindir: /usr/lib/llvm-9/bin +pkgs: bmake libarchive-dev + - os: ubuntu-20.04 +compiler: clang-10 +cross-bindir: /usr/lib/llvm-10/bin +pkgs: bmake libarchive-dev + - os: macOS-latest +compiler: clang-11 +#cross-bindir: /usr/local/Cellar/llvm/11.0.0/bin # script figures this out automatically +pkgs: bmake libarchive llvm@11 steps: - uses: actions/checkout@v2 - - name: install LLVM+libarchive (Ubuntu) + - name: install packages (Ubuntu) +if: runner.os == 'Linux' run: | - wget -O /tmp/llvm.sh https://apt.llvm.org/llvm.sh - chmod +x /tmp/llvm.sh - sudo /tmp/llvm.sh 11 - sudo apt install -y libarchive-dev - echo "::set-env name=EXTRA_MAKE_ARGS::--cross-bindir=/usr/lib/llvm-11/bin" -if: ${{ startsWith(matrix.os, 'ubuntu') }} - - name: install LLVM+libarchive (macOS) -run: brew install llvm coreutils libarchive xz -if: ${{ startsWith(matrix.os, 'macOS') }} - - name: create build dir -run: rm -rf ../build && mkdir -p ../build + sudo apt-get update --quiet || true + sudo apt-get -yq --no-install-suggests --no-install-recommends install ${{ matrix.pkgs }} + - name: install packages (macOS) +if: runner.os == 'macOS' +run: | + brew update --quiet || true + brew install ${{ matrix.pkgs }} + - name: create environment +run: | + echo "GITHUB_WORKSPACE = $GITHUB_WORKSPACE" + if [ -n "${{ matrix.cross-bindir }}" ]; then +echo "EXTRA_BUILD_ARGS=--cross-bindir=${{ matrix.cross-bindir }}" >> $GITHUB_ENV + fi + mkdir -p ../build + echo "MAKEOBJDIRPREFIX=${PWD%/*}/build" >> $GITHUB_ENV + # heh, works on Linux/BSD/macOS ... + echo "NPROC=`getconf _NPROCESSORS_ONLN 2>/dev/null || getconf NPROCESSORS_ONLN 2>/dev/null || echo 1`" >> $GITHUB_ENV + - name: bootstrap bmake +run: ./tools/build/make.py --debug $EXTRA_BUILD_ARGS TARGET=amd64 TARGET_ARCH=amd64 -n - name: make kernel-toolchain -run: env MAKEOBJDIRPREFIX=`realpath ../build` ./tools/build/make.py $EXTRA_MAKE_ARGS TARGET=amd64 TARGET_ARCH=amd64 kernel-toolchain -s -j$(nproc) +run: ./tools/build/make.py --debug $EXTRA_BUILD_ARGS TARGET=amd64 TARGET_ARCH=amd64 kernel-toolchain -s -j$NPROC - name: make buildkernel -run: env MAKEOBJDIRPREFIX=`realpath ../build` ./tools/build/make.py $EXTRA_MAKE_ARGS TARGET=amd64 TARGET_ARCH=amd64 KERNCONF=GENERIC NO_MODULES=yes buildkernel -s -j$(nproc) +run: ./tools/build/make.py --debug $EXTRA_BUILD_ARGS TARGET=amd64 TARGET_ARCH=amd64 KERNCONF=GENERIC NO_MODULES=yes buildkernel -s -j$NPROC $EXTRA_MAKE_ARGS Modified: head/tools/build/make.py == --- head/tools/build/make.pyThu Nov 26 13:31:57 2020(r368055) +++ head/tools/build/make.pyThu Nov 26 14:42:16 2020(r368056) @@ -115,6 +115,9 @@ def check_required_make_env_var(varname, binary_name, " does not exist") new_env_vars[varname] = guess debug("Inferred", varname, "as", guess) +global parsed_args +if parsed_args.debug: +
Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail
On Apr 26, 2016 11:44 AM, "Conrad Meyer"wrote: > > Right. False positive. Coverity doesn't grok sbuf memory management fully. > If someone can explain it to me in very simple words, I can update the model to make these go away ... maybe. ___ 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: r298585 - in head: sys/kern usr.sbin/jail
2016-04-25 10:06 GMT-07:00 Jamie Gritton: > Author: jamie > Date: Mon Apr 25 17:06:50 2016 > New Revision: 298585 > URL: https://svnweb.freebsd.org/changeset/base/298585 > > Log: > Encapsulate SYSV IPC objects in jails. Define per-module parameters > sysvmsg, sysvsem, and sysvshm, with the following bahavior: > > inherit: allow full access to the IPC primitives. This is the same as > the current setup with allow.sysvipc is on. Jails and the base system > can see (and moduly) each other's objects, which is generally considered > a bad thing (though may be useful in some circumstances). > > disable: all no access, same as the current setup with allow.sysvipc off. > > new: A jail may see use the IPC objects that it has created. It also > gets its own IPC key namespace, so different jails may have their own > objects using the same key value. The parent jail (or base system) can > see the jail's IPC objects, but not its keys. > > PR: 48471 > Submitted by: based on work by kikucha...@gmail.com > MFC after:5 days > > Modified: > head/sys/kern/sysv_msg.c > head/sys/kern/sysv_sem.c > head/sys/kern/sysv_shm.c > head/usr.sbin/jail/jail.8 Looks like some bad sbuf_deletes, see the recent Coverity report (are you folks getting these emails?) *** CID 1354974: Memory - corruptions (BAD_FREE) /sys/kern/sysv_shm.c: 1043 in sysctl_shmsegs() 1037shmseg->u.shm_perm.key = IPC_PRIVATE; 1038} 1039 1040sbuf_bcat(, shmseg, sizeof(*shmseg)); 1041} 1042error = sbuf_finish(); >>> CID 1354974: Memory - corruptions (BAD_FREE) >>> "sbuf_delete" frees address of "sb". 1043sbuf_delete(); 1044 1045 done: 1046SYSVSHM_UNLOCK(); 1047return (error); 1048 } ** CID 1354975: Memory - corruptions (BAD_FREE) and one in sysv_msg.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"
Re: svn commit: r276071 - in head/contrib/ntp: ntpd util
On Mon, 2014-12-22 at 18:54:56 +, Xin LI wrote: Author: delphij Date: Mon Dec 22 18:54:55 2014 New Revision: 276071 URL: https://svnweb.freebsd.org/changeset/base/276071 Log: Fix multiple ntp vulnerabilities. Reviewed by:roberto (earlier revision), philip Security: CVE-2014-9293, CVE-2014-9294 Security: CVE-2014-9295, CVE-2014-9296 Security: FreeBSD-SA-14:31.ntp Differential Revision: https://reviews.freebsd.org/D1343 Hi the latest Coverity run (which should include these patches, I think) still flags two DEADCODEs in ntp_proto.c: *** CID 1260388: Logically dead code (DEADCODE) /contrib/ntp/ntpd/ntp_proto.c: 702 in receive() 696 if (!(rbufp-dstadr-flags INT_MCASTOPEN)) { 697 if (AUTH(restrict_mask RES_DONTTRUST, 698is_authentic)) 699 fast_xmit(rbufp, MODE_SERVER, skeyid, 700 restrict_mask); 701 else if (is_authentic == AUTH_ERROR) CID 1260388: Logically dead code (DEADCODE) Execution cannot reach this statement fast_xmit(rbufp, 4, 0U, res 702 fast_xmit(rbufp, MODE_SERVER, 0, 703 restrict_mask); 704 return; /* hooray */ 705 } 706 707 /* /contrib/ntp/ntpd/ntp_proto.c: 869 in receive() 863 * symmetric active response is sent. If authentication 864 * fails, send a crypto-NAK packet. 865 */ 866 if (!AUTH(restrict_mask RES_DONTTRUST, is_authentic)) 867 { 868 if (is_authentic == AUTH_ERROR) CID 1260388: Logically dead code (DEADCODE) Execution cannot reach this statement fast_xmit(rbufp, 1, 0U, res 869 fast_xmit(rbufp, MODE_ACTIVE, 0, 870 restrict_mask); 871 return; /* bad auth */ 872 } 873 if (!AUTH(sys_authenticate | (restrict_mask 874 RES_NOPEER), is_authentic)) { ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254138 - in head: share/man/man9 sys/amd64/amd64 sys/arm/arm sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/dev/agp sys/dev/drm2/i915 sys/dev/drm2/ttm sys/dev/md sys/fs/fuse sys/f
On Fri, 2013-08-09 at 11:11:12 +, Attilio Rao wrote: Author: attilio Date: Fri Aug 9 11:11:11 2013 New Revision: 254138 URL: http://svnweb.freebsd.org/changeset/base/254138 Log: The soft and hard busy mechanism rely on the vm object lock to work. Unify the 2 concept into a real, minimal, sxlock where the shared acquisition represent the soft busy and the exclusive acquisition represent the hard busy. The old VPO_WANTED mechanism becames the hard-path for this new lock and it becomes per-page rather than per-object. The vm_object lock becames an interlock for this functionality: it can be held in both read or write mode. However, if the vm_object lock is held in read mode while acquiring or releasing the busy state, the thread owner cannot make any assumption on the busy state unless it is also busying it. Also: - Add a new flag to directly shared busy pages while vm_page_alloc and vm_page_grab are being executed. This will be very helpful once these functions happen under a read object lock. - Move the swapping sleep into its own per-object flag The KPI is heavilly changed this is why the version is bumped. It is very likely that some VM ports users will need to change their own code. Sponsored by: EMC / Isilon storage division Discussed with: alc Reviewed by:jeff, kib Tested by: gavin, bapt (older version) Tested by: pho, scottl The changes to sys/vm/vm_fault.c introduce a call to vm_page_sleep_if_busy() where the return code is not checked. The other 5 places in the tree check the return code, please fix this here too. It's CID 1062398, and I would encourage folks to get an account with scan.coverity.com and have an eye on newly found defects. Thanks! Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254138 - in head: share/man/man9 sys/amd64/amd64 sys/arm/arm sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/dev/agp sys/dev/drm2/i915 sys/dev/drm2/ttm sys/dev/md sys/fs/fuse sys/f
2013/8/13 Attilio Rao atti...@freebsd.org: On Tue, Aug 13, 2013 at 4:22 PM, Ulrich Spörlein u...@freebsd.org wrote: On Fri, 2013-08-09 at 11:11:12 +, Attilio Rao wrote: Author: attilio Date: Fri Aug 9 11:11:11 2013 New Revision: 254138 URL: http://svnweb.freebsd.org/changeset/base/254138 Log: The soft and hard busy mechanism rely on the vm object lock to work. Unify the 2 concept into a real, minimal, sxlock where the shared acquisition represent the soft busy and the exclusive acquisition represent the hard busy. The old VPO_WANTED mechanism becames the hard-path for this new lock and it becomes per-page rather than per-object. The vm_object lock becames an interlock for this functionality: it can be held in both read or write mode. However, if the vm_object lock is held in read mode while acquiring or releasing the busy state, the thread owner cannot make any assumption on the busy state unless it is also busying it. Also: - Add a new flag to directly shared busy pages while vm_page_alloc and vm_page_grab are being executed. This will be very helpful once these functions happen under a read object lock. - Move the swapping sleep into its own per-object flag The KPI is heavilly changed this is why the version is bumped. It is very likely that some VM ports users will need to change their own code. Sponsored by: EMC / Isilon storage division Discussed with: alc Reviewed by:jeff, kib Tested by: gavin, bapt (older version) Tested by: pho, scottl The changes to sys/vm/vm_fault.c introduce a call to vm_page_sleep_if_busy() where the return code is not checked. The other 5 places in the tree check the return code, please fix this here too. It's CID 1062398, and I would encourage folks to get an account with scan.coverity.com and have an eye on newly found defects. Not true. The same call existed also before with exactly the same semantic. The trick there is that it is not important to check for the return value because we are going to retry the operation anyway. The code looks ok to me. Thanks for the explanation. The code shuffling meant that Coverity saw it as new code, that's what prompted me to email you. Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253680 - in head: lib/libfetch usr.bin/fetch
On Fri, 2013-07-26 at 15:53:43 +, Dag-Erling SmÞrgrav wrote: Modified: head/lib/libfetch/common.c == --- head/lib/libfetch/common.cFri Jul 26 14:43:38 2013 (r253679) +++ head/lib/libfetch/common.cFri Jul 26 15:53:43 2013 (r253680) +static struct addrinfo * +fetch_ssl_get_numeric_addrinfo(const char *hostname, size_t len) +{ + struct addrinfo hints, *res; + char *host; + + host = (char *)malloc(len + 1); + memcpy(host, hostname, len); + host[len] = '\0'; + memset(hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_protocol = 0; + hints.ai_flags = AI_NUMERICHOST; + /* port is not relevant for this purpose */ + getaddrinfo(host, 443, hints, res); We check the return value for getaddrinfo() 210 out of 217 times in our tree, please check it here too. Thanks! CID 1061016 +static int +fetch_ssl_setup_peer_verification(SSL_CTX *ctx, int verbose) +{ + X509_LOOKUP *crl_lookup; + X509_STORE *crl_store; + const char *ca_cert_file, *ca_cert_path, *crl_file; + + if (getenv(SSL_NO_VERIFY_PEER) == NULL) { + ca_cert_file = getenv(SSL_CA_CERT_FILE) != NULL ? + getenv(SSL_CA_CERT_FILE) : /etc/ssl/cert.pem; + ca_cert_path = getenv(SSL_CA_CERT_PATH); + if (verbose) { + fetch_info(Peer verification enabled); + if (ca_cert_file != NULL) + fetch_info(Using CA cert file: %s, + ca_cert_file); + if (ca_cert_path != NULL) + fetch_info(Using CA cert path: %s, + ca_cert_path); + } + SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, + fetch_ssl_cb_verify_crt); The return value is unchecked here. Coverity claims we check it 4 out of 5 times in our tree, please fix this one too. CID 1061015 Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253719 - in head: sys/conf sys/dev/watchdog sys/libkern sys/sys usr.sbin/watchdogd
On Sat, 2013-07-27 at 20:47:02 +, Alfred Perlstein wrote: Author: alfred Date: Sat Jul 27 20:47:01 2013 New Revision: 253719 URL: http://svnweb.freebsd.org/changeset/base/253719 Log: Fix watchdog pretimeout. Alfred, this broken the build and hasn't been fixed for almost three days now. What's up with that? How was this change tested before commit? === usr.sbin/watchdogd (all) cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /data/src/freebsd-head/usr.sbin/watchdogd/watchdogd.c /data/src/freebsd-head/usr.sbin/watchdogd/watchdogd.c:777:18: error: comparison of integers of different signs: 'u_int' (aka 'unsigned int') and 'time_t' (aka 'int') [-Werror,-Wsign-compare] if (pretimeout = ts.tv_sec) { ~~ ^ ~ 1 error generated. *** Error code 1 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253210 - in head/sys: conf netinet
Hey Andre, I don't see why this commit triggers it, but Coverity Scan found a new resource leak in this file. syncache_expand() will leak *s when line 1071 is reached. The failed: case below correctly frees the resources. 1068/* how do we find the inp for the new socket? */ 22. Condition sc != scs, taking true branch 1069if (sc != scs) 1070syncache_free(sc); CID null (#1 of 1): Resource leak (RESOURCE_LEAK) 23. leaked_storage: Variable s going out of scope leaks the storage it points to. 1071return (1); 1072failed: 1073if (sc != NULL sc != scs) 1074syncache_free(sc); 1075if (s != NULL) 1076free(s, M_TCPLOG); 1077*lsop = NULL; 1078return (0); 1079} This has no CID yet ... Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253322 - in head/sys/cam: . scsi
On Sat, 2013-07-13 at 13:35:10 +, Alexander Motin wrote: Author: mav Date: Sat Jul 13 13:35:09 2013 New Revision: 253322 URL: http://svnweb.freebsd.org/changeset/base/253322 Log: Improve handling of 0x3F/0x0E Reported LUNs data has changed and 0x25/0x00 Logical unit not supported errors. First initiates specific target rescan, second -- destroys specific LUN. That allows to automatically detect changes in list of device LUNs. This mechanism doesn't work when target is completely idle, but probably that is all what can be done without active polling. Reviewed by:ken Sponsored by: iXsystems, Inc. Modified: head/sys/cam/cam_periph.c head/sys/cam/scsi/scsi_all.c head/sys/cam/scsi/scsi_all.h Modified: head/sys/cam/cam_periph.c == @@ -1761,12 +1759,25 @@ cam_periph_error(union ccb *ccb, cam_fla xpt_async(AC_LOST_DEVICE, newpath, NULL); xpt_free_path(newpath); } + } /* Broadcast UNIT ATTENTIONs to all periphs. */ - } else if (scsi_extract_sense_ccb(ccb, - error_code, sense_key, asc, ascq) - sense_key == SSD_KEY_UNIT_ATTENTION) { + if ((action SSQ_UA) != 0) xpt_async(AC_UNIT_ATTENTION, orig_ccb-ccb_h.path, orig_ccb); + + /* Rescan target on Reported LUNs data has changed */ + if ((action SSQ_RESCAN) != 0) { + if (xpt_create_path(newpath, NULL, + xpt_path_path_id(ccb-ccb_h.path), + xpt_path_target_id(ccb-ccb_h.path), + -1) == CAM_REQ_CMP) { + + scan_ccb = xpt_alloc_ccb_nowait(); + scan_ccb-ccb_h.path = newpath; + scan_ccb-ccb_h.func_CODe = XPT_SCAN_BUS; + scan_ccb-crcn.flags = 0; + xpt_rescan(scan_ccb); + } } /* Attempt a retry */ This introduces a possible NULL dereference. xpt_alloc_ccb_nowait() may return NULL. Coverity reports that this is checked for NULL returns 31 out of 36 times. Please grep over the tree and fix this plus the other 4 locations where this is not being null-checked. Thanks! This has no CID yet (they run a background check that merges and assigns CIDs, and this is a fresh run ...) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253274 - head/sys/cam/scsi
On Fri, 2013-07-12 at 17:09:50 +, Kenneth D. Merry wrote: Author: ken Date: Fri Jul 12 17:09:50 2013 New Revision: 253274 URL: http://svnweb.freebsd.org/changeset/base/253274 Log: Fix a problem with READ ELEMENT STATUS that occurs on some changers that don't support the DVCID and CURDATA bits that were introduced in the SMC spec. These changers will return an Illegal Request type error if the bits are set. This causes chio status to fail. The fix is two-fold. First, for changers that claim to be SCSI-2 or older, don't set the DVCID and CURDATA bits for READ ELEMENT STATUS. For newer changers (SCSI-3 and newer), we default to setting the new bits, but back off and try the READ ELEMENT STATUS without the bits if we get an Illegal Request type error. This has been tested on a Qualstar TLS-8211, which is a SCSI-2 changer that does not support the new bits, and a Spectra T-380, which is a SCSI-3 changer that does support the new bits. In the absence of a SCSI-3 changer that does not support the bits, I tested that with some error injection code. (The SMC spec says that support for CURDATA is mandatory, and DVCID is optional.) scsi_ch.c: Add a new quirk, CH_Q_NO_DVCID that gets set for SCSI-2 and older libraries, or newer libraries that report errors when the DVCID/CURDATA bits are set. In chgetelemstatus(), use the new quirk to determine whether or not to set DVCID and CURDATA. If we get an error with the bits set, back off and try without the bits. Set the quirk flag if the read element status succeeds without the bits set. Increase the READ ELEMENT STATUS timeout to 60 seconds after testing with a Spectra T-380. The previous value was 10 seconds, and too short for the T-380. This may be decreased later after some additional testing and investigation. Tested by: Andre Albsmeier andre.albsme...@siemens.com Sponsored by: Spectra Logic MFC after: 3 days Modified: head/sys/cam/scsi/scsi_ch.c Modified: head/sys/cam/scsi/scsi_ch.c == --- head/sys/cam/scsi/scsi_ch.c Fri Jul 12 16:41:58 2013 (r253273) +++ head/sys/cam/scsi/scsi_ch.c Fri Jul 12 17:09:50 2013 (r253274) @@ -1284,8 +1342,8 @@ chgetelemstatus(struct cam_periph *perip /* voltag */ want_voltags, /* sea */ softc-sc_firsts[chet] + cesr-cesr_element_base, - /* dvcid */ 1, - /* curdata */ 1, + /* dvcid */ dvcid, + /* curdata */ curdata, /* count */ cesr-cesr_element_count, /* data_ptr */ data, /* dxfer_len */ size, Are you sure? Coverity flags this as being in the wrong argument order (there's no CID for this yet). CID null (#2 of 2): Arguments in wrong order (SWAPPED_ARGUMENTS) swapped_arguments: The positions of arguments curdata and dvcid are inconsistent with the positions of the corresponding parameters for scsi_read_element_status(struct ccb_scsiio *, u_int32_t, void (*)(struct cam_periph *, union ccb *), u_int8_t, int, u_int32_t, int, int, u_int32_t, u_int8_t *, u_int32_t, u_int8_t, u_int32_t). [show details] 1338scsi_read_element_status(ccb-csio, 1339 /* retries */ 1, 1340 /* cbfcnp */ chdone, 1341 /* tag_action */ MSG_SIMPLE_Q_TAG, 1342 /* voltag */ want_voltags, 1343 /* sea */ softc-sc_firsts[chet] 1344 + cesr-cesr_element_base, 1345 /* dvcid */ dvcid, 1346 /* curdata */ curdata, 1347 /* count */ cesr-cesr_element_count, 1348 /* data_ptr */ data, 1349 /* dxfer_len */ size, 1350 /* sense_len */ SSD_FULL_SIZE, 1351 /* timeout */ CH_TIMEOUT_READ_ELEMENT_STATUS); And this is the definition: 1860void 1861scsi_read_element_status(struct ccb_scsiio *csio, u_int32_t retries, 1862 void (*cbfcnp)(struct cam_periph *, union ccb *), 1863 u_int8_t tag_action, int voltag, u_int32_t sea, 1864 int curdata, int dvcid, 1865 u_int32_t count, u_int8_t *data_ptr, 1866 u_int32_t dxfer_len, u_int8_t sense_len, 1867
Re: svn commit: r253274 - head/sys/cam/scsi
2013/7/15 Kenneth D. Merry k...@freebsd.org: Oops, you're right! Thanks for pointing it out! I just committed a fix. How does Coverity detect something like that? Using the comment, or the variable name? I would guess the variable name, maybe with a fuzzy match. At least that's how I would do it, I don't know the internal workings of their software and I'm sure they won't tell anyone :) Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252408 - head/sbin/ifconfig
On Sun, 2013-06-30 at 07:37:32 +, Hiroki Sato wrote: Author: hrs Date: Sun Jun 30 07:37:31 2013 New Revision: 252408 URL: http://svnweb.freebsd.org/changeset/base/252408 Log: Do not display a warning message in a jail without AF_INET6 support. MFC after: 3 days Modified: head/sbin/ifconfig/af_nd6.c Modified: head/sbin/ifconfig/af_nd6.c == --- head/sbin/ifconfig/af_nd6.c Sun Jun 30 06:44:31 2013 (r252407) +++ head/sbin/ifconfig/af_nd6.c Sun Jun 30 07:37:31 2013 (r252408) @@ -148,7 +148,7 @@ nd6_status(int s) memset(nd, 0, sizeof(nd)); strncpy(nd.ifname, ifr.ifr_name, sizeof(nd.ifname)); if ((s6 = socket(AF_INET6, SOCK_DGRAM, 0)) 0) { - if (errno != EAFNOSUPPORT) + if (errno != EAFNOSUPPORT error != EPROTONOSUPPORT) warn(socket(AF_INET6, SOCK_DGRAM)); return; } This gives undefined behavior, error is uninitialized at this point. Found by: Coverity Scan, CID 1042128 Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252356 - in head: contrib/smbfs/mount_smbfs etc/defaults etc/mtree include lib lib/libprocstat rescue/rescue sbin/mount share/examples share/examples/etc share/mk sys/conf sys/kern sy
On Fri, 2013-06-28 at 21:00:08 +, Davide Italiano wrote: Author: davide Date: Fri Jun 28 21:00:08 2013 New Revision: 252356 URL: http://svnweb.freebsd.org/changeset/base/252356 Log: - Trim an unused and bogus Makefile for mount_smbfs. - Reconnect with some minor modifications, in particular now selsocket() internals are adapted to use sbintime units after recent'ish calloutng switch. yay, for reconnecting this to the build. Now Coverity Scan is seeing this code and there are dozens of double frees in the form: smb_rq_done(rqp); free(rqp, M_SMBFSDATA); But smb_rq_done() is already calling free(rqp). This seems easy to audit and fix. (sometimes the order is swapped, so it's a USE_AFTER_FREE instead) This is CIDs 1042109 -- 1042126, all in smbfs_smb.c. Thanks for looking into this Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r247960 - head/cddl/contrib/opensolaris/tools/ctf/cvt
On Thu, 2013-03-07 at 20:45:20 -0500, Eitan Adler wrote: On 7 March 2013 18:00, Dimitry Andric d...@freebsd.org wrote: On 2013-03-07 23:29, Andriy Gapon wrote: ... I was not really kidding when I said that this change, as is, is a nop: ... + bname = strrchr(match.iim_name, '/'); + bname = bname == NULL ? match.iim_name : bname + 1; It would probably make sense to make use of bname after going to through all the trouble of calculating it: match.iim_file = match.iim_name; Should be match.iim_file = bname ? Yes, I actually had this in my test code, and committed the wrong diff by accident. :( Fixed in r247962, in any case. Surprised that clang hasn't warned you about this one :-) Clang currently does not have the -Wunused-but-set-variable warning; it is apparently available in the static analyzer. On the other hand, that warning is one of the most annoying ones that newer gcc's have. :-) I have found real bugs in FreeBSD's code base as a result of this warning, but the vast majority were more annoying than useful. That's why I've disabled them on http://scan.freebsd.your.org/freebsd-head/ :) Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r246362 - head/games/fortune/datfiles
On Wed, 2013-02-06 at 08:42:01 +0100, Joel Dahl wrote: On 06-02-2013 11:18, Gleb Smirnoff wrote: On Tue, Feb 05, 2013 at 04:17:25PM -0500, John Baldwin wrote: J On Tuesday, February 05, 2013 3:55:47 pm Gleb Smirnoff wrote: J On Tue, Feb 05, 2013 at 11:58:54AM -0500, John Baldwin wrote: J J On Tuesday, February 05, 2013 9:39:38 am Dag-Erling SmXXrgrav wrote: J JAuthor: des J JDate: Tue Feb 5 14:39:37 2013 J JNew Revision: 246362 J JURL: http://svnweb.freebsd.org/changeset/base/246362 J J J JLog: J J Remove political propaganda J J J JModified: J J head/games/fortune/datfiles/fortunes-o.real J J J J *sigh* J J J J I'm sure there are other quotes that people who do not share your political J J persuasion might find propaganda or offensive, etc. Censorship and freedom J J of speech is quite a sticky widget, and I think the only truly sane policy J J is that fortune files are append-only (unless we outright remove them and J J that seems excessive). And new things should have a very high bar to be J J added to fortune. Perhaps we should move fortunes-o to ports entirely? J J J J J J I am more concerned about the insta-MFC than the removal per se. J J Only security or legal issues are cause to go under 3 days, was my J J impression. J J J J Yes, the insta-MFC is also not appropriate, esp. for something that you know J J is going to raise eyebrows when it is committed. Having to debate this sort J J of thing in public on mailing lists is also distinctly unhelpful and very J J distracting from productive work. Also, I'd like to preemptively ask J J developers to refrain from any further commits to the fortunes datfiles for J J the time being as the last thing we need is a commit war over this sort of J J thing. J J What about just moving the entire games subdirectory to ports repo? J J We've already moved most of it many years ago. The yesterday bikeshed proves that most isn't enough. :( The entire games subdir needs to be moved. +1 This is a worthless discussion that seems to pop up from time to time. Move it to ports. No. There are people that use morse(6) in production code and stuff like random(6) can also be very useful. This is *BSD legacy and if it was for me, the whole games stuff would be brought *back* into the tree from ports. So can we move on to something else now and let this one die? kthxbai Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r245700 - head/usr.sbin/bsdinstall/partedit
On Sun, 2013-01-20 at 22:25:59 +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Sun Jan 20 22:25:58 2013 New Revision: 245700 URL: http://svnweb.freebsd.org/changeset/base/245700 Log: Add a simple scripted partitioner. Documentation and more scripting support will come soon. This lets the install process have a line like: bsdinstall scriptedpart 'ada0 GPT {1.5G freebsd-ufs /, 10G freebsd-swap, auto freebsd-ufs /usr}' to set up a system with a 1.5GB /, some swap space, and a /usr using the rest of ada0. What will be the alignment/offset for these? (and also for the fully automated case?) We should make sure the first partition starts at 1MB all the time, unless the user points the gun at his feet ... Thanks Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r242767 - in head/tools/regression/bin/sh: builtins parser
On Thu, 2012-11-08 at 13:36:19 +, Jilles Tjoelker wrote: Author: jilles Date: Thu Nov 8 13:36:19 2012 New Revision: 242767 URL: http://svnweb.freebsd.org/changeset/base/242767 Log: sh: Add tests for modifying an alias (r242766). Note: parser/alias10.0 will eat a lot of memory/cpu time when it fails (with the old sh). Can't you run it with reduced ulimits to have it fail fast? Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r243130 - head/etc/root
On Fri, 2012-11-16 at 04:25:35 +, Eitan Adler wrote: Author: eadler Date: Fri Nov 16 04:25:35 2012 New Revision: 243130 URL: http://svnweb.freebsd.org/changeset/base/243130 Log: dot.login is supposed to be for bourne shell, not csh Pointyhat to: me Approved by: cperciva (implicit) Modified: head/etc/root/dot.login Modified: head/etc/root/dot.login == --- head/etc/root/dot.login Fri Nov 16 03:33:34 2012(r243129) +++ head/etc/root/dot.login Fri Nov 16 04:25:35 2012(r243130) @@ -6,4 +6,4 @@ # # Uncomment to display a random cookie each login: -# if ( -x /usr/games/fortune ) /usr/games/fortune -s +# [ -x /usr/games/fortune ] /usr/games/fortune -s Please add || true to that line, so that when it is enabled and /usr/games/fortune doesn't exist or is not executable, the shell startup doesn't return with $? set to something non-zero. This is especially annoying if you have $? somewhere in your prompt. Thanks Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241916 - in head/sys: netinet netinet6
On Tue, 2012-10-23 at 20:43:33 +0200, Michael Tuexen wrote: On Oct 23, 2012, at 8:28 PM, Bruce Evans wrote: On Tue, 23 Oct 2012, Michael Tuexen wrote: On Oct 23, 2012, at 6:23 AM, Bruce Evans wrote: On Mon, 22 Oct 2012, Xin LI wrote: Log: Remove __P. This was a chance to remove style bugs in the prototypes. At least it didn't create so many new ones, unlike the original __P axing. It still enlarged about a hundred by changing from Gnu style continuation to Gnu style continuation indentation with an off-by-5 error. please note that the SCTP code in the FreeBSD sources is generated via an export script from a codebase which runs on multiple platforms. The script tries to follow FreeBSDs guidelines, but is far from being perfect. The export script might not like manual editing of its output. Portability might require __P(()), and then removing it cleaning requires a complicated script. Maybe I wasn't clear... * The removal of __P() needs also be done upstream. I'll handle this, not problem. I don't think we need __P on any platform. * My comment was regarding your list of formatting issues of the code. Changing the formatting would require changing the export script. If someone just changes the FreeBSD sources and these changes are not included upstream, they are lost by the next commit of rrs@ or mine. My point was: Getting rid of __P is fine and we can handle that upstream (as any other non whitespace/formatting changes needed), but changing the formatting is NOT that easy. I'm sorry about that and just wanted to let you know that there is a reason why the style 9 stuff is not followed exactly within the SCTP code. I hope this makes the situation clearer. Maybe running it through uncrustify[1] as part of the export for FreeBSD could help here? hth Uli [1] http://uncrustify.sourceforge.net/ and textproc/uncrustify ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r232249 - head
On Tue, 2012-02-28 at 11:06:52 +, Sergey Kandaurov wrote: Author: pluknet Date: Tue Feb 28 11:06:52 2012 New Revision: 232249 URL: http://svn.freebsd.org/changeset/base/232249 Log: Add lib32 part after libarchive 3.0.3 update. Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.incTue Feb 28 08:36:38 2012(r232248) +++ head/ObsoleteFiles.incTue Feb 28 11:06:52 2012(r232249) @@ -56,6 +56,9 @@ OLD_FILES+=man/man3/archive_read_data_in man/man3/archive_write_set_compression_none.3.gz \ man/man3/archive_write_set_compression_program.3.gz OLD_LIBS+=usr/lib/libarchive.so.5 +.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == powerpc64 +OLD_LIBS+=usr/lib32/libarchive.so.5 +.endif # 20120113: removal of wtmpcvt(1) OLD_FILES+=usr/bin/wtmpcvt OLD_FILES+=usr/share/man/man1/wtmpcvt.1.gz Please don't add TARGET_ARCH checks unless they are really necessary. Here they aren't, they very rarely are. Thanks Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228953 - in head/tools: regression/pthread/mutex_isowned_np tools/ansify tools/genericize tools/hcomp tools/mtxstat tools/prstats tools/whereintheworld
I know :) Making my way through them one subdir at a time... Cheers Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228896 - head/contrib/netcat
On Mon, 2011-12-26 at 01:14:28 -0800, Doug Barton wrote: On 12/26/2011 01:07, Xin LI wrote: Author: delphij Date: Mon Dec 26 09:07:08 2011 New Revision: 228896 URL: http://svn.freebsd.org/changeset/base/228896 Log: Merge from OpenBSD 5.0 (this is a dummy change, the vendor change does not apply to us). When I'm importing stat(1) stuff from Net/OpenBSD I don't do this. I will however comment in the commit log for the next substantive change, Skipped update N.NN because the change was not relevant to us, or words to that effect. I'm not suggesting that my way of doing this is perfect, or cannot be improved. I would suggest however that this change was needless churn. I think it was the right thing to do. It's better to have one person (Xin LI) figure out if the change is needed or a no-op and do the upgrade to match our version to upstream's version, than to have a discrepancy between the two and cause half a dozen developers that stumble upon that difference to scratch their heads and spend time in figuring out if we should import the change. Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228909 - head/games/fortune/datfiles
On Tue, 2011-12-27 at 10:21:57 +, Doug Barton wrote: Author: dougb Date: Tue Dec 27 10:21:57 2011 New Revision: 228909 URL: http://svn.freebsd.org/changeset/base/228909 Log: 1. Remove a bunch of duplicates. Usually this means removing them from fortunes, but occasionally remove them from the other 2 files when they are not offensive, or not murphy'ish enough. Where the version in fortunes had better attribution and/or formatting, copy it over. 2. Fix a few typos 3. Use the full name of François De La Rochefoucauld, fix one of his quotes, and remove the duplicate of it. Sigh, except for a stupid Unicode version of an apostrophe (’ vs ') this file was ASCII. And I made it so for a reason. We don't currently have a way to iconv fortune(6)'s output to the users LC_CTYPE. ASCII is the common denominator so that's what we have to choose to be bug free. My plan was to teach fortune to use bsdiconv once that is ready and in the tree to convert from Unicode to the users' locale. But until that is ready, we have to stick to ASCII. This is not a backout request, merely an explanation for why things were the way they were. I wish we'd mandated UTF-8 as the one true encoding a looong time ago. If Plan9 could do it, why not us? Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228909 - head/games/fortune/datfiles
On Wed, 2011-12-28 at 09:59:13 -0800, Doug Barton wrote: On 12/28/2011 07:53, Ulrich Spörlein wrote: On Tue, 2011-12-27 at 10:21:57 +, Doug Barton wrote: Author: dougb Date: Tue Dec 27 10:21:57 2011 New Revision: 228909 URL: http://svn.freebsd.org/changeset/base/228909 Log: 1. Remove a bunch of duplicates. Usually this means removing them from fortunes, but occasionally remove them from the other 2 files when they are not offensive, or not murphy'ish enough. Where the version in fortunes had better attribution and/or formatting, copy it over. 2. Fix a few typos 3. Use the full name of François De La Rochefoucauld, fix one of his quotes, and remove the duplicate of it. Sigh, except for a stupid Unicode version of an apostrophe (’ vs ') That seems like an easy thing to fix? Sure, somebody must have snuk that in while I was not watching ;] However, the real solution would be some sort of pre-submit check or even breaking the build when the datfile is not 7bit clean. The state is that all datfiles were ASCII clean some time in the past, except for gerrold.limerick which has a unicode (C) in a comment, so it doesn't actually affect operation of fortune so I left it in. this file was ASCII. And I made it so for a reason. We don't currently have a way to iconv fortune(6)'s output to the users LC_CTYPE. ASCII is the common denominator so that's what we have to choose to be bug free. What breaks for non-ASCII text? If your terminal is ISO8859-1 (aka latin1) or an other non-UTF-8 groking terminal, you'll get garbage instead of François. Not a biggie but ugly anyhow. My plan was to teach fortune to use bsdiconv once that is ready and in the tree to convert from Unicode to the users' locale. But until that is ready, we have to stick to ASCII. I'm not opposed to doing that, but I want to make sure that a) it's for a good reason, and b) that we have some way to know what needs to be added back when it's safe. Meanwhile, I did actually test this change and it worked for me, so I thought it was safe to proceed. Your terminal understands UTF-8, so you don't see a difference between ASCII and Unicode chars. Try setting LANG to, e.g. en_US.ISO8859-1 and run xterm +u8 with it (just to make sure). Then, when displaying a quote you get: % fortune -m Rochefoucauld %% (fortunes) Absence diminishes mediocre passions and increases great ones, as the wind blows out candles and fans fires. -- François De La Rochefoucauld (I hope this makes it through the way I see it). It all boils down to that fact that fortune(6) is not locale aware and thus only ASCII chars are safe to display (no EBCDIC does not count). This is not a backout request, I've no objection to making a change. Apparently the De should be de anyway, so what do you suggest? I cannot speak to that with any authority. Uli PS: I'd love for us to drop supporting anything but Unicode, but then again I'd also would like to have a pony ... ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228896 - head/contrib/netcat
On Wed, 2011-12-28 at 15:11:33 -0600, Mark Linimon wrote: On Wed, Dec 28, 2011 at 04:40:49PM +0100, Ulrich Spörlein wrote: It's better to have one person (Xin LI) figure out if the change is needed or a no-op and do the upgrade to match our version to upstream's version, than to have a discrepancy between the two and cause half a dozen developers that stumble upon that difference to scratch their heads and spend time in figuring out if we should import the change. We already have the following wiki page: http://wiki.freebsd.org/PortsNotUpgraded Perhaps an analagous page for src would be helpful? mcl We have http://wiki.freebsd.org/ContribSoftware that tries to track the state of anything upstream in src. Maintainers are encouraged to add notes to their entries if there are reasons the software is kept at a lower version or whatever. See also the section for GPLv3'ed software on that page. Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228896 - head/contrib/netcat
On Wed, 2011-12-28 at 15:00:07 -0800, Doug Barton wrote: On 12/28/2011 14:52, Ulrich Spörlein wrote: We have http://wiki.freebsd.org/ContribSoftware that tries to track the state of anything upstream in src. I've been maintaining BIND in the base for 9 1/2 years, and never knew about that page ... the wiki is a good tool for some things, but IMO this kind of information needs to be in the src tree where it is easily available, archived for the future, etc. Agreed. It would make branching that information a whole lot easier! Any good ideas on how to implement this? It could be as simple as having all that information in /CONTRIB or something, similar to UPDATING or MAINTAINERS. Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r225951 - head
On Mon, 2011-10-03 at 20:46:36 +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Mon Oct 3 20:46:36 2011 New Revision: 225951 URL: http://svn.freebsd.org/changeset/base/225951 Log: Fix a number of platform problems in this file (mostly assuming that only amd64 has lib32). Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.incMon Oct 3 20:32:55 2011(r225950) +++ head/ObsoleteFiles.incMon Oct 3 20:46:36 2011(r225951) @@ -56,7 +56,7 @@ OLD_LIBS+=usr/lib/libdwarf.so.2 OLD_LIBS+=usr/lib/libopie.so.6 OLD_LIBS+=usr/lib/librtld_db.so.1 OLD_LIBS+=usr/lib/libtacplus.so.4 -.if ${TARGET_ARCH} == amd64 +.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == powerpc64 OLD_LIBS+=usr/lib32/libcam.so.5 OLD_LIBS+=usr/lib32/libpcap.so.7 OLD_LIBS+=usr/lib32/libufs.so.5 These conditionals should all be removed. 99% of them are not needed. The rm(1) should only be conditional on TARGET != arch1 iff arch1 is still using the file in question. It doesn't matter that arch2 never ever had that file. It's just one more rm(1) to a non-existing file. Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On Sat, 11.06.2011 at 13:55:15 -0700, Doug Barton wrote: On 6/11/2011 1:02 PM, Warner Losh wrote: On Jun 11, 2011, at 12:17 PM, Doug Barton wrote: On 6/11/2011 6:07 AM, Robert Watson wrote: To me, this seems like the wrong direction. Over the last decade, we've been trying to move away from conditional compilation of features to having them be loadable as modules. FWIW, I agree. I'm wondering though, is there still a performance penalty for modules? My understanding in the past was that there is, although for most use cases it's in the statistical noise. Is that still true? At run time, I believe that's true. At load time, lots of modules can take a few seconds longer. I have 3 or 4 modules loaded via loader.conf at boot time. They take at least 2 seconds each. IMO loading everything via loader.conf would slow the boot so much as to be a non-starter. OTOH, I could imagine an rc.d script that depends on mountcritlocal that could load a list of modules. Unless I'm missing something that would be several times faster. I suspect this is your BIOS' fault. I load 22 modules via loader.conf and the loader takes 2, at most 3, seconds to load them all (next to the kernel). This is true for all machines that I own/owned. As you can guess, I'm very much in favour of moving modules from GENERIC to loader.conf ... Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r222273 - in head: gnu/usr.bin gnu/usr.bin/grep tools/build/options usr.bin usr.bin/grep
On Wed, 25.05.2011 at 01:04:13 +, David E. O'Brien wrote: Author: obrien Date: Wed May 25 01:04:12 2011 New Revision: 73 URL: http://svn.freebsd.org/changeset/base/73 Log: Build and install a BSD licensed grep. If WITH_BSD_GREP is not set, it will be 'bsdgrep' and GNUgrep will be '[ef]grep'. Otherwise, BSD-grep will be the grep family, and GNUgrep will be 'gnugrep'. Discussed with: brooks Modified: head/gnu/usr.bin/Makefile head/gnu/usr.bin/grep/Makefile head/tools/build/options/WITH_BSD_GREP head/usr.bin/Makefile head/usr.bin/grep/Makefile Modified: head/gnu/usr.bin/Makefile == --- head/gnu/usr.bin/Makefile Wed May 25 00:34:25 2011(r72) +++ head/gnu/usr.bin/Makefile Wed May 25 01:04:12 2011(r73) @@ -27,9 +27,7 @@ _groff= groff .endif .endif -.if ${MK_BSD_GREP} != yes _grep= grep -.endif You should have done the same here as in usr.bin/Makefile, i.e. get rid of the ${_grep} variable completely. Just saying ... Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r222094 - head/share/misc
On Sun, 22.05.2011 at 20:16:47 +1000, Edwin Groothuis wrote: On 22/05/2011, at 7:29 PM, Ulrich Spörlein wrote: On Thu, 19.05.2011 at 13:09:39 +, Edwin Groothuis wrote: Author: edwin Date: Thu May 19 13:09:39 2011 New Revision: 222094 URL: http://svn.freebsd.org/changeset/base/222094 Log: Put AN back after finding out that tzsetup(1) will complain that it doesn't exist. It will be removed again once the tzdata distribution files have been updated with the replacements for AN. Wouldn't it be better to have tzsetup use iso3166.tab from the tzdata distribution, which is mostly guaranteed to be in sync with zone.tab? Which opens a different can of worms. Duplicate file, with semi-similar contents. Whenever there are changes in the distribution of the tzdata iso3166.tab equivalent file, I check if they are in the /usr/share/misc equivalent file. A warning to that file should be added that tzsetup uses it and that they always should check tzsetup functionality before commiting it. This seems way too brittle, as can be seen by random people going in and updating our iso3166 file. I'd rather take a tiny duplication of files than manual fixups needed to unbreak installing. AFAICS only tzsetup and sysinstall depend on /usr/share/misc/iso3166, if we change tzsetup to use the iso list from tzdata and since sysinstall is on the chopping block we could then simply remove our iso3166 list. And as for duplicated files, have you looked at regdomain.xml and ieee80211_regdomain.h? Just saying ... Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r222094 - head/share/misc
On Thu, 19.05.2011 at 13:09:39 +, Edwin Groothuis wrote: Author: edwin Date: Thu May 19 13:09:39 2011 New Revision: 222094 URL: http://svn.freebsd.org/changeset/base/222094 Log: Put AN back after finding out that tzsetup(1) will complain that it doesn't exist. It will be removed again once the tzdata distribution files have been updated with the replacements for AN. Wouldn't it be better to have tzsetup use iso3166.tab from the tzdata distribution, which is mostly guaranteed to be in sync with zone.tab? Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r221348 - head/sys/boot/i386/boot2
On Tue, 03.05.2011 at 18:51:19 +0200, Roman Divacky wrote: On Tue, May 03, 2011 at 04:27:57AM -0500, Brooks Davis wrote: On Tue, May 03, 2011 at 03:39:27PM +0200, Roman Divacky wrote: With the recent libobjc removal this means that we can compile all (no exceptions) of FreeBSD/{i386,amd64} with clang. Quite a milestone in my opinion :) Great news! Thanks for all the work to make this happen! Has boot2 been submitted to LLVM as a clang regression test? No, but we are setting up a testing environment to track the code size changes in boot2. Pawel, can you comment on this? Bonus points for doing this retro-actively. That is, use the current clang we have in the tree and track the size changes to boot2 over the years. Just for the lulz ... Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219084 - in head: bin/test tools/regression/bin/test
On Sun, 27.02.2011 at 12:28:06 +, Xin LI wrote: Author: delphij Date: Sun Feb 27 12:28:06 2011 New Revision: 219084 URL: http://svn.freebsd.org/changeset/base/219084 Log: Accept == as an alias of = which is a popular GNU extension. This is intentionally undocumented for now since it's not part of any standard. MFC after: 1 month So we are giving up the fight? Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r218421 - head/usr.bin/gzip
On Sun, 13.02.2011 at 18:05:46 -0500, Glen Barber wrote: On 2/13/11 5:58 PM, Glen Barber wrote: Hi, On 2/13/11 5:27 PM, Ulrich Spörlein wrote: Log: Update manpage to remove CRT reference. Would you mind tackling these as well? share/man/man4/acpi_panasonic.4 Hmm.. acpi_panasonic(4) appears to have a mode which differentiates between LCD and CRT modes. Do you think this manual should be left as-is? I think this is bogus. Sure, the internal display is of type LCD, but what the manpage really tries to say is, that the button switches between the laptop display (can you call that internal?) and the external VGA port. Not sure how to best phrase this. LCD brightness should be replaced with display brightness, although it only pertains to the internal display, not any externally attached ones ...) Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r218421 - head/usr.bin/gzip
On Mon, 07.02.2011 at 22:33:39 +, Glen Barber wrote: Author: gjb (doc committer) Date: Mon Feb 7 22:33:39 2011 New Revision: 218421 URL: http://svn.freebsd.org/changeset/base/218421 Log: Update manpage to remove CRT reference. Would you mind tackling these as well? bin/stty/stty.1 share/man/man4/acpi_panasonic.4 usr.bin/colcrt/colcrt.1 (I think this tool should be removed) usr.bin/ul/ul.1 Cheers Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r217073 - head/etc/rc.d
On Thu, 06.01.2011 at 21:09:22 +, Warner Losh wrote: Author: imp Date: Thu Jan 6 21:09:22 2011 New Revision: 217073 URL: http://svn.freebsd.org/changeset/base/217073 Log: Don't require /usr/lib/aout to be on the system. Test for its existance since we don't generally need it. MFC after: 1 week Modified: head/etc/rc.d/ldconfig Umm, Would someone object if the aout stuff get's ripped out with prejudice? Regards, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216694 - head/libexec/rtld-elf
On Sat, 25.12.2010 at 08:42:38 +, Konstantin Belousov wrote: Author: kib Date: Sat Dec 25 08:42:38 2010 New Revision: 216694 URL: http://svn.freebsd.org/changeset/base/216694 Log: Add a hook to pass debug flags to the build of rtld when doing make in the rtld directory. Reviewed by:kan Please revert this, $(VAR) is against style, and passing DEBUG_FLAGS is the canonical way to achieve what you wanted, eg. make DEBUG_FLAGS=-g is working just fine for me. Modified: head/libexec/rtld-elf/Makefile Modified: head/libexec/rtld-elf/Makefile == --- head/libexec/rtld-elf/MakefileFri Dec 24 21:31:18 2010 (r216693) +++ head/libexec/rtld-elf/MakefileSat Dec 25 08:42:38 2010 (r216694) @@ -34,7 +34,7 @@ CFLAGS+=-fPIC .else CFLAGS+= -fpic .endif -CFLAGS+= -DPIC +CFLAGS+= -DPIC $(DEBUG) LDFLAGS+=-shared -Wl,-Bsymbolic DPADD= ${LIBC_PIC} LDADD= -lc_pic -lssp_nonshared ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216473 - head/sbin/geom/class/eli
On Thu, 16.12.2010 at 16:43:48 -0800, David O'Brien wrote: On Thu, Dec 16, 2010 at 12:27:04PM -0800, Xin LI wrote: On 12/16/10 12:23, Ulrich Spörlein wrote: Shamless plug: the attached, crude expect(1) script allows you to do $ cd /usr/src universe-build sbin/geom WARNS=6 with the minimal amount of compilation (you have to build the toolchain once, though). I found it invaluable. I think we could probably put that in src/tools/somewhere... Ulrich, Yes, please. I'd love to, but some tcl/expect expert should get in contact with me first, as the script has some serious deficiencies that need fixing before a public release. Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216147 - head/sbin/geom/class/eli
On Fri, 03.12.2010 at 10:06:19 +, Xin LI wrote: Author: delphij Date: Fri Dec 3 10:06:19 2010 New Revision: 216147 URL: http://svn.freebsd.org/changeset/base/216147 Log: * Recommend a overwrite of whole geli provider before use. * Correct a typo while I'm there. Reviewed by:pjd MFC after: 2 weeks Modified: head/sbin/geom/class/eli/geli.8 Modified: head/sbin/geom/class/eli/geli.8 == --- head/sbin/geom/class/eli/geli.8 Fri Dec 3 09:26:56 2010 (r216146) +++ head/sbin/geom/class/eli/geli.8 Fri Dec 3 10:06:19 2010 (r216147) @@ -24,7 +24,7 @@ .\ .\ $FreeBSD$ .\ -.Dd October 20, 2010 +.Dd December 3, 2010 .Dt GELI 8 .Os .Sh NAME @@ -842,7 +842,7 @@ Enter passphrase: .Nm supports two encryption modes: .Nm XTS , -which was standarized as +which was standardized as .Nm IEE P1619 and .Nm CBC @@ -873,6 +873,10 @@ changes with the data he owns without no In other words .Nm will not protect your data against replay attacks. +.Pp +It is recommended to write the whole provider before the first use, +in order to make sure that all sectors and their corresponding +checksums are properly initialized into a consistent state. .Sh SEE ALSO .Xr crypto 4 , .Xr gbde 4 , I'm not sure this wording is very helpful. Why should there be a consistent state? In fact, if you write all zeros to the partition before creating the geom, then an attacker pretty much knows how much data you have written to the provider. I'm not saying this weakens any security, but I think the current phrasing will confuse the reader. What needs to be consistent? What does writing to the provider mean? Or am I mixing up provider and consumer here? Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r215271 - head
On Sat, 13.11.2010 at 22:38:33 +, Warner Losh wrote: Author: imp Date: Sat Nov 13 22:38:33 2010 New Revision: 215271 URL: http://svn.freebsd.org/changeset/base/215271 Log: Add mips back to universe Modified: head/Makefile Modified: head/Makefile == --- head/Makefile Sat Nov 13 22:34:12 2010(r215270) +++ head/Makefile Sat Nov 13 22:38:33 2010(r215271) @@ -281,7 +281,7 @@ tinderbox: # existing system is. # .if make(universe) || make(universe_kernels) || make(tinderbox) -TARGETS?=amd64 i386 ia64 pc98 powerpc sparc64 sun4v +TARGETS?=amd64 i386 ia64 pc98 powerpc sparc64 sun4v mips Can we have that sorted, please? I'm sure it was sorted before ... -TARGETS?=amd64 i386 ia64 pc98 powerpc sparc64 sun4v mips +TARGETS?=amd64 i386 ia64 mips pc98 powerpc sparc64 sun4v Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r215041 - head/contrib/bzip2
On Tue, 09.11.2010 at 18:32:57 +, David E. O'Brien wrote: Author: obrien Date: Tue Nov 9 18:32:57 2010 New Revision: 215041 URL: http://svn.freebsd.org/changeset/base/215041 Log: Upgrade to Bzip2 version 1.0.6. Reviewed by: SO (cperciva) Modified: head/contrib/bzip2/CHANGES head/contrib/bzip2/LICENSE head/contrib/bzip2/Makefile head/contrib/bzip2/Makefile-libbz2_so head/contrib/bzip2/README head/contrib/bzip2/README.COMPILATION.PROBLEMS head/contrib/bzip2/blocksort.c head/contrib/bzip2/bzip2.1 head/contrib/bzip2/bzip2.c head/contrib/bzip2/bzip2recover.c head/contrib/bzip2/bzlib.c head/contrib/bzip2/bzlib.h head/contrib/bzip2/bzlib_private.h head/contrib/bzip2/compress.c head/contrib/bzip2/crctable.c head/contrib/bzip2/decompress.c head/contrib/bzip2/huffman.c head/contrib/bzip2/randtable.c head/contrib/bzip2/spewG.c head/contrib/bzip2/unzcrash.c Directory Properties: head/contrib/bzip2/ (props changed) Perhaps I'm reading this wrong, but shouldn't those files have been copied/merged from vendor/bzip2/dist? Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r215041 - head/contrib/bzip2
On Tue, 09.11.2010 at 17:04:27 -0500, John Baldwin wrote: On Tuesday, November 09, 2010 4:23:56 pm Ulrich Spörlein wrote: On Tue, 09.11.2010 at 18:32:57 +, David E. O'Brien wrote: Author: obrien Date: Tue Nov 9 18:32:57 2010 New Revision: 215041 URL: http://svn.freebsd.org/changeset/base/215041 Log: Upgrade to Bzip2 version 1.0.6. Reviewed by: SO (cperciva) Modified: head/contrib/bzip2/CHANGES head/contrib/bzip2/LICENSE head/contrib/bzip2/Makefile head/contrib/bzip2/Makefile-libbz2_so head/contrib/bzip2/README head/contrib/bzip2/README.COMPILATION.PROBLEMS head/contrib/bzip2/blocksort.c head/contrib/bzip2/bzip2.1 head/contrib/bzip2/bzip2.c head/contrib/bzip2/bzip2recover.c head/contrib/bzip2/bzlib.c head/contrib/bzip2/bzlib.h head/contrib/bzip2/bzlib_private.h head/contrib/bzip2/compress.c head/contrib/bzip2/crctable.c head/contrib/bzip2/decompress.c head/contrib/bzip2/huffman.c head/contrib/bzip2/randtable.c head/contrib/bzip2/spewG.c head/contrib/bzip2/unzcrash.c Directory Properties: head/contrib/bzip2/ (props changed) Perhaps I'm reading this wrong, but shouldn't those files have been copied/merged from vendor/bzip2/dist? I think they were. Notice the prop change on the directory. Also, 1.0.6 was imported into the vendor area a while ago. I think David was just now able to get review completed and commit the merge. Subversion is weird. I was expecting lines like these to appear: (from /vendor/bzip2/dist/foo:12345) but this seems to be only done for (A)dded files. Sorry for the noise. Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r211397 - in head: lib/libbluetooth lib/libc/gen lib/libc/net lib/libc/stdlib lib/libc/sys lib/libedit lib/libelf lib/libgeom lib/libgpib lib/libgssapi lib/libpmc lib/libradius lib/lib
On Mon, 16.08.2010 at 15:18:30 +, Joel Dahl wrote: Author: joel (doc committer) Date: Mon Aug 16 15:18:30 2010 New Revision: 211397 URL: http://svn.freebsd.org/changeset/base/211397 Log: Fix typos, spelling, formatting and mdoc mistakes found by Nobuyuki while translating these manual pages. Minor corrections by me. Submitted by: Nobuyuki Koganemaru n-kog...@syd.odn.ne.jp Awesome! Cheers, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r209153 - head/lib/clang
On Mon, 14.06.2010 at 06:23:47 +, Ed Schouten wrote: Author: ed Date: Mon Jun 14 06:23:47 2010 New Revision: 209153 URL: http://svn.freebsd.org/changeset/base/209153 Log: Unbreak Clang on PowerPC. It seems GCC 4.2.1 on PowerPC miscompiles Clang, causing it to crash when building even simple Hello World applications. Switch back to -O1 for this architecture. What about clang compiled using clang -O2? Ie., does clang bootstrap correctly on PPC and this is a genuine gcc 4.2.1 bug? Regards, Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r206497 - in head: sbin/geom/class sbin/geom/class/sched sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/modules/geom/geom_sched/gs_sched sys/modules/geom/geom_sched/gs
On Thu, 15.04.2010 at 17:15:57 +0200, Luigi Rizzo wrote: On Thu, Apr 15, 2010 at 04:38:23PM +0200, Attila Nagy wrote: On 04/12/2010 06:37 PM, Luigi Rizzo wrote: Bring in geom_sched, support for scheduling disk I/O requests in a device independent manner. Also include an example anticipatory scheduler, gsched_rr, which gives very nice performance improvements in presence of competing random access patterns. This is joint work with Fabio Checconi, developed last year and presented at BSDCan 2009. You can find details in the README file or at Are there any plans to bring in something like Linux's ionice (or even better solutions)? Is it possible to do it easily at all (the user and GEOM are seemingly very far from each other)? I can easily[*] modify the I/O priority/weight of process or threads, but you have to keep in mind that once a request is intercepted by the filesystem code (e.g. for delayed writes, or avoid duplication of pending reads), by the time it hits the disk it is not trivial to tell who should be charged for it. This is an area where we still need to experiment a bit (especially to find on which process issues which request, say for metadata, delayed writes, shared reads). [*] the 'easy' way is put the information in an external hash table and look it up using as a search key either of uid, gid, pid/struct thread *. I think we did something like this in the GSOC2005 project on disk scheduling. A more intrusive way involves extending the struct thread with an extra field to store the io priority. What would already be helpful, is an I/O time measurement of the overall system and have that displayed in, eg., vmstat like Linux and Solaris do. It gives a better measure of if a system is CPU bound or I/O bound or neither. Can the scheduler help here? Uli ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org