svn commit: r252499 - head/sys/powerpc/wii
Author: rpaulo
Date: Tue Jul 2 06:59:37 2013
New Revision: 252499
URL: http://svnweb.freebsd.org/changeset/base/252499
Log:
Add register definitions for the Wii IPC system.
Modified:
head/sys/powerpc/wii/wii_ipcreg.h
Modified: head/sys/powerpc/wii/wii_ipcreg.h
==
--- head/sys/powerpc/wii/wii_ipcreg.h Tue Jul 2 06:49:05 2013
(r252498)
+++ head/sys/powerpc/wii/wii_ipcreg.h Tue Jul 2 06:59:37 2013
(r252499)
@@ -34,4 +34,69 @@
#defineWIIIPC_IOH_ADDR 0x133e
#defineWIIIPC_IOH_LEN 0xc2
+#defineWIIIPC_TXBUF0x00
+#defineWIIIPC_CSR 0x04
+#defineWIIIPC_CSR_TXSTART 0x01
+#defineWIIIPC_CSR_TBEI 0x02
+#defineWIIIPC_CSR_RBFI 0x04
+#defineWIIIPC_CSR_RXREADY 0x08
+#defineWIIIPC_CSR_RBFIMASK 0x10
+#defineWIIIPC_CSR_TBEIMASK 0x20
+#defineWIIIPC_RXBUF0x08
+#defineWIIIPC_ISR 0x30
+#defineWIIIPC_ISR_MAGIC0x4000
+
+enum wiiipc_cmd {
+ WIIIPC_CMD_OPEN = 1,
+ WIIIPC_CMD_CLOSE= 2,
+ WIIIPC_CMD_READ = 3,
+ WIIIPC_CMD_WRITE= 4,
+ WIIIPC_CMD_SEEK = 5,
+ WIIIPC_CMD_IOCTL= 6,
+ WIIIPC_CMD_IOCTLV = 7,
+ WIIIPC_CMD_ASYNCRESP= 8
+};
+
+struct wiiipc_ipc_msg {
+ uint32_tipc_cmd;
+ int32_t ipc_result;
+ int32_t ipc_fd; /* WIIIPC_CMD_ASYNCRESP - the original cmd */
+ union {
+ struct {
+ intptr_t pathname;
+ uint32_t mode;
+ } _ipc_open;
+ struct {
+ intptr_t data;
+ uint32_t len;
+ } _ipc_read, _ipc_write;
+ struct {
+ int32_t offset;
+ int32_t whence;
+ } _ipc_seek;
+ struct {
+ uint32_t request;
+ intptr_t ibuf;
+ uint32_t ilen;
+ intptr_t obuf;
+ uint32_t olen;
+ } _ipc_ioctl;
+ struct {
+ uint32_t request;
+ uint32_t argin;
+ uint32_t argout;
+ intptr_t iovec;
+ } _ipc_ioctlv;
+ uint32_t _ipc_argv[5];
+ } args;
+} __attribute__((packed));
+
+CTASSERT(sizeof(struct wiiipc_ipc_msg) == 32);
+
+#define ipc_open args._ipc_open
+#defineipc_readargs._ipc_read
+#defineipc_write args._ipc_write
+#define ipc_ioctl args._ipc_ioctl
+#define ipc_ioctlv args._ipc_ioctlv
+
#endif /* _POWERPC_WII_WII_IPCREG_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"
svn commit: r252500 - head/sys/powerpc/wii
Author: rpaulo
Date: Tue Jul 2 07:17:56 2013
New Revision: 252500
URL: http://svnweb.freebsd.org/changeset/base/252500
Log:
Fix indentation.
Submitted by: jmallet
Modified:
head/sys/powerpc/wii/wii_ipcreg.h
Modified: head/sys/powerpc/wii/wii_ipcreg.h
==
--- head/sys/powerpc/wii/wii_ipcreg.h Tue Jul 2 06:59:37 2013
(r252499)
+++ head/sys/powerpc/wii/wii_ipcreg.h Tue Jul 2 07:17:56 2013
(r252500)
@@ -93,10 +93,10 @@ struct wiiipc_ipc_msg {
CTASSERT(sizeof(struct wiiipc_ipc_msg) == 32);
-#define ipc_open args._ipc_open
+#defineipc_openargs._ipc_open
#defineipc_readargs._ipc_read
#defineipc_write args._ipc_write
-#define ipc_ioctl args._ipc_ioctl
-#define ipc_ioctlv args._ipc_ioctlv
+#defineipc_ioctl args._ipc_ioctl
+#defineipc_ioctlv args._ipc_ioctlv
#endif /* _POWERPC_WII_WII_IPCREG_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"
svn commit: r252502 - head/sys/kern
Author: mjg
Date: Tue Jul 2 07:36:04 2013
New Revision: 252502
URL: http://svnweb.freebsd.org/changeset/base/252502
Log:
Fix receiving fd over unix socket broken in r247740.
If n fds were passed, it would receive the first one n times.
Reported by: Shawn Webb , koobs, gleb
Tested by:koobs, gleb
Reviewed by: pjd
Modified:
head/sys/kern/uipc_usrreq.c
Modified: head/sys/kern/uipc_usrreq.c
==
--- head/sys/kern/uipc_usrreq.c Tue Jul 2 07:35:57 2013(r252501)
+++ head/sys/kern/uipc_usrreq.c Tue Jul 2 07:36:04 2013(r252502)
@@ -1764,8 +1764,8 @@ unp_externalize(struct mbuf *control, st
}
for (i = 0; i < newfds; i++, fdp++) {
fde = &fdesc->fd_ofiles[*fdp];
- fde->fde_file = fdep[0]->fde_file;
- filecaps_move(&fdep[0]->fde_caps,
+ fde->fde_file = fdep[i]->fde_file;
+ filecaps_move(&fdep[i]->fde_caps,
&fde->fde_caps);
if ((flags & MSG_CMSG_CLOEXEC) != 0)
fde->fde_flags |= UF_EXCLOSE;
___
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: r252501 - in head/sys/dev/usb: . quirk
Author: hrs Date: Tue Jul 2 07:35:57 2013 New Revision: 252501 URL: http://svnweb.freebsd.org/changeset/base/252501 Log: Add Planex MZK-UE150N. Submitted by: Yusuke Tanaka MFC after:3 days Modified: head/sys/dev/usb/quirk/usb_quirk.c head/sys/dev/usb/usbdevs Modified: head/sys/dev/usb/quirk/usb_quirk.c == --- head/sys/dev/usb/quirk/usb_quirk.c Tue Jul 2 07:17:56 2013 (r252500) +++ head/sys/dev/usb/quirk/usb_quirk.c Tue Jul 2 07:35:57 2013 (r252501) @@ -94,6 +94,7 @@ static struct usb_quirk_entry usb_quirks USB_QUIRK(SILICONPORTALS, YAPPHONE, 0x100, 0x100, UQ_AU_INP_ASYNC), USB_QUIRK(LOGITECH, UN53B, 0x, 0x, UQ_NO_STRINGS), USB_QUIRK(ELSA, MODEM1, 0x, 0x, UQ_CFG_INDEX_1), + USB_QUIRK(PLANEX2, MZKUE150N, 0x, 0x, UQ_CFG_INDEX_1), /* Quirks for printer devices */ USB_QUIRK(HP, 895C, 0x, 0x, UQ_BROKEN_BIDIR), USB_QUIRK(HP, 880C, 0x, 0x, UQ_BROKEN_BIDIR), Modified: head/sys/dev/usb/usbdevs == --- head/sys/dev/usb/usbdevsTue Jul 2 07:17:56 2013(r252500) +++ head/sys/dev/usb/usbdevsTue Jul 2 07:35:57 2013(r252501) @@ -3351,6 +3351,7 @@ product PLANEX2 RTL8192CU 0xab2b RTL8192 product PLANEX2 GWUS54HP 0xab01 GW-US54HP product PLANEX2 GWUS300MINIS 0xab24 GW-US300MiniS product PLANEX2RT3070 0xab25 RT3070 +product PLANEX2 MZKUE150N 0xab2f MZK-UE150N product PLANEX2 GWUS54MINI20xab50 GW-US54Mini2 product PLANEX2 GWUS54SG 0xc002 GW-US54SG product PLANEX2 GWUS54GZL 0xc007 GW-US54GZL ___ 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"
RAND_MAX broken (was: Re: svn commit: r252484 - head/sys/ufs/ffs)
On Tue, 2 Jul 2013, Bruce Evans wrote:
...
Also, random(9) is internally broken on 64-bit arches. It shouldn't
exist. It is not random() at all, but just rand() with the clamp to
RAND_MAX removed. Its linear congruential generator is suboptimal
for 64 bits, and other parts of its algorithm are just broken for
64 bits. It uses longs internally to try to fake unsigned 31 bits,
but the faking is broken in different ways depending on the size of
long. It is documented to return a 31-bit value, but on 32-bit
arches it seems to be possible for it to return 0xf, and on
64-bit arches it does return full 64-bit values.
random(9) was cloned from rand(3). The userland versions have been
edited a bit, but still have most of the bugs:
random(3) uses an internal copy of rand(3) named good_rand() for
seeding. If USE_WEAK_SEEDING is defined, this uses a weaker linear
congruential generator (LCG). This uses int32_t instead of long
internally, and doesn't attempt to reduce the value to 31 bits.
Otherwise, the same LCG as random(9) is used, with the same buggy code
except for changing the longs to 32-bits. Using int32_t gives the
same overflow bugs on all (supported) arches, and avoids returning
invalid values half the time on 64-bit arches. There are 2 callers
of good_rand(), and only 1 of them discards bits above the 31st.
srand() also supports USE_WEAK_SEEDING. It uses u_long internally,
so it is actually correct. The internal value has the number of
bits in a u_long and is generated without overflow and without any
bias in the reduction to 31 bits. Then returning this value as
an int in by taking the value modulo ((u_long)RAND_MAX + 1) gives
a correct reduction to 31 bits when RAND_MAX is 0x7fff (or
15 bits if RAND_MAX is 0x7fff, etc.).
srand() in the !USE_WEAK_SEEDING case still uses the same buggy code
as random(9), with type long, so the internal values overflow and the
inernal reduction to 31 bits is buggy, with the bugs depending on the
size of long and other things. But it is mostly saved by taking the
value modulo ((u_long)RAND_MAX + 1). This reduces to a valid value
and leaves only minor biases from the buggy earlier reduction.
random(6) used to have bugs related to the buggy internal reduction,
and the biases from these were noticed. It uses floating point, so
the reduction was easier, but it was still done wrong, by dividing
by LONG_MAX instead of RANDOM_MAX_PLUS1. Using LONG_MAX is like using
0x7fff in random(9), but obviously buggier since the range for
both is documented to be [0,0x7fff]. Hard-coding 0x7fff in
random(6) would have been equally buggy. I think 0x8000 is correct
in both, but in random(9) this assumes too much about type sizes and
layouts. The correct method in integer code is to take an unsigned
modulus with divisor 0x8000. Let the compiler optimize this to
masking with 0x7fff. This depends on the maximum value plus 1
being representable in an unsigned type. For rand(), this occurs
because rand() returns int, and for random(3), this occurs because
random(3) returns long.
Another bug in random(9) is that it returns u_long, so its API is
different from random(3), but since it is documented to return only
31 bits, it is not really different except in the buggy cases where
it returns 32-64 bits.
The bugs are a little different than I said above. There is no overflow
problem and no problem with invalid values being produces, since the
algorithm from ACM is careful to do everything with 32 bit signed
integers without causing overflow. The algorithm just doesn't produce
values mod 2**32 as expected by all the functions. It does what it
claims to do -- it produces values mod (2**32 - 1). The largest bug
is that RAND_MAX is off by 1. It is specified as the largest value
returned by rand(), but in FreeBSD rand() never returns it unless
USE_WEAK_SEEDING is confgured. The values should be unifornly
distributed on average beteen 0 and RAND_MAX,but that is impossible
if RADND_MAX is never returned. From libc/stdlib/srand.c:
% static int
% do_rand(unsigned long *ctx)
% {
% #ifdef USE_WEAK_SEEDING
% /*
% * Historic implementation compatibility.
% * The random sequences do not vary much with the seed,
% * even with overflowing.
% */
% return ((*ctx = *ctx * 1103515245 + 12345) % ((u_long)RAND_MAX + 1));
RAND_MAX is correct for this algorithm. Except it is off by about a factor
of 65536 instead of just by +1. This is the LCG documented as an example in
C standards. It is only suitable for use with 16-bit ints and/or with
RAND_MAX = 32767 and that is how it is used in the example. With FreeBSD's
RAND_MAX = 0x7fff, RAND_MAX is correct but the implementation is of low
quality.
% #else /* !USE_WEAK_SEEDING */
% /*
% * Compute x = (7^5 * x) mod (2^31 - 1)
Note that (2**31 - 1) is not 2**31.
% * without overflowing 31 bits:
% * (2^31 - 1) = 127773 * (7^5) + 2836
% * From "Random number generators: good ones
svn commit: r252503 - head/contrib/llvm/lib/Target/ARM
Author: andrew
Date: Tue Jul 2 08:04:41 2013
New Revision: 252503
URL: http://svnweb.freebsd.org/changeset/base/252503
Log:
Work around an ARM EABI issue where clang would sometimes incorrectly align
the stack in a leaf function that uses TLS.
The issue is, when using TLS, the function is no longer a leaf as it calls
__aeabi_read_tp. With statically linked programs this is not an issue as
it doesn't make use of the stack, however with dynamically linked
applications we enter rtld which does use the stack and makes assumptions
about it's alignment.
This is only a temporary fix until a better patch can be made and submitted
upstream.
Modified:
head/contrib/llvm/lib/Target/ARM/ARMFrameLowering.h
Modified: head/contrib/llvm/lib/Target/ARM/ARMFrameLowering.h
==
--- head/contrib/llvm/lib/Target/ARM/ARMFrameLowering.h Tue Jul 2 07:36:04
2013(r252502)
+++ head/contrib/llvm/lib/Target/ARM/ARMFrameLowering.h Tue Jul 2 08:04:41
2013(r252503)
@@ -27,7 +27,7 @@ protected:
public:
explicit ARMFrameLowering(const ARMSubtarget &sti)
-: TargetFrameLowering(StackGrowsDown, sti.getStackAlignment(), 0, 4),
+: TargetFrameLowering(StackGrowsDown, sti.getStackAlignment(), 0, 8),
STI(sti) {
}
___
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: r252504 - in head: share/man/man4 sys/modules/cc sys/modules/cc/cc_cdg sys/netinet/cc
Author: lstewart Date: Tue Jul 2 08:44:56 2013 New Revision: 252504 URL: http://svnweb.freebsd.org/changeset/base/252504 Log: Import an implementation of the CAIA Delay-Gradient (CDG) congestion control algorithm, which is based on the 2011 v0.1 patch release and described in the paper "Revisiting TCP Congestion Control using Delay Gradients" by David Hayes and Grenville Armitage. It is implemented as a kernel module compatible with the modular congestion control framework. CDG is a hybrid congestion control algorithm which reacts to both packet loss and inferred queuing delay. It attempts to operate as a delay-based algorithm where possible, but utilises heuristics to detect loss-based TCP cross traffic and will compete effectively as required. CDG is therefore incrementally deployable and suitable for use on shared networks. In collaboration with:David Hayes and Grenville Armitage MFC after:4 days Sponsored by: Cisco University Research Program and FreeBSD Foundation Added: head/share/man/man4/cc_cdg.4 (contents, props changed) head/sys/modules/cc/cc_cdg/ head/sys/modules/cc/cc_cdg/Makefile (contents, props changed) head/sys/netinet/cc/cc_cdg.c (contents, props changed) Modified: head/share/man/man4/Makefile head/sys/modules/cc/Makefile Modified: head/share/man/man4/Makefile == --- head/share/man/man4/MakefileTue Jul 2 08:04:41 2013 (r252503) +++ head/share/man/man4/MakefileTue Jul 2 08:44:56 2013 (r252504) @@ -81,6 +81,7 @@ MAN= aac.4 \ cardbus.4 \ carp.4 \ cas.4 \ + cc_cdg.4 \ cc_chd.4 \ cc_cubic.4 \ cc_hd.4 \ Added: head/share/man/man4/cc_cdg.4 == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/man/man4/cc_cdg.4Tue Jul 2 08:44:56 2013 (r252504) @@ -0,0 +1,155 @@ +.\" +.\" Copyright (c) 2013 Swinburne University of Technology, Melbourne, Australia +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\"notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\"notice, this list of conditions and the following disclaimer in the +.\"documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR +.\" ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd July 2, 2013 +.Dt CC_CDG 4 +.Os +.Sh NAME +.Nm cc_cdg +.Nd CDG Congestion Control Algorithm +.Sh DESCRIPTION +CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm which reacts +to both packet loss and inferred queuing delay. +It attempts to operate as a delay-based algorithm where possible, but utilises +heuristics to detect loss-based TCP cross traffic and will compete effectively +as required. +CDG is therefore incrementally deployable and suitable for use on shared +networks. +.Pp +During delay-based operation, CDG uses a delay-gradient based probabilistic +backoff mechanism, and will also try to infer non congestion related +packet losses and avoid backing off when they occur. +During loss-based operation, CDG essentially reverts to +.Xr cc_newreno 4 Ns - Ns like +behaviour. +.Pp +CDG switches to loss-based operation when it detects that a configurable number +of consecutive delay-based backoffs have had no measurable effect. +It periodically attempts to return to delay-based operation, but will keep +switching back to loss-based operation as required. +.Sh MIB Variables +The algorithm exposes the following variables in the +.Va net.inet.tcp.cc.cdg +branch of the +.Xr sysctl 3 +MIB: +.Bl -tag -width ".Va exp_backoff_scale" +.It Va version +Current algorithm/implementation version number. +.It Va beta_delay +Delay-based window decrease factor as a percentage (on delay-based backoff, w = +w * beta_delay / 100). +D
svn commit: r252505 - head/sys/conf
Author: gjb
Date: Tue Jul 2 10:36:57 2013
New Revision: 252505
URL: http://svnweb.freebsd.org/changeset/base/252505
Log:
- Update newvers.sh to include svn revision in uname(1) if the
system has svnliteversion.
- If svnliteversion is not found, look for svnversion in /usr/bin
and /usr/local/bin, since svnlite can be installed as svn if
WITH_SVN is set.[1]
- Remove /bin from binary search paths.[1]
Discussed with: kib [1]
MFC after:3 days
Approved by: kib (mentor)
Modified:
head/sys/conf/newvers.sh
Modified: head/sys/conf/newvers.sh
==
--- head/sys/conf/newvers.shTue Jul 2 08:44:56 2013(r252504)
+++ head/sys/conf/newvers.shTue Jul 2 10:36:57 2013(r252505)
@@ -88,16 +88,26 @@ v=`cat version` u=${USER:-root} d=`pwd`
i=`${MAKE:-make} -V KERN_IDENT`
compiler_v=$($(${MAKE:-make} -V CC) -v 2>&1 | grep 'version')
-for dir in /bin /usr/bin /usr/local/bin; do
+if [ -x /usr/bin/svnliteversion ] ; then
+ svnversion=/usr/bin/svnliteversion
+fi
+
+for dir in /usr/bin /usr/local/bin; do
+ if [ ! -z "${svnversion}" ] ; then
+ break
+ fi
if [ -x "${dir}/svnversion" ] && [ -z ${svnversion} ] ; then
svnversion=${dir}/svnversion
+ break
fi
+done
+for dir in /usr/bin /usr/local/bin; do
if [ -x "${dir}/p4" ] && [ -z ${p4_cmd} ] ; then
p4_cmd=${dir}/p4
fi
done
if [ -d "${SYSDIR}/../.git" ] ; then
- for dir in /bin /usr/bin /usr/local/bin; do
+ for dir in /usr/bin /usr/local/bin; do
if [ -x "${dir}/git" ] ; then
git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git"
break
___
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: r252506 - head/sbin/dhclient
Author: bms
Date: Tue Jul 2 13:24:37 2013
New Revision: 252506
URL: http://svnweb.freebsd.org/changeset/base/252506
Log:
When acquiring a lease, record the value of the BOOTP siaddr field
contained in the DHCP offer, and write it out to the lease file
as an unquoted value of the "next-server" keyword. The value is ignored
when the lease is read back by dhclient, however other applications
are free to parse it.
The intent behind this change is to allow easier interoperability
with automated installation systems e.g. Cobbler, Foreman, Razor;
FreeBSD installation kernels can automatically probe the network
to discover deployment servers. There are no plans to MFC this
change unless a backport is specifically requested.
The syntax of the "next-server " lease keyword is intended to be
identical to that used by the ISC DHCPD server in its configuration files.
The required defines are already present in dhclient but were unused before
this change. (Note: This is NOT the same as Option 66, tftp-server-name).
It has been exercised in a university protocol testbed environment, with
Cobbler and an mfsBSD image containing pc-sysinstall (driven by Cobbler
Cheetah templates). The SYSLINUX memdisk driver is used to boot mfsBSD.
Currently this approach requires that a dedicated system profile has
been created for the node where FreeBSD is to be deployed. If this
is not present, the pc-sysinstall wrapper will be unable to obtain
a node configuration. There is code in progress to allow mfsBSD images
to obtain the required hints from the memdisk environment by parsing
the MBFT ACPI chunk. This is non-standard as it is not linked into
the platform's ACPI RSDT.
Reviewed by: des
Modified:
head/sbin/dhclient/clparse.c
head/sbin/dhclient/dhclient.c
head/sbin/dhclient/dhcpd.h
Modified: head/sbin/dhclient/clparse.c
==
--- head/sbin/dhclient/clparse.cTue Jul 2 10:36:57 2013
(r252505)
+++ head/sbin/dhclient/clparse.cTue Jul 2 13:24:37 2013
(r252506)
@@ -642,6 +642,10 @@ parse_client_lease_declaration(FILE *cfi
case FILENAME:
lease->filename = parse_string(cfile);
return;
+ case NEXT_SERVER:
+ if (!parse_ip_addr(cfile, &lease->nextserver))
+ return;
+ break;
case SERVER_NAME:
lease->server_name = parse_string(cfile);
return;
Modified: head/sbin/dhclient/dhclient.c
==
--- head/sbin/dhclient/dhclient.c Tue Jul 2 10:36:57 2013
(r252505)
+++ head/sbin/dhclient/dhclient.c Tue Jul 2 13:24:37 2013
(r252506)
@@ -1063,6 +1063,9 @@ packet_to_lease(struct packet *packet)
lease->address.len = sizeof(packet->raw->yiaddr);
memcpy(lease->address.iabuf, &packet->raw->yiaddr, lease->address.len);
+ lease->nextserver.len = sizeof(packet->raw->siaddr);
+ memcpy(lease->nextserver.iabuf, &packet->raw->siaddr,
lease->nextserver.len);
+
/* If the server name was filled out, copy it.
Do not attempt to validate the server name as a host name.
RFC 2131 merely states that sname is NUL-terminated (which do
@@ -1874,6 +1877,11 @@ write_client_lease(struct interface_info
fprintf(leaseFile, " bootp;\n");
fprintf(leaseFile, " interface \"%s\";\n", ip->name);
fprintf(leaseFile, " fixed-address %s;\n", piaddr(lease->address));
+ if (lease->nextserver.len == sizeof(inaddr_any) &&
+ 0 != memcmp(lease->nextserver.iabuf, &inaddr_any,
+ sizeof(inaddr_any)))
+ fprintf(leaseFile, " next-server %s;\n",
+ piaddr(lease->nextserver));
if (lease->filename)
fprintf(leaseFile, " filename \"%s\";\n", lease->filename);
if (lease->server_name)
Modified: head/sbin/dhclient/dhcpd.h
==
--- head/sbin/dhclient/dhcpd.h Tue Jul 2 10:36:57 2013(r252505)
+++ head/sbin/dhclient/dhcpd.h Tue Jul 2 13:24:37 2013(r252506)
@@ -121,6 +121,7 @@ struct client_lease {
struct client_lease *next;
time_t expiry, renewal, rebind;
struct iaddr address;
+ struct iaddr nextserver;
char*server_name;
char*filename;
struct string_list *medium;
___
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: r252508 - head/sbin/devd
Author: asomers
Date: Tue Jul 2 14:48:39 2013
New Revision: 252508
URL: http://svnweb.freebsd.org/changeset/base/252508
Log:
Explicitly include to fix compilation with libc++. It is implicitly
included by libstdc++.
Reported By: Oliver Hartmann
Approved by: gibbs (co-mentor, implicit)
Modified:
head/sbin/devd/devd.cc
Modified: head/sbin/devd/devd.cc
==
--- head/sbin/devd/devd.cc Tue Jul 2 13:48:16 2013(r252507)
+++ head/sbin/devd/devd.cc Tue Jul 2 14:48:39 2013(r252508)
@@ -79,6 +79,7 @@ __FBSDID("$FreeBSD$");
#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"
Re: RAND_MAX broken
On 02.07.2013 11:39, Bruce Evans wrote: > The bugs are a little different than I said above. There is no overflow > problem and no problem with invalid values being produces, since the > algorithm from ACM is careful to do everything with 32 bit signed > integers without causing overflow. The algorithm just doesn't produce > values mod 2**32 as expected by all the functions. It does what it > claims to do -- it produces values mod (2**32 - 1). The largest bug > is that RAND_MAX is off by 1. It is specified as the largest value > returned by rand(), but in FreeBSD rand() never returns it unless > USE_WEAK_SEEDING is confgured. The values should be unifornly > distributed on average beteen 0 and RAND_MAX,but that is impossible > if RADND_MAX is never returned. From libc/stdlib/srand.c: Don't ever consider USE_WEAK_SEEDING defined - result is distributet _very_ poorly and the code should be removed long time ago. BTW, I don't understand well fixes you suggest. Is it to define RAND_MAX as 0x7ffe ? -- http://ache.vniz.net/ bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N ___ 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: r252346 - head/share/man/man9
On 6/29/13 6:37 AM, Julian Elischer wrote: > On 6/29/13 9:16 PM, Julian Elischer wrote: >> thanks! >> >> >>> -If the owner is not currently actually running then the spin step is >>> skipped. >>> +then a thread attempting to acquire the mutex will spin rather than >>> yielding >>> +the processor. > Am I wrong in thinking that it will only spin for a short while, > eventually yielding? > > The original text said this but the new text implies it will spin forever. It does not use a spin timeout. I considered adding a separate note to define adaptive spinning generically as it is used by multiple lock types (mutexes, rwlocks, and sx locks). -- John Baldwin ___ 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: RAND_MAX broken
On Tue, 2 Jul 2013, Andrey Chernov wrote: On 02.07.2013 11:39, Bruce Evans wrote: The bugs are a little different than I said above. There is no overflow problem and no problem with invalid values being produces, since the algorithm from ACM is careful to do everything with 32 bit signed integers without causing overflow. The algorithm just doesn't produce values mod 2**32 as expected by all the functions. It does what it claims to do -- it produces values mod (2**32 - 1). The largest bug is that RAND_MAX is off by 1. It is specified as the largest value returned by rand(), but in FreeBSD rand() never returns it unless USE_WEAK_SEEDING is confgured. The values should be unifornly distributed on average beteen 0 and RAND_MAX,but that is impossible if RADND_MAX is never returned. From libc/stdlib/srand.c: Don't ever consider USE_WEAK_SEEDING defined - result is distributet _very_ poorly and the code should be removed long time ago. BTW, I don't understand well fixes you suggest. Is it to define RAND_MAX as 0x7ffe ? That would would be more correct. It might have compatibility problems. I checked the values returned by rand(). The ACM part works as intended, so it never returns RAND_MAX. It also never returns 0. So the distribution of values in the documented range [0, RAND_MAX] is very non-uniform. It is uniform in [1, RAND_MAX - 1]. To use this algorithm for rand(), 1 should have been subtracted, giving a range of [0, 0x7ffe]. In mathematical terms, the algorithm uses the (multiplicative) group of units in the field Z/(0x7fff.Z), but for rand() we want the values to be in the the additive group Z/(0x7ffe.Z). Subtracting 1 doesn't preserve the group operation but gives the right set of values. 0x7 is used because it is prime. 0x80001, 0x and 0x10001 are not prime, so the algorithm can't easily be modified to give the range [0, 0x7fff] or a 32-bit range. The most interesting prime near 2**31 or 2*32 is 2**32 - 5. 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: r252510 - head/sys/netinet
Author: hrs
Date: Tue Jul 2 16:39:12 2013
New Revision: 252510
URL: http://svnweb.freebsd.org/changeset/base/252510
Log:
Fix a panic when leaving MC group in a kernel with VIMAGE enabled.
in_leavegroup() is called from an asynchronous task, and
igmp_change_state() requires that curvnet is set by the caller.
Modified:
head/sys/netinet/in_mcast.c
Modified: head/sys/netinet/in_mcast.c
==
--- head/sys/netinet/in_mcast.c Tue Jul 2 14:54:18 2013(r252509)
+++ head/sys/netinet/in_mcast.c Tue Jul 2 16:39:12 2013(r252510)
@@ -1236,7 +1236,9 @@ in_leavegroup_locked(struct in_multi *in
KASSERT(error == 0, ("%s: failed to merge inm state", __func__));
CTR1(KTR_IGMPV3, "%s: doing igmp downcall", __func__);
+ CURVNET_SET(inm->inm_ifp->if_vnet);
error = igmp_change_state(inm);
+ CURVNET_RESTORE();
if (error)
CTR1(KTR_IGMPV3, "%s: failed igmp downcall", __func__);
___
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"
should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 03/06/2013 20:36 Konstantin Belousov said the following:
> Author: kib
> Date: Mon Jun 3 17:36:43 2013
> New Revision: 251322
> URL: http://svnweb.freebsd.org/changeset/base/251322
>
> Log:
> Be more generous when donating the current thread time to the owner of
> the vnode lock while iterating over the free vnode list. Instead of
> yielding, pause for 1 tick. The change is reported to help in some
> virtualized environments.
Kostik,
I've just run into a problem where word "generous" does not seem to be
applicable at all unless I am mistaken about how the code works.
There is a thread in vdropl() call that has a vnode interlock and want to take
vnode_free_list_mtx.
Then there is a thread that keeps cycling on the locked interlock while holding
vnode_free_list_mtx:
#0 cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1391
#1 0x80cc8e1d in ipi_nmi_handler () at
/usr/src/sys/amd64/amd64/mp_machdep.c:1373
#2 0x80cd6269 in trap (frame=0xff80002baf30) at
/usr/src/sys/amd64/amd64/trap.c:211
#3 0x80cbf86f in nmi_calltrap () at
/usr/src/sys/amd64/amd64/exception.S:501
#4 0x80924f22 in _mtx_trylock (m=0xfe00236f4c98, opts=0,
file=, line=0) at atomic.h:160
#5 0x809d3e5a in mnt_vnode_next_active (mvp=0xff86c95e4958,
mp=0xfe00118039a8) at /usr/src/sys/kern/vfs_subr.c:4813
#6 0x809daa86 in vfs_msync (mp=0xfe00118039a8, flags=2) at
/usr/src/sys/kern/vfs_subr.c:3542
#7 0x809e06ef in sys_sync (td=, uap=) at /usr/src/sys/kern/vfs_syscalls.c:149
#8 0x80cd515a in amd64_syscall (td=0xfe019d966490, traced=0) at
subr_syscall.c:135
#9 0x80cbf717 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:387
Now the curious part:
(kgdb) p td->td_swvoltick
$4 = 0
(kgdb) p td->td_ru.ru_nvcsw
$7 = 0
ticks happen to be in negative territory:
(kgdb) p ticks
$2 = -1946084020
Give this definition:
int
should_yield(void)
{
return (ticks - curthread->td_swvoltick >= hogticks);
}
We see that should_yield() is going to return false until ticks roll over to
become positive again. And obviously with the thread spinning on VI_TRYLOCK()
it's not going to get its td_swvoltick updated.
I am not sure if the originally reported problem was also caused by
should_yield() or if it was something else. But in either case I think that we
should fix should_yield. Perhaps (ticks - curthread->td_swvoltick) should be
cast to unsigned before comparison?
> Submitted by: Roger Pau Monn?
> Discussed with: jilles
> Tested by: pho
> MFC after: 2 weeks
>
> Modified:
> head/sys/kern/vfs_subr.c
>
> Modified: head/sys/kern/vfs_subr.c
> ==
> --- head/sys/kern/vfs_subr.c Mon Jun 3 17:36:26 2013(r251321)
> +++ head/sys/kern/vfs_subr.c Mon Jun 3 17:36:43 2013(r251322)
> @@ -4693,7 +4693,7 @@ restart:
> if (mp_ncpus == 1 || should_yield()) {
> TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist);
> mtx_unlock(&vnode_free_list_mtx);
> - kern_yield(PRI_USER);
> + pause("vnacti", 1);
> mtx_lock(&vnode_free_list_mtx);
> goto restart;
> }
>
--
Andriy Gapon
___
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: r252511 - in head/sys: net netinet6
Author: hrs
Date: Tue Jul 2 16:58:15 2013
New Revision: 252511
URL: http://svnweb.freebsd.org/changeset/base/252511
Log:
- Allow ND6_IFF_AUTO_LINKLOCAL for IFT_BRIDGE. An interface with IFT_BRIDGE
is initialized with !ND6_IFF_AUTO_LINKLOCAL && !ND6_IFF_ACCEPT_RTADV
regardless of net.inet6.ip6.accept_rtadv and net.inet6.ip6.auto_linklocal.
To configure an autoconfigured link-local address (RFC 4862), the
following rc.conf(5) configuration can be used:
ifconfig_bridge0_ipv6="inet6 auto_linklocal"
- if_bridge(4) now removes IPv6 addresses on a member interface to be
added when the parent interface or one of the existing member
interfaces has an IPv6 address. if_bridge(4) merges each link-local
scope zone which the member interfaces form respectively, so it causes
address scope violation. Removal of the IPv6 addresses prevents it.
- if_lagg(4) now removes IPv6 addresses on a member interfaces
unconditionally.
- Set reasonable flags to non-IPv6-capable interfaces. [*]
Submitted by: rpaulo [*]
MFC after:1 week
Modified:
head/sys/net/if_bridge.c
head/sys/net/if_lagg.c
head/sys/netinet6/in6.c
head/sys/netinet6/in6_ifattach.c
head/sys/netinet6/in6_var.h
head/sys/netinet6/nd6.c
Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cTue Jul 2 16:39:12 2013(r252510)
+++ head/sys/net/if_bridge.cTue Jul 2 16:58:15 2013(r252511)
@@ -118,6 +118,7 @@ __FBSDID("$FreeBSD$");
#ifdef INET6
#include
#include
+#include
#endif
#if defined(INET) || defined(INET6)
#include
@@ -1041,14 +1042,6 @@ bridge_ioctl_add(struct bridge_softc *sc
if (ifs->if_bridge != NULL)
return (EBUSY);
- bif = malloc(sizeof(*bif), M_DEVBUF, M_NOWAIT|M_ZERO);
- if (bif == NULL)
- return (ENOMEM);
-
- bif->bif_ifp = ifs;
- bif->bif_flags = IFBIF_LEARNING | IFBIF_DISCOVER;
- bif->bif_savedcaps = ifs->if_capenable;
-
switch (ifs->if_type) {
case IFT_ETHER:
case IFT_L2VLAN:
@@ -1056,20 +1049,94 @@ bridge_ioctl_add(struct bridge_softc *sc
/* permitted interface types */
break;
default:
- error = EINVAL;
- goto out;
+ return (EINVAL);
}
+#ifdef INET6
+ /*
+* Two valid inet6 addresses with link-local scope must not be
+* on the parent interface and the member interfaces at the
+* same time. This restriction is needed to prevent violation
+* of link-local scope zone. Attempts to add a member
+* interface which has inet6 addresses when the parent has
+* inet6 triggers removal of all inet6 addresses on the member
+* interface.
+*/
+
+ /* Check if the parent interface has a link-local scope addr. */
+ if (in6ifa_llaonifp(sc->sc_ifp) != NULL) {
+ /*
+* If any, remove all inet6 addresses from the member
+* interfaces.
+*/
+ BRIDGE_XLOCK(sc);
+ LIST_FOREACH(bif, &sc->sc_iflist, bif_next) {
+ if (in6ifa_llaonifp(bif->bif_ifp)) {
+ BRIDGE_UNLOCK(sc);
+ in6_ifdetach(bif->bif_ifp);
+ BRIDGE_LOCK(sc);
+ if_printf(sc->sc_ifp,
+ "IPv6 addresses on %s have been removed "
+ "before adding it as a member to prevent "
+ "IPv6 address scope violation.\n",
+ bif->bif_ifp->if_xname);
+ }
+ }
+ BRIDGE_XDROP(sc);
+ if (in6ifa_llaonifp(ifs)) {
+ BRIDGE_UNLOCK(sc);
+ in6_ifdetach(ifs);
+ BRIDGE_LOCK(sc);
+ if_printf(sc->sc_ifp,
+ "IPv6 addresses on %s have been removed "
+ "before adding it as a member to prevent "
+ "IPv6 address scope violation.\n",
+ ifs->if_xname);
+ }
+ } else {
+ struct in6_ifaddr *ia6_m, *ia6_s;
+ /*
+* If not, check whether one of the existing member
+* interfaces have inet6 address. If any, remove
+* inet6 addresses on the interface to be added.
+*/
+ BRIDGE_XLOCK(sc);
+ LIST_FOREACH(bif, &sc->sc_iflist, bif_next) {
+ ia6_m = in6ifa_llaonifp(bif->bif_ifp);
+ if (ia6_m != NULL)
+ break;
+ }
+ BRIDGE_XDROP(sc);
+ ia6_s = in6i
svn commit: r252512 - head/gnu/usr.bin/patch
Author: obrien
Date: Tue Jul 2 17:09:57 2013
New Revision: 252512
URL: http://svnweb.freebsd.org/changeset/base/252512
Log:
Make it so that 'patch < FUBAR' and 'patch -i FUBAR' operate the same.
The former makes a copy of stdin, but was not accurately putting the
content of stdin into a temp file. This lead to the undercounting
the number of lines in hunks containing NUL characters when reading
from stdin. Thus resulting in "unexpected end of file in patch" errors.
Modified:
head/gnu/usr.bin/patch/pch.c
Modified: head/gnu/usr.bin/patch/pch.c
==
--- head/gnu/usr.bin/patch/pch.cTue Jul 2 16:58:15 2013
(r252511)
+++ head/gnu/usr.bin/patch/pch.cTue Jul 2 17:09:57 2013
(r252512)
@@ -83,12 +83,17 @@ re_patch(void)
void
open_patch_file(char *filename)
{
+ int nr, nw;
+
if (filename == Nullch || !*filename || strEQ(filename, "-")) {
pfp = fopen(TMPPATNAME, "w");
if (pfp == Nullfp)
pfatal2("can't create %s", TMPPATNAME);
- while (fgets(buf, buf_size, stdin) != Nullch)
- fputs(buf, pfp);
+ while ((nr = fread(buf, 1, buf_size, stdin)) > 0) {
+ nw = fwrite(buf, 1, nr, pfp);
+ if (nr != nw)
+ pfatal2("write error to %s", TMPPATNAME);
+ }
Fclose(pfp);
filename = TMPPATNAME;
}
___
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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On Tue, Jul 2, 2013 at 6:48 PM, Andriy Gapon wrote: > on 03/06/2013 20:36 Konstantin Belousov said the following: >> Author: kib >> Date: Mon Jun 3 17:36:43 2013 >> New Revision: 251322 >> URL: http://svnweb.freebsd.org/changeset/base/251322 >> >> Log: >> Be more generous when donating the current thread time to the owner of >> the vnode lock while iterating over the free vnode list. Instead of >> yielding, pause for 1 tick. The change is reported to help in some >> virtualized environments. > > Kostik, > > I've just run into a problem where word "generous" does not seem to be > applicable at all unless I am mistaken about how the code works. While "ticks" is signed it is used as an unsigned int. td_swvolticks is always derived by ticks, which again will always be used as an unisgned and then the subtractions among the 2 will be consistent. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r252513 - head/gnu/usr.bin/patch
Author: obrien Date: Tue Jul 2 17:17:42 2013 New Revision: 252513 URL: http://svnweb.freebsd.org/changeset/base/252513 Log: Properly handle input lines containing NUL characters such that pgets() accurately fills the read buffer. Callers of pgets() still mis-process the buffer contents if the read line contains NUL characters, but this at least makes pgets() accurate. Modified: head/gnu/usr.bin/patch/pch.c Modified: head/gnu/usr.bin/patch/pch.c == --- head/gnu/usr.bin/patch/pch.cTue Jul 2 17:09:57 2013 (r252512) +++ head/gnu/usr.bin/patch/pch.cTue Jul 2 17:17:42 2013 (r252513) @@ -1181,7 +1181,7 @@ pgets(bool do_indent) indent++; } } - Strncpy(buf, line, len - skipped); + memcpy(buf, line, len - skipped); buf[len - skipped] = '\0'; } return len; ___ 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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 02/07/2013 20:12 Attilio Rao said the following: > While "ticks" is signed it is used as an unsigned int. > td_swvolticks is always derived by ticks, which again will always be > used as an unisgned and then the subtractions among the 2 will be > consistent. So returning to my example where ticks == -1946084020 and td_swvoltick == 0 and (ticks - td->td_swvoltick) == -1946084020. Is this consistent in your opinion? -- Andriy Gapon ___ 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: r252514 - head/sbin/swapon
Author: delphij
Date: Tue Jul 2 17:34:34 2013
New Revision: 252514
URL: http://svnweb.freebsd.org/changeset/base/252514
Log:
Plug a memory leak.
Modified:
head/sbin/swapon/swapon.c
Modified: head/sbin/swapon/swapon.c
==
--- head/sbin/swapon/swapon.c Tue Jul 2 17:17:42 2013(r252513)
+++ head/sbin/swapon/swapon.c Tue Jul 2 17:34:34 2013(r252514)
@@ -491,6 +491,7 @@ swap_on_off_md(const char *name, char *m
if (!qflag)
warnx("%s: Device already in use",
vnodefile);
+ free(vnodefile);
return (NULL);
}
error = run_cmd(&fd, "%s -a -t vnode -n -f %s",
@@ -498,6 +499,7 @@ swap_on_off_md(const char *name, char *m
if (error) {
warnx("mdconfig (attach) error: file=%s",
vnodefile);
+ free(vnodefile);
return (NULL);
}
sfd = fdopen(fd, "r");
@@ -537,6 +539,7 @@ swap_on_off_md(const char *name, char *m
if (!qflag)
warnx("md%d on %s: Device already "
"in use", mdunit, vnodefile);
+ free(vnodefile);
return (NULL);
}
error = run_cmd(NULL, "%s -a -t vnode -u %d -f %s",
@@ -544,6 +547,7 @@ swap_on_off_md(const char *name, char *m
if (error) {
warnx("mdconfig (attach) error: "
"md%d on file=%s", mdunit, vnodefile);
+ free(vnodefile);
return (NULL);
}
}
@@ -557,6 +561,7 @@ swap_on_off_md(const char *name, char *m
if (!qflag)
warnx("md on %s: Device not found",
vnodefile);
+ free(vnodefile);
return (NULL);
}
sfd = fdopen(fd, "r");
@@ -599,6 +604,7 @@ swap_on_off_md(const char *name, char *m
if (!qflag)
warnx("md%d on %s: Device not found",
mdunit, vnodefile);
+ free(vnodefile);
return (NULL);
}
}
@@ -622,6 +628,7 @@ err:
fclose(sfd);
if (fd != -1)
close(fd);
+ free(vnodefile);
return (ret);
}
___
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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On Tue, Jul 2, 2013 at 7:24 PM, Andriy Gapon wrote: > on 02/07/2013 20:12 Attilio Rao said the following: >> While "ticks" is signed it is used as an unsigned int. >> td_swvolticks is always derived by ticks, which again will always be >> used as an unisgned and then the subtractions among the 2 will be >> consistent. > > So returning to my example where ticks == -1946084020 and td_swvoltick == 0 > and > (ticks - td->td_swvoltick) == -1946084020. Is this consistent in your > opinion? I was just pointing out that the real bug is not in the subtraction itself but on the hogticks comparison. This is because hogticks is not an absolute measurement but it represents really a ticks difference. In my opinion we should define hogticks as an unsigned int and add a small comment saying that it is a differential. This will fix the issue. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On 2 July 2013 12:48, Andriy Gapon wrote: > I am not sure if the originally reported problem was also caused by > should_yield() or if it was something else. But in either case I think that > we > should fix should_yield. Perhaps (ticks - curthread->td_swvoltick) should be > cast to unsigned before comparison? What about just initializing td_swvoltick to ticks at td creation? ___ 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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 02/07/2013 20:52 Attilio Rao said the following: > I was just pointing out that the real bug is not in the subtraction > itself but on the hogticks comparison. > This is because hogticks is not an absolute measurement but it > represents really a ticks difference. > In my opinion we should define hogticks as an unsigned int and add a > small comment saying that it is a differential. > This will fix the issue. I think that my original suggestion is equivalently well if not more obvious. This is a common knowledge: http://en.wikipedia.org/wiki/Serial_number_arithmetic#General_Solution distance = (signed)( i1 - i2 ) -- Andriy Gapon ___ 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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 02/07/2013 20:59 Ed Maste said the following: > On 2 July 2013 12:48, Andriy Gapon wrote: >> I am not sure if the originally reported problem was also caused by >> should_yield() or if it was something else. But in either case I think that >> we >> should fix should_yield. Perhaps (ticks - curthread->td_swvoltick) should be >> cast to unsigned before comparison? > > What about just initializing td_swvoltick to ticks at td creation? I like this idea. Still I think that distance between two wrapping numbers should be calculated properly even if that mostly would not matter in practice. distance = (signed)( i1 - i2 ) -- Andriy Gapon ___ 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: r252515 - head/sys/ufs/ffs
Author: pfg
Date: Tue Jul 2 18:45:37 2013
New Revision: 252515
URL: http://svnweb.freebsd.org/changeset/base/252515
Log:
Style fix: spaces.
Cleanup the incomplete revert.
Reported by: bde
MFC after:4 weeks
Modified:
head/sys/ufs/ffs/ffs_vfsops.c
Modified: head/sys/ufs/ffs/ffs_vfsops.c
==
--- head/sys/ufs/ffs/ffs_vfsops.c Tue Jul 2 17:34:34 2013
(r252514)
+++ head/sys/ufs/ffs/ffs_vfsops.c Tue Jul 2 18:45:37 2013
(r252515)
@@ -1791,7 +1791,7 @@ ffs_vgetf(mp, ino, flags, vpp, ffs_flags
* already have one. This should only happen on old filesystems.
*/
if (ip->i_gen == 0) {
- ip->i_gen = arc4random()/2 + 1;
+ ip->i_gen = arc4random() / 2 + 1;
if ((vp->v_mount->mnt_flag & MNT_RDONLY) == 0) {
ip->i_flag |= IN_MODIFIED;
DIP_SET(ip, i_gen, ip->i_gen);
___
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: r252516 - head/usr.sbin/bsnmpd/modules/snmp_hast
Author: trociny
Date: Tue Jul 2 18:54:39 2013
New Revision: 252516
URL: http://svnweb.freebsd.org/changeset/base/252516
Log:
Add a mib for worker process ID.
MFC after:3 days
Modified:
head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt
head/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c
head/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def
Modified: head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt
==
--- head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Tue Jul 2
18:45:37 2013(r252515)
+++ head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Tue Jul 2
18:54:39 2013(r252516)
@@ -57,6 +57,9 @@ begemotHast MODULE-IDENTITY
REVISION "20130413Z"
DESCRIPTION
"Initial revision."
+REVISION "20130701Z"
+DESCRIPTION
+ "Added hastResourceWorkerPid."
::= { begemot 220 }
begemotHastObjects OBJECT IDENTIFIER ::= { begemotHast 1 }
@@ -116,7 +119,8 @@ HastResourceEntry ::= SEQUENCE {
hastResourceReadErrors Counter64,
hastResourceWriteErrorsCounter64,
hastResourceDeleteErrors Counter64,
-hastResourceFlushErrorsCounter64
+hastResourceFlushErrorsCounter64,
+hastResourceWorkerPid INTEGER
}
hastResourceIndex OBJECT-TYPE
@@ -295,4 +299,12 @@ hastResourceFlushErrors OBJECT-TYPE
"Count of resource local flush operations that failed."
::= { hastResourceEntry 21 }
+hastResourceWorkerPid OBJECT-TYPE
+SYNTAX INTEGER
+MAX-ACCESS read-write
+STATUS current
+DESCRIPTION
+ "Worker process ID."
+::= { hastResourceEntry 22 }
+
END
Modified: head/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c
==
--- head/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c Tue Jul 2 18:45:37
2013(r252515)
+++ head/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c Tue Jul 2 18:54:39
2013(r252516)
@@ -78,6 +78,7 @@ struct hast_snmp_resource {
uint64_twrite_errors;
uint64_tdelete_errors;
uint64_tflush_errors;
+ pid_t workerpid;
};
static TAILQ_HEAD(, hast_snmp_resource) resources =
@@ -343,6 +344,7 @@ update_resources(void)
nv_get_uint64(nvout, "stat_delete_error%u", i);
res->flush_errors =
nv_get_uint64(nvout, "stat_flush_error%u", i);
+ res->workerpid = nv_get_int32(nvout, "workerpid%u", i);
TAILQ_INSERT_TAIL(&resources, res, link);
}
nv_free(nvout);
@@ -498,6 +500,9 @@ op_hastResourceTable(struct snmp_context
case LEAF_hastResourceFlushErrors:
value->v.counter64 = res->flush_errors;
break;
+ case LEAF_hastResourceWorkerPid:
+ value->v.integer = res->workerpid;
+ break;
default:
ret = SNMP_ERR_RES_UNAVAIL;
break;
Modified: head/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def
==
--- head/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.defTue Jul 2
18:45:37 2013(r252515)
+++ head/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.defTue Jul 2
18:54:39 2013(r252516)
@@ -59,6 +59,7 @@
(19 hastResourceWriteErrors COUNTER64 GET)
(20 hastResourceDeleteErrors COUNTER64 GET)
(21 hastResourceFlushErrors COUNTER64 GET)
+ (22 hastResourceWorkerPid INTEGER GET)
)
)
)
___
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: r252522 - head/sys/arm/conf
Author: andrew Date: Tue Jul 2 19:35:04 2013 New Revision: 252522 URL: http://svnweb.freebsd.org/changeset/base/252522 Log: Enable VFP on Raspberry Pi. This has worked as of r251712. Modified: head/sys/arm/conf/RPI-B Modified: head/sys/arm/conf/RPI-B == --- head/sys/arm/conf/RPI-B Tue Jul 2 19:33:19 2013(r252521) +++ head/sys/arm/conf/RPI-B Tue Jul 2 19:35:04 2013(r252522) @@ -120,3 +120,6 @@ options FDT # handed to kernel via U-Boot and ubldr. #options FDT_DTB_STATIC makeoptions FDT_DTS_FILE=rpi.dts + +device vfp # vfp/neon +optionsARM_VFP_SUPPORT # vfp/neon ___ 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: r252523 - head/sbin/mdconfig
Author: delphij
Date: Tue Jul 2 19:42:47 2013
New Revision: 252523
URL: http://svnweb.freebsd.org/changeset/base/252523
Log:
When listing with -f, skip all memory disks that are not vnode-backed.
Noticed by: kevlo
MFC after:3 days
Modified:
head/sbin/mdconfig/mdconfig.c
Modified: head/sbin/mdconfig/mdconfig.c
==
--- head/sbin/mdconfig/mdconfig.c Tue Jul 2 19:35:04 2013
(r252522)
+++ head/sbin/mdconfig/mdconfig.c Tue Jul 2 19:42:47 2013
(r252523)
@@ -450,7 +450,8 @@ md_list(const char *units, int opt, cons
continue;
else
ffound = 1;
- }
+ } else if (fflag != NULL)
+ continue;
if (nflag && strncmp(pp->lg_name, MD_NAME, 2) == 0)
printf("%s", pp->lg_name + 2);
else
___
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: RAND_MAX broken
On 02.07.2013 20:33, Bruce Evans wrote: > I checked the values returned by rand(). The ACM part works as > intended, so it never returns RAND_MAX. It also never returns 0. So > the distribution of values in the documented range [0, RAND_MAX] is > very non-uniform. It is uniform in [1, RAND_MAX - 1]. To use this > algorithm for rand(), 1 should have been subtracted, giving a range > of [0, 0x7ffe]. Do you mean [0, 0x7ffd] (assuming 1 subtracted)? See attached patch. I don't see compatibility problems at least from POSIX specs point of view - they don't say something specific about RAND_MAX. -- http://ache.vniz.net/ bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N --- stdlib.h.bak2013-07-03 00:08:25.0 +0400 +++ stdlib.h2013-07-03 00:10:17.0 +0400 @@ -69,7 +69,7 @@ #defineEXIT_FAILURE1 #defineEXIT_SUCCESS0 -#defineRAND_MAX0x7fff +#defineRAND_MAX0x7ffd __BEGIN_DECLS #ifdef _XLOCALE_H_ --- rand.c.bak 2013-07-03 00:08:00.0 +0400 +++ rand.c 2013-07-03 00:11:33.0 +0400 @@ -75,7 +75,8 @@ x = 16807 * lo - 2836 * hi; if (x < 0) x += 0x7fff; - return ((*ctx = x) % ((u_long)RAND_MAX + 1)); + *ctx = x; + return (x - 1); #endif /* !USE_WEAK_SEEDING */ } ___ 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: r252526 - head/share/man/man4
Author: eadler Date: Tue Jul 2 20:25:58 2013 New Revision: 252526 URL: http://svnweb.freebsd.org/changeset/base/252526 Log: Remove extranious '.' Submitted by: swild...@dragonflybsd.org Modified: head/share/man/man4/oce.4 Modified: head/share/man/man4/oce.4 == --- head/share/man/man4/oce.4 Tue Jul 2 19:45:14 2013(r252525) +++ head/share/man/man4/oce.4 Tue Jul 2 20:25:58 2013(r252526) @@ -91,7 +91,7 @@ Firmware can be updated by following the .It Copy the below code to a Makefile: .Bd -literal -offset indent -\&.KMOD=elxflash +KMOD=elxflash FIRMWS=imagename.ufi:elxflash \&.include .Ed ___ 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: r252527 - head/sys/ufs/ffs
Author: mckusick
Date: Tue Jul 2 21:07:08 2013
New Revision: 252527
URL: http://svnweb.freebsd.org/changeset/base/252527
Log:
Make better use of metadata area by avoiding using it for data blocks
that no should no longer immediately follow their indirect blocks.
MFC after:2 weeks
Modified:
head/sys/ufs/ffs/ffs_alloc.c
head/sys/ufs/ffs/ffs_balloc.c
Modified: head/sys/ufs/ffs/ffs_alloc.c
==
--- head/sys/ufs/ffs/ffs_alloc.cTue Jul 2 20:25:58 2013
(r252526)
+++ head/sys/ufs/ffs/ffs_alloc.cTue Jul 2 21:07:08 2013
(r252527)
@@ -1710,7 +1710,7 @@ ffs_alloccgblk(ip, bp, bpref, size)
cgp = (struct cg *)bp->b_data;
blksfree = cg_blksfree(cgp);
if (bpref == 0) {
- bpref = cgp->cg_rotor;
+ bpref = cgbase(fs, cgp->cg_cgx) + cgp->cg_rotor + fs->fs_frag;
} else if ((cgbpref = dtog(fs, bpref)) != cgp->cg_cgx) {
/* map bpref to correct zone in this cg */
if (bpref < cgdata(fs, cgbpref))
Modified: head/sys/ufs/ffs/ffs_balloc.c
==
--- head/sys/ufs/ffs/ffs_balloc.c Tue Jul 2 20:25:58 2013
(r252526)
+++ head/sys/ufs/ffs/ffs_balloc.c Tue Jul 2 21:07:08 2013
(r252527)
@@ -299,6 +299,10 @@ retry:
continue;
}
UFS_LOCK(ump);
+ /*
+* If parent indirect has just been allocated, try to cluster
+* immediately following it.
+*/
if (pref == 0)
pref = ffs_blkpref_ufs1(ip, lbn, i - num - 1,
(ufs1_daddr_t *)0);
@@ -368,7 +372,14 @@ retry:
*/
if (nb == 0) {
UFS_LOCK(ump);
- if (pref == 0)
+ /*
+* If allocating metadata at the front of the cylinder
+* group and parent indirect block has just been allocated,
+* then cluster next to it if it is the first indirect in
+* the file. Otherwise it has been allocated in the metadata
+* area, so we want to find our own place out in the data area.
+*/
+ if (pref == 0 || (lbn > NDADDR && fs->fs_metaspace != 0))
pref = ffs_blkpref_ufs1(ip, lbn, indirs[i].in_off,
&bap[0]);
error = ffs_alloc(ip, lbn, pref, (int)fs->fs_bsize,
@@ -850,6 +861,10 @@ retry:
continue;
}
UFS_LOCK(ump);
+ /*
+* If parent indirect has just been allocated, try to cluster
+* immediately following it.
+*/
if (pref == 0)
pref = ffs_blkpref_ufs2(ip, lbn, i - num - 1,
(ufs2_daddr_t *)0);
@@ -920,7 +935,14 @@ retry:
*/
if (nb == 0) {
UFS_LOCK(ump);
- if (pref == 0)
+ /*
+* If allocating metadata at the front of the cylinder
+* group and parent indirect block has just been allocated,
+* then cluster next to it if it is the first indirect in
+* the file. Otherwise it has been allocated in the metadata
+* area, so we want to find our own place out in the data area.
+*/
+ if (pref == 0 || (lbn > NDADDR && fs->fs_metaspace != 0))
pref = ffs_blkpref_ufs2(ip, lbn, indirs[i].in_off,
&bap[0]);
error = ffs_alloc(ip, lbn, pref, (int)fs->fs_bsize,
___
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: r252516 - head/usr.sbin/bsnmpd/modules/snmp_hast
On Tue, Jul 02, 2013 at 06:54:39PM +, Mikolaj Golub wrote:
> Author: trociny
> Date: Tue Jul 2 18:54:39 2013
> New Revision: 252516
> URL: http://svnweb.freebsd.org/changeset/base/252516
> Log:
> Add a mib for worker process ID.
> MFC after: 3 days
> Modified:
> head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt
> head/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c
> head/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def
>
> Modified: head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt
> ==
> --- head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Tue Jul
> 2 18:45:37 2013(r252515)
> +++ head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Tue Jul
> 2 18:54:39 2013(r252516)
> @@ -57,6 +57,9 @@ begemotHast MODULE-IDENTITY
> [snip]
> @@ -295,4 +299,12 @@ hastResourceFlushErrors OBJECT-TYPE
> "Count of resource local flush operations that failed."
> ::= { hastResourceEntry 21 }
>
> +hastResourceWorkerPid OBJECT-TYPE
> +SYNTAX INTEGER
> +MAX-ACCESS read-write
I think MAX-ACCESS should be read-only here. The process ID is assigned
when the worker process is created and it makes no sense for a network
management system to change it.
> +STATUS current
> +DESCRIPTION
> + "Worker process ID."
> +::= { hastResourceEntry 22 }
> +
> END
--
Jilles Tjoelker
___
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: r252528 - head/sys/fs/nfsclient
Author: rmacklem
Date: Wed Jul 3 00:19:03 2013
New Revision: 252528
URL: http://svnweb.freebsd.org/changeset/base/252528
Log:
A problem with the old NFS client where large writes to large files
would sometimes result in a corrupted file was reported via email.
This problem appears to have been caused by r251719 (reverting
r251719 fixed the problem). Although I have not been able to
reproduce this problem, I suspect it is caused by another thread
increasing np->n_size after the mtx_unlock(&np->n_mtx) but before
the vnode_pager_setsize() call. Since the np->n_mtx mutex serializes
updates to np->n_size, doing the vnode_pager_setsize() with the
mutex locked appears to avoid the problem.
Unfortunately, vnode_pager_setsize() where the new size is smaller,
cannot be called with a mutex held.
This patch returns the semantics to be close to pre-r251719 (actually
pre-r248567, r248581, r248567 for the new client) such that the call to
vnode_pager_setsize() is only delayed until after the mutex is
unlocked when np->n_size is shrinking. Since the file is growing
when being written, I believe this will fix the corruption.
A better solution might be to replace the mutex with a sleep lock,
but that is a non-trivial conversion, so this fix is hoped to be
sufficient in the meantime.
Reported by: David G. Lawrence (d...@dglawrence.com)
Tested by:David G. Lawrence (to be done soon)
Reviewed by: kib
MFC after:1 week
Modified:
head/sys/fs/nfsclient/nfs_clport.c
Modified: head/sys/fs/nfsclient/nfs_clport.c
==
--- head/sys/fs/nfsclient/nfs_clport.c Tue Jul 2 21:07:08 2013
(r252527)
+++ head/sys/fs/nfsclient/nfs_clport.c Wed Jul 3 00:19:03 2013
(r252528)
@@ -433,6 +433,7 @@ nfscl_loadattrcache(struct vnode **vpp,
vap->va_size = np->n_size;
np->n_attrstamp = 0;
KDTRACE_NFS_ATTRCACHE_FLUSH_DONE(vp);
+ vnode_pager_setsize(vp, np->n_size);
} else if (np->n_flag & NMODIFIED) {
/*
* We've modified the file: Use the larger
@@ -444,12 +445,22 @@ nfscl_loadattrcache(struct vnode **vpp,
np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
}
+ vnode_pager_setsize(vp, np->n_size);
+ } else if (vap->va_size < np->n_size) {
+ /*
+* When shrinking the size, the call to
+* vnode_pager_setsize() cannot be done
+* with the mutex held, so delay it until
+* after the mtx_unlock call.
+*/
+ nsize = np->n_size = vap->va_size;
+ np->n_flag |= NSIZECHANGED;
+ setnsize = 1;
} else {
np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
+ vnode_pager_setsize(vp, np->n_size);
}
- setnsize = 1;
- nsize = vap->va_size;
} else {
np->n_size = vap->va_size;
}
___
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: r252527 - head/sys/ufs/ffs
On Tue, 2 Jul 2013, Kirk McKusick wrote:
Log:
Make better use of metadata area by avoiding using it for data blocks
that no should no longer immediately follow their indirect blocks.
I use the following changes for allocation at the start of cylinder group.
They seem to be related.
% diff -u2 ffs_alloc.c~ ffs_alloc.c
% --- ffs_alloc.c~ Sun Jun 20 12:53:30 2004
% +++ ffs_alloc.c Mon Jan 2 16:52:39 2012
% @@ -1010,5 +1062,6 @@
% * Select the desired position for the next block in a file. The file is
% * logically divided into sections. The first section is composed of the
% - * direct blocks. Each additional section contains fs_maxbpg blocks.
% + * direct blocks and the next fs_maxbpg blocks. Each additional section
% + * contains fs_maxbpg blocks.
% *
% * If no blocks have been allocated in the first section, the policy is to
% @@ -1022,12 +1075,11 @@
% * continues until a cylinder group with greater than the average number
% * of free blocks is found. If the allocation is for the first block in an
% - * indirect block, the information on the previous allocation is unavailable;
% + * indirect block or the previous block is a hole, then the information on
% + * the previous allocation is unavailable;
% * here a best guess is made based upon the logical block number being
% * allocated.
% *
% * If a section is already partially allocated, the policy is to
% - * contiguously allocate fs_maxcontig blocks. The end of one of these
% - * contiguous blocks and the beginning of the next is laid out
% - * contiguously if possible.
% + * allocate blocks contiguously within the section if possible.
% */
% ufs2_daddr_t
IIRC, the comments were out of date before this change. Especially the
final paragraph -- fs_maxcontig is not used for anything.
% @@ -1039,12 +1091,18 @@
% {
% struct fs *fs;
% - int cg;
% - int avgbfree, startcg;
% + int avgbfree, cg, firstsection, newsection, startcg;
BTW, I don't like changing the type of these variables to u_int in
-current. This asks for new sign extension bugs to break the warnings
about old ones. Even 16-bit signed int is almost large enough for cg,
so it is far from necessary to change it from signed to unsigned to
double its range.
%
% fs = ip->i_fs;
% - if (indx % fs->fs_maxbpg == 0 || bap[indx - 1] == 0) {
% - if (lbn < NDADDR + NINDIR(fs)) {
% + if (lbn < NDADDR + fs->fs_maxbpg) {
% + firstsection = 1;
% + newsection = 0;
% + } else {
% + firstsection = 0;
% + newsection = ((lbn - NDADDR) % fs->fs_maxbpg == 0);
% + }
% + if (indx == 0 || bap[indx - 1] == 0 || newsection) {
% + if (firstsection) {
% cg = ino_to_cg(fs, ip->i_number);
% - return (fs->fs_fpg * cg + fs->fs_frag);
% + return (cgdmin(fs, cg));
% }
% /*
% @@ -1052,8 +1110,17 @@
%* unused data blocks.
%*/
% - if (indx == 0 || bap[indx - 1] == 0)
% - startcg =
% - ino_to_cg(fs, ip->i_number) + lbn / fs->fs_maxbpg;
% - else
% + if (indx == 0 || bap[indx - 1] == 0) {
% + cg = ino_to_cg(fs, ip->i_number) +
% + (lbn - NDADDR) / fs->fs_maxbpg;
% + if (!newsection) {
% + /*
% + * Actually, use our best guess if the
% + * section is not new.
% + */
% + cg %= fs->fs_ncg;
% + return (cgdmin(fs, cg));
% + }
% + startcg = cg;
% + } else
% startcg = dtog(fs, bap[indx - 1]) + 1;
% startcg %= fs->fs_ncg;
% @@ -1062,16 +1129,13 @@
% if (fs->fs_cs(fs, cg).cs_nbfree >= avgbfree) {
% fs->fs_cgrotor = cg;
% - return (fs->fs_fpg * cg + fs->fs_frag);
% + return (cgdmin(fs, cg));
% }
% for (cg = 0; cg <= startcg; cg++)
% if (fs->fs_cs(fs, cg).cs_nbfree >= avgbfree) {
% fs->fs_cgrotor = cg;
% - return (fs->fs_fpg * cg + fs->fs_frag);
% + return (cgdmin(fs, cg));
% }
% return (0);
% }
% - /*
% - * We just always try to lay things out contiguously.
% - */
% return (bap[indx - 1] + fs->fs_frag);
% }
% @@ -1095,5 +1159,5 @@
% if (lbn < NDADDR + NINDIR(fs)) {
% cg = ino_to_cg(fs, ip->i_number);
% - return (fs->fs_fpg * cg + fs->fs_frag);
% + return (cgdmin(fs, cg));
% }
%
Re: svn commit: r252346 - head/share/man/man9
On 7/3/13 12:00 AM, John Baldwin wrote: On 6/29/13 6:37 AM, Julian Elischer wrote: On 6/29/13 9:16 PM, Julian Elischer wrote: thanks! -If the owner is not currently actually running then the spin step is skipped. +then a thread attempting to acquire the mutex will spin rather than yielding +the processor. Am I wrong in thinking that it will only spin for a short while, eventually yielding? The original text said this but the new text implies it will spin forever. It does not use a spin timeout. I considered adding a separate note to define adaptive spinning generically as it is used by multiple lock types (mutexes, rwlocks, and sx locks). this would be a good idea. ___ 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: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On Tue, 2 Jul 2013, Andriy Gapon wrote: on 02/07/2013 20:52 Attilio Rao said the following: I was just pointing out that the real bug is not in the subtraction itself but on the hogticks comparison. This is because hogticks is not an absolute measurement but it represents really a ticks difference. In my opinion we should define hogticks as an unsigned int and add a small comment saying that it is a differential. This will fix the issue. This is sort of backwards. hogticks is a small positive integer. Making it unsigned just asks for sign extension bugs when it is compared with signed values. However, the tick counters are circular counters. Making them signed asks for undefined behaviour when they overflow. I think that my original suggestion is equivalently well if not more obvious. This is a common knowledge: http://en.wikipedia.org/wiki/Serial_number_arithmetic#General_Solution distance = (signed)( i1 - i2 ) With 2's complement and benign overflow, this is no different from 'distance = i1 - i2'. But signed counters are not wanted here. A negative distance, or equivalently with 32-bit unsigned ints, an unsigned difference of >= 0x8000 means overflow or an initialization error. Your bug is an initialization error. BTW, -ftrapv is broken in gcc-4.2.1. It seems to have worked in gcc-3.3, but gcc-3.3 generates pessimal code for it, with a call to an extern function even for adding ints. gcc-4.2.1 still generates an declaration of the extern function, but never calls it. The declaration is unnecessary even when it is used. These bugs seem to be fixed in clang, at least on amd64. clang generates an explicit inline check for overflow and executes an unsupported instruction on overflow. The code for the check is good with -O but bad (large and slow) with -O0. These bugs are still large at the hardware level. Overflow checking is handled correctly on x86 only for floating point. In floating point, you can set or clear the mode bit for trapping on overflow, so that programs can be tested without recompiling them and without adding slow runtime checks (the hardware has to pipleline the checks well so that they have low cost). Hardware support for trapping on integer overflow keeps getting worse since programmers never check for overflow. i386 has an "into" instruction that should have been used instead of "jo foo" to check for overflow. It should have been easier for hardware to optimize than the branch. But AFAIK, "into" has never been optimized and has always been slower than the branch, so programmers never used it, so AMD removed it in 64-bit mode. Speed tests for incrementing a volatile local variable on corei7 in 32-bit mode: - -fno-trapv: 6.2 cycles (clang bug: warn about -fno-trapv being unused) - add into: 12.3 cycles (error handling is SIGBUS) - -ftrapv:6.7 cycles (error handling is SIGILL) - mod jo to into: 7.3 cycles (error handling is SIGBUS). 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: RAND_MAX broken
On Wed, 3 Jul 2013, Andrey Chernov wrote: On 02.07.2013 20:33, Bruce Evans wrote: I checked the values returned by rand(). The ACM part works as intended, so it never returns RAND_MAX. It also never returns 0. So the distribution of values in the documented range [0, RAND_MAX] is very non-uniform. It is uniform in [1, RAND_MAX - 1]. To use this algorithm for rand(), 1 should have been subtracted, giving a range of [0, 0x7ffe]. Do you mean [0, 0x7ffd] (assuming 1 subtracted)? Yes. See attached patch. I don't see compatibility problems at least from POSIX specs point of view - they don't say something specific about RAND_MAX. I like the patch. It is binary compatibility problems and maybe applications assuming that (RAND_MAX + 1) is 0x8000 so as to do magic bit operations with it that may be problems. 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: r252540 - head/usr.sbin/bsnmpd/modules/snmp_hast
Author: trociny Date: Wed Jul 3 05:54:23 2013 New Revision: 252540 URL: http://svnweb.freebsd.org/changeset/base/252540 Log: hastResourceWorkerPid is read-only. Submitted by: jilles MFC after:3 days Modified: head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Modified: head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt == --- head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Wed Jul 3 05:48:46 2013(r252539) +++ head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Wed Jul 3 05:54:23 2013(r252540) @@ -301,7 +301,7 @@ hastResourceFlushErrors OBJECT-TYPE hastResourceWorkerPid OBJECT-TYPE SYNTAX INTEGER -MAX-ACCESS read-write +MAX-ACCESS read-only STATUS current DESCRIPTION "Worker process ID." ___ 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: r252516 - head/usr.sbin/bsnmpd/modules/snmp_hast
On Tue, Jul 02, 2013 at 11:40:50PM +0200, Jilles Tjoelker wrote: > > +hastResourceWorkerPid OBJECT-TYPE > > +SYNTAX INTEGER > > +MAX-ACCESS read-write > > I think MAX-ACCESS should be read-only here. The process ID is assigned > when the worker process is created and it makes no sense for a network > management system to change it. Yes, it was intended to be read-only. Fixed. Thank you for spotting this. -- Mikolaj Golub ___ 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: r252514 - head/sbin/swapon
On Tue, Jul 02, 2013 at 05:34:35PM +, Xin LI wrote: > New Revision: 252514 > URL: http://svnweb.freebsd.org/changeset/base/252514 > > Log: > Plug a memory leak. Is MFC to stable/[89] applicable? If yes, can it be scheduled? ;-) ./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"
