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

2015-08-04 Thread Mark R V Murray

> 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

2015-08-04 Thread Marcelo Araujo
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

2015-08-04 Thread Alexey Dokuchaev
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

2015-08-04 Thread Edward Tomasz Napierala
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

2015-08-04 Thread Edward Tomasz Napierala
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

2015-08-04 Thread Steven Hartland



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

2015-08-04 Thread Edward Tomasz Napierala
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

2015-08-04 Thread Edward Tomasz Napierala
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 Thread Ed Schouten
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

2015-08-04 Thread Konstantin Belousov
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

2015-08-04 Thread Hans Petter Selasky
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

2015-08-04 Thread Ed Schouten
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

2015-08-04 Thread Oliver Pinter
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

2015-08-04 Thread Oliver Pinter
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

2015-08-04 Thread Edward Tomasz Napierala
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

2015-08-04 Thread Hans Petter Selasky

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 Thread Ed Schouten
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

2015-08-04 Thread Bruce Evans

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.

2015-08-04 Thread Julian Elischer
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

2015-08-04 Thread Bruce Evans

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

2015-08-04 Thread Konstantin Belousov
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

2015-08-04 Thread Glen Barber
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

2015-08-04 Thread Konstantin Belousov
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

2015-08-04 Thread Steven Hartland
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

2015-08-04 Thread Edward Tomasz Napierala
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

2015-08-04 Thread Allan Jude
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

2015-08-04 Thread Kevin Lo
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

2015-08-04 Thread Konstantin Belousov
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

2015-08-04 Thread Slawa Olhovchenkov
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

2015-08-04 Thread John-Mark Gurney
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

2015-08-04 Thread John-Mark Gurney
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

2015-08-04 Thread Pedro Giffuni



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-08-04 Thread Ed Schouten
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

2015-08-04 Thread Warner Losh

> 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 Thread Ed Schouten
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

2015-08-04 Thread Jung-uk Kim
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

2015-08-04 Thread Rui Paulo
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

2015-08-04 Thread Jung-uk Kim
-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

2015-08-04 Thread Warner Losh

> 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...

2015-08-04 Thread Jason A. Harmening
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

2015-08-04 Thread Steven Hartland



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

2015-08-04 Thread Slawa Olhovchenkov
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

2015-08-04 Thread Bjoern A. Zeeb

> 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

2015-08-04 Thread Bjoern A. Zeeb

> 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

2015-08-04 Thread Jason Harmening


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

2015-08-04 Thread Justin Hibbits
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

2015-08-04 Thread Justin Hibbits
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

2015-08-04 Thread Garrett Cooper
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

2015-08-04 Thread Garrett Cooper
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

2015-08-04 Thread Bruce Evans

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

2015-08-04 Thread Konstantin Belousov
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

2015-08-04 Thread Bruce Evans

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"