Re: svn commit: r213398 - head/bin/rm
On Mon, 04.10.2010 at 14:04:53 +0200, Ivan Voras wrote: > On 4 October 2010 13:42, Alexander Best wrote: > > > good point. ZFS should really be added to the list and LFS should go away. > > are > > there any other relevant filesystems without a fixed-block size that need > > to be > > mentioned? what about afs? or tmpfs? > > (it's not that the block sizes aren't fixed, it's that the assignment > of blocks to the file is not fixed). Review of attached patch, anyone? I didn't come up with a clever way to describe non-COW file systems :/ commit 1756b0548e6b18a88e58fad0d078a507c2d87422 Author: Ulrich Spörlein Date: Fri Oct 8 12:29:06 2010 +0200 rm(1): clarify that -P works only when the block allocation is static Suggested by: pjd, ivoras diff --git a/bin/rm/rm.1 b/bin/rm/rm.1 index f580d33..dfba07b 100644 --- a/bin/rm/rm.1 +++ b/bin/rm/rm.1 @@ -32,7 +32,7 @@ .\" @(#)rm.1 8.5 (Berkeley) 12/5/94 .\" $FreeBSD$ .\" -.Dd October 3, 2010 +.Dd October 8, 2010 .Dt RM 1 .Os .Sh NAME @@ -229,8 +229,8 @@ command appeared in .Sh BUGS The .Fl P -option assumes that the underlying file system is a fixed-block file -system. -UFS is a fixed-block file system, LFS is not. +option assumes that the underlying file system does not allocate new blocks +when writing to existing blocks. +This is true for UFS but not for ZFS, which is using Copy-On-Write. In addition, only regular files are overwritten, other types of files are not. diff --git a/bin/rm/rm.c b/bin/rm/rm.c index d9bd296..653833a 100644 --- a/bin/rm/rm.c +++ b/bin/rm/rm.c @@ -402,8 +402,8 @@ rm_file(char **argv) * This is a cheap way to *really* delete files. Note that only regular * files are deleted, directories (and therefore names) will remain. * Also, this assumes a fixed-block file system (like FFS, or a V7 or a - * System V file system). In a logging file system, you'll have to have - * kernel support. + * System V file system). In a logging or COW file system, you'll have to + * have kernel support. */ int rm_overwrite(char *file, struct stat *sbp) ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227997 - vendor/libcxxrt/8931d9e5180830a5433d16ae6b3ad8dd9e629512
On Sat, 2011-11-26 at 14:20:34 +, David Chisnall wrote: > Author: theraven > Date: Sat Nov 26 14:20:34 2011 > New Revision: 227997 > URL: http://svn.freebsd.org/changeset/base/227997 > > Log: > Versioned snapshot for libcxxrt > > Approved by:dim (mentor) > > Added: > vendor/libcxxrt/8931d9e5180830a5433d16ae6b3ad8dd9e629512/ > - copied from r227996, vendor/libcxxrt/dist/ Ho humm, would you really call this a versioned directory? It's kinda silly, IMHO, as it provides no clues as to the evolution of the code. It's just a content identifier and cannot even be sorted. Please consider using dated snapshots instead, e.g. -MM-DD, etc. Thanks Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228896 - head/contrib/netcat
On Wed, 2011-12-28 at 14:09:10 -0800, Doug Barton wrote: > On 12/28/2011 07:40, Ulrich Spörlein wrote: > > 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. > > Fair enough. Having thought more about this my only remaining concern is > that by slipping the tag we're misrepresenting the status quo since > what's in our tree is not really that version of the file. Perhaps a > comment to the effect of "purposely skipping version 1.23 because ..." > would be better? I always look at the CVS Ids from other projects as some kind of guideline or high water mark as to when someone has last looked at all the upstream changes and possibly brought over all the changes that apply. I mean the files are never guaranteed to be the *exact* revision 1.23 from OpenBSD, due to FreeBSD specific changes. Should every committer changing a file look for CVS Ids of other projects and then remove them as the file is being altered and no longer matches upstream bit for bit? That surely is impractical, of course no one would propose such a scheme. Adding that information to the commit message is prudent, however. In the end, whoever gets shit done is getting shit done :) Cheers, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216473 - head/sbin/geom/class/eli
On Thu, 16.12.2010 at 14:22:47 -0500, John Baldwin wrote:
> On Thursday, December 16, 2010 2:04:08 pm Robert Watson wrote:
> > On Thu, 16 Dec 2010, David O'Brien wrote:
> >
> > >>> Log:
> > >>> Bump WARNS to 6.
> > >>>
> > >>> Modified:
> > >>> head/sbin/geom/class/eli/Makefile
> > >>
> > >> FYI, this broke the tinderbox on arm, ia64, mips, and sparc64.
> > >
> > > Errr. Reverted. I built it on the architectures I had access to...
> >
> > For WARNS-related changes, I generally use "make universe" to test across
> > architectures. This builds all of our architectures world + all available
> > kernels, and seems the most effective way to avoid the above situations.
> > (I've
> > fallen into exactly the same trap...)
> >
> > The one thing to be cautious about is that make universe won't fail if an
> > individual build fails, so you need to check the logs to make sure
> > everything
> > actually succeeded.
>
> Which is why I prefer 'make tinderbox' since it tells you what fails. :)
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.
Regards,
Uli
#!/usr/local/bin/expect
# Does the following for variable subdirs and a given set of target archs,
# exits upon first failure.
# % cd /usr/src
# % make toolchain TARGET=powerpc
# % make buildenv TARGET=powerpc
# %% cd usr.sbin/rwhod
# %% make
set timeout -1
set toolchain 0
proc usage {argv0} {
send_user "usage: $argv0 -t \[target1 target2 ...\]\n"
send_user " $argv0 subdir \[make-args\] \[target1 target2 ...\]\n"
send_user "available targets: amd64 arm i386 ia64 mips pc98 powerpc sparc64
sun4v\n"
exit
}
while {[llength $argv]>0} {
set flag [lindex $argv 0]
switch -- $flag \
"-t" {
set toolchain 1
set argv [lrange $argv 1 end]
set argc [expr ($argc - 1)]
} default {
break
}
}
if {$toolchain!=1} {
if {$argc<1} {
usage $argv0
exit 1
}
set subdir [lindex $argv 0]
set argv [lrange $argv 1 end]
set argc [expr ($argc - 1)]
# if something is present, use it as make args
if {$argc>=1} {
set margs [lindex $argv 0]
set argv [lrange $argv 1 end]
set argc [expr ($argc - 1)]
} else {
set margs {}
}
}
# if there is still something, use it as target list,
# else default to everything
if {$argc>=1} {
set targets [lrange $argv 0 end]
} else {
set input [open "|make universe -V TARGETS" r]
set targets [split [string trimright [read $input]] " "]
close $input
}
if {$toolchain==1} {
foreach target $targets {
spawn /bin/sh
expect "$ "
send "env MAKEOBJDIRPREFIX=/usr/obj/$target make toolchain
__MAKE_CONF=/dev/null TARGET=$target\n"
expect "$ "
send "exit \$?\n"
expect eof
}
puts "\n"
exit
}
foreach target $targets {
spawn /bin/sh
set sid($target) $spawn_id
expect "$ "
send "env MAKEOBJDIRPREFIX=/usr/obj/$target make buildenv
__MAKE_CONF=/dev/null TARGET=$target\n"
expect "$ "
send "make -C $subdir obj clean; make -C $subdir $margs\n"
expect "$ "
# 'make buildenv' is doing sh || true, so we cannot propagate by doing exit
$rc
# grab echo output instead
send "echo rc=\$?; exit \$?\n"
# this sucks, but we cant do (.*) and also not ([0-9]*) as these are special
expect -re "rc=(0|1|2|3|4|5|6|7|8|9)\r"
# TODO: save rc per target, don't exit below but print rcs for all archs on
exit
set rc $expect_out(1,string)
expect "$ "
send "exit \$?\n"
expect eof
if {$rc!=0} {
puts "Build failed in ``$subdir'' for arch ``$target'' and flags:
``$margs''"
exit $rc
}
## if we expect eof, the wait below will not return, wtf?
## XXX sid($target) wont work here??
#catch {close -i $spawn_id}
## wait returns PID, TYPE, CODE, grab code
#set rc [lindex [wait sid($target)] 3]
}
puts "\n"
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r221363 - head/sbin/geom/class/part
On Tue, 03.05.2011 at 07:33:39 +, Andrey V. Elsukov wrote: > Author: ae > Date: Tue May 3 07:33:39 2011 > New Revision: 221363 > URL: http://svn.freebsd.org/changeset/base/221363 > > Log: > Add "-a alignment" option to gpart(8). When it specified gpart(8) > tries to align partition start offset and size to be multiple of > alignment value. > Aligned to what? The disk or the partition scheme? Consider someone having a GELI partition of arbitrary alignment, how would a bsdlabel or GPT label inside this GELI partition be aligned when 4K alignment is requested? Cheers, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r252381 - head/sys/contrib/dev/ath/ath_hal/ar9300
On Sat, 2013-06-29 at 16:49:01 +, Adrian Chadd wrote: > Author: adrian > Date: Sat Jun 29 16:49:00 2013 > New Revision: 252381 > URL: http://svnweb.freebsd.org/changeset/base/252381 > > Log: > Check the return value from ath_hal_malloc() > > Reported by:uqs > > Modified: > head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_attach.c Thanks! And for the record, this is Coverity Scan CID: 1040303 Cheers, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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 > 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
Re: svn commit: r253274 - head/sys/cam/scsi
2013/7/15 Kenneth D. Merry : > 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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253457 - head/usr.bin/uniq
On Thu, 2013-07-18 at 22:11:27 +, Pawel Jakub Dawidek wrote:
> Author: pjd
> Date: Thu Jul 18 22:11:27 2013
> New Revision: 253457
> URL: http://svnweb.freebsd.org/changeset/base/253457
>
> Log:
> Close uniq(1) in the capability mode sandbox and limit descriptors using
> capability rights.
>
> Modified:
> head/usr.bin/uniq/uniq.c
>
> Modified: head/usr.bin/uniq/uniq.c
> ==
> --- head/usr.bin/uniq/uniq.c Thu Jul 18 21:56:10 2013(r253456)
> +++ head/usr.bin/uniq/uniq.c Thu Jul 18 22:11:27 2013(r253457)
> @@ -128,8 +145,34 @@ main (int argc, char *argv[])
> ofp = stdout;
> if (argc > 0 && strcmp(argv[0], "-") != 0)
> ifp = file(ifn = argv[0], "r");
> + if (cap_rights_limit(fileno(ifp), CAP_FSTAT | CAP_READ) < 0 &&
> + errno != ENOSYS) {
> + err(1, "unable to limit rights for %s", ifn);
> + }
> + rights = CAP_FSTAT | CAP_WRITE;
> if (argc > 1)
> ofp = file(argv[1], "w");
> + else
> + rights |= CAP_IOCTL;
> + if (cap_rights_limit(fileno(ofp), rights) < 0 && errno != ENOSYS) {
> + err(1, "unable to limit rights for %s",
> + argc > 1 ? argv[1] : "stdout");
> + }
> + if ((rights & CAP_IOCTL) != 0) {
> + unsigned long cmd;
> +
> + cmd = TIOCGETA; /* required by isatty(3) in printf(3) */
> +
> + if (cap_ioctls_limit(fileno(ofp), &cmd, 1) < 0 &&
> + errno != ENOSYS) {
> + err(1, "unable to limit ioctls for %s",
> + argc > 1 ? argv[1] : "stdout");
> + }
> + }
Deadcode, found by Coverity Scan, CID 1054780 (please mention in your
fix-commit). You check for argc > 1 at line 153, only if that is false
(meaning argc==1) do you set CAP_IOCTL. So on line 169 argc cannot be >1
and the result is always "stdout".
Cheers,
Uli
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253504 - head/sbin/route
On Sat, 2013-07-20 at 16:46:51 +, Hiroki Sato wrote:
> Author: hrs
> Date: Sat Jul 20 16:46:51 2013
> New Revision: 253504
> URL: http://svnweb.freebsd.org/changeset/base/253504
>
> Log:
> - Simplify getaddr() and print_getmsg() by using RTAX_* instead of RTA_*
> as the argument.
> - Reduce unnecessary loop in print_getmsg().
>
> Modified:
> head/sbin/route/route.c
>
> Modified: head/sbin/route/route.c
> ==
> --- head/sbin/route/route.c Sat Jul 20 15:58:43 2013(r253503)
> +++ head/sbin/route/route.c Sat Jul 20 16:46:51 2013(r253504)
> @@ -1105,7 +1105,7 @@ inet6_makenetandmask(struct sockaddr_in6
> * returning 1 if a host address, 0 if a network address.
> */
> static int
> -getaddr(int which, char *str, struct hostent **hpp, int nrflags)
> +getaddr(int idx, char *str, struct hostent **hpp, int nrflags)
> {
> struct sockaddr *sa;
> #if defined(INET)
> @@ -1130,36 +1130,16 @@ getaddr(int which, char *str, struct hos
> aflen = sizeof(struct sockaddr_dl);
> #endif
> }
> - rtm_addrs |= which;
> + rtm_addrs |= (1 << idx);
>
> - switch (which) {
> - case RTA_DST:
> - sa = (struct sockaddr *)&so[RTAX_DST];
> - break;
> - case RTA_GATEWAY:
> - sa = (struct sockaddr *)&so[RTAX_GATEWAY];
> - break;
> - case RTA_NETMASK:
> - sa = (struct sockaddr *)&so[RTAX_NETMASK];
> - break;
> - case RTA_GENMASK:
> - sa = (struct sockaddr *)&so[RTAX_GENMASK];
> - break;
> - case RTA_IFA:
> - sa = (struct sockaddr *)&so[RTAX_IFA];
> - break;
> - case RTA_IFP:
> - sa = (struct sockaddr *)&so[RTAX_IFP];
> - break;
> - default:
> + if (idx > RTAX_MAX)
> usage("internal error");
> - /*NOTREACHED*/
> - }
> + sa = (struct sockaddr *)&so[idx];
Coverity Scan flags this as an out-of-bounds write. RTAX_MAX is 8, so
idx can be up to 8 (inclusive) in the check above. Do you want to check
for idx >= RTAX_MAX maybe? idx is also signed ...
Coverity CID is 1054779, btw.
Cheers,
Uli
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253351 - in head: sys/arm/arm sys/i386/i386 sys/kern sys/mips/mips sys/powerpc/aim sys/powerpc/booke sys/sparc64/sparc64 sys/sys usr.bin/netstat
On Mon, 2013-07-15 at 06:16:57 +, Andrey V. Elsukov wrote:
> Author: ae
> Date: Mon Jul 15 06:16:57 2013
> New Revision: 253351
> URL: http://svnweb.freebsd.org/changeset/base/253351
>
> Log:
> Introduce new structure sfstat for collecting sendfile's statistics
> and remove corresponding fields from struct mbstat. Use PCPU counters
> and SFSTAT_INC() macro for update these statistics.
>
> Discussed with: glebius
>
> Modified:
> head/sys/arm/arm/vm_machdep.c
> head/sys/i386/i386/vm_machdep.c
> head/sys/kern/kern_mbuf.c
> head/sys/kern/uipc_syscalls.c
> head/sys/mips/mips/vm_machdep.c
> head/sys/powerpc/aim/vm_machdep.c
> head/sys/powerpc/booke/vm_machdep.c
> head/sys/sparc64/sparc64/vm_machdep.c
> head/sys/sys/mbuf.h
> head/sys/sys/sf_buf.h
> head/usr.bin/netstat/main.c
> head/usr.bin/netstat/mbuf.c
>
> Modified: head/usr.bin/netstat/mbuf.c
> ==
> --- head/usr.bin/netstat/mbuf.c Mon Jul 15 05:09:13 2013
> (r253350)
> +++ head/usr.bin/netstat/mbuf.c Mon Jul 15 06:16:57 2013
> (r253351)
> @@ -308,20 +309,21 @@ mbpr(void *kvmd, u_long mbaddr)
> &mlen, NULL, 0))
> printf("%d/%d/%d sfbufs in use (current/peak/max)\n",
> nsfbufsused, nsfbufspeak, nsfbufs);
> - mlen = sizeof(mbstat);
> - if (sysctlbyname("kern.ipc.mbstat", &mbstat, &mlen, NULL, 0)) {
> - warn("kern.ipc.mbstat");
> + mlen = sizeof(sfstat);
> + if (sysctlbyname("kern.ipc.sfstat", &sfstat, &mlen, NULL, 0)) {
> + warn("kern.ipc.sfstat");
> goto out;
> }
> } else {
Hmm, Coverity flags the sysctlbyname() as an OVERRUN, claiming:
overrun-buffer-val: Overrunning struct type sfstat of 24 bytes by passing it to
a function which accesses it at byte offset 37.
So sysctlbyname.c basically calls sysctl(3) and Coverity thinks that
name[1] is USER_CS_PATH in this case, entering the case statement on
line 69, which then clobbers oldlenp with sizeof(_PATH_STDPATH) at line
74 in lib/libc/gen/sysctl.c, which is 37 bytes
(sizeof("/rescue:/usr/bin:/bin:/usr/sbin:/sbin")).
Then it calls
memmove(oldp, _PATH_STDPATH, sizeof(_PATH_STDPATH));
where the oldp only has space for the aforementioned 24 bytes of struct
sfstat.
Any thoughts on this? It's CID 1054778 at scan.coverity.com, if you
wanna have a look yourself.
Cheers,
Uli
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r262569 - in vendor/device-tree: . Bindings Bindings/arc Bindings/arm Bindings/arm/altera Bindings/arm/bcm Bindings/arm/calxeda Bindings/arm/davinci Bindings/arm/exynos Bindings/arm/fi
On Thu, 2014-02-27 at 19:39:46 +, Warner Losh wrote: > Author: imp > Date: Thu Feb 27 19:39:44 2014 > New Revision: 262569 > URL: http://svnweb.freebsd.org/changeset/base/262569 > > Log: > Bring in Ian Campbell's pruned dts repo. > From git://xenbits.xen.org/people/ianc/device-tree-rebasing.git > commit efa963ec806366c9628dfd1269316bb93b7ecb15 > Merge: a72ba09 459c249 > Author: Ian Campbell > Date: Wed Feb 26 08:39:16 2014 + > > Merge tag 'v3.14-rc4-dts' > > Linux 3.14-rc4 > > Added: > vendor/device-tree/ > vendor/device-tree/Bindings/ Yo Warner, this does not match the typical layout under /vendor, where we would have /vendor/name/dist + /vendor/name/tagged-dist I need to fix that up in the git converters but wanted to check first if you're going to leave it as is or if you're switching to that other naming scheme? Cheers, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r254225 - in head: . contrib/nvi contrib/nvi/build contrib/nvi/catalog contrib/nvi/cl contrib/nvi/clib contrib/nvi/common contrib/nvi/docs/USD.doc/vi.man contrib/nvi/ex contrib/nvi/inc
On Sun, 2013-08-11 at 20:03:13 +, Peter Wemm wrote: > Author: peter > Date: Sun Aug 11 20:03:12 2013 > New Revision: 254225 > URL: http://svnweb.freebsd.org/changeset/base/254225 > > Log: > Update nvi-1.79 to 2.1.1-4334a8297f Cool beans! Please get an account at scan.coverity.com and have a look at the fallout this causes. There are ton's of new issues within this code. Thanks Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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 : > On Tue, Aug 13, 2013 at 4:22 PM, Ulrich Spörlein 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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r261319 - in head: contrib/groff/tmac gnu/usr.bin/groff/tmac
I'd prefer to upstream these things in batches. So go ahead and add NetBSD 7.0 to our mdoc.local and I'll catch it the next time round. Cheers Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r261335 - vendor/mdocml/1.12.3
Sorry for the mess. I'd like to have a chat with whoever thought it a good idea to implement tagging via copy commands ... Regards, Uli 2014-02-01 Ulrich Spoerlein : > Author: uqs > Date: Fri Jan 31 23:14:08 2014 > New Revision: 261335 > URL: http://svnweb.freebsd.org/changeset/base/261335 > > Log: > Tag mdocml 1.12.3 correctly and the right version this time. > > Added: > vendor/mdocml/1.12.3/ > - copied from r261334, vendor/mdocml/dist/ > ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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> > J> > > > Author: des > > J> > J> > > > Date: Tue Feb 5 14:39:37 2013 > > J> > J> > > > New Revision: 246362 > > J> > J> > > > URL: http://svnweb.freebsd.org/changeset/base/246362 > > J> > J> > > > > > J> > J> > > > Log: > > J> > J> > > > Remove political propaganda > > J> > J> > > > > > J> > J> > > > Modified: > > 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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r189765 - in head: . lib/libc lib/libc/nls
On Fri, 13.03.2009 at 14:22:16 -0400, David Schultz wrote: > On Fri, Mar 13, 2009, Sean C. Farley wrote: > > Now, you only need to revive the BSD-licensed libiconv[1]. :) > [...] > > 1. http://people.freebsd.org/~bland/iconv-2.1.tar.gz > > I asked a few weeks ago on standards@ why we weren't using Citrus > iconv, which is what NetBSD uses, and seems to be in a somewhat > better state than this. It also provides various wide character > conversion routines that overlap with what tjr@ has already done > in FreeBSD, so we'd have to sort that out. And we'd have to sort > out a gazillion ports that want -liconv. I, for one, would love to see some iconv overlo^Wsupport in base. That way, I could teach calendar(1) to translate stuff to LC_CTYPE, right now the German calendar file is saved in Latin1 whereas I'm using UTF-8 terminals :/ Cheers, Ulrich Spörlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200818 - head/etc
On Mon, 21.12.2009 at 22:16:07 +, Jilles Tjoelker wrote: > Author: jilles > Date: Mon Dec 21 22:16:07 2009 > New Revision: 200818 > URL: http://svn.freebsd.org/changeset/base/200818 > > Log: > rc.subr: Use pwait in wait_for_pids. > > This waits for the requested process(es) to terminate, rather than polling > with an interval of 2 seconds. > > If pwait is not available, the old method is used. A timeout for pwait would be nice, so that we still get a progress report and not simply a "hang". The return value for timeout-has-fired-but-PID-is-still-alive and no-such-PID would have to be different, though. Btw, I haven't actually tested the current code, perhaps it already DTRT. Regards, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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 Awesome! Cheers, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: INCLUDE_CONFIG_FILE in GENERIC
On Fri, 15.01.2010 at 19:58:57 +1100, Peter Jeremy wrote: > On 2010-Jan-14 20:12:24 +, "Robert N. M. Watson" > wrote: > >- Desktop/server users who want their system to work without any > > special tuning or magic, and likely feel the comments they put in > > configuration files are important > > As far as I'm concerned, the most critical bit of my kernel config file > is the $Header...$ comment - which lets me extract the remainder of the > file from my CVS repository. I don't currently use includes (because > most of my config files have roots pre-dating the include directive). > > I find it a PITA that INCLUDE_CONFIG_FILE _doesn't_ include comments > (or at least my $Header$ line) by default. Seriously, is that the only "comment" people care about? I really have a hard time coming up with *important* stuff that people put in config's comments and then somehow lose the connection between comment and running kernel. > IMO, it would be useful to have an "include this literal string in the > kernel" config directive. This would allow config file version control > information to be embedded without needing the comments. And that would > resolve the issue of embedding fully expanded details of all included > files without the hassle of keeping the comments around. Ok, this I can understand. We could then call this directive something ... um like ident perhaps? :) Seems like all that people want to do is simply: cpu i386 ident SERVER descr "$Id: foo,v" That shouldn't be too hard? FWIW I think it is more important to have a way to recreate the current running kernel than to get a verbatim/expanded copy of all config files used to create it in the first place. Just my two cents, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208417 - head/share/mk
On Sat, 22.05.2010 at 16:30:33 +, Maxim Konovalov wrote: > Author: maxim > Date: Sat May 22 16:30:33 2010 > New Revision: 208417 > URL: http://svn.freebsd.org/changeset/base/208417 > > Log: > o Grammar. > > PR: conf/146827 > Submitted by: chris petrik > > Modified: > head/share/mk/bsd.README > > Modified: head/share/mk/bsd.README > == > --- head/share/mk/bsd.README Sat May 22 15:13:41 2010(r208416) > +++ head/share/mk/bsd.README Sat May 22 16:30:33 2010(r208417) > @@ -91,12 +91,12 @@ the command "make b" will echo "bar". T > way the V7 make behaved. > > It's fairly difficult to make the BSD .mk files work when you're building > -multiple programs in a single directory. It's a lot easier split up the > -programs than to deal with the problem. Most of the agony comes from making > -the "obj" directory stuff work right, not because we switch to a new version > -of make. So, don't get mad at us, figure out a better way to handle multiple > -architectures so we can quit using the symbolic link stuff. (Imake doesn't > -count.) > +multiple programs in a single directory. It's a lot easier to split up > +the programs than to deal with the problem. Most of the agony comes from > +making the "obj" directory stuff work right, not because we switch to a new > +version of make. So, don't get mad at us, figure out a better way to handle > +multiple architectures so we can quit using the symbolic link stuff. > +(Imake doesn't count.) I don't quite get, why the paragraph had to be re-wrapped (making it worse). But what's more annoying is, that you introduced whitespace at end-of-line. Too bad 'svn diff' doesn't highligh this nicely as other SCMs do :( Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r187523 - in stable/7/sys: . amd64/amd64 contrib/pf dev/ath/ath_hal dev/cxgb
Just picking a random commit, but since a couple of days, nearly all commits to stable/7/sys contain the props changed line for > Modified: > stable/7/sys/ (props changed) > stable/7/sys/contrib/pf/ (props changed) > stable/7/sys/dev/ath/ath_hal/ (props changed) > stable/7/sys/dev/cxgb/ (props changed) It's always these four. What's up with that? Cheers, Ulrich Spörlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r194687 - head/sys/dev/firewire
On Tue, 23.06.2009 at 11:30:58 +0200, Roman Divacky wrote: > On Tue, Jun 23, 2009 at 09:02:24AM +, Roman Divacky wrote: > > Log: > > Fix what seems to be an obvious typo preventing the body of the > > if statement to ever be executed. > > what I meant was the the goto out; is executed every time. :( Better than staying inside all the time, no? *scnr* Cheers, Ulrich Spörlein ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r194628 - head/lib/ncurses/ncurses
On Tue, 30.06.2009 at 09:46:32 -0600, M. Warner Losh wrote: > In message: > Robert Watson writes: > : On Tue, 30 Jun 2009, M. Warner Losh wrote: > : > : > Last time this BBQ came up, I thought it was agreed that there would be a > : > xterm-XXX that didn't do this behavior for those folks that think the > : > current behavior is harmfully wrong... > : > : Whereas I think it's a bug in more(1)/less(1) that it tries to use those > : sequences... > > Agreed. vi too. I'll note that on Mac OS, in the xterm, you don't > see this with either... But I don't know how to undo tic(1) > formatting to get back to the raw xterm entries... For vim(1) you can use something like set t_ti= t_te= Btw, I do like the current behaviour, but if $PAGER can be coerced into not clearing screen after exit, I think more people could be persuaded. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r203926 - in head/games/fortune: fortune strfile unstr
On Wed, 17.02.2010 at 11:43:57 -0500, John Baldwin wrote: > On Monday 15 February 2010 10:10:22 am Ulrich Spoerlein wrote: > > Author: uqs > > Date: Mon Feb 15 15:10:21 2010 > > New Revision: 203926 > > URL: http://svn.freebsd.org/changeset/base/203926 > > > > Log: > > fortune(6) switch to 3-clause BSDL; style(9) > > > > This reduces the diff to other *BSD and makes it possible to actually > > see the code differences. > > > > Approved by: ed (Co-mentor) > > There appear to be a lot of unrelated changes to at least fortune.c in this > commit. Hi John, care to elaborate? The commit log says that style(9) has been applied and it is a diff reduction commit in general. That said, the only object code altering change is the replacing of exit(0) with return(0) at the end of main(). There's nothing definitive in style(9) about that ... Cheers, Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204103 - in head/usr.bin: . seq
On Sat, 20.02.2010 at 11:58:38 +, Alexey Dokuchaev wrote: > On Fri, Feb 19, 2010 at 11:54:12PM +, Xin LI wrote: > > Author: delphij > > Date: Fri Feb 19 23:54:12 2010 > > New Revision: 204103 > > URL: http://svn.freebsd.org/changeset/base/204103 > > > > Log: > > Add seq(1), a small utility to generate sequence number. > > Why do we need this when we have jot(1)? Compatibility with shell scripts, I suppose. Some ports may use seq(1) in their test or build targets, etc. There is no jot(1) on any Linux or Solaris I've seen so usage of seq(1) is fairly common. I wonder though, if we could merge functionality into jot(1) and employ a link to seq. Uli ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
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
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(&sb, shmseg, sizeof(*shmseg)); 1041} 1042error = sbuf_finish(&sb); >>> CID 1354974: Memory - corruptions (BAD_FREE) >>> "sbuf_delete" frees address of "sb". 1043sbuf_delete(&sb); 1044 1045 done: 1046SYSVSHM_UNLOCK(); 1047return (error); 1048 } ** CID 1354975: Memory - corruptions (BAD_FREE) and one in sysv_msg.c ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
