Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
> On 2 Jul 2015, at 00:07, Simon J. Gerraty wrote: > > Mark Murray wrote: >> * src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h >> - Remove; plugability is no longer used. Compile-time algorithm >>selection is the way to go. > > Errr we use that and need it. > Please put it back. > > Whether we agree with NIST's ideas about how randomness should be > handled or not, we need to to be able to comply and we do not want to > burn their desired arrangement into our kernels. I’m nearly done with this. Please be patient for a few more days. Thanks! M -- Mark R V Murray ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286279 - head/usr.bin/ypcat
Author: araujo (ports committer) Date: Tue Aug 4 07:04:36 2015 New Revision: 286279 URL: https://svnweb.freebsd.org/changeset/base/286279 Log: Get it closes to style(9). Staticization usage() and printit(). Fix the usage of err(3). Reviewed by: bde Modified: head/usr.bin/ypcat/ypcat.c Modified: head/usr.bin/ypcat/ypcat.c == --- head/usr.bin/ypcat/ypcat.c Tue Aug 4 06:02:03 2015(r286278) +++ head/usr.bin/ypcat/ypcat.c Tue Aug 4 07:04:36 2015(r286279) @@ -33,21 +33,19 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include -#include -#include -#include + #include #include +#include +#include +#include +#include #include #include #include #include -void usage(void); -intprintit(u_long, char *, int, char *, int, void *); - static const struct ypalias { char *alias, *name; } ypaliases[] = { @@ -65,16 +63,16 @@ static const struct ypalias { static int key; -void +static void usage(void) { - fprintf(stderr, - "usage: ypcat [-kt] [-d domainname] mapname\n" - " ypcat -x\n"); + fprintf(stderr, "%s\n%s\n", + "usage: ypcat [-kt] [-d domainname] mapname", + " ypcat -x"); exit(1); } -int +static int printit(u_long instatus, char *inkey, int inkeylen, char *inval, int invallen, void *indata) { @@ -91,9 +89,7 @@ main(int argc, char *argv[]) { char *domain = NULL, *inmap; struct ypall_callback ypcb; - extern char *optarg; - extern int optind; - int notrans, c, r; + int c, notrans, r; u_int i; notrans = key = 0; @@ -120,7 +116,7 @@ main(int argc, char *argv[]) if (optind + 1 != argc) usage(); - if (!domain) + if (domain == NULL) yp_get_default_domain(&domain); inmap = argv[optind]; @@ -137,12 +133,10 @@ main(int argc, char *argv[]) case 0: break; case YPERR_YPBIND: - errx(1, "ypcat: not running ypbind\n"); - exit(1); + errx(1, "not running ypbind"); default: - errx(1, "No such map %s. Reason: %s\n", + errx(1, "no such map %s. Reason: %s", inmap, yperr_string(r)); - exit(1); } exit(0); } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286234 - head/sys/boot/common
On Mon, Aug 03, 2015 at 08:54:51PM +0300, Andriy Gapon wrote: > On 03/08/2015 19:27, Edward Tomasz Napierala wrote: > > New Revision: 286234 > > URL: https://svnweb.freebsd.org/changeset/base/286234 > > > > Log: > > Fix a problem which made loader(8) load non-kld files twice. > > What was the problem? > The change looks like defensive coding, but it's not clear why the > loader would attempt to load the same file more than once in the > first place. Seconded; it would be nice to know which commit had intriduced the issue, to make it easier for review and understand which stable branches need MFC. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286280 - head/share/man/man9
Author: trasz Date: Tue Aug 4 08:16:18 2015 New Revision: 286280 URL: https://svnweb.freebsd.org/changeset/base/286280 Log: Revert r286236; vgonel() is a static function. Sponsored by: The FreeBSD Foundation Modified: head/share/man/man9/Makefile head/share/man/man9/vgone.9 Modified: head/share/man/man9/Makefile == --- head/share/man/man9/MakefileTue Aug 4 07:04:36 2015 (r286279) +++ head/share/man/man9/MakefileTue Aug 4 08:16:18 2015 (r286280) @@ -1739,7 +1739,6 @@ MLINKS+=vfs_getopt.9 vfs_copyopt.9 \ vfs_getopt.9 vfs_setopt.9 \ vfs_getopt.9 vfs_setopt_part.9 \ vfs_getopt.9 vfs_setopts.9 -MLINKS+=vgone.9 vgonel.9 MLINKS+=vhold.9 vdrop.9 \ vhold.9 vdropl.9 \ vhold.9 vholdl.9 Modified: head/share/man/man9/vgone.9 == --- head/share/man/man9/vgone.9 Tue Aug 4 07:04:36 2015(r286279) +++ head/share/man/man9/vgone.9 Tue Aug 4 08:16:18 2015(r286280) @@ -37,7 +37,6 @@ .In sys/vnode.h .Ft void .Fn vgone "struct vnode *vp" -.Fn vgonel "struct vnode *vp" .Sh DESCRIPTION The .Fn vgone @@ -57,11 +56,6 @@ The .Fn vgone function takes an exclusively locked vnode, and returns with the vnode exclusively locked. -The -.Fn vgonel -differs from -.Fn vgone -by requiring the vnode interlock to be held. .Sh SEE ALSO .Xr vnode 9 .Sh AUTHORS ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286236 - head/share/man/man9
On 0803T1352, Benjamin Kaduk wrote: > On Mon, Aug 3, 2015 at 12:30 PM, Edward Tomasz Napierala > wrote: > > > Author: trasz > > Date: Mon Aug 3 16:30:47 2015 > > New Revision: 286236 > > URL: https://svnweb.freebsd.org/changeset/base/286236 > > > > Log: > > Document vgonel(9). > > > > Er, isn't this a step backwards? > > % static void vgonel(struct vnode *); > > It is only accidental that anything outside vfs_subr.c can call vgonel(). Not sure how did I manage to miss that. Reverted, thanks. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 03/08/2015 21:48, Warner Losh wrote: On Aug 3, 2015, at 1:44 PM, Slawa Olhovchenkov wrote: On Tue, Aug 04, 2015 at 03:35:50AM +0800, Julian Elischer wrote: On 8/3/15 8:03 PM, Konstantin Belousov wrote: On Mon, Aug 03, 2015 at 12:50:19PM +0100, Steven Hartland wrote: For this change I don't want to get into fixing the thread0 stack size, which can be done later, just to provide a reasonable warning to the user that smaller values could cause a panic. Hmm, is it limited to the thread0 only ? I.e., would only increasing the initial thread stack size be enough to boot the kernel ? The zfs threads do request larger stack size, I know this. Can somebody test the following patch in the i386 configuration which does not boot ? I think this is a reasonable thing to do. Thread0 (and proc0) are special. I don't see why giving it a specially sized stack would be a problem. This is always do for ARM. May be need increase stack size for Thread0 on ARM too? Seems reasonable. There should be a MI way of doing this, but all the code and defines are buried in MD files, so each architecture needs some love to make this a reality. Warner In the mean time are people happier with https://reviews.freebsd.org/D3279 or should I just leave it using the #define until someone has time to work on a full solution? Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286281 - head/sys/kern
Author: trasz Date: Tue Aug 4 08:51:56 2015 New Revision: 286281 URL: https://svnweb.freebsd.org/changeset/base/286281 Log: Mark vgonel() as static. It was already declared static earlier; no idea why compilers don't warn about this. MFC after:1 month Sponsored by: The FreeBSD Foundation Modified: head/sys/kern/vfs_subr.c Modified: head/sys/kern/vfs_subr.c == --- head/sys/kern/vfs_subr.cTue Aug 4 08:16:18 2015(r286280) +++ head/sys/kern/vfs_subr.cTue Aug 4 08:51:56 2015(r286281) @@ -2850,7 +2850,7 @@ unlock: /* * vgone, with the vp interlock held. */ -void +static void vgonel(struct vnode *vp) { struct thread *td; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286236 - head/share/man/man9
On 0804T0724, Konstantin Belousov wrote: > On Tue, Aug 04, 2015 at 07:16:50AM +0300, Konstantin Belousov wrote: > > On Mon, Aug 03, 2015 at 01:52:46PM -0400, Benjamin Kaduk wrote: > > > On Mon, Aug 3, 2015 at 12:30 PM, Edward Tomasz Napierala > > > > > > wrote: > > > > > > > Author: trasz > > > > Date: Mon Aug 3 16:30:47 2015 > > > > New Revision: 286236 > > > > URL: https://svnweb.freebsd.org/changeset/base/286236 > > > > > > > > Log: > > > > Document vgonel(9). > > > > > > > > > > Er, isn't this a step backwards? > > > > > > % static void vgonel(struct vnode *); > > > > > > It is only accidental that anything outside vfs_subr.c can call vgonel(). > > Indeed, only kernel modules on some architectures could use a hole in > > the kernel linker to reference vgonel(). The kernel itself cannot call > > vgonel() outside vfs_subr.c. There is no point in putting vgonel(9) in > > the man page. > > I believe the source of the confusion is the vgonel() definition, which > lacks the static qualifier. I propose to remove vgonel(9) reference from > the man page and add static to definition. Done. > Might be, a review of all functions in vfs_*.c and fixing their missed > qualifiers would be useful. Would be nice if clang warned about this case. No idea why it doesn't. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286281 - head/sys/kern
2015-08-04 10:51 GMT+02:00 Edward Tomasz Napierala : > Mark vgonel() as static. It was already declared static earlier; > no idea why compilers don't warn about this. That's because according to the standard, those keywords are meant to pile up: static void foo(void); _Noreturn void foo(void); void foo(void) { ... } is the same as: static _Noreturn void foo(void) { ... } -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286236 - head/share/man/man9
On Tue, Aug 04, 2015 at 10:56:45AM +0200, Edward Tomasz Napierala wrote: > Would be nice if clang warned about this case. No idea why it doesn't. Because it is valid standard C. Qualifiers are required for declaration, and are optional for definition. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286282 - head/sys/ofed/drivers/net/mlx4
Author: hselasky Date: Tue Aug 4 09:45:10 2015 New Revision: 286282 URL: https://svnweb.freebsd.org/changeset/base/286282 Log: Avoid calling into the random subsystem before it is initialized. Sponsored by: Mellanox Technologies Modified: head/sys/ofed/drivers/net/mlx4/en_tx.c Modified: head/sys/ofed/drivers/net/mlx4/en_tx.c == --- head/sys/ofed/drivers/net/mlx4/en_tx.c Tue Aug 4 08:51:56 2015 (r286281) +++ head/sys/ofed/drivers/net/mlx4/en_tx.c Tue Aug 4 09:45:10 2015 (r286282) @@ -701,9 +701,13 @@ static void build_inline_wqe(struct mlx4 static uint32_t hashrandom; static void hashrandom_init(void *arg) { + /* +* It is assumed that the random subsystem has been +* initialized when this function is called: +*/ hashrandom = m_ether_tcpip_hash_init(); } -SYSINIT(hashrandom_init, SI_SUB_KLD, SI_ORDER_SECOND, &hashrandom_init, NULL); +SYSINIT(hashrandom_init, SI_SUB_RANDOM, SI_ORDER_ANY, &hashrandom_init, NULL); u16 mlx4_en_select_queue(struct net_device *dev, struct mbuf *mb) { ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286170 - head/share/man/man9
Hi Bruce, 2015-08-02 7:35 GMT+02:00 Bruce Evans : > This function shouldn't be deprecated. It is a kernel wrapper with a > good name for hiding the implementation detail or not-yet standard > interface _Static_assert(). _Static_assert has been part of the C standard for approximately 4 years now. I personally couldn't care less about the naming, but in a couple of years from now we'll have an entire generation of recently graduated computer scientists who know what _Static_assert does, because they used it in their C/C++ programming classes. None of them know what a 'CTASSERT' is. We constantly complain about how hard it is to attract new developers to the project. Maybe it's because we require them to learn nonsensical things in order to contribute code. > CTASSERT() is the compile-time variant of KASSERT(). We intentionally > use KASSERT() instead of anything like the standard assert(3) since > we don't like the API or semantics of assert() and want one with > different design and implementation bugs. I can't think of any use > for different semantics to _Static_assert(), but using CTASSERT() > retains flexibility. The problem with this reasoning is that it can be extrapolated. Why is _Static_assert() special in this regard? Why wouldn't we then write a wrapper around 'while' and use it all over our codebase, simply to retain flexibility? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285041 - in head: gnu/usr.bin/gdb/kgdb sys/amd64/include sys/cddl/dev/dtrace/i386 sys/i386/include
On 7/2/15, Konstantin Belousov wrote: > Author: kib > Date: Thu Jul 2 14:37:21 2015 > New Revision: 285041 > URL: https://svnweb.freebsd.org/changeset/base/285041 > > Log: > Use single instance of the identical INKERNEL() and PMC_IN_KERNEL() > macros on amd64 and i386. Move the definition to machine/param.h. > kgdb defines INKERNEL() too, the conflict is resolved by renaming kgdb > version to PINKERNEL(). > > On i386, correct the lowest kernel address. After the shared page was > introduced, USRSTACK no longer points to the last user address + 1 [*] > > Submitted by: Oliver Pinter [*] > Sponsored by: The FreeBSD Foundation > MFC after: 1 week Hi Kostik! Do you have any plan to merge these changes back to 10-stable in the near future? > > Modified: > head/gnu/usr.bin/gdb/kgdb/trgt.c > head/sys/amd64/include/param.h > head/sys/amd64/include/pmc_mdep.h > head/sys/amd64/include/stack.h > head/sys/cddl/dev/dtrace/i386/dtrace_isa.c > head/sys/i386/include/param.h > head/sys/i386/include/pmc_mdep.h > head/sys/i386/include/stack.h > ... ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285046 - head/sys/vm
On 7/2/15, Konstantin Belousov wrote: > Author: kib > Date: Thu Jul 2 15:22:13 2015 > New Revision: 285046 > URL: https://svnweb.freebsd.org/changeset/base/285046 > > Log: > Account for the main process stack being one page below the highest > user address when ABI uses shared page. > > Note that the change is no-op for correctness, since shared page does > not fault. The mapping for the shared page is installed at the > address space creation, the page is unmanaged and its pte/pv entry > cannot be reclaimed. > > Submitted by: Oliver Pinter > Review: https://reviews.freebsd.org/D2954 > MFC after: 1 week Hi Kostik! As same MFC this? Oliver > > Modified: > head/sys/vm/vm_map.c > > Modified: head/sys/vm/vm_map.c > == > --- head/sys/vm/vm_map.c Thu Jul 2 15:17:30 2015(r285045) > +++ head/sys/vm/vm_map.c Thu Jul 2 15:22:13 2015(r285046) > @@ -3640,7 +3640,8 @@ Retry: > return (KERN_NO_SPACE); > } > > - is_procstack = (addr >= (vm_offset_t)vm->vm_maxsaddr) ? 1 : 0; > + is_procstack = (addr >= (vm_offset_t)vm->vm_maxsaddr && > + addr < (vm_offset_t)p->p_sysent->sv_usrstack) ? 1 : 0; > > /* >* If this is the main process stack, see if we're over the stack > ___ > svn-src-head@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286283 - head/sys/geom
Author: trasz Date: Tue Aug 4 10:40:08 2015 New Revision: 286283 URL: https://svnweb.freebsd.org/changeset/base/286283 Log: Fix panic triggered by code like this: open("/dev/md0", O_EXEC); Discussed with: kib@, mav@ MFC after:1 month Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D3051 Modified: head/sys/geom/geom_dev.c Modified: head/sys/geom/geom_dev.c == --- head/sys/geom/geom_dev.cTue Aug 4 09:45:10 2015(r286282) +++ head/sys/geom/geom_dev.cTue Aug 4 10:40:08 2015(r286283) @@ -358,6 +358,13 @@ g_dev_open(struct cdev *dev, int flags, #else e = 0; #endif + + /* +* This happens on attempt to open a device node with O_EXEC. +*/ + if (r + w + e == 0) + return (EINVAL); + if (w) { /* * When running in very secure mode, do not allow ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286170 - head/share/man/man9
On 08/04/15 12:03, Ed Schouten wrote: Hi Bruce, 2015-08-02 7:35 GMT+02:00 Bruce Evans: >This function shouldn't be deprecated. It is a kernel wrapper with a >good name for hiding the implementation detail or not-yet standard >interface _Static_assert(). _Static_assert has been part of the C standard for approximately 4 years now. I personally couldn't care less about the naming, but in a couple of years from now we'll have an entire generation of recently graduated computer scientists who know what _Static_assert does, because they used it in their C/C++ programming classes. None of them know what a 'CTASSERT' is. Hi, Is it correct to assume that everyone doing programming has done a programming class of a certain kind? My gut feeling is it's good practice to have those wrapper macros because they isolate the compiler into a consistent and coherent API. Wouldn't the argument be the same for queue.3 . Once C-compilers finally decide to compile time support queues, we should throw queue.3 aswell? I'd say it is better to stay independent of what the compiler guys will come up with next, reminding me how hard it was to upgrade a machine recently from 9- to 10- because of C++11 --HPS ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286170 - head/share/man/man9
2015-08-04 12:48 GMT+02:00 Hans Petter Selasky : > Once C-compilers finally decide to compile time support queues, we should > throw queue.3 aswell? If the API provided by the C standard would be functionally identical and easy to emulate with older compilers (which is the case for _Static_assert), then yes. Meaning: we should put a notice at the top of the man page that the C standard functionality should be used instead. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286281 - head/sys/kern
On Tue, 4 Aug 2015, Ed Schouten wrote: 2015-08-04 10:51 GMT+02:00 Edward Tomasz Napierala : Mark vgonel() as static. It was already declared static earlier; no idea why compilers don't warn about this. That's because according to the standard, those keywords are meant to pile up: static void foo(void); _Noreturn void foo(void); void foo(void) { ... } is the same as: static _Noreturn void foo(void) { ... } This is a bug in the standard. You can build up enormously complicated declarations, with the full declaration not visible in any one of the parts. E.g.: int foo(); int foo(int (*foo1())); int foo(int (*foo1(int (*foo2(); int foo(int (*foo1(int (*foo2(int (*foo3)()); /* ... */ Every declaration in this sequence completes the type a little more, but the type is never complete. To obfuscate this further, remove the function parameter names, or use different ones in each prototype. To complicate this further, there are many possibilities. E.g., make foo() have several function args and (partially) complete each of these independently. Or use attributes to give even more independence in the steps. I don't know of any useful use for this except to complete function definitions in K&R or bad code. The code might have "int foo();" in it and you want to add a complete prototype without changing the original declaration. The complete prototypes should be declared in one step to avoid further obfuscations. Compilers have very bad support for warning about this. -Wredundant-decls is broken in gcc from when it was born up to at least gcc-4.2.1. The above declarations are non-redundant non-redeclarations, but gcc warns that they are redundant redaclaration. -Wredundant-decls is even more broken in clang. It doesn't warn even if all of the above declarations are repeated so that every declaration in the second copy is redundant. "Building up" doesn't work for all parts of declarations. In particular, the rules for linkage and storage class are confusing without building up, and building up doesn't work for them. Consider: static int foo; int foo; vs int foo; static int foo; According to TenDRA C90, the former is valid, but according to gcc and clang it is invalid. The latter is invalid according to all 3 compilers, so building up by adding the static is always invalid. I only trust TenDRA here. The former is a valid obfuscation (the opposite of building up) for all 3 compilers if foo is replaced by foo(). Now change 'int foo;' to 'extern int foo;' in the former. Then all 3 compilers accept it. extern is generally more confusing than static, especially in combination with inline. For static inline, the most common obfuscation is like this one for vgonel. You declare the function as inline in its prototype but not in its function body. This makes it inline if it is static in both. With static in neither and extern in either, both or neither, the behaviour is even more confusing. Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
another ipfw regression I think.
another thing that seems broken now is that -q no longer stopps errors when deleting non existant rules. root@vps1:~ # ipfw -q delete 4000 ipfw: rule 4000 not found root@vps1:~ # echo $? 69 root@vps1: ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286170 - head/share/man/man9
On Tue, 4 Aug 2015, Ed Schouten wrote: Hi Bruce, 2015-08-02 7:35 GMT+02:00 Bruce Evans : This function shouldn't be deprecated. It is a kernel wrapper with a good name for hiding the implementation detail or not-yet standard interface _Static_assert(). _Static_assert has been part of the C standard for approximately 4 years now. We don't have any C11 compilers yet. I'm still waiting for a C99 compiler (with fenv support). I personally couldn't care less about the naming, but in a couple of years from now we'll have an entire generation of recently graduated computer scientists who know what _Static_assert does, because they used it in their C/C++ programming classes. None of them know what a 'CTASSERT' is. I doubt that many of them will have even seen the identifier _Static_assert. It should be taught some time after fenv, but there probably isn't time to cover either. We constantly complain about how hard it is to attract new developers to the project. Maybe it's because we require them to learn nonsensical things in order to contribute code. CTASSERT() isn't nonsense. It is just another special kernel API. CTASSERT() is the compile-time variant of KASSERT(). We intentionally use KASSERT() instead of anything like the standard assert(3) since we don't like the API or semantics of assert() and want one with different design and implementation bugs. I can't think of any use for different semantics to _Static_assert(), but using CTASSERT() retains flexibility. The problem with this reasoning is that it can be extrapolated. Why is _Static_assert() special in this regard? Why wouldn't we then write a wrapper around 'while' and use it all over our codebase, simply to retain flexibility? Because of portability. The kernel can use new things like _Static_assert() but has negative reasons to switch from its better CTASSERT() API. Contribed code not written for C11 should be portable and not use it without messy ifdefs. Current contribed code doesn't even use it with messy ifdefs. Its only uses in src/contrib are in clang, llvm, once in libcxxrt, and once in top/utils.c written recently. The latter is just a mistake. Try getting such a change (in dusty deck code) accepted by the vendor. It would be easier to fix the code by using a C99 feature (snprintf()), but that would probably be too unportable for the vendor. contrib_top only uses snprintf() once now, and this is in a FreeBSD change. Non-contribed code in userland shouldn't abuse the kernel CTASSERT() and can reasonably use _Static_assert(). Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286284 - in head: lib/libc/amd64/sys lib/libc/i386/sys lib/libc/sys sys/kern
Author: kib Date: Tue Aug 4 12:33:51 2015 New Revision: 286284 URL: https://svnweb.freebsd.org/changeset/base/286284 Log: Copy the fencing of the algorithm to do lock-less update and reading of the timehands, from the kern_tc.c implementation to vdso. Add comments giving hints where to look for the algorithm explanation. To compensate the removal of rmb() in userspace binuptime(), add explicit lfence instruction before rdtsc. On i386, add usual complications to detect SSE2 presence; assume that old CPUs which do not implement SSE2 also execute rdtsc almost in order. Reviewed by: alc, bde (previous version) Sponsored by: The FreeBSD Foundation MFC after:2 weeks Modified: head/lib/libc/amd64/sys/__vdso_gettc.c head/lib/libc/i386/sys/__vdso_gettc.c head/lib/libc/sys/__vdso_gettimeofday.c head/sys/kern/kern_sharedpage.c Modified: head/lib/libc/amd64/sys/__vdso_gettc.c == --- head/lib/libc/amd64/sys/__vdso_gettc.c Tue Aug 4 10:40:08 2015 (r286283) +++ head/lib/libc/amd64/sys/__vdso_gettc.c Tue Aug 4 12:33:51 2015 (r286284) @@ -36,19 +36,29 @@ __FBSDID("$FreeBSD$"); static u_int __vdso_gettc_low(const struct vdso_timehands *th) { - uint32_t rv; + u_int rv; - __asm __volatile("rdtsc; shrd %%cl, %%edx, %0" + __asm __volatile("lfence; rdtsc; shrd %%cl, %%edx, %0" : "=a" (rv) : "c" (th->th_x86_shift) : "edx"); return (rv); } +static u_int +__vdso_rdtsc32(void) +{ + u_int rv; + + __asm __volatile("lfence;rdtsc" : "=a" (rv) : : "edx"); + return (rv); +} + #pragma weak __vdso_gettc u_int __vdso_gettc(const struct vdso_timehands *th) { - return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32()); + return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : + __vdso_rdtsc32()); } #pragma weak __vdso_gettimekeep Modified: head/lib/libc/i386/sys/__vdso_gettc.c == --- head/lib/libc/i386/sys/__vdso_gettc.c Tue Aug 4 10:40:08 2015 (r286283) +++ head/lib/libc/i386/sys/__vdso_gettc.c Tue Aug 4 12:33:51 2015 (r286284) @@ -31,24 +31,78 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include "libc_private.h" +static int lfence_works = -1; + +static int +get_lfence_usage(void) +{ + u_int cpuid_supported, p[4]; + + if (lfence_works == -1) { + __asm __volatile( + " pushfl\n" + " popl%%eax\n" + " movl%%eax,%%ecx\n" + " xorl$0x20,%%eax\n" + " pushl %%eax\n" + " popfl\n" + " pushfl\n" + " popl%%eax\n" + " xorl%%eax,%%ecx\n" + " je 1f\n" + " movl$1,%0\n" + " jmp 2f\n" + "1: movl$0,%0\n" + "2:\n" + : "=r" (cpuid_supported) : : "eax", "ecx"); + if (cpuid_supported) { + __asm __volatile( + " pushl %%ebx\n" + " cpuid\n" + " movl%%ebx,%1\n" + " popl%%ebx\n" + : "=a" (p[0]), "=r" (p[1]), "=c" (p[2]), "=d" (p[3]) + : "0" (0x1)); + lfence_works = (p[3] & CPUID_SSE2) != 0; + } else + lfence_works = 0; + } + return (lfence_works); +} + static u_int __vdso_gettc_low(const struct vdso_timehands *th) { - uint32_t rv; + u_int rv; + if (get_lfence_usage() == 1) + lfence(); __asm __volatile("rdtsc; shrd %%cl, %%edx, %0" : "=a" (rv) : "c" (th->th_x86_shift) : "edx"); return (rv); } +static u_int +__vdso_rdtsc32(void) +{ + u_int rv; + + if (get_lfence_usage() == 1) + lfence(); + rv = rdtsc32(); + return (rv); +} + #pragma weak __vdso_gettc u_int __vdso_gettc(const struct vdso_timehands *th) { - return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32()); + return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : + __vdso_rdtsc32()); } #pragma weak __vdso_gettimekeep Modified: head/lib/libc/sys/__vdso_gettimeofday.c == --- head/lib/libc/sys/__vdso_gettimeofday.c Tue Aug 4 10:40:08 2015 (r286283) +++ head/lib/libc/sys/__vdso_gettimeofday.c Tue Aug 4 12:33:51 2015 (r286284) @@ -42,6 +42,15 @@ tc_delta(const struct vdso_timehands *th th->th_counter_mask); } +/* + * Calculate the absolute or boot-r
svn commit: r286285 - head/usr.sbin/bsdinstall/scripts
Author: gjb Date: Tue Aug 4 13:40:26 2015 New Revision: 286285 URL: https://svnweb.freebsd.org/changeset/base/286285 Log: Ensure the local MANIFEST is always used when verifying remote distribution sets. MFC after:immediately Sponsored by: The FreeBSD Foundation Modified: head/usr.sbin/bsdinstall/scripts/auto Modified: head/usr.sbin/bsdinstall/scripts/auto == --- head/usr.sbin/bsdinstall/scripts/auto Tue Aug 4 12:33:51 2015 (r286284) +++ head/usr.sbin/bsdinstall/scripts/auto Tue Aug 4 13:40:26 2015 (r286285) @@ -284,7 +284,7 @@ if [ ! -z "$FETCH_DISTRIBUTIONS" ]; then DISTDIR_IS_UNIONFS=1 mount_nullfs -o union "$BSDINSTALL_FETCHDEST" "$BSDINSTALL_DISTDIR" else - export DISTRIBUTIONS="MANIFEST $ALL_DISTRIBUTIONS" + export DISTRIBUTIONS="$ALL_DISTRIBUTIONS" export BSDINSTALL_DISTDIR="$BSDINSTALL_FETCHDEST" fi ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286288 - in head/sys/i386: i386 include
Author: kib Date: Tue Aug 4 13:50:52 2015 New Revision: 286288 URL: https://svnweb.freebsd.org/changeset/base/286288 Log: Give large kernel stack to the initial thread . Otherwise, ZFS overflows the stack during root mount in some configurations. Tested by:Fabian Keil (previous version) Sponsored by: The FreeBSD Foundation MFC after:2 weeks Modified: head/sys/i386/i386/genassym.c head/sys/i386/i386/locore.s head/sys/i386/i386/machdep.c head/sys/i386/include/param.h Modified: head/sys/i386/i386/genassym.c == --- head/sys/i386/i386/genassym.c Tue Aug 4 13:42:44 2015 (r286287) +++ head/sys/i386/i386/genassym.c Tue Aug 4 13:50:52 2015 (r286288) @@ -103,6 +103,7 @@ ASSYM(V_SYSCALL, offsetof(struct vmmeter ASSYM(V_INTR, offsetof(struct vmmeter, v_intr)); /* ASSYM(UPAGES, UPAGES);*/ ASSYM(KSTACK_PAGES, KSTACK_PAGES); +ASSYM(TD0_KSTACK_PAGES, TD0_KSTACK_PAGES); ASSYM(PAGE_SIZE, PAGE_SIZE); ASSYM(NPTEPG, NPTEPG); ASSYM(NPDEPG, NPDEPG); Modified: head/sys/i386/i386/locore.s == --- head/sys/i386/i386/locore.s Tue Aug 4 13:42:44 2015(r286287) +++ head/sys/i386/i386/locore.s Tue Aug 4 13:50:52 2015(r286288) @@ -731,7 +731,7 @@ no_kernend: movl%esi,R(IdlePTD) /* Allocate KSTACK */ - ALLOCPAGES(KSTACK_PAGES) + ALLOCPAGES(TD0_KSTACK_PAGES) movl%esi,R(p0kpa) addl$KERNBASE, %esi movl%esi, R(proc0kstack) @@ -800,7 +800,7 @@ no_kernend: /* Map proc0's KSTACK in the physical way ... */ movlR(p0kpa), %eax - movl$(KSTACK_PAGES), %ecx + movl$(TD0_KSTACK_PAGES), %ecx fillkptphys($PG_RW) /* Map ISA hole */ Modified: head/sys/i386/i386/machdep.c == --- head/sys/i386/i386/machdep.cTue Aug 4 13:42:44 2015 (r286287) +++ head/sys/i386/i386/machdep.cTue Aug 4 13:50:52 2015 (r286288) @@ -2445,7 +2445,7 @@ init386(first) #endif thread0.td_kstack = proc0kstack; - thread0.td_kstack_pages = KSTACK_PAGES; + thread0.td_kstack_pages = TD0_KSTACK_PAGES; /* * This may be done better later if it gets more high level Modified: head/sys/i386/include/param.h == --- head/sys/i386/include/param.h Tue Aug 4 13:42:44 2015 (r286287) +++ head/sys/i386/include/param.h Tue Aug 4 13:50:52 2015 (r286288) @@ -114,6 +114,11 @@ #define KSTACK_PAGES 2 /* Includes pcb! */ #endif #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ +#if KSTACK_PAGES < 4 +#defineTD0_KSTACK_PAGES 4 +#else +#defineTD0_KSTACK_PAGES KSTACK_PAGES +#endif /* * Ceiling on amount of swblock kva space, can be changed via ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286288 - in head/sys/i386: i386 include
This effects other platforms arm and mips spring to mind from when I last checked. Would you like me to backout the checks I added to the ZFS module once all the platforms are addressed? Regards Steve On 04/08/2015 14:50, Konstantin Belousov wrote: Author: kib Date: Tue Aug 4 13:50:52 2015 New Revision: 286288 URL: https://svnweb.freebsd.org/changeset/base/286288 Log: Give large kernel stack to the initial thread . Otherwise, ZFS overflows the stack during root mount in some configurations. Tested by: Fabian Keil (previous version) Sponsored by:The FreeBSD Foundation MFC after: 2 weeks Modified: head/sys/i386/i386/genassym.c head/sys/i386/i386/locore.s head/sys/i386/i386/machdep.c head/sys/i386/include/param.h Modified: head/sys/i386/i386/genassym.c == --- head/sys/i386/i386/genassym.c Tue Aug 4 13:42:44 2015 (r286287) +++ head/sys/i386/i386/genassym.c Tue Aug 4 13:50:52 2015 (r286288) @@ -103,6 +103,7 @@ ASSYM(V_SYSCALL, offsetof(struct vmmeter ASSYM(V_INTR, offsetof(struct vmmeter, v_intr)); /* ASSYM(UPAGES, UPAGES);*/ ASSYM(KSTACK_PAGES, KSTACK_PAGES); +ASSYM(TD0_KSTACK_PAGES, TD0_KSTACK_PAGES); ASSYM(PAGE_SIZE, PAGE_SIZE); ASSYM(NPTEPG, NPTEPG); ASSYM(NPDEPG, NPDEPG); Modified: head/sys/i386/i386/locore.s == --- head/sys/i386/i386/locore.s Tue Aug 4 13:42:44 2015(r286287) +++ head/sys/i386/i386/locore.s Tue Aug 4 13:50:52 2015(r286288) @@ -731,7 +731,7 @@ no_kernend: movl%esi,R(IdlePTD) /* Allocate KSTACK */ - ALLOCPAGES(KSTACK_PAGES) + ALLOCPAGES(TD0_KSTACK_PAGES) movl%esi,R(p0kpa) addl$KERNBASE, %esi movl%esi, R(proc0kstack) @@ -800,7 +800,7 @@ no_kernend: /* Map proc0's KSTACK in the physical way ... */ movlR(p0kpa), %eax - movl$(KSTACK_PAGES), %ecx + movl$(TD0_KSTACK_PAGES), %ecx fillkptphys($PG_RW) /* Map ISA hole */ Modified: head/sys/i386/i386/machdep.c == --- head/sys/i386/i386/machdep.cTue Aug 4 13:42:44 2015 (r286287) +++ head/sys/i386/i386/machdep.cTue Aug 4 13:50:52 2015 (r286288) @@ -2445,7 +2445,7 @@ init386(first) #endif thread0.td_kstack = proc0kstack; - thread0.td_kstack_pages = KSTACK_PAGES; + thread0.td_kstack_pages = TD0_KSTACK_PAGES; /* * This may be done better later if it gets more high level Modified: head/sys/i386/include/param.h == --- head/sys/i386/include/param.h Tue Aug 4 13:42:44 2015 (r286287) +++ head/sys/i386/include/param.h Tue Aug 4 13:50:52 2015 (r286288) @@ -114,6 +114,11 @@ #define KSTACK_PAGES 2/* Includes pcb! */ #endif #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ +#if KSTACK_PAGES < 4 +#defineTD0_KSTACK_PAGES 4 +#else +#defineTD0_KSTACK_PAGES KSTACK_PAGES +#endif /* * Ceiling on amount of swblock kva space, can be changed via ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286234 - head/sys/boot/common
On 0803T2054, Andriy Gapon wrote: > On 03/08/2015 19:27, Edward Tomasz Napierala wrote: > > Author: trasz > > Date: Mon Aug 3 16:27:36 2015 > > New Revision: 286234 > > URL: https://svnweb.freebsd.org/changeset/base/286234 > > > > Log: > > Fix a problem which made loader(8) load non-kld files twice. > > What was the problem? > The change looks like defensive coding, but it's not clear why the loader > would > attempt to load the same file more than once in the first place. It's because the "load_modules" Forth word gets called twice. It could be fixed, I guess, but I'm no good at Forth, so I chose the other way: I made the "load" command behave consistently; it already silently refused to load KLDs twice, and I made it behave the same way for other types of modules. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286289 - head/usr.bin/xargs
Author: allanjude Date: Tue Aug 4 14:27:25 2015 New Revision: 286289 URL: https://svnweb.freebsd.org/changeset/base/286289 Log: xargs now takes -P0, creating as many concurrent processes as possible PR: 199976 Submitted by: Nikolai Lifanov Reviewed by: mjg, bjk Approved by: bapt (mentor) MFC after:1 month Relnotes: yes Sponsored by: ScaleEngine Inc. Differential Revision:https://reviews.freebsd.org/D2616 Modified: head/usr.bin/xargs/xargs.1 head/usr.bin/xargs/xargs.c Modified: head/usr.bin/xargs/xargs.1 == --- head/usr.bin/xargs/xargs.1 Tue Aug 4 13:50:52 2015(r286288) +++ head/usr.bin/xargs/xargs.1 Tue Aug 4 14:27:25 2015(r286289) @@ -33,7 +33,7 @@ .\" $FreeBSD$ .\" $xMach: xargs.1,v 1.2 2002/02/23 05:23:37 tim Exp $ .\" -.Dd March 16, 2012 +.Dd August 4, 2015 .Dt XARGS 1 .Os .Sh NAME @@ -207,6 +207,11 @@ Parallel mode: run at most invocations of .Ar utility at once. +If +.Ar maxprocs +is set to 0, +.Nm +will run as many processes as possible. .It Fl p Echo each command to be executed and ask the user whether it should be executed. Modified: head/usr.bin/xargs/xargs.c == --- head/usr.bin/xargs/xargs.c Tue Aug 4 13:50:52 2015(r286288) +++ head/usr.bin/xargs/xargs.c Tue Aug 4 14:27:25 2015(r286289) @@ -46,9 +46,11 @@ static char sccsid[] = "@(#)xargs.c 8.1 #include __FBSDID("$FreeBSD$"); -#include +#include #include - +#include +#include +#include #include #include #include @@ -100,6 +102,7 @@ main(int argc, char *argv[]) long arg_max; int ch, Jflag, nargs, nflag, nline; size_t linelen; + struct rlimit rl; char *endptr; const char *errstr; @@ -166,6 +169,14 @@ main(int argc, char *argv[]) maxprocs = strtonum(optarg, 1, INT_MAX, &errstr); if (errstr) errx(1, "-P %s: %s", optarg, errstr); + if (getrlimit(RLIMIT_NPROC, &rl) != 0) + errx(1, "getrlimit failed"); + if (*endptr != '\0') + errx(1, "invalid number for -P option"); + if (maxprocs < 0) + errx(1, "value for -P option should be >= 0"); + if (maxprocs == 0 || maxprocs > rl.rlim_cur) + maxprocs = rl.rlim_cur; break; case 'p': pflag = 1; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286290 - head/share/man/man4
Author: kevlo Date: Tue Aug 4 15:04:28 2015 New Revision: 286290 URL: https://svnweb.freebsd.org/changeset/base/286290 Log: Add support for Planex GW-NS300N. Modified: head/share/man/man4/ral.4 Modified: head/share/man/man4/ral.4 == --- head/share/man/man4/ral.4 Tue Aug 4 14:27:25 2015(r286289) +++ head/share/man/man4/ral.4 Tue Aug 4 15:04:28 2015(r286290) @@ -14,7 +14,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 10, 2012 +.Dd August 4, 2015 .Dt RAL 4 .Os .Sh NAME @@ -184,6 +184,7 @@ chipsets, including: .It "MSI PC54G2" Ta RT2560 Ta PCI .It "OvisLink EVO-W54PCI" Ta RT2560 Ta PCI .It "PheeNet HWL-PCIG/RA" Ta RT2560 Ta PCI +.It "Planex GW-NS300N" Ta RT2860 Ta CardBus .It "Pro-Nets CB80211G" Ta RT2560 Ta CardBus .It "Pro-Nets PC80211G" Ta RT2560 Ta PCI .It "Repotec RP-WB7108" Ta RT2560 Ta CardBus ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286288 - in head/sys/i386: i386 include
On Tue, Aug 04, 2015 at 03:00:59PM +0100, Steven Hartland wrote: > This effects other platforms arm and mips spring to mind from when I > last checked. > > Would you like me to backout the checks I added to the ZFS module once > all the platforms are addressed? I stated my opinion in a review follow-up, IMO kernel should not lecture users. I cannot fix ARM or MIPS, and I am not even sure that the issue is there. Note that e.g. i386 uses clang, which somehow is much more stack-space hungry than even old gcc. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Aug 04, 2015 at 09:30:30AM +0100, Steven Hartland wrote: > > > On 03/08/2015 21:48, Warner Losh wrote: > >> On Aug 3, 2015, at 1:44 PM, Slawa Olhovchenkov wrote: > >> > >> On Tue, Aug 04, 2015 at 03:35:50AM +0800, Julian Elischer wrote: > >> > >>> On 8/3/15 8:03 PM, Konstantin Belousov wrote: > On Mon, Aug 03, 2015 at 12:50:19PM +0100, Steven Hartland wrote: > > For this change I don't want to get into fixing the thread0 stack size, > > which can be done later, just > > to provide a reasonable warning to the user that smaller values could > > cause a panic. > Hmm, is it limited to the thread0 only ? I.e., would only increasing > the initial thread stack size be enough to boot the kernel ? The zfs > threads do request larger stack size, I know this. > > Can somebody test the following patch in the i386 configuration which > does not boot ? > >>> I think this is a reasonable thing to do. Thread0 (and proc0) are special. > >>> I don't see why giving it a specially sized stack would be a problem. > >> This is always do for ARM. > >> May be need increase stack size for Thread0 on ARM too? > > Seems reasonable. There should be a MI way of doing this, but all the code > > and defines are buried in MD files, so each architecture needs some love to > > make this a reality. > > > > Warner > In the mean time are people happier with > https://reviews.freebsd.org/D3279 or should I just leave it using the > #define until someone has time to work on a full solution? Checking by #ifdef you check only parametr at time of building zfs.ko, checking variable you check actual value. May be check thread stack best if only for current tread. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286170 - head/share/man/man9
Hans Petter Selasky wrote this message on Tue, Aug 04, 2015 at 12:48 +0200: > My gut feeling is it's good practice to have those wrapper macros > because they isolate the compiler into a consistent and coherent API. Except that we now have a consistent and coherent API w/ _Static_assert... We emulate this function on all compilers (or at least try to, see bde's other email about issues w/ the ifdef mess), and is available to both userland and kernel... It will also be available on other platforms, as opposed to having to port our CTASSERT macros to other platforms and introduce #ifdef's to make it compatible... > Wouldn't the argument be the same for queue.3 . Once C-compilers finally > decide to compile time support queues, we should throw queue.3 aswell? > I'd say it is better to stay independent of what the compiler guys will > come up with next, reminding me how hard it was to upgrade a machine > recently from 9- to 10- because of C++11 Last I checked, they don't change their API's ever revision of the langauge... Comparing this to C++11? Just wow, see above how this is properly covered by the ifdef mess in sys/cdefs.h for all compilers, this won't introduce any complications like the C++11... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286292 - in head/sys: netipsec opencrypto
Author: jmg Date: Tue Aug 4 17:47:11 2015 New Revision: 286292 URL: https://svnweb.freebsd.org/changeset/base/286292 Log: Make IPsec work with AES-GCM and AES-ICM (aka CTR) in OCF... IPsec defines the keys differently than NIST does, so we have to muck with key lengths and nonce/IVs to be standard compliant... Remove the iv from secasvar as it was unused... Add a counter protected by a mutex to ensure that the counter for GCM and ICM will never be repeated.. This is a requirement for security.. I would use atomics, but we don't have a 64bit one on all platforms.. Fix a bug where IPsec was depending upon the OCF to ensure that the blocksize was always at least 4 bytes to maintain alignment... Move this logic into IPsec so changes to OCF won't break IPsec... In one place, espx was always non-NULL, so don't test that it's non-NULL before doing work.. minor style cleanups... drop setting key and klen as they were not used... Enforce that OCF won't pass invalid key lengths to AES that would panic the machine... This was has been tested by others too... I tested this against NetBSD 6.1.5 using mini-test suite in https://github.com/jmgurney/ipseccfgs and the only things that don't pass are keyed md5 and sha1, and 3des-deriv (setkey syntax error), all other modes listed in setkey's man page... The nice thing is that NetBSD uses setkey, so same config files were used on both... Reviewed by: gnn Modified: head/sys/netipsec/key.c head/sys/netipsec/key_debug.c head/sys/netipsec/keydb.h head/sys/netipsec/xform_esp.c head/sys/opencrypto/cryptodev.h head/sys/opencrypto/cryptosoft.c head/sys/opencrypto/xform.c Modified: head/sys/netipsec/key.c == --- head/sys/netipsec/key.c Tue Aug 4 15:15:06 2015(r286291) +++ head/sys/netipsec/key.c Tue Aug 4 17:47:11 2015(r286292) @@ -2835,7 +2835,6 @@ key_cleansav(struct secasvar *sav) sav->tdb_xform->xf_zeroize(sav); sav->tdb_xform = NULL; } else { - KASSERT(sav->iv == NULL, ("iv but no xform")); if (sav->key_auth != NULL) bzero(sav->key_auth->key_data, _KEYLEN(sav->key_auth)); if (sav->key_enc != NULL) @@ -3013,7 +3012,6 @@ key_setsaval(struct secasvar *sav, struc sav->key_enc = NULL; sav->sched = NULL; sav->schedlen = 0; - sav->iv = NULL; sav->lft_c = NULL; sav->lft_h = NULL; sav->lft_s = NULL; Modified: head/sys/netipsec/key_debug.c == --- head/sys/netipsec/key_debug.c Tue Aug 4 15:15:06 2015 (r286291) +++ head/sys/netipsec/key_debug.c Tue Aug 4 17:47:11 2015 (r286292) @@ -577,11 +577,6 @@ kdebug_secasv(struct secasvar *sav) kdebug_sadb_key((struct sadb_ext *)sav->key_auth); if (sav->key_enc != NULL) kdebug_sadb_key((struct sadb_ext *)sav->key_enc); - if (sav->iv != NULL) { - printf(" iv="); - ipsec_hexdump(sav->iv, sav->ivlen ? sav->ivlen : 8); - printf("\n"); - } if (sav->replay != NULL) kdebug_secreplay(sav->replay); Modified: head/sys/netipsec/keydb.h == --- head/sys/netipsec/keydb.h Tue Aug 4 15:15:06 2015(r286291) +++ head/sys/netipsec/keydb.h Tue Aug 4 17:47:11 2015(r286292) @@ -122,10 +122,10 @@ struct secasvar { struct seckey *key_auth;/* Key for Authentication */ struct seckey *key_enc; /* Key for Encryption */ - caddr_t iv; /* Initilization Vector */ u_int ivlen;/* length of IV */ void *sched;/* intermediate encryption key */ size_t schedlen; + uint64_t cntr; /* counter for GCM and CTR */ struct secreplay *replay; /* replay prevention */ time_t created; /* for lifetime */ @@ -163,6 +163,12 @@ struct secasvar { #defineSECASVAR_UNLOCK(_sav) mtx_unlock(&(_sav)->lock) #defineSECASVAR_LOCK_DESTROY(_sav) mtx_destroy(&(_sav)->lock) #defineSECASVAR_LOCK_ASSERT(_sav) mtx_assert(&(_sav)->lock, MA_OWNED) +#defineSAV_ISGCM(_sav) \ + ((_sav)->alg_enc == SADB_X_EALG_AESGCM8 || \ + (_sav)->alg_enc == SADB_X_EALG_AESGCM12 || \ + (_sav)->alg_enc == SADB_X_EALG_AESGCM16) +#defineSAV_ISCTR(_sav) ((_sav)->alg_enc == SADB_X_EALG_AESCTR) +#define SAV_ISCTRORGCM(_sav) (SAV_ISCTR((_sav)) || SAV_ISGCM((_sav))) /* replay prevention */ struct secre
Re: svn commit: r286268 - head/usr.bin/wall
On 08/04/15 01:12, Bruce Evans wrote: On Tue, 4 Aug 2015, Pedro F. Giffuni wrote: Log: Revert r286144 leaving the original fix to the buffer overflow. Some developers consider the new code unnecessarily obfuscated. There was also a benign off-by-one. Discussed with:bde, vangyzen, jmallett It is this version that is unnecessarily obfuscated. I preferred the previous solution, with some adjustment for the off-by-one, but of course I am biased. I am aware you wanted a new fix with strlcat(): the original fix used strlcat so it should be nearer to your expected solution. At this time I really don't want to start a re-write of wall(1) beyond avoiding the buffer overflow. Modified: head/usr.bin/wall/ttymsg.c == --- head/usr.bin/wall/ttymsg.cTue Aug 4 02:41:14 2015(r286267) +++ head/usr.bin/wall/ttymsg.cTue Aug 4 02:56:31 2015(r286268) @@ -62,7 +62,7 @@ ttymsg(struct iovec *iov, int iovcnt, co struct iovec localiov[7]; ssize_t left, wret; int cnt, fd; -char device[MAXNAMLEN]; +char device[MAXNAMLEN] = _PATH_DEV; static char errbuf[1024]; char *p; int forked; Half of the string initialization is done by an auto initializer. Initializations in declarations are specifically forbidden in style(9), and this is a good example of how to obfuscate code using them. The original version using a static initializer was almost as obfuscated, but it was at least maximally efficient and had a technical reason for using the initializer. I understand initialization is done during compile time, while assignments are done in runtime. I personally prefer having the compiler do the effort instead of having the executable do it. Being this a style(9) issue I guess it should be fixed but it is a preexisting condition outside of the scope of the present patch: closing the overflow. @@ -71,9 +71,8 @@ ttymsg(struct iovec *iov, int iovcnt, co if (iovcnt > (int)(sizeof(localiov) / sizeof(localiov[0]))) return ("too many iov's (change code in wall/ttymsg.c)"); -strlcpy(device, _PATH_DEV, sizeof(device)); +strlcat(device, line, sizeof(device)); The other half of the initialization is done using strlcat(). p = device + sizeof(_PATH_DEV) - 1; -strlcpy(p, line, sizeof(device) - sizeof(_PATH_DEV)); if (strncmp(p, "pts/", 4) == 0) p += 4; if (strchr(p, '/') != NULL) { In private mail, I pointed out lots more bad code here. The pointer 'p' was introdiced to avoid writing out the expression for it in more places, especially in the "pts/" check. But the "pts/" check is badly written. It checks the copy of 'line' in 'device'. This is an obfuscated way of checking 'line' itself. It might be more secure the check the final string, but it is actually more secure to check 'line' since this will detect slashes that lost by strlcat() with no error checking. This method becomes even more unnatural when combined with the strcat(). We use the knowledge of the prefix to find the place to start for the check, but don't use this to find the place to start for the concatenation. These places are the same, and unwinding the obfuscation in the check requires knowing that they are the same. I welcome a patch, but I don't want to run the risk of introducing more changes in this commit. This change is only about fixing a buffer overflow that breaks wall(1) when running it with bounds checking. Pedro. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286103 - head/share/man/man9
2015-07-31 8:21 GMT+02:00 Bruce Evans : > For gcc before 4.6, > the ifdef reduces to using __COUNTER__ as the second variable if > __COUNTER__ is supported, else nothing. So for the undocumented > subset of compilers that support __COUNTER__ all cases work, and > for the complementary subset no cases work (the macro is null). I was wondering: could we solve this by not using a typedef, but an external declaration: extern int __whatever[expr ? 1 : -1]; I think we can safely repeat this multiple times without triggering any compiler errors. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286103 - head/share/man/man9
> On Aug 4, 2015, at 12:19 PM, Ed Schouten wrote: > > 2015-07-31 8:21 GMT+02:00 Bruce Evans : >> For gcc before 4.6, >> the ifdef reduces to using __COUNTER__ as the second variable if >> __COUNTER__ is supported, else nothing. So for the undocumented >> subset of compilers that support __COUNTER__ all cases work, and >> for the complementary subset no cases work (the macro is null). > > I was wondering: could we solve this by not using a typedef, but an > external declaration: > > extern int __whatever[expr ? 1 : -1]; > > I think we can safely repeat this multiple times without triggering > any compiler errors. There’s at least one compiler in common use that warns about extern int fred[1]; extern int fred[1]; being a repeated declaration (despite being legal C). Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r286103 - head/share/man/man9
2015-08-04 20:23 GMT+02:00 Warner Losh : > There’s at least one compiler in common use that warns about > > extern int fred[1]; > extern int fred[1]; > > being a repeated declaration (despite being legal C). Would you happen to know which one that is? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286293 - head/sys/x86/include
Author: jkim Date: Tue Aug 4 18:59:54 2015 New Revision: 286293 URL: https://svnweb.freebsd.org/changeset/base/286293 Log: Fix style(9) bugs. Modified: head/sys/x86/include/_types.h Modified: head/sys/x86/include/_types.h == --- head/sys/x86/include/_types.h Tue Aug 4 17:47:11 2015 (r286292) +++ head/sys/x86/include/_types.h Tue Aug 4 18:59:54 2015 (r286293) @@ -154,12 +154,11 @@ typedef int ___wchar_t; typedef__builtin_va_list __va_list; /* internally known to gcc */ #else #ifdef __LP64__ -typedefstruct { - unsigned int__gpo; - unsigned int__fpo; - void*__oaa; - void*__rsa; -} __va_list; +struct __s_va_list { + __uint32_t pad1[2];/* gp_offset, fp_offset */ + __uint64_t pad2[2];/* overflow_arg_area, reg_save_area */ +}; +typedef struct __s_va_list __va_list; #else typedefchar * __va_list; #endif ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286294 - head/sys/arm/conf
Author: rpaulo Date: Tue Aug 4 19:04:02 2015 New Revision: 286294 URL: https://svnweb.freebsd.org/changeset/base/286294 Log: BEAGLEBONE: remove dtrace from MODULES_EXTRA. This config is already building all modules, so we don't need the MODULES_EXTRA definition. It was also causing problems to users who rely on MODULES_OVERRIDE to do the right thing. Discussed with: ian Modified: head/sys/arm/conf/BEAGLEBONE Modified: head/sys/arm/conf/BEAGLEBONE == --- head/sys/arm/conf/BEAGLEBONETue Aug 4 18:59:54 2015 (r286293) +++ head/sys/arm/conf/BEAGLEBONETue Aug 4 19:04:02 2015 (r286294) @@ -32,7 +32,6 @@ makeoptions MODULES_EXTRA="dtb/am335x" optionsKDTRACE_HOOKS # Kernel DTrace hooks optionsDDB_CTF # all architectures - kernel ELF linker loads CTF data makeoptionsWITH_CTF=1 -makeoptionsMODULES_EXTRA+="opensolaris dtrace dtrace/profile dtrace/fbt" optionsHZ=100 optionsSCHED_4BSD # 4BSD scheduler ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286265 - head/sys/x86/include
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2015 01:04, Bruce Evans wrote: > On Tue, 4 Aug 2015, Konstantin Belousov wrote: > >> On Tue, Aug 04, 2015 at 12:11:40AM +, Jung-uk Kim wrote: >>> Log: Always define __va_list for amd64 and restore pre-r232261 >>> behavior for i386. Note it allows exotic compilers, e.g., TCC, >>> to build with our stdio.h, etc. > > Thanks. > >>> PR:201749 MFC after:1 week >>> >>> Modified: head/sys/x86/include/_types.h >>> >>> Modified: head/sys/x86/include/_types.h >>> == >>> >>> >>> - --- head/sys/x86/include/_types.hTue Aug 4 00:11:38 2015 >>> (r286264) +++ head/sys/x86/include/_types.hTue Aug 4 >>> 00:11:39 2015 (r286265) @@ -152,8 +152,17 @@ typedefint >>> ___wchar_t; */ #ifdef __GNUCLIKE_BUILTIN_VARARGS typedef >>> __builtin_va_list__va_list;/* internally known to gcc >>> */ -#elif defined(lint) -typedefchar * >>> __va_list;/* pretend */ +#else +#ifdef __LP64__ +typedef >>> struct { +unsigned int__gpo; +unsigned int >>> __fpo; +void*__oaa; +void*__rsa; +} >>> __va_list; > > Ugh. This is ugly and has many excical style bugs: - tab in > 'typedef struct' - use of 'typedef struct' at all. style(9) > forbids this. structs should be declared with a tag and the used > directly. That means '#define__va_liststruct __s_va_list' > here Fixed. Actually, I followed sys/powerpc/include/_types.h style. I guess we should fix that, too. > - verbose spelling of 'unsigned' This file consistently uses "unsigned int" instead of "unsigned". > - ugly indentation from previous - excessive underscores in struct > member names. Only names in outer scope need 2 underscores and . > See stdio.h. Fixed. >> What do the structure fields mean ? How is it related to the >> amd64 vararg ABI ? > > It seems ABI compatible, but perhaps not API compatible. The > double underscores in the names might be to match an API. But I > doubt that old compilers even support the __LP64__ case. The > certainly don't access these names in any FreeBSD header. So the > ABI could be matched by defining __va_list as an array of 3 > uint64_t's or as a struct with unnamed fields or padding. Done. I was not really interested in API compatibility. FYI, "Figure 3.34: va_list Type Declaration" defines the structure like this: typedef struct { unsigned int gp_offset; unsigned int fp_offset; void *overflow_arg_area; void *reg_save_area; } va_list[1]; >>> +#else +typedefchar *__va_list; > > This still has the '*' misplaced. Note all sys/*/include/_types.h has similar style problems. Jung-uk Kim >>> +#endif #endif #if defined(__GNUC_VA_LIST_COMPATIBILITY) && >>> !defined(__GNUC_VA_LIST) \ && !defined(__NO_GNUC_VA_LIST) > > Is this uglyness still necessary? The gnu-style '&&' in it isn't. > This seems to be for very old versions of gcc that probably don't > have builtin varargs. In old versions of this file, the condition > defined(__GNUC_VA_LIST_COMPATIBILITY) was defined(__GNUC__) && > !defined(__INTEL_COMPILER__), so I think this ifdef is just for > defining something used in old gcc's distribution stdarg.h. The > __INTEL_COMPILER__ part of this makes no sense, and > __GNUC_VA_LIST_COMPATIBILITY is now just an obfuscated spelling of > __GNUC__. Since this is for old gcc internals, non-gcc compilers > are unlikely to need it for compatibility, so the obfuscation is > just wrong. > > Bruce -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwQzUAAoJEHyflib82/FGbSsH/RfgNJxjeu8tJV7KE7szVLV1 bdfzGLXDs/40M4NqCjVd+9z2CFGzvfIfNXWykIwCTV0HAE6UUMb4BpirTYy9lfQF V7y61bd6Mn6i4NbIKMksO6KZduPzGDFAbfPOX4WHOQ6IwPiG/2mzUY9oIT0Sd90D B42Z+p1YljJfFHfaNsupL6xtYDR0SbB3avXeLaTWqf9QatTZvPatHMIncJsZ65ZD x2FAAC7g0Xjp8DKgWiEYmbEKYQsNJgDQ1jQJlmiI3pSdp+yOdQG3RkUs+Pd54Qte LkVdOVYRUwDIxEZIRNVcIpCEo6E+jYgRFfjZZB2v7UXVx8qoKO1qmP/RFyxRHcw= =sj5l -END PGP SIGNATURE- ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286294 - head/sys/arm/conf
> On Aug 4, 2015, at 1:04 PM, Rui Paulo wrote: > > Author: rpaulo > Date: Tue Aug 4 19:04:02 2015 > New Revision: 286294 > URL: https://svnweb.freebsd.org/changeset/base/286294 > > Log: > BEAGLEBONE: remove dtrace from MODULES_EXTRA. > > This config is already building all modules, so we don't need the > MODULES_EXTRA definition. It was also causing problems to users who > rely on MODULES_OVERRIDE to do the right thing. -makeoptionsMODULES_EXTRA+="opensolaris dtrace dtrace/profile dtrace/fbt” The dtrace modules are building by default on ARM now? Are you sure? My reading of the sys/modules/Makefile says that it isn’t on ARM. It was added specifically for the dtrace stuff. Now the dtrace stuff isn’t built. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r286296 - in head/sys: amd64/amd64 arm/arm arm/include arm64/arm64 i386/i386 i386/include mips/mips powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc64/include sparc64/spa...
Author: jah Date: Tue Aug 4 19:46:13 2015 New Revision: 286296 URL: https://svnweb.freebsd.org/changeset/base/286296 Log: Add two new pmap functions: vm_offset_t pmap_quick_enter_page(vm_page_t m) void pmap_quick_remove_page(vm_offset_t kva) These will create and destroy a temporary, CPU-local KVA mapping of a specified page. Guarantees: --Will not sleep and will not fail. --Safe to call under a non-sleepable lock or from an ithread Restrictions: --Not guaranteed to be safe to call from an interrupt filter or under a spin mutex on all platforms --Current implementation does not guarantee more than one page of mapping space across all platforms. MI code should not make nested calls to pmap_quick_enter_page. --MI code should not perform locking while holding onto a mapping created by pmap_quick_enter_page The idea is to use this in busdma, for bounce buffer copies as well as virtually-indexed cache maintenance on mips and arm. NOTE: the non-i386, non-amd64 implementations of these functions still need review and testing. Reviewed by: kib Approved by: kib (mentor) Differential Revision:http://reviews.freebsd.org/D3013 Modified: head/sys/amd64/amd64/pmap.c head/sys/arm/arm/pmap-v6-new.c head/sys/arm/arm/pmap-v6.c head/sys/arm/arm/pmap.c head/sys/arm/include/pcpu.h head/sys/arm64/arm64/pmap.c head/sys/i386/i386/pmap.c head/sys/i386/include/pcpu.h head/sys/mips/mips/pmap.c head/sys/powerpc/aim/mmu_oea.c head/sys/powerpc/aim/mmu_oea64.c head/sys/powerpc/booke/pmap.c head/sys/powerpc/include/pcpu.h head/sys/powerpc/powerpc/mmu_if.m head/sys/powerpc/powerpc/pmap_dispatch.c head/sys/sparc64/include/pcpu.h head/sys/sparc64/sparc64/pmap.c head/sys/vm/pmap.h Modified: head/sys/amd64/amd64/pmap.c == --- head/sys/amd64/amd64/pmap.c Tue Aug 4 19:43:48 2015(r286295) +++ head/sys/amd64/amd64/pmap.c Tue Aug 4 19:46:13 2015(r286296) @@ -6940,6 +6940,18 @@ pmap_unmap_io_transient(vm_page_t page[] } } +vm_offset_t +pmap_quick_enter_page(vm_page_t m) +{ + + return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m))); +} + +void +pmap_quick_remove_page(vm_offset_t addr) +{ +} + #include "opt_ddb.h" #ifdef DDB #include Modified: head/sys/arm/arm/pmap-v6-new.c == --- head/sys/arm/arm/pmap-v6-new.c Tue Aug 4 19:43:48 2015 (r286295) +++ head/sys/arm/arm/pmap-v6-new.c Tue Aug 4 19:46:13 2015 (r286296) @@ -1156,6 +1156,22 @@ pmap_bootstrap(vm_offset_t firstaddr) virtual_end = vm_max_kernel_address; } +static void +pmap_init_qpages(void) +{ + struct pcpu *pc; + int i; + + CPU_FOREACH(i) { + pc = pcpu_find(i); + pc->pc_qmap_addr = kva_alloc(PAGE_SIZE); + if (pc->pc_qmap_addr == 0) + panic("pmap_init_qpages: unable to allocate KVA"); + } +} + +SYSINIT(qpages_init, SI_SUB_CPU, SI_ORDER_ANY, pmap_init_qpages, NULL); + /* * The function can already be use in second initialization stage. * As such, the function DOES NOT call pmap_growkernel() where PT2 @@ -5709,6 +5725,42 @@ pmap_copy_pages(vm_page_t ma[], vm_offse mtx_unlock(&sysmaps->lock); } +vm_offset_t +pmap_quick_enter_page(vm_page_t m) +{ + pt2_entry_t *pte; + vm_offset_t qmap_addr; + + critical_enter(); + + qmap_addr = PCPU_GET(qmap_addr); + pte = pt2map_entry(qmap_addr); + + KASSERT(*pte == 0, ("pmap_quick_enter_page: PTE busy")); + + pte2_store(pte, PTE2_KERN_NG(VM_PAGE_TO_PHYS(m), + PTE2_AP_KRW, pmap_page_get_memattr(m))); + tlb_flush_local(qmap_addr); + + return (qmap_addr); +} + +void +pmap_quick_remove_page(vm_offset_t addr) +{ + pt2_entry_t *pte; + vm_offset_t qmap_addr; + + qmap_addr = PCPU_GET(qmap_addr); + pte = pt2map_entry(qmap_addr); + + KASSERT(addr == qmap_addr, ("pmap_quick_remove_page: invalid address")); + KASSERT(*pte != 0, ("pmap_quick_remove_page: PTE not in use")); + + pte2_clear(pte); + critical_exit(); +} + /* * Copy the range specified by src_addr/len * from the source map to the range dst_addr/len Modified: head/sys/arm/arm/pmap-v6.c == --- head/sys/arm/arm/pmap-v6.c Tue Aug 4 19:43:48 2015(r286295) +++ head/sys/arm/arm/pmap-v6.c Tue Aug 4 19:46:13 2015(r286296) @@ -1979,6 +1979,7 @@ pmap_bootstrap(vm_offset_t firstaddr, st pmap_set_pcb_pagedir(kernel_pmap, thread0.td_pcb); } + /*** * Pmap allocation/deallocation routines. ***/ @@ -2306,6 +2307,31 @@ pmap_remove_pages(pmap_t pmap) PMAP_UNLOCK(pmap); }
Re: svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 04/08/2015 17:14, Slawa Olhovchenkov wrote: On Tue, Aug 04, 2015 at 09:30:30AM +0100, Steven Hartland wrote: On 03/08/2015 21:48, Warner Losh wrote: On Aug 3, 2015, at 1:44 PM, Slawa Olhovchenkov wrote: On Tue, Aug 04, 2015 at 03:35:50AM +0800, Julian Elischer wrote: On 8/3/15 8:03 PM, Konstantin Belousov wrote: On Mon, Aug 03, 2015 at 12:50:19PM +0100, Steven Hartland wrote: For this change I don't want to get into fixing the thread0 stack size, which can be done later, just to provide a reasonable warning to the user that smaller values could cause a panic. Hmm, is it limited to the thread0 only ? I.e., would only increasing the initial thread stack size be enough to boot the kernel ? The zfs threads do request larger stack size, I know this. Can somebody test the following patch in the i386 configuration which does not boot ? I think this is a reasonable thing to do. Thread0 (and proc0) are special. I don't see why giving it a specially sized stack would be a problem. This is always do for ARM. May be need increase stack size for Thread0 on ARM too? Seems reasonable. There should be a MI way of doing this, but all the code and defines are buried in MD files, so each architecture needs some love to make this a reality. Warner In the mean time are people happier with https://reviews.freebsd.org/D3279 or should I just leave it using the #define until someone has time to work on a full solution? Checking by #ifdef you check only parametr at time of building zfs.ko, checking variable you check actual value. May be check thread stack best if only for current tread. Not sure I follow you as its not a #ifdef check its straight if in the new version i.e. if (kstack_pages < ZFS_MIN_KSTACK_PAGES) { Just in case you didn't notice kib committed a fix for i386 thread0 in r286288 so this may not be needed at all any more which is good news :) Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Aug 04, 2015 at 09:06:55PM +0100, Steven Hartland wrote: > > > On 04/08/2015 17:14, Slawa Olhovchenkov wrote: > > On Tue, Aug 04, 2015 at 09:30:30AM +0100, Steven Hartland wrote: > > > >> > >> On 03/08/2015 21:48, Warner Losh wrote: > On Aug 3, 2015, at 1:44 PM, Slawa Olhovchenkov wrote: > > On Tue, Aug 04, 2015 at 03:35:50AM +0800, Julian Elischer wrote: > > > On 8/3/15 8:03 PM, Konstantin Belousov wrote: > >> On Mon, Aug 03, 2015 at 12:50:19PM +0100, Steven Hartland wrote: > >>> For this change I don't want to get into fixing the thread0 stack > >>> size, > >>> which can be done later, just > >>> to provide a reasonable warning to the user that smaller values could > >>> cause a panic. > >> Hmm, is it limited to the thread0 only ? I.e., would only increasing > >> the initial thread stack size be enough to boot the kernel ? The zfs > >> threads do request larger stack size, I know this. > >> > >> Can somebody test the following patch in the i386 configuration which > >> does not boot ? > > I think this is a reasonable thing to do. Thread0 (and proc0) are > > special. > > I don't see why giving it a specially sized stack would be a problem. > This is always do for ARM. > May be need increase stack size for Thread0 on ARM too? > >>> Seems reasonable. There should be a MI way of doing this, but all the > >>> code and defines are buried in MD files, so each architecture needs some > >>> love to make this a reality. > >>> > >>> Warner > >> In the mean time are people happier with > >> https://reviews.freebsd.org/D3279 or should I just leave it using the > >> #define until someone has time to work on a full solution? > > Checking by #ifdef you check only parametr at time of building zfs.ko, > > checking variable you check actual value. > > May be check thread stack best if only for current tread. > Not sure I follow you as its not a #ifdef check its straight if in the > new version i.e. > if (kstack_pages < ZFS_MIN_KSTACK_PAGES) { This check checked how actual kernel compile vs how compile zfs.ko. Remeber that kenel may be compiled independed from modules? > Just in case you didn't notice kib committed a fix for i386 thread0 in > r286288 so this may not be needed at all any more which is good news :) If I understund kib fix (and you about ZFS stack requirements) you need check curthread->td_kstack_pages (for case old, unfixed kerenel, depended from KSTACK_PAGES in Thread0). I.e. for all cases: - unfixed kernel with KSTACK_PAGES < 4 - unfixed kernel with KSTACK_PAGES >= 4 - fixed kernel with KSTACK_PAGES < 4 - fixed kernel with KSTACK_PAGES >= 4 - compiling zfs.ko separately from kernel with different KSTACK_PAGES - using zfs.ko with old kernel checking curthread->td_kstack_pages is right way (or, may be curthread->td_kstack_pages*PAGE_SIZE -- I am not cleanly understund what need to check -- size in bytes or size in pages). Checking KSTACK_PAGES by ifdef can produce vrong result. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286292 - in head/sys: netipsec opencrypto
> On 04 Aug 2015, at 17:47 , John-Mark Gurney wrote: > > Author: jmg > Date: Tue Aug 4 17:47:11 2015 > New Revision: 286292 > URL: https://svnweb.freebsd.org/changeset/base/286292 > > Log: > .. . .. > > Reviewed by: gnn > This should have been 6-8 commits; dissecting what is what even if obvious in some places will even be more pain to understand this in 4 years from now. Especially given it seems cleanup, whitespace, and multiple functional changes all mixed together; not to mention that it’s (complex) security stuff. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286296 - in head/sys: amd64/amd64 arm/arm arm/include arm64/arm64 i386/i386 i386/include mips/mips powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc64/include sparc64/sp
> On 04 Aug 2015, at 19:46 , Jason A. Harmening wrote: > > Author: jah > Date: Tue Aug 4 19:46:13 2015 > New Revision: 286296 > URL: https://svnweb.freebsd.org/changeset/base/286296 > > Log: > Add two new pmap functions: > vm_offset_t pmap_quick_enter_page(vm_page_t m) > void pmap_quick_remove_page(vm_offset_t kva) > > These will create and destroy a temporary, CPU-local KVA mapping of a > specified page. > > Guarantees: > --Will not sleep and will not fail. > --Safe to call under a non-sleepable lock or from an ithread > > Restrictions: > --Not guaranteed to be safe to call from an interrupt filter or under a spin > mutex on all platforms > --Current implementation does not guarantee more than one page of mapping > space across all platforms. MI code should not make nested calls to > pmap_quick_enter_page. > --MI code should not perform locking while holding onto a mapping created by > pmap_quick_enter_page > > The idea is to use this in busdma, for bounce buffer copies as well as > virtually-indexed cache maintenance on mips and arm. > > NOTE: the non-i386, non-amd64 implementations of these functions still need > review and testing. Most of this description should go into a section 9 man page rather than the commit message ;-) /bz ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286296 - in head/sys: amd64/amd64 arm/arm arm/include arm64/arm64 i386/i386 i386/include mips/mips powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc64/include sparc64/sp
On 08/04/15 18:22, Bjoern A. Zeeb wrote: > >> On 04 Aug 2015, at 19:46 , Jason A. Harmening wrote: >> >> Author: jah >> Date: Tue Aug 4 19:46:13 2015 >> New Revision: 286296 >> URL: https://svnweb.freebsd.org/changeset/base/286296 >> >> Log: >> Add two new pmap functions: >> vm_offset_t pmap_quick_enter_page(vm_page_t m) >> void pmap_quick_remove_page(vm_offset_t kva) >> >> These will create and destroy a temporary, CPU-local KVA mapping of a >> specified page. >> >> Guarantees: >> --Will not sleep and will not fail. >> --Safe to call under a non-sleepable lock or from an ithread >> >> Restrictions: >> --Not guaranteed to be safe to call from an interrupt filter or under a >> spin mutex on all platforms >> --Current implementation does not guarantee more than one page of mapping >> space across all platforms. MI code should not make nested calls to >> pmap_quick_enter_page. >> --MI code should not perform locking while holding onto a mapping created >> by pmap_quick_enter_page >> >> The idea is to use this in busdma, for bounce buffer copies as well as >> virtually-indexed cache maintenance on mips and arm. >> >> NOTE: the non-i386, non-amd64 implementations of these functions still need >> review and testing. > > Most of this description should go into a section 9 man page rather than the > commit message ;-) > > /bz > Yep, I'm planning to write one. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286298 - head/sys/dev/nand
Author: jhibbits Date: Wed Aug 5 01:52:11 2015 New Revision: 286298 URL: https://svnweb.freebsd.org/changeset/base/286298 Log: Remove some unnecessary includes. Modified: head/sys/dev/nand/nfc_rb.c Modified: head/sys/dev/nand/nfc_rb.c == --- head/sys/dev/nand/nfc_rb.c Wed Aug 5 00:00:06 2015(r286297) +++ head/sys/dev/nand/nfc_rb.c Wed Aug 5 01:52:11 2015(r286298) @@ -31,16 +31,12 @@ __FBSDID("$FreeBSD$"); #include #include -#include #include -#include #include #include #include #include -#include -#include -#include +#include #include ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286299 - head/sys/dev/nand
Author: jhibbits Date: Wed Aug 5 01:52:52 2015 New Revision: 286299 URL: https://svnweb.freebsd.org/changeset/base/286299 Log: Remove one more that crept in unnecessarily from previous commit. Modified: head/sys/dev/nand/nfc_rb.c Modified: head/sys/dev/nand/nfc_rb.c == --- head/sys/dev/nand/nfc_rb.c Wed Aug 5 01:52:11 2015(r286298) +++ head/sys/dev/nand/nfc_rb.c Wed Aug 5 01:52:52 2015(r286299) @@ -36,7 +36,6 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include #include ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286303 - head/etc
Author: ngie Date: Wed Aug 5 03:03:57 2015 New Revision: 286303 URL: https://svnweb.freebsd.org/changeset/base/286303 Log: Update the comment about handling old-style rc(5) scripts The old-style (*.sh) scripts in /etc/rc.d are explicitly ignored, whereas other scripts ending in .sh are permitted Modified: head/etc/rc.subr Modified: head/etc/rc.subr == --- head/etc/rc.subrWed Aug 5 02:19:38 2015(r286302) +++ head/etc/rc.subrWed Aug 5 03:03:57 2015(r286303) @@ -1266,8 +1266,11 @@ _run_rc_killcmd() # run_rc_script file arg # Start the script `file' with `arg', and correctly handle the # return value from the script. -# If `file' ends with `.sh', it's sourced into the current environment -# when $rc_fast_and_loose is set, otherwise it is run as a child process. +# If `file' ends with `.sh' and lives in /etc/rc.d, ignore it as it's +# an old-style startup file. +# If `file' ends with `.sh' and does not live in /etc/rc.d, it's sourced +# into the current environment if $rc_fast_and_loose is set; otherwise +# it is run as a child process. # If `file' appears to be a backup or scratch file, ignore it. # Otherwise if it is executable run as a child process. # ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r286304 - head/usr.sbin/syslogd
Author: ngie Date: Wed Aug 5 03:17:06 2015 New Revision: 286304 URL: https://svnweb.freebsd.org/changeset/base/286304 Log: Set f_file to -1/F_UNUSED when after closing when possible This will help ensure we don't trash file descriptors that get used later on in the daemon Found via internal Coverity scan MFC after: 2 weeks Discussed with: cem, ed, markj Differential Revision: https://reviews.freebsd.org/D3081 Submitted by: Miles Ohlrich Sponsored by: EMC / Isilon Storage Division Modified: head/usr.sbin/syslogd/syslogd.c Modified: head/usr.sbin/syslogd/syslogd.c == --- head/usr.sbin/syslogd/syslogd.c Wed Aug 5 03:03:57 2015 (r286303) +++ head/usr.sbin/syslogd/syslogd.c Wed Aug 5 03:17:06 2015 (r286304) @@ -349,6 +349,18 @@ static int waitdaemon(int, int, int); static voidtimedout(int); static voidincrease_rcvbuf(int); +static void +close_filed(struct filed *f) +{ + + if (f == NULL || f->f_file == -1) + return; + + (void)close(f->f_file); + f->f_file = -1; + f->f_type = F_UNUSED; +} + int main(int argc, char *argv[]) { @@ -1024,7 +1036,8 @@ logmsg(int pri, const char *msg, const c (void)strlcpy(f->f_lasttime, timestamp, sizeof(f->f_lasttime)); fprintlog(f, flags, msg); - (void)close(f->f_file); + close(f->f_file); + f->f_file = -1; } (void)sigsetmask(omask); return; @@ -1313,8 +1326,7 @@ fprintlog(struct filed *f, int flags, co */ if (errno != ENOSPC) { int e = errno; - (void)close(f->f_file); - f->f_type = F_UNUSED; + close_filed(f); errno = e; logerror(f->f_un.f_fname); } @@ -1338,7 +1350,7 @@ fprintlog(struct filed *f, int flags, co } if (writev(f->f_file, iov, IOV_SIZE) < 0) { int e = errno; - (void)close(f->f_file); + close_filed(f); if (f->f_un.f_pipe.f_pid > 0) deadq_enter(f->f_un.f_pipe.f_pid, f->f_un.f_pipe.f_pname); @@ -1446,7 +1458,7 @@ reapchild(int signo __unused) for (f = Files; f; f = f->f_next) if (f->f_type == F_PIPE && f->f_un.f_pipe.f_pid == pid) { - (void)close(f->f_file); + close_filed(f); f->f_un.f_pipe.f_pid = 0; log_deadchild(pid, status, f->f_un.f_pipe.f_pname); @@ -1550,7 +1562,7 @@ die(int signo) if (f->f_prevcount) fprintlog(f, 0, (char *)NULL); if (f->f_type == F_PIPE && f->f_un.f_pipe.f_pid > 0) { - (void)close(f->f_file); + close_filed(f); f->f_un.f_pipe.f_pid = 0; } } @@ -1634,11 +1646,11 @@ init(int signo) case F_FORW: case F_CONSOLE: case F_TTY: - (void)close(f->f_file); + close_filed(f); break; case F_PIPE: if (f->f_un.f_pipe.f_pid > 0) { - (void)close(f->f_file); + close_filed(f); deadq_enter(f->f_un.f_pipe.f_pid, f->f_un.f_pipe.f_pname); } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286103 - head/share/man/man9
On Tue, 4 Aug 2015, Ed Schouten wrote: 2015-08-04 20:23 GMT+02:00 Warner Losh : There???s at least one compiler in common use that warns about extern int fred[1]; extern int fred[1]; being a repeated declaration (despite being legal C). Would you happen to know which one that is? All non-broken compilers warn about this when directed to do so by -Wredundant-decls. I think -Wno-system-headers turns this off, but we use -Wsystem-headers so as to see bugs in our system headers. clang is broken and doesn't even warn that it ignores -Wredundant-decls. We use -Wredundant-decls at WARNS >= 6. We used to use it always in the kernel, but now we turn it and most other warnings off in cddl code. We use -Wsystem-headers at WARNS >= 1. We don't use it explicitly in the kernel. That might be a bug. The kernel uses nonstandard include paths, but so does userland for bootstrapping and cross compiling. The kernel also uses -nostdinc and that should kill any idea that the kernel has about which headers are system ones. Makeworld doesn't seem to use -nostdinc. That might be another bug. It uses lots of -I paths, but there is still a possibility of getting host headers mixed with target ones. cddl has different messes for -nostdinc. It seems to duplicate it together with spamming CFLAGS with lots of -I's. Bruce___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286265 - head/sys/x86/include
On Tue, Aug 04, 2015 at 03:04:58PM -0400, Jung-uk Kim wrote: > Done. I was not really interested in API compatibility. FYI, "Figure > 3.34: va_list Type Declaration" defines the structure like this: > > typedef struct { > unsigned int gp_offset; > unsigned int fp_offset; > void *overflow_arg_area; > void *reg_save_area; > } va_list[1]; Thank you for the pointer. I read this long time ago as an optional advice for the possible implementation and not as the ABI requirement, so I forgot about it. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286293 - head/sys/x86/include
On Tue, 4 Aug 2015, Jung-uk Kim wrote: Log: Fix style(9) bugs. Thanks. Modified: head/sys/x86/include/_types.h Modified: head/sys/x86/include/_types.h == --- head/sys/x86/include/_types.h Tue Aug 4 17:47:11 2015 (r286292) +++ head/sys/x86/include/_types.h Tue Aug 4 18:59:54 2015 (r286293) @@ -154,12 +154,11 @@ typedef int ___wchar_t; typedef __builtin_va_list __va_list; /* internally known to gcc */ #else #ifdef __LP64__ -typedefstruct { - unsigned int__gpo; - unsigned int__fpo; - void*__oaa; - void*__rsa; -} __va_list; +struct __s_va_list { + __uint32_t pad1[2];/* gp_offset, fp_offset */ + __uint64_t pad2[2];/* overflow_arg_area, reg_save_area */ +}; Er, the struct members need at least 1 underscore, since pad* is in the application namespace and this is a very public file. +typedef struct __s_va_list __va_list; I said to use #define, but now prefer this since it is better for debuggers and all the nearby __va_list's are typedefs. This typedef should be followed by a tab like all the nearby ones. #else typedef char * __va_list; #endif Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"