svn commit: r252498 - head/sys/dev/usb

2013-07-02 Thread Rui Paulo
Author: rpaulo
Date: Tue Jul  2 06:49:05 2013
New Revision: 252498
URL: http://svnweb.freebsd.org/changeset/base/252498

Log:
  Add RealTek 8192SU product IDs.

Modified:
  head/sys/dev/usb/usbdevs

Modified: head/sys/dev/usb/usbdevs
==
--- head/sys/dev/usb/usbdevsTue Jul  2 04:45:51 2013(r252497)
+++ head/sys/dev/usb/usbdevsTue Jul  2 06:49:05 2013(r252498)
@@ -849,6 +849,7 @@ product ACCTON RT3070_2 0xa702  RT3070
 product ACCTON RT2870_10xb522  RT2870
 productACCTON RT3070_3 0xc522  RT3070
 productACCTON RT3070_5 0xd522  RT3070
+product ACCTON RTL8192SU0xc512  RTL8192SU
 product ACCTON ZD1211B 0xe501  ZD1211B
 
 /* Aceeca products */
@@ -1134,7 +1135,9 @@ product ASUS RT2870_4 0x1760  RT2870
 product ASUS RT2870_5  0x1761  RT2870
 productASUS USBN13 0x1784  USB-N13
 productASUS RT3070_1   0x1790  RT3070
+product ASUS USBN100x1786  USB-N10
 product ASUS RTL8192CU 0x17ab  RTL8192CU
+product ASUS RTL8192SU 0x1791  RTL8192SU
 product ASUS A730W 0x4202  ASUS MyPal A730W
 product ASUS P535  0x420f  ASUS P535 PDA
 productASUS GMSC   0x422f  ASUS Generic Mass Storage
@@ -1185,7 +1188,11 @@ product  AZUREWAVE RT3070_3  0x3305  RT3070
 product AZUREWAVE RTL8188CU0x3357  RTL8188CU
 product AZUREWAVE RTL8188CE_1  0x3358  RTL8188CE
 product AZUREWAVE RTL8188CE_2  0x3359  RTL8188CE
-
+product AZUREWAVE RTL8192SU_1  0x3306  RTL8192SU
+product AZUREWAVE RTL8192SU_2  0x3309  RTL8192SU
+product AZUREWAVE RTL8192SU_3  0x3310  RTL8192SU
+product AZUREWAVE RTL8192SU_4  0x3311  RTL8192SU
+product AZUREWAVE RTL8192SU_5  0x3325  RTL8192SU
 
 /* Baltech products */
 product BALTECH CARDREADER 0x  Card reader
@@ -1242,6 +1249,9 @@ product BELKIN F5D7050E   0x705e  F5D7050E
 product BELKIN RT2870_10x8053  RT2870
 product BELKIN RT2870_20x805c  RT2870
 product BELKIN F5D8053V3   0x815c  F5D8053 v3
+product BELKIN RTL8192SU_1 0x815f  RTL8192SU
+product BELKIN RTL8192SU_2 0x845a  RTL8192SU
+product BELKIN RTL8192SU_3 0x945a  RTL8192SU
 product BELKIN F5D8055 0x825a  F5D8055
 product BELKIN F5D8055V2   0x825b  F5D8055 v2
 product BELKIN F5D9050V3   0x905b  F5D9050 ver 3 Wireless Adapter
@@ -1368,6 +1378,9 @@ product CONCEPTRONIC AR5523_1 0x7801  AR5
 product CONCEPTRONIC AR5523_1_NF   0x7802  AR5523 (no firmware)
 product CONCEPTRONIC AR5523_2  0x7811  AR5523
 product CONCEPTRONIC AR5523_2_NF   0x7812  AR5523 (no firmware)
+product CONCEPTRONIC2 RTL8192SU_1  0x3300  RTL8192SU
+product CONCEPTRONIC2 RTL8192SU_2  0x3301  RTL8192SU
+product CONCEPTRONIC2 RTL8192SU_3  0x3302  RTL8192SU
 product CONCEPTRONIC2 C54RU0x3c02  C54RU WLAN
 product CONCEPTRONIC2 C54RU2   0x3c22  C54RU
 product CONCEPTRONIC2 RT3070_1 0x3c08  RT3070
@@ -1404,6 +1417,7 @@ product COREGA RT2870_2   0x003c  RT2870
 product COREGA RT2870_30x003f  RT2870
 product COREGA RT3070  0x0041  RT3070
 product COREGA CGWLUSB300GNM   0x0042  CG-WLUSB300GNM
+product COREGA RTL8192SU0x0047  RTL8192SU
 product COREGA RTL8192CU   0x0056  RTL8192CU
 
 product COREGA WLUSB_11_STICK  0x7613  WLAN USB Stick 11
@@ -1546,6 +1560,9 @@ product   DLINK RTL8192CU_1   0x3307  RTL8192
 productDLINK RTL8192CU_2   0x3309  RTL8192CU
 productDLINK RTL8192CU_3   0x330a  RTL8192CU
 productDLINK DWA131B   0x330d  DWA-131 rev B
+product DLINK2 RTL8192SU_1 0x3300  RTL8192SU
+product DLINK2 RTL8192SU_2 0x3302  RTL8192SU
+product DLINK2 DWA131A10x3303  DWA-131 A1
 product DLINK2 DWA120  0x3a0c  DWA-120
 product DLINK2 DWA120_NF   0x3a0d  DWA-120 (no firmware)
 product DLINK2 DWLG122C1   0x3c03  DWL-G122 c1
@@ -1582,6 +1599,9 @@ product DYNASTREAM ANTDEVBOARD2   0x1006  A
 
 /* Edimax products */
 product EDIMAX EW7318USG   0x7318  USB Wireless dongle
+product EDIMAX RTL8192SU_1 0x7611  RTL8192SU
+product EDIMAX RTL8192SU_2 0x7612  RTL8192SU
+product EDIMAX RTL8192SU_3 0x7622  RTL8192SU
 product EDIMAX RT2870_10x7711  RT2870
 product EDIMAX EW7717  0x7717  EW-7717
 product EDIMAX EW7718  0x7718  EW-7718
@@ -2075,6 +2095,8 @@ product GUILLEMOT HWGUSB254   0xe000  HWGUS
 product GUILLEMOT HWGUSB254LB  0xe010  HWGUSB2-54-LB
 product GUILLEMOT HWGUSB254V2AP0xe020  HWGUSB2-54V2-AP
 product GUILLEMOT HWNU300  0xe030  HWNU-300
+product GUILLEMOT HWNUM300 0xe031  HWNUm-300
+product GUILLEMOT HWGUN54  0xe032  HWGUn-54
 product GUILLEMOT HWNUP150 0xe033  HWNUP-150
 
 /* Hagiwara products */
@@ -2101,6 +2123,8 @@ product HAWKING HWUN2 0x0009  HWUN2
 product HAWKING RT3070 0x000b  

svn commit: r252499 - head/sys/powerpc/wii

2013-07-02 Thread Rui Paulo
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252500 - head/sys/powerpc/wii

2013-07-02 Thread Rui Paulo
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252501 - in head/sys/dev/usb: . quirk

2013-07-02 Thread Hiroki Sato
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252502 - head/sys/kern

2013-07-02 Thread Mateusz Guzik
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 latt...@gmail.com, 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


RAND_MAX broken (was: Re: svn commit: r252484 - head/sys/ufs/ffs)

2013-07-02 Thread Bruce Evans

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

2013-07-02 Thread Andrew Turner
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252504 - in head: share/man/man4 sys/modules/cc sys/modules/cc/cc_cdg sys/netinet/cc

2013-07-02 Thread Lawrence Stewart
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 david.hayes at ieee.org and
Grenville Armitage garmitage at swin edu au
  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 * 

svn commit: r252505 - head/sys/conf

2013-07-02 Thread Glen Barber
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 21 | 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252506 - head/sbin/dhclient

2013-07-02 Thread Bruce M Simpson
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 ip 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252508 - head/sbin/devd

2013-07-02 Thread Alan Somers
Author: asomers
Date: Tue Jul  2 14:48:39 2013
New Revision: 252508
URL: http://svnweb.freebsd.org/changeset/base/252508

Log:
  Explicitly include cstdarg 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 cstdio
 #include csignal
 #include cstring
+#include cstdarg
 
 #include dirent.h
 #include err.h
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: RAND_MAX broken

2013-07-02 Thread Andrey Chernov
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252346 - head/share/man/man9

2013-07-02 Thread John Baldwin
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: RAND_MAX broken

2013-07-02 Thread Bruce Evans

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252510 - head/sys/netinet

2013-07-02 Thread Hiroki Sato
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Andriy Gapon
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=value optimized out, 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=value optimized out, uap=value
optimized out) 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? roger@citrix.com
   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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252511 - in head/sys: net netinet6

2013-07-02 Thread Hiroki Sato
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 netinet/ip6.h
 #include netinet6/ip6_var.h
+#include netinet6/in6_ifattach.h
 #endif
 #if defined(INET) || defined(INET6)
 #include netinet/ip_carp.h
@@ -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;
+   }
+   

svn commit: r252512 - head/gnu/usr.bin/patch

2013-07-02 Thread David E. O'Brien
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Attilio Rao
On Tue, Jul 2, 2013 at 6:48 PM, Andriy Gapon a...@freebsd.org 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252513 - head/gnu/usr.bin/patch

2013-07-02 Thread David E. O'Brien
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Andriy Gapon
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252514 - head/sbin/swapon

2013-07-02 Thread Xin LI
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Attilio Rao
On Tue, Jul 2, 2013 at 7:24 PM, Andriy Gapon a...@freebsd.org 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Ed Maste
On 2 July 2013 12:48, Andriy Gapon a...@freebsd.org 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Andriy Gapon
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Andriy Gapon
on 02/07/2013 20:59 Ed Maste said the following:
 On 2 July 2013 12:48, Andriy Gapon a...@freebsd.org 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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252515 - head/sys/ufs/ffs

2013-07-02 Thread Pedro F. Giffuni
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252516 - head/usr.sbin/bsnmpd/modules/snmp_hast

2013-07-02 Thread Mikolaj Golub
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252517 - stable/9/sbin/hastd

2013-07-02 Thread Mikolaj Golub
Author: trociny
Date: Tue Jul  2 19:27:07 2013
New Revision: 252517
URL: http://svnweb.freebsd.org/changeset/base/252517

Log:
  MFC r248294, r248296:
  
  r248294 (pjd):
  
  Delete requests can be larger than MAXPHYS.
  
  r248296 (pjd):
  
  Minor corrections.

Modified:
  stable/9/sbin/hastd/hastd.8
  stable/9/sbin/hastd/secondary.c
Directory Properties:
  stable/9/sbin/hastd/   (props changed)

Modified: stable/9/sbin/hastd/hastd.8
==
--- stable/9/sbin/hastd/hastd.8 Tue Jul  2 18:54:39 2013(r252516)
+++ stable/9/sbin/hastd/hastd.8 Tue Jul  2 19:27:07 2013(r252517)
@@ -51,7 +51,7 @@ Only one machine (cluster node) can acti
 This machine is called primary.
 The
 .Nm
-daemon operates on block level, which makes it transparent for file
+daemon operates on block level, which makes it transparent to file
 systems and applications.
 .Pp
 There is one main
@@ -68,7 +68,7 @@ The exact format is:
 hastd: resource name (role)
 .Ed
 .Pp
-When (and only when)
+If (and only if)
 .Nm
 operates in primary role for the given resource, corresponding
 .Pa /dev/hast/name
@@ -77,8 +77,8 @@ File systems and applications can use th
 requests to.
 Every write, delete and flush operation
 .Dv ( BIO_WRITE , BIO_DELETE , BIO_FLUSH )
-is send to local component and synchronously replicated
-to the remote (secondary) node if it is available.
+is send to local component and replicated to the remote (secondary) node if it
+is available.
 Read operations
 .Dv ( BIO_READ )
 are handled locally unless I/O error occurs or local version of the data

Modified: stable/9/sbin/hastd/secondary.c
==
--- stable/9/sbin/hastd/secondary.c Tue Jul  2 18:54:39 2013
(r252516)
+++ stable/9/sbin/hastd/secondary.c Tue Jul  2 19:27:07 2013
(r252517)
@@ -582,7 +582,7 @@ requnpack(struct hast_resource *res, str
hio-hio_error = EINVAL;
goto end;
}
-   if (hio-hio_length  MAXPHYS) {
+   if (hio-hio_cmd != HIO_DELETE  hio-hio_length  MAXPHYS) {
pjdlog_error(Data length is too large (%ju  %ju).,
(uintmax_t)hio-hio_length, (uintmax_t)MAXPHYS);
hio-hio_error = EINVAL;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252514 - head/sbin/swapon

2013-07-02 Thread Florent Peterschmitt
Le 02/07/2013 19:34, Xin LI a écrit :
 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)

Hi,

Wouldn't be simpler to do a goto somewhere in the code to do the
free() and return(NULL) instead of copying those instructions at each case ?

It's just a question.

-- 
Florent Peterschmitt   | Please:
flor...@peterschmitt.fr|  * Avoid HTML/RTF in E-mail.
+33 (0)6 64 33 97 92   |  * Send PDF for documents.
http://florent.peterschmitt.fr | Thank you :)



signature.asc
Description: OpenPGP digital signature


svn commit: r252518 - stable/8/sbin/hastd

2013-07-02 Thread Mikolaj Golub
Author: trociny
Date: Tue Jul  2 19:28:16 2013
New Revision: 252518
URL: http://svnweb.freebsd.org/changeset/base/252518

Log:
  MFC r248294, r248296:
  
  r248294 (pjd):
  
  Delete requests can be larger than MAXPHYS.
  
  r248296 (pjd):
  
  Minor corrections.

Modified:
  stable/8/sbin/hastd/hastd.8
  stable/8/sbin/hastd/secondary.c
Directory Properties:
  stable/8/sbin/hastd/   (props changed)

Modified: stable/8/sbin/hastd/hastd.8
==
--- stable/8/sbin/hastd/hastd.8 Tue Jul  2 19:27:07 2013(r252517)
+++ stable/8/sbin/hastd/hastd.8 Tue Jul  2 19:28:16 2013(r252518)
@@ -51,7 +51,7 @@ Only one machine (cluster node) can acti
 This machine is called primary.
 The
 .Nm
-daemon operates on block level, which makes it transparent for file
+daemon operates on block level, which makes it transparent to file
 systems and applications.
 .Pp
 There is one main
@@ -68,7 +68,7 @@ The exact format is:
 hastd: resource name (role)
 .Ed
 .Pp
-When (and only when)
+If (and only if)
 .Nm
 operates in primary role for the given resource, corresponding
 .Pa /dev/hast/name
@@ -77,8 +77,8 @@ File systems and applications can use th
 requests to.
 Every write, delete and flush operation
 .Dv ( BIO_WRITE , BIO_DELETE , BIO_FLUSH )
-is send to local component and synchronously replicated
-to the remote (secondary) node if it is available.
+is send to local component and replicated to the remote (secondary) node if it
+is available.
 Read operations
 .Dv ( BIO_READ )
 are handled locally unless I/O error occurs or local version of the data

Modified: stable/8/sbin/hastd/secondary.c
==
--- stable/8/sbin/hastd/secondary.c Tue Jul  2 19:27:07 2013
(r252517)
+++ stable/8/sbin/hastd/secondary.c Tue Jul  2 19:28:16 2013
(r252518)
@@ -582,7 +582,7 @@ requnpack(struct hast_resource *res, str
hio-hio_error = EINVAL;
goto end;
}
-   if (hio-hio_length  MAXPHYS) {
+   if (hio-hio_cmd != HIO_DELETE  hio-hio_length  MAXPHYS) {
pjdlog_error(Data length is too large (%ju  %ju).,
(uintmax_t)hio-hio_length, (uintmax_t)MAXPHYS);
hio-hio_error = EINVAL;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252519 - stable/9/sbin/hastctl

2013-07-02 Thread Mikolaj Golub
Author: trociny
Date: Tue Jul  2 19:29:00 2013
New Revision: 252519
URL: http://svnweb.freebsd.org/changeset/base/252519

Log:
  MFC r248286 (pjd):
  
  Removed redundant includes.

Modified:
  stable/9/sbin/hastctl/hastctl.c
Directory Properties:
  stable/9/sbin/hastctl/   (props changed)

Modified: stable/9/sbin/hastctl/hastctl.c
==
--- stable/9/sbin/hastctl/hastctl.c Tue Jul  2 19:28:16 2013
(r252518)
+++ stable/9/sbin/hastctl/hastctl.c Tue Jul  2 19:29:00 2013
(r252519)
@@ -31,21 +31,11 @@
 __FBSDID($FreeBSD$);
 
 #include sys/param.h
-#include sys/disk.h
-#include sys/ioctl.h
-#include sys/stat.h
-#include sys/sysctl.h
 
 #include err.h
-#include errno.h
-#include fcntl.h
 #include libutil.h
-#include limits.h
-#include signal.h
 #include stdio.h
-#include stdlib.h
 #include string.h
-#include sysexits.h
 #include unistd.h
 
 #include activemap.h
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252520 - stable/8/sbin/hastctl

2013-07-02 Thread Mikolaj Golub
Author: trociny
Date: Tue Jul  2 19:29:45 2013
New Revision: 252520
URL: http://svnweb.freebsd.org/changeset/base/252520

Log:
  MFC r248286 (pjd):
  
  Removed redundant includes.

Modified:
  stable/8/sbin/hastctl/hastctl.c
Directory Properties:
  stable/8/sbin/hastctl/   (props changed)

Modified: stable/8/sbin/hastctl/hastctl.c
==
--- stable/8/sbin/hastctl/hastctl.c Tue Jul  2 19:29:00 2013
(r252519)
+++ stable/8/sbin/hastctl/hastctl.c Tue Jul  2 19:29:45 2013
(r252520)
@@ -31,21 +31,11 @@
 __FBSDID($FreeBSD$);
 
 #include sys/param.h
-#include sys/disk.h
-#include sys/ioctl.h
-#include sys/stat.h
-#include sys/sysctl.h
 
 #include err.h
-#include errno.h
-#include fcntl.h
 #include libutil.h
-#include limits.h
-#include signal.h
 #include stdio.h
-#include stdlib.h
 #include string.h
-#include sysexits.h
 #include unistd.h
 
 #include activemap.h
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252521 - svnadmin/conf

2013-07-02 Thread Gavin Atkinson
Author: gavin
Date: Tue Jul  2 19:33:19 2013
New Revision: 252521
URL: http://svnweb.freebsd.org/changeset/base/252521

Log:
  Take into safekeeping the following bits:
  
  anchie, ariff, daichi, darrenr, dd, eivind, flz, green, hmp, iedowse,
  jls, kmacy, kris, le, luoqi, markus, mbr, mlaier, motoyuki, mpp, mr,
  nork, pb, peadar, rik, rodrigc, rse, sam, sepotvin, simokawa, sson,
  ssouhlal, suz, syrinx, tanimura, ticso, weongyo, wes, wpaul.
  
  All have been idle in the src tree for some time, and have not responded
  to emails asking whether they are likely to become active again and so
  wish to retain their commit bit.  Remove them, and entries from
  conf/mentors where necessary.
  
  Thank you all for all your work in the past, and feel free to request
  your commit bit back should you find yourself able to contribute again
  in the future.
  
  Approved by:  core

Modified:
  svnadmin/conf/access
  svnadmin/conf/mentors

Modified: svnadmin/conf/access
==
--- svnadmin/conf/accessTue Jul  2 19:29:45 2013(r252520)
+++ svnadmin/conf/accessTue Jul  2 19:33:19 2013(r252521)
@@ -25,12 +25,10 @@ akiyama
 alc
 alfred
 ambrisko
-anchie
 andre
 andreast
 andrew
 antoine
-ariff
 asomers
 attilio
 avatar
@@ -54,15 +52,12 @@ cperciva
 cracauer
 csjp
 cy
-daichi
-darrenr
 das
 davidch
 davidcs
 davide
 davidxu
 dchagin
-dd
 deischen
 delphij
 des
@@ -75,7 +70,6 @@ dwmalone  dwmalone=freebsd-committers@mat
 eadler
 ed
 edwin
-eivind
 emaste
 emax
 eri
@@ -83,7 +77,6 @@ erwin
 fabient
 fanf
 fjoe
-flz
 gabor
 gad
 gallatin
@@ -96,17 +89,14 @@ gleb
 glebius
 gnn
 gonzo
-green
 grehan
 grog
 gshapiro   freebsd-cvs-committ...@g.gshapiro.net
 harti
 hiren
-hmp
 hrs
 hselasky
 ian
-iedowse
 imp
 ivoras
 iwasaki
@@ -124,7 +114,6 @@ jilles
 jimharris
 jkim
 jlh
-jls
 jmallett
 jmg
 joerg  freebsd-de...@uriah.heep.sax.de
@@ -140,21 +129,15 @@ kensmith
 kevlo
 kib
 kientzle
-kmacy
-kris
 kuriyama
-le
 lstewart
 luigi
-luoqi
 marcel
 marius
 markj
 markm
-markus
 mav
 maxim
-mbr
 mckay
 mckusick
 mdf
@@ -162,24 +145,17 @@ melifaro
 miwi
 mjacob
 mjg
-mlaier
 mm
 monthadar
-motoyuki
 mp
-mpp
-mr
 n_hibmadevnull
 neel
 netchild
-nork
 np
 nwhitehorn
 nyan
 obrien
 oleg
-pb
-peadar
 peter  pe...@wemm.org
 peterj
 pfg
@@ -194,45 +170,33 @@ raj
 ray
 rdivacky
 remko
-rik
 rmacklem
 rmh
 rnoland
 roberto
-rodrigc
 rpaulo
 rrs
-rse
 rstone
 ru
 rwatson bb+lists.freebsd.cvs-committ...@cyrus.watson.org
-sam
 sanpei
 sbruno
 scf
 schweikh
 scottl
 se
-sepotvin
 silby
-simokawa
 simon
 sjg
 smh
 sobomax
-sson
-ssouhlal
 stas
 stefanf
-suz
-syrinx
 syuu
 takawata
-tanimura
 theraven
 thomas
 thompsa
-ticso
 tijl
 trasz
 trhodes
@@ -244,12 +208,9 @@ upsups_...@stups.com
 uqs
 vanhu
 versus
-weongyo
-wes
 will
 wkoszek
 wollman
-wpaul
 yongari
 zec
 zont

Modified: svnadmin/conf/mentors
==
--- svnadmin/conf/mentors   Tue Jul  2 19:29:45 2013(r252520)
+++ svnadmin/conf/mentors   Tue Jul  2 19:33:19 2013(r252521)
@@ -11,7 +11,6 @@
 
 # Mentee   Mentor  Optional comment
 achim  scottl  Co-mentor: emaste
-anchie bz
 asomersken Co-mentor: gibbs, will
 benl   philip  Co-mentor: simon
 carl   jimharris
@@ -26,7 +25,6 @@ jonathan  rwatson
 jwdrmacklem
 miwi   rwatson
 monthadar  adrian
-nork   imp
 peterj jhb Co-mentor: grog
 snbdwmalone
 versus gavin   Co-mentor: fjoe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252522 - head/sys/arm/conf

2013-07-02 Thread Andrew Turner
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252523 - head/sbin/mdconfig

2013-07-02 Thread Xin LI
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252524 - stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2013-07-02 Thread Martin Matuska
Author: mm
Date: Tue Jul  2 19:44:02 2013
New Revision: 252524
URL: http://svnweb.freebsd.org/changeset/base/252524

Log:
  MFC r252380:
  Unbreak zfs jail and zfs unjail (broken in stable/9 since r249643)
  
  I missed to register zfs_ioc_jail and zfs_ioc_unjail as legacy ioctl's
  with the new zfs_ioctl_register_legacy() function.
  
  These operations do not modify pools or datasets so there is no need to
  log them to pool history.
  
  Reported by:  Alexander Leidinger netch...@freebsd.org on current@

Modified:
  stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
Directory Properties:
  stable/9/sys/   (props changed)
  stable/9/sys/cddl/contrib/opensolaris/   (props changed)

Modified: stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==
--- stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Tue Jul 
 2 19:42:47 2013(r252523)
+++ stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Tue Jul 
 2 19:44:02 2013(r252524)
@@ -5575,6 +5575,13 @@ zfs_ioctl_init(void)
zfs_ioctl_register_dataset_nolog(ZFS_IOC_TMP_SNAPSHOT,
zfs_ioc_tmp_snapshot, zfs_secpolicy_tmp_snapshot,
POOL_CHECK_SUSPENDED | POOL_CHECK_READONLY);
+
+#ifdef __FreeBSD__
+   zfs_ioctl_register_dataset_nolog(ZFS_IOC_JAIL, zfs_ioc_jail,
+   zfs_secpolicy_config, POOL_CHECK_NONE);
+   zfs_ioctl_register_dataset_nolog(ZFS_IOC_UNJAIL, zfs_ioc_unjail,
+   zfs_secpolicy_config, POOL_CHECK_NONE);
+#endif
 }
 
 int
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252525 - stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2013-07-02 Thread Martin Matuska
Author: mm
Date: Tue Jul  2 19:45:14 2013
New Revision: 252525
URL: http://svnweb.freebsd.org/changeset/base/252525

Log:
  MFC r252380:
  Unbreak zfs jail and zfs unjail (broken in stable/8 since r251757)
  
  I missed to register zfs_ioc_jail and zfs_ioc_unjail as legacy ioctl's
  with the new zfs_ioctl_register_legacy() function.
  
  These operations do not modify pools or datasets so there is no need to
  log them to pool history.
  
  Reported by:  Alexander Leidinger netch...@freebsd.org on current@

Modified:
  stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
Directory Properties:
  stable/8/sys/   (props changed)
  stable/8/sys/cddl/   (props changed)
  stable/8/sys/cddl/contrib/opensolaris/   (props changed)

Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==
--- stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Tue Jul 
 2 19:44:02 2013(r252524)
+++ stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Tue Jul 
 2 19:45:14 2013(r252525)
@@ -5575,6 +5575,13 @@ zfs_ioctl_init(void)
zfs_ioctl_register_dataset_nolog(ZFS_IOC_TMP_SNAPSHOT,
zfs_ioc_tmp_snapshot, zfs_secpolicy_tmp_snapshot,
POOL_CHECK_SUSPENDED | POOL_CHECK_READONLY);
+
+#ifdef __FreeBSD__
+   zfs_ioctl_register_dataset_nolog(ZFS_IOC_JAIL, zfs_ioc_jail,
+   zfs_secpolicy_config, POOL_CHECK_NONE);
+   zfs_ioctl_register_dataset_nolog(ZFS_IOC_UNJAIL, zfs_ioc_unjail,
+   zfs_secpolicy_config, POOL_CHECK_NONE);
+#endif
 }
 
 int
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: RAND_MAX broken

2013-07-02 Thread Andrey Chernov
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r252526 - head/share/man/man4

2013-07-02 Thread Eitan Adler
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 bsd.kmod.mk
 .Ed
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252527 - head/sys/ufs/ffs

2013-07-02 Thread Kirk McKusick
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252516 - head/usr.sbin/bsnmpd/modules/snmp_hast

2013-07-02 Thread Jilles Tjoelker
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252528 - head/sys/fs/nfsclient

2013-07-02 Thread Rick Macklem
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252527 - head/sys/ufs/ffs

2013-07-02 Thread Bruce Evans

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));
%   }
%   /*
% @@ 

svn commit: r252532 - stable/9/sys/kern

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 03:36:36 2013
New Revision: 252532
URL: http://svnweb.freebsd.org/changeset/base/252532

Log:
  When a previous call to sbsndptr() leaves sb-sb_sndptroff at the start of an
  mbuf that was fully consumed by the previous call, the mbuf ptr returned by 
the
  current call ends up being the previous mbuf in the sb chain to the one that
  contains the data we want.
  
  This does not cause any observable issues because the mbuf copy routines 
happily
  walk the mbuf chain to get to the data at the moff offset, which in this case
  means they effectively skip over the mbuf returned by sbsndptr().
  
  We can't adjust sb-sb_sndptr during the previous call for this case because 
the
  next mbuf in the chain may not exist yet. We therefore need to detect the
  condition and make the adjustment during the current call.
  
  Fix by detecting the special case of moff being at the start of the next mbuf 
in
  the chain and adjust the required accounting variables accordingly.
  
  Reviewed by:  andre

Modified:
  stable/9/sys/kern/uipc_sockbuf.c
Directory Properties:
  stable/9/sys/   (props changed)

Modified: stable/9/sys/kern/uipc_sockbuf.c
==
--- stable/9/sys/kern/uipc_sockbuf.cWed Jul  3 02:14:12 2013
(r252531)
+++ stable/9/sys/kern/uipc_sockbuf.cWed Jul  3 03:36:36 2013
(r252532)
@@ -939,6 +939,13 @@ sbsndptr(struct sockbuf *sb, u_int off, 
/* Return closest mbuf in chain for current offset. */
*moff = off - sb-sb_sndptroff;
m = ret = sb-sb_sndptr ? sb-sb_sndptr : sb-sb_mb;
+   if (*moff == m-m_len) {
+   *moff = 0;
+   sb-sb_sndptroff += m-m_len;
+   m = ret = m-m_next;
+   KASSERT(ret-m_len  0,
+   (mbuf %p in sockbuf %p chain has no valid data, ret, sb));
+   }
 
/* Advance by len to be as close as possible for the next transmit. */
for (off = off - sb-sb_sndptroff + len - 1;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252533 - stable/8/sys/kern

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 03:40:06 2013
New Revision: 252533
URL: http://svnweb.freebsd.org/changeset/base/252533

Log:
  When a previous call to sbsndptr() leaves sb-sb_sndptroff at the start of an
  mbuf that was fully consumed by the previous call, the mbuf ptr returned by 
the
  current call ends up being the previous mbuf in the sb chain to the one that
  contains the data we want.
  
  This does not cause any observable issues because the mbuf copy routines 
happily
  walk the mbuf chain to get to the data at the moff offset, which in this case
  means they effectively skip over the mbuf returned by sbsndptr().
  
  We can't adjust sb-sb_sndptr during the previous call for this case because 
the
  next mbuf in the chain may not exist yet. We therefore need to detect the
  condition and make the adjustment during the current call.
  
  Fix by detecting the special case of moff being at the start of the next mbuf 
in
  the chain and adjust the required accounting variables accordingly.
  
  Reviewed by:  andre

Modified:
  stable/8/sys/kern/uipc_sockbuf.c
Directory Properties:
  stable/8/sys/   (props changed)
  stable/8/sys/kern/   (props changed)

Modified: stable/8/sys/kern/uipc_sockbuf.c
==
--- stable/8/sys/kern/uipc_sockbuf.cWed Jul  3 03:36:36 2013
(r252532)
+++ stable/8/sys/kern/uipc_sockbuf.cWed Jul  3 03:40:06 2013
(r252533)
@@ -939,6 +939,13 @@ sbsndptr(struct sockbuf *sb, u_int off, 
/* Return closest mbuf in chain for current offset. */
*moff = off - sb-sb_sndptroff;
m = ret = sb-sb_sndptr ? sb-sb_sndptr : sb-sb_mb;
+   if (*moff == m-m_len) {
+   *moff = 0;
+   sb-sb_sndptroff += m-m_len;
+   m = ret = m-m_next;
+   KASSERT(ret-m_len  0,
+   (mbuf %p in sockbuf %p chain has no valid data, ret, sb));
+   }
 
/* Advance by len to be as close as possible for the next transmit. */
for (off = off - sb-sb_sndptroff + len - 1;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252346 - head/share/man/man9

2013-07-02 Thread Julian Elischer

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252534 - in stable/9/sys: kern sys

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 04:20:36 2013
New Revision: 252534
URL: http://svnweb.freebsd.org/changeset/base/252534

Log:
  MFC r251732,251752:
  
  Add support for non-virtualised hhook points, which are uniquely identified by
  type and id, as compared to virtualised hook points which are now uniquely
  identified by type, id and a vid (which for vimage is the pointer to the vnet
  that the hhook resides in).
  
  All hhook_head structs for both virtualised and non-virtualised hook points
  coexist in hhook_head_list, and a separate list is maintained for hhook points
  within each vnet to simplify some vimage-related housekeeping.
  
  Reviewed by:  scottl

Modified:
  stable/9/sys/kern/kern_hhook.c
  stable/9/sys/sys/hhook.h
Directory Properties:
  stable/9/sys/   (props changed)
  stable/9/sys/sys/   (props changed)

Modified: stable/9/sys/kern/kern_hhook.c
==
--- stable/9/sys/kern/kern_hhook.c  Wed Jul  3 03:40:06 2013
(r252533)
+++ stable/9/sys/kern/kern_hhook.c  Wed Jul  3 04:20:36 2013
(r252534)
@@ -61,8 +61,9 @@ struct hhook {
 static MALLOC_DEFINE(M_HHOOK, hhook, Helper hooks are linked off hhook_head 
lists);
 
 LIST_HEAD(hhookheadhead, hhook_head);
-VNET_DEFINE(struct hhookheadhead, hhook_head_list);
-#defineV_hhook_head_list VNET(hhook_head_list)
+struct hhookheadhead hhook_head_list;
+VNET_DEFINE(struct hhookheadhead, hhook_vhead_list);
+#defineV_hhook_vhead_list VNET(hhook_vhead_list)
 
 static struct mtx hhook_head_list_lock;
 MTX_SYSINIT(hhookheadlistlock, hhook_head_list_lock, hhook_head list lock,
@@ -245,13 +246,6 @@ hhook_head_register(int32_t hhook_type, 
return (EEXIST);
}
 
-   /* XXXLAS: Need to implement support for non-virtualised hooks. */
-   if ((flags  HHOOK_HEADISINVNET) == 0) {
-   printf(%s: only vnet-style virtualised hooks can be used\n,
-   __func__);
-   return (EINVAL);
-   }
-
tmphhh = malloc(sizeof(struct hhook_head), M_HHOOK,
M_ZERO | ((flags  HHOOK_WAITOK) ? M_WAITOK : M_NOWAIT));
 
@@ -270,14 +264,17 @@ hhook_head_register(int32_t hhook_type, 
} else
refcount_init(tmphhh-hhh_refcount, 0);
 
+   HHHLIST_LOCK();
if (flags  HHOOK_HEADISINVNET) {
tmphhh-hhh_flags |= HHH_ISINVNET;
-   HHHLIST_LOCK();
-   LIST_INSERT_HEAD(V_hhook_head_list, tmphhh, hhh_next);
-   HHHLIST_UNLOCK();
-   } else {
-   /* XXXLAS: Add tmphhh to the non-virtualised list. */
+#ifdef VIMAGE
+   KASSERT(curvnet != NULL, (curvnet is NULL));
+   tmphhh-hhh_vid = (uintptr_t)curvnet;
+   LIST_INSERT_HEAD(V_hhook_vhead_list, tmphhh, hhh_vnext);
+#endif
}
+   LIST_INSERT_HEAD(hhook_head_list, tmphhh, hhh_next);
+   HHHLIST_UNLOCK();
 
return (0);
 }
@@ -290,6 +287,10 @@ hhook_head_destroy(struct hhook_head *hh
HHHLIST_LOCK_ASSERT();
 
LIST_REMOVE(hhh, hhh_next);
+#ifdef VIMAGE
+   if (hhook_head_is_virtualised(hhh) == HHOOK_HEADISINVNET)
+   LIST_REMOVE(hhh, hhh_vnext);
+#endif
HHH_WLOCK(hhh);
STAILQ_FOREACH_SAFE(tmp, hhh-hhh_hooks, hhk_next, tmp2)
free(tmp, M_HHOOK);
@@ -347,10 +348,17 @@ hhook_head_get(int32_t hhook_type, int32
 {
struct hhook_head *hhh;
 
-   /* XXXLAS: Pick hhook_head_list based on hhook_head flags. */
HHHLIST_LOCK();
-   LIST_FOREACH(hhh, V_hhook_head_list, hhh_next) {
+   LIST_FOREACH(hhh, hhook_head_list, hhh_next) {
if (hhh-hhh_type == hhook_type  hhh-hhh_id == hhook_id) {
+#ifdef VIMAGE
+   if (hhook_head_is_virtualised(hhh) ==
+   HHOOK_HEADISINVNET) {
+   KASSERT(curvnet != NULL, (curvnet is NULL));
+   if (hhh-hhh_vid != (uintptr_t)curvnet)
+   continue;
+   }
+#endif
refcount_acquire(hhh-hhh_refcount);
break;
}
@@ -412,7 +420,7 @@ static void
 hhook_vnet_init(const void *unused __unused)
 {
 
-   LIST_INIT(V_hhook_head_list);
+   LIST_INIT(V_hhook_vhead_list);
 }
 
 /*
@@ -429,7 +437,7 @@ hhook_vnet_uninit(const void *unused __u
 * subsystem should have already called hhook_head_deregister().
 */
HHHLIST_LOCK();
-   LIST_FOREACH_SAFE(hhh, V_hhook_head_list, hhh_next, tmphhh) {
+   LIST_FOREACH_SAFE(hhh, V_hhook_vhead_list, hhh_vnext, tmphhh) {
printf(%s: hhook_head type=%d, id=%d cleanup required\n,
__func__, hhh-hhh_type, hhh-hhh_id);
hhook_head_destroy(hhh);
@@ -439,7 +447,7 @@ hhook_vnet_uninit(const void *unused __u
 
 
 /*
- * When a vnet is created and being initialised, init 

svn commit: r252535 - in stable/8/sys: kern sys

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 04:21:29 2013
New Revision: 252535
URL: http://svnweb.freebsd.org/changeset/base/252535

Log:
  MFC r251732,251752:
  
  Add support for non-virtualised hhook points, which are uniquely identified by
  type and id, as compared to virtualised hook points which are now uniquely
  identified by type, id and a vid (which for vimage is the pointer to the vnet
  that the hhook resides in).
  
  All hhook_head structs for both virtualised and non-virtualised hook points
  coexist in hhook_head_list, and a separate list is maintained for hhook points
  within each vnet to simplify some vimage-related housekeeping.
  
  Reviewed by:  scottl

Modified:
  stable/8/sys/kern/kern_hhook.c
  stable/8/sys/sys/hhook.h
Directory Properties:
  stable/8/sys/   (props changed)
  stable/8/sys/kern/   (props changed)
  stable/8/sys/sys/   (props changed)

Modified: stable/8/sys/kern/kern_hhook.c
==
--- stable/8/sys/kern/kern_hhook.c  Wed Jul  3 04:20:36 2013
(r252534)
+++ stable/8/sys/kern/kern_hhook.c  Wed Jul  3 04:21:29 2013
(r252535)
@@ -61,8 +61,9 @@ struct hhook {
 static MALLOC_DEFINE(M_HHOOK, hhook, Helper hooks are linked off hhook_head 
lists);
 
 LIST_HEAD(hhookheadhead, hhook_head);
-VNET_DEFINE(struct hhookheadhead, hhook_head_list);
-#defineV_hhook_head_list VNET(hhook_head_list)
+struct hhookheadhead hhook_head_list;
+VNET_DEFINE(struct hhookheadhead, hhook_vhead_list);
+#defineV_hhook_vhead_list VNET(hhook_vhead_list)
 
 static struct mtx hhook_head_list_lock;
 MTX_SYSINIT(hhookheadlistlock, hhook_head_list_lock, hhook_head list lock,
@@ -245,13 +246,6 @@ hhook_head_register(int32_t hhook_type, 
return (EEXIST);
}
 
-   /* XXXLAS: Need to implement support for non-virtualised hooks. */
-   if ((flags  HHOOK_HEADISINVNET) == 0) {
-   printf(%s: only vnet-style virtualised hooks can be used\n,
-   __func__);
-   return (EINVAL);
-   }
-
tmphhh = malloc(sizeof(struct hhook_head), M_HHOOK,
M_ZERO | ((flags  HHOOK_WAITOK) ? M_WAITOK : M_NOWAIT));
 
@@ -270,14 +264,17 @@ hhook_head_register(int32_t hhook_type, 
} else
refcount_init(tmphhh-hhh_refcount, 0);
 
+   HHHLIST_LOCK();
if (flags  HHOOK_HEADISINVNET) {
tmphhh-hhh_flags |= HHH_ISINVNET;
-   HHHLIST_LOCK();
-   LIST_INSERT_HEAD(V_hhook_head_list, tmphhh, hhh_next);
-   HHHLIST_UNLOCK();
-   } else {
-   /* XXXLAS: Add tmphhh to the non-virtualised list. */
+#ifdef VIMAGE
+   KASSERT(curvnet != NULL, (curvnet is NULL));
+   tmphhh-hhh_vid = (uintptr_t)curvnet;
+   LIST_INSERT_HEAD(V_hhook_vhead_list, tmphhh, hhh_vnext);
+#endif
}
+   LIST_INSERT_HEAD(hhook_head_list, tmphhh, hhh_next);
+   HHHLIST_UNLOCK();
 
return (0);
 }
@@ -290,6 +287,10 @@ hhook_head_destroy(struct hhook_head *hh
HHHLIST_LOCK_ASSERT();
 
LIST_REMOVE(hhh, hhh_next);
+#ifdef VIMAGE
+   if (hhook_head_is_virtualised(hhh) == HHOOK_HEADISINVNET)
+   LIST_REMOVE(hhh, hhh_vnext);
+#endif
HHH_WLOCK(hhh);
STAILQ_FOREACH_SAFE(tmp, hhh-hhh_hooks, hhk_next, tmp2)
free(tmp, M_HHOOK);
@@ -347,10 +348,17 @@ hhook_head_get(int32_t hhook_type, int32
 {
struct hhook_head *hhh;
 
-   /* XXXLAS: Pick hhook_head_list based on hhook_head flags. */
HHHLIST_LOCK();
-   LIST_FOREACH(hhh, V_hhook_head_list, hhh_next) {
+   LIST_FOREACH(hhh, hhook_head_list, hhh_next) {
if (hhh-hhh_type == hhook_type  hhh-hhh_id == hhook_id) {
+#ifdef VIMAGE
+   if (hhook_head_is_virtualised(hhh) ==
+   HHOOK_HEADISINVNET) {
+   KASSERT(curvnet != NULL, (curvnet is NULL));
+   if (hhh-hhh_vid != (uintptr_t)curvnet)
+   continue;
+   }
+#endif
refcount_acquire(hhh-hhh_refcount);
break;
}
@@ -412,7 +420,7 @@ static void
 hhook_vnet_init(const void *unused __unused)
 {
 
-   LIST_INIT(V_hhook_head_list);
+   LIST_INIT(V_hhook_vhead_list);
 }
 
 /*
@@ -429,7 +437,7 @@ hhook_vnet_uninit(const void *unused __u
 * subsystem should have already called hhook_head_deregister().
 */
HHHLIST_LOCK();
-   LIST_FOREACH_SAFE(hhh, V_hhook_head_list, hhh_next, tmphhh) {
+   LIST_FOREACH_SAFE(hhh, V_hhook_vhead_list, hhh_vnext, tmphhh) {
printf(%s: hhook_head type=%d, id=%d cleanup required\n,
__func__, hhh-hhh_type, hhh-hhh_id);
hhook_head_destroy(hhh);
@@ -439,7 +447,7 @@ hhook_vnet_uninit(const void *unused __u
 
 
 /*
- * When a vnet 

Re: svn commit: r252532 - stable/9/sys/kern

2013-07-02 Thread Lawrence Stewart
On 07/03/13 13:36, Lawrence Stewart wrote:
 Author: lstewart
 Date: Wed Jul  3 03:36:36 2013
 New Revision: 252532
 URL: http://svnweb.freebsd.org/changeset/base/252532
 
 Log:

MFC r251984:

   When a previous call to sbsndptr() leaves sb-sb_sndptroff at the start of 
 an
   mbuf that was fully consumed by the previous call, the mbuf ptr returned by 
 the
   current call ends up being the previous mbuf in the sb chain to the one that
   contains the data we want.
   
   This does not cause any observable issues because the mbuf copy routines 
 happily
   walk the mbuf chain to get to the data at the moff offset, which in this 
 case
   means they effectively skip over the mbuf returned by sbsndptr().
   
   We can't adjust sb-sb_sndptr during the previous call for this case 
 because the
   next mbuf in the chain may not exist yet. We therefore need to detect the
   condition and make the adjustment during the current call.
   
   Fix by detecting the special case of moff being at the start of the next 
 mbuf in
   the chain and adjust the required accounting variables accordingly.
   
   Reviewed by:andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252533 - stable/8/sys/kern

2013-07-02 Thread Lawrence Stewart
On 07/03/13 13:40, Lawrence Stewart wrote:
 Author: lstewart
 Date: Wed Jul  3 03:40:06 2013
 New Revision: 252533
 URL: http://svnweb.freebsd.org/changeset/base/252533
 
 Log:

MFC r251984:

   When a previous call to sbsndptr() leaves sb-sb_sndptroff at the start of 
 an
   mbuf that was fully consumed by the previous call, the mbuf ptr returned by 
 the
   current call ends up being the previous mbuf in the sb chain to the one that
   contains the data we want.
   
   This does not cause any observable issues because the mbuf copy routines 
 happily
   walk the mbuf chain to get to the data at the moff offset, which in this 
 case
   means they effectively skip over the mbuf returned by sbsndptr().
   
   We can't adjust sb-sb_sndptr during the previous call for this case 
 because the
   next mbuf in the chain may not exist yet. We therefore need to detect the
   condition and make the adjustment during the current call.
   
   Fix by detecting the special case of moff being at the start of the next 
 mbuf in
   the chain and adjust the required accounting variables accordingly.
   
   Reviewed by:andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]

2013-07-02 Thread Bruce Evans

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: RAND_MAX broken

2013-07-02 Thread Bruce Evans

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

2013-07-02 Thread Kenneth D. Merry
On Tue, Jul 02, 2013 at 07:53:33 +0200, Andre Albsmeier wrote:
 On Tue, 25-Jun-2013 at 23:43:50 +0200, Kenneth D. Merry wrote:
  Author: ken
  Date: Tue Jun 25 21:43:49 2013
  New Revision: 252214
  URL: http://svnweb.freebsd.org/changeset/base/252214
 
 Hi Ken,
 
  Log:
MFC: 249658, 249701
  
Update chio(1) and ch(4) to support reporting element designators.
  
This allows mapping a tape drive in a changer (as reported by
'chio status') to a sa(4) driver instance by comparing the
serial numbers.
  
The designators can be ASCII (which is printed out directly), binary
(which is printed in hex format) or UTF-8, which is printed in either
native UTF-8 format if the terminal can support it, or in %XX notation
for non-ASCII characters.  Thanks to Hiroki Sato hrs@ for the
explanation and example UTF-8 printing code.
  
chio.h:   Modify the changer_element_status structure to add 
  new
  fields and definitions from the SMC3r16 spec.
  
  Rename the original CHIOGSTATUS ioctl to OCHIOGTATUS and
  define a new CHIOGSTATUS ioctl.
  
  Clean up some tab/space issues.
  
chio.c:   For the 'status' subcommand, print the designator field
  if it is supplied by a device.
  
scsi_ch.h:Add new flags for DVCID and CURDATA to the READ
  ELEMENT STATUS command structure.
  
  Add a read_element_status_device_id structure
  for the data fields in the new standard. Add new
  unions, dt_or_obsolete and voltage_devid, to hold
  and address data from either SCSI-2 or newer devices.
  
scsi_ch.c:Implement support for fetching device IDs with READ
  ELEMENT STATUS data.
  
  Add new arguments to scsi_read_element_status() to
  allow the user to request the DVCID and CURDATA bits.
 
 This broke chio status when talking to my QUALSTAR TLS-8211 library:
 
 Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): READ ELEMENT 
 STATUS. CDB: b8 10 fd e8 00 01 03 00 04 00 00 00
 Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): CAM status: SCSI 
 Status Error
 Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI status: 
 Check Condition
 Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI sense: 
 ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
 Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Command byte 6 
 is invalid
 Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Error 22, 
 Unretryable error
 
 scsi_cmd-flags (Byte 6) must be zero for this library so I had to use
 this workaround to make it work again until a better solution is available:
 
 --- sys/cam/scsi/scsi_ch.c.ORI2013-06-26 13:38:54.0 +0200
 +++ sys/cam/scsi/scsi_ch.c2013-07-02 07:42:24.0 +0200
 @@ -1245,8 +1245,8 @@
/* tag_action */ MSG_SIMPLE_Q_TAG,
/* voltag */ want_voltags,
/* sea */ softc-sc_firsts[chet],
 -  /* dvcid */ 1,
 -  /* curdata */ 1,
 +  /* dvcid */ 0,
 +  /* curdata */ 0,
/* count */ 1,
/* data_ptr */ data,
/* dxfer_len */ 1024,
 @@ -1284,8 +1284,8 @@
/* voltag */ want_voltags,
/* sea */ softc-sc_firsts[chet]
+ cesr-cesr_element_base,
 -  /* dvcid */ 1,
 -  /* curdata */ 1,
 +  /* dvcid */ 0,
 +  /* curdata */ 0,
/* count */ cesr-cesr_element_count,
/* data_ptr */ data,
/* dxfer_len */ size,
 
   -Andre

Oops, sorry.

We need to check the SCSI version to see whether to set those bits, and
also fall back in case it doesn't work.

I am on vacation and have very spotty net access.  I can't do anything
about it until I get back next week.

Justin and Alan (CCed) can work on the fix, though.

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252536 - in stable/9/sys: kern sys

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 05:28:22 2013
New Revision: 252536
URL: http://svnweb.freebsd.org/changeset/base/252536

Log:
  MFC r251770:
  
  Internalise handling of virtualised hook points inside
  hhook_{add|remove}_hook_lookup() so that khelp (and other potential API
  consumers) do not have to care when they attempt to (un)hook a particular hook
  point identified by id and type.
  
  Reviewed by:  scottl

Modified:
  stable/9/sys/kern/kern_hhook.c
  stable/9/sys/kern/kern_khelp.c
  stable/9/sys/sys/hhook.h
Directory Properties:
  stable/9/sys/   (props changed)
  stable/9/sys/sys/   (props changed)

Modified: stable/9/sys/kern/kern_hhook.c
==
--- stable/9/sys/kern/kern_hhook.c  Wed Jul  3 04:21:29 2013
(r252535)
+++ stable/9/sys/kern/kern_hhook.c  Wed Jul  3 05:28:22 2013
(r252536)
@@ -1,5 +1,5 @@
 /*-
- * Copyright (c) 2010 Lawrence Stewart lstew...@freebsd.org
+ * Copyright (c) 2010,2013 Lawrence Stewart lstew...@freebsd.org
  * Copyright (c) 2010 The FreeBSD Foundation
  * All rights reserved.
  *
@@ -69,6 +69,9 @@ static struct mtx hhook_head_list_lock;
 MTX_SYSINIT(hhookheadlistlock, hhook_head_list_lock, hhook_head list lock,
 MTX_DEF);
 
+/* Protected by hhook_head_list_lock. */
+static uint32_t n_hhookheads;
+
 /* Private function prototypes. */
 static void hhook_head_destroy(struct hhook_head *hhh);
 
@@ -165,21 +168,71 @@ hhook_add_hook(struct hhook_head *hhh, s
 }
 
 /*
- * Lookup a helper hook point and register a new helper hook function with it.
+ * Register a helper hook function with a helper hook point (including all
+ * virtual instances of the hook point if it is virtualised).
+ *
+ * The logic is unfortunately far more complex than for
+ * hhook_remove_hook_lookup() because hhook_add_hook() can call malloc() with
+ * M_WAITOK and thus we cannot call hhook_add_hook() with the
+ * hhook_head_list_lock held.
+ *
+ * The logic assembles an array of hhook_head structs that correspond to the
+ * helper hook point being hooked and bumps the refcount on each (all done with
+ * the hhook_head_list_lock held). The hhook_head_list_lock is then dropped, 
and
+ * hhook_add_hook() is called and the refcount dropped for each hhook_head
+ * struct in the array.
  */
 int
 hhook_add_hook_lookup(struct hookinfo *hki, uint32_t flags)
 {
-   struct hhook_head *hhh;
-   int error;
+   struct hhook_head **heads_to_hook, *hhh;
+   int error, i, n_heads_to_hook;
 
-   hhh = hhook_head_get(hki-hook_type, hki-hook_id);
+tryagain:
+   error = i = 0;
+   /*
+* Accessing n_hhookheads without hhook_head_list_lock held opens up a
+* race with hhook_head_register() which we are unlikely to lose, but
+* nonetheless have to cope with - hence the complex goto logic.
+*/
+   n_heads_to_hook = n_hhookheads;
+   heads_to_hook = malloc(n_heads_to_hook * sizeof(struct hhook_head *),
+   M_HHOOK, flags  HHOOK_WAITOK ? M_WAITOK : M_NOWAIT);
+   if (heads_to_hook == NULL)
+   return (ENOMEM);
 
-   if (hhh == NULL)
-   return (ENOENT);
+   HHHLIST_LOCK();
+   LIST_FOREACH(hhh, hhook_head_list, hhh_next) {
+   if (hhh-hhh_type == hki-hook_type 
+   hhh-hhh_id == hki-hook_id) {
+   if (i  n_heads_to_hook) {
+   heads_to_hook[i] = hhh;
+   
refcount_acquire(heads_to_hook[i]-hhh_refcount);
+   i++;
+   } else {
+   /*
+* We raced with hhook_head_register() which
+* inserted a hhook_head that we need to hook
+* but did not malloc space for. Abort this run
+* and try again.
+*/
+   for (i--; i = 0; i--)
+   
refcount_release(heads_to_hook[i]-hhh_refcount);
+   free(heads_to_hook, M_HHOOK);
+   HHHLIST_UNLOCK();
+   goto tryagain;
+   }
+   }
+   }
+   HHHLIST_UNLOCK();
 
-   error = hhook_add_hook(hhh, hki, flags);
-   hhook_head_release(hhh);
+   for (i--; i = 0; i--) {
+   if (!error)
+   error = hhook_add_hook(heads_to_hook[i], hki, flags);
+   refcount_release(heads_to_hook[i]-hhh_refcount);
+   }
+
+   free(heads_to_hook, M_HHOOK);
 
return (error);
 }
@@ -211,20 +264,21 @@ hhook_remove_hook(struct hhook_head *hhh
 }
 
 /*
- * Lookup a helper hook point and remove a helper hook function from it.
+ * Remove a helper hook function from a helper hook point (including all
+ * virtual instances of the hook point if it 

svn commit: r252537 - in stable/8/sys: kern sys

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 05:29:21 2013
New Revision: 252537
URL: http://svnweb.freebsd.org/changeset/base/252537

Log:
  MFC r251770:
  
  Internalise handling of virtualised hook points inside
  hhook_{add|remove}_hook_lookup() so that khelp (and other potential API
  consumers) do not have to care when they attempt to (un)hook a particular hook
  point identified by id and type.
  
  Reviewed by:  scottl

Modified:
  stable/8/sys/kern/kern_hhook.c
  stable/8/sys/kern/kern_khelp.c
  stable/8/sys/sys/hhook.h
Directory Properties:
  stable/8/sys/   (props changed)
  stable/8/sys/kern/   (props changed)
  stable/8/sys/sys/   (props changed)

Modified: stable/8/sys/kern/kern_hhook.c
==
--- stable/8/sys/kern/kern_hhook.c  Wed Jul  3 05:28:22 2013
(r252536)
+++ stable/8/sys/kern/kern_hhook.c  Wed Jul  3 05:29:21 2013
(r252537)
@@ -1,5 +1,5 @@
 /*-
- * Copyright (c) 2010 Lawrence Stewart lstew...@freebsd.org
+ * Copyright (c) 2010,2013 Lawrence Stewart lstew...@freebsd.org
  * Copyright (c) 2010 The FreeBSD Foundation
  * All rights reserved.
  *
@@ -69,6 +69,9 @@ static struct mtx hhook_head_list_lock;
 MTX_SYSINIT(hhookheadlistlock, hhook_head_list_lock, hhook_head list lock,
 MTX_DEF);
 
+/* Protected by hhook_head_list_lock. */
+static uint32_t n_hhookheads;
+
 /* Private function prototypes. */
 static void hhook_head_destroy(struct hhook_head *hhh);
 
@@ -165,21 +168,71 @@ hhook_add_hook(struct hhook_head *hhh, s
 }
 
 /*
- * Lookup a helper hook point and register a new helper hook function with it.
+ * Register a helper hook function with a helper hook point (including all
+ * virtual instances of the hook point if it is virtualised).
+ *
+ * The logic is unfortunately far more complex than for
+ * hhook_remove_hook_lookup() because hhook_add_hook() can call malloc() with
+ * M_WAITOK and thus we cannot call hhook_add_hook() with the
+ * hhook_head_list_lock held.
+ *
+ * The logic assembles an array of hhook_head structs that correspond to the
+ * helper hook point being hooked and bumps the refcount on each (all done with
+ * the hhook_head_list_lock held). The hhook_head_list_lock is then dropped, 
and
+ * hhook_add_hook() is called and the refcount dropped for each hhook_head
+ * struct in the array.
  */
 int
 hhook_add_hook_lookup(struct hookinfo *hki, uint32_t flags)
 {
-   struct hhook_head *hhh;
-   int error;
+   struct hhook_head **heads_to_hook, *hhh;
+   int error, i, n_heads_to_hook;
 
-   hhh = hhook_head_get(hki-hook_type, hki-hook_id);
+tryagain:
+   error = i = 0;
+   /*
+* Accessing n_hhookheads without hhook_head_list_lock held opens up a
+* race with hhook_head_register() which we are unlikely to lose, but
+* nonetheless have to cope with - hence the complex goto logic.
+*/
+   n_heads_to_hook = n_hhookheads;
+   heads_to_hook = malloc(n_heads_to_hook * sizeof(struct hhook_head *),
+   M_HHOOK, flags  HHOOK_WAITOK ? M_WAITOK : M_NOWAIT);
+   if (heads_to_hook == NULL)
+   return (ENOMEM);
 
-   if (hhh == NULL)
-   return (ENOENT);
+   HHHLIST_LOCK();
+   LIST_FOREACH(hhh, hhook_head_list, hhh_next) {
+   if (hhh-hhh_type == hki-hook_type 
+   hhh-hhh_id == hki-hook_id) {
+   if (i  n_heads_to_hook) {
+   heads_to_hook[i] = hhh;
+   
refcount_acquire(heads_to_hook[i]-hhh_refcount);
+   i++;
+   } else {
+   /*
+* We raced with hhook_head_register() which
+* inserted a hhook_head that we need to hook
+* but did not malloc space for. Abort this run
+* and try again.
+*/
+   for (i--; i = 0; i--)
+   
refcount_release(heads_to_hook[i]-hhh_refcount);
+   free(heads_to_hook, M_HHOOK);
+   HHHLIST_UNLOCK();
+   goto tryagain;
+   }
+   }
+   }
+   HHHLIST_UNLOCK();
 
-   error = hhook_add_hook(hhh, hki, flags);
-   hhook_head_release(hhh);
+   for (i--; i = 0; i--) {
+   if (!error)
+   error = hhook_add_hook(heads_to_hook[i], hki, flags);
+   refcount_release(heads_to_hook[i]-hhh_refcount);
+   }
+
+   free(heads_to_hook, M_HHOOK);
 
return (error);
 }
@@ -211,20 +264,21 @@ hhook_remove_hook(struct hhook_head *hhh
 }
 
 /*
- * Lookup a helper hook point and remove a helper hook function from it.
+ * Remove a helper hook function from a helper hook point (including all
+ * 

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

2013-07-02 Thread Andre Albsmeier
On Wed, 03-Jul-2013 at 07:22:36 +0200, Kenneth D. Merry wrote:
 On Tue, Jul 02, 2013 at 07:53:33 +0200, Andre Albsmeier wrote:
  On Tue, 25-Jun-2013 at 23:43:50 +0200, Kenneth D. Merry wrote:
   Author: ken
   Date: Tue Jun 25 21:43:49 2013
   New Revision: 252214
   URL: http://svnweb.freebsd.org/changeset/base/252214
  
  Hi Ken,
  
   Log:
 MFC: 249658, 249701
   
 Update chio(1) and ch(4) to support reporting element designators.
   
 This allows mapping a tape drive in a changer (as reported by
 'chio status') to a sa(4) driver instance by comparing the
 serial numbers.
   
 The designators can be ASCII (which is printed out directly), binary
 (which is printed in hex format) or UTF-8, which is printed in either
 native UTF-8 format if the terminal can support it, or in %XX notation
 for non-ASCII characters.  Thanks to Hiroki Sato hrs@ for the
 explanation and example UTF-8 printing code.
   
 chio.h:   Modify the changer_element_status structure to 
   add new
   fields and definitions from the SMC3r16 spec.
   
   Rename the original CHIOGSTATUS ioctl to OCHIOGTATUS and
   define a new CHIOGSTATUS ioctl.
   
   Clean up some tab/space issues.
   
 chio.c:   For the 'status' subcommand, print the designator field
   if it is supplied by a device.
   
 scsi_ch.h:Add new flags for DVCID and CURDATA to the READ
   ELEMENT STATUS command structure.
   
   Add a read_element_status_device_id structure
   for the data fields in the new standard. Add new
   unions, dt_or_obsolete and voltage_devid, to hold
   and address data from either SCSI-2 or newer devices.
   
 scsi_ch.c:Implement support for fetching device IDs with READ
   ELEMENT STATUS data.
   
   Add new arguments to scsi_read_element_status() to
   allow the user to request the DVCID and CURDATA bits.
  
  This broke chio status when talking to my QUALSTAR TLS-8211 library:
  
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): READ ELEMENT 
  STATUS. CDB: b8 10 fd e8 00 01 03 00 04 00 00 00
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): CAM status: 
  SCSI Status Error
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI status: 
  Check Condition
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI sense: 
  ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Command byte 6 
  is invalid
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Error 22, 
  Unretryable error
  
  scsi_cmd-flags (Byte 6) must be zero for this library so I had to use
  this workaround to make it work again until a better solution is available:
  
  --- sys/cam/scsi/scsi_ch.c.ORI  2013-06-26 13:38:54.0 +0200
  +++ sys/cam/scsi/scsi_ch.c  2013-07-02 07:42:24.0 +0200
  @@ -1245,8 +1245,8 @@
   /* tag_action */ MSG_SIMPLE_Q_TAG,
   /* voltag */ want_voltags,
   /* sea */ softc-sc_firsts[chet],
  -/* dvcid */ 1,
  -/* curdata */ 1,
  +/* dvcid */ 0,
  +/* curdata */ 0,
   /* count */ 1,
   /* data_ptr */ data,
   /* dxfer_len */ 1024,
  @@ -1284,8 +1284,8 @@
   /* voltag */ want_voltags,
   /* sea */ softc-sc_firsts[chet]
   + cesr-cesr_element_base,
  -/* dvcid */ 1,
  -/* curdata */ 1,
  +/* dvcid */ 0,
  +/* curdata */ 0,
   /* count */ cesr-cesr_element_count,
   /* data_ptr */ data,
   /* dxfer_len */ size,
  
  -Andre
 
 Oops, sorry.
 
 We need to check the SCSI version to see whether to set those bits, and
 also fall back in case it doesn't work.
 
 I am on vacation and have very spotty net access.  I can't do anything
 about it until I get back next week.
 
 Justin and Alan (CCed) can work on the fix, though.

Take your time, for me it's working right now
with the above patch...

-Andre

 
 Ken
 -- 
 Kenneth Merry
 k...@freebsd.org
 

-- 
Linux: Sozialismus, der nicht funktioniert
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


svn commit: r252538 - stable/8/sys/kern

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 05:47:28 2013
New Revision: 252538
URL: http://svnweb.freebsd.org/changeset/base/252538

Log:
  MFC r251774:
  
  Add a private KPI between hhook and khelp that allows khelp modules to insert
  hook functions into hhook points which register after the modules were loaded 
-
  potentially useful during boot or if hhook points are dynamically registered.

Modified:
  stable/8/sys/kern/kern_hhook.c
  stable/8/sys/kern/kern_khelp.c
Directory Properties:
  stable/8/sys/   (props changed)
  stable/8/sys/kern/   (props changed)

Modified: stable/8/sys/kern/kern_hhook.c
==
--- stable/8/sys/kern/kern_hhook.c  Wed Jul  3 05:29:21 2013
(r252537)
+++ stable/8/sys/kern/kern_hhook.c  Wed Jul  3 05:47:28 2013
(r252538)
@@ -74,6 +74,7 @@ static uint32_t n_hhookheads;
 
 /* Private function prototypes. */
 static void hhook_head_destroy(struct hhook_head *hhh);
+void khelp_new_hhook_registered(struct hhook_head *hhh, uint32_t flags);
 
 #defineHHHLIST_LOCK() mtx_lock(hhook_head_list_lock)
 #defineHHHLIST_UNLOCK() mtx_unlock(hhook_head_list_lock)
@@ -311,12 +312,7 @@ hhook_head_register(int32_t hhook_type, 
tmphhh-hhh_nhooks = 0;
STAILQ_INIT(tmphhh-hhh_hooks);
HHH_LOCK_INIT(tmphhh);
-
-   if (hhh != NULL) {
-   refcount_init(tmphhh-hhh_refcount, 1);
-   *hhh = tmphhh;
-   } else
-   refcount_init(tmphhh-hhh_refcount, 0);
+   refcount_init(tmphhh-hhh_refcount, 1);
 
HHHLIST_LOCK();
if (flags  HHOOK_HEADISINVNET) {
@@ -331,6 +327,13 @@ hhook_head_register(int32_t hhook_type, 
n_hhookheads++;
HHHLIST_UNLOCK();
 
+   khelp_new_hhook_registered(tmphhh, flags);
+
+   if (hhh != NULL)
+   *hhh = tmphhh;
+   else
+   refcount_release(tmphhh-hhh_refcount);
+
return (0);
 }
 

Modified: stable/8/sys/kern/kern_khelp.c
==
--- stable/8/sys/kern/kern_khelp.c  Wed Jul  3 05:29:21 2013
(r252537)
+++ stable/8/sys/kern/kern_khelp.c  Wed Jul  3 05:47:28 2013
(r252538)
@@ -40,7 +40,6 @@ __FBSDID($FreeBSD$);
 #include sys/param.h
 #include sys/kernel.h
 #include sys/hhook.h
-#include sys/jail.h
 #include sys/khelp.h
 #include sys/lock.h
 #include sys/malloc.h
@@ -52,8 +51,6 @@ __FBSDID($FreeBSD$);
 #include sys/rwlock.h
 #include sys/systm.h
 
-#include net/vnet.h
-
 static struct rwlock khelp_list_lock;
 RW_SYSINIT(khelplistlock, khelp_list_lock, helper list lock);
 
@@ -61,6 +58,7 @@ static TAILQ_HEAD(helper_head, helper) h
 
 /* Private function prototypes. */
 static inline void khelp_remove_osd(struct helper *h, struct osd *hosd);
+void khelp_new_hhook_registered(struct hhook_head *hhh, uint32_t flags);
 
 #defineKHELP_LIST_WLOCK() rw_wlock(khelp_list_lock)
 #defineKHELP_LIST_WUNLOCK() rw_wunlock(khelp_list_lock)
@@ -289,6 +287,36 @@ khelp_remove_hhook(struct hookinfo *hki)
return (error);
 }
 
+/*
+ * Private KPI between hhook and khelp that allows khelp modules to insert hook
+ * functions into hhook points which register after the modules were loaded.
+ */
+void
+khelp_new_hhook_registered(struct hhook_head *hhh, uint32_t flags)
+{
+   struct helper *h;
+   int error, i;
+
+   KHELP_LIST_RLOCK();
+   TAILQ_FOREACH(h, helpers, h_next) {
+   for (i = 0; i  h-h_nhooks; i++) {
+   if (hhh-hhh_type != h-h_hooks[i].hook_type ||
+   hhh-hhh_id != h-h_hooks[i].hook_id)
+   continue;
+   error = hhook_add_hook(hhh, h-h_hooks[i], flags);
+   if (error) {
+   printf(%s: \%s\ khelp module unable to 
+   hook type %d id %d due to error %d\n,
+   __func__, h-h_name,
+   h-h_hooks[i].hook_type,
+   h-h_hooks[i].hook_id, error);
+   error = 0;
+   }
+   }
+   }
+   KHELP_LIST_RUNLOCK();
+}
+
 int
 khelp_modevent(module_t mod, int event_type, void *data)
 {
@@ -348,95 +376,3 @@ khelp_modevent(module_t mod, int event_t
 
return (error);
 }
-
-/*
- * This function is called in two separate situations:
- *
- * - When the kernel is booting, it is called directly by the SYSINIT framework
- * to allow Khelp modules which were compiled into the kernel or loaded by the
- * boot loader to insert their non-virtualised hook functions into the kernel.
- *
- * - When the kernel is booting or a vnet is created, this function is also
- * called indirectly through khelp_vnet_init() by the vnet initialisation code.
- * In this situation, Khelp modules are able to insert their virtualised 

svn commit: r252539 - stable/9/sys/kern

2013-07-02 Thread Lawrence Stewart
Author: lstewart
Date: Wed Jul  3 05:48:46 2013
New Revision: 252539
URL: http://svnweb.freebsd.org/changeset/base/252539

Log:
  MFC r251774:
  
  Add a private KPI between hhook and khelp that allows khelp modules to insert
  hook functions into hhook points which register after the modules were loaded 
-
  potentially useful during boot or if hhook points are dynamically registered.

Modified:
  stable/9/sys/kern/kern_hhook.c
  stable/9/sys/kern/kern_khelp.c
Directory Properties:
  stable/9/sys/   (props changed)

Modified: stable/9/sys/kern/kern_hhook.c
==
--- stable/9/sys/kern/kern_hhook.c  Wed Jul  3 05:47:28 2013
(r252538)
+++ stable/9/sys/kern/kern_hhook.c  Wed Jul  3 05:48:46 2013
(r252539)
@@ -74,6 +74,7 @@ static uint32_t n_hhookheads;
 
 /* Private function prototypes. */
 static void hhook_head_destroy(struct hhook_head *hhh);
+void khelp_new_hhook_registered(struct hhook_head *hhh, uint32_t flags);
 
 #defineHHHLIST_LOCK() mtx_lock(hhook_head_list_lock)
 #defineHHHLIST_UNLOCK() mtx_unlock(hhook_head_list_lock)
@@ -311,12 +312,7 @@ hhook_head_register(int32_t hhook_type, 
tmphhh-hhh_nhooks = 0;
STAILQ_INIT(tmphhh-hhh_hooks);
HHH_LOCK_INIT(tmphhh);
-
-   if (hhh != NULL) {
-   refcount_init(tmphhh-hhh_refcount, 1);
-   *hhh = tmphhh;
-   } else
-   refcount_init(tmphhh-hhh_refcount, 0);
+   refcount_init(tmphhh-hhh_refcount, 1);
 
HHHLIST_LOCK();
if (flags  HHOOK_HEADISINVNET) {
@@ -331,6 +327,13 @@ hhook_head_register(int32_t hhook_type, 
n_hhookheads++;
HHHLIST_UNLOCK();
 
+   khelp_new_hhook_registered(tmphhh, flags);
+
+   if (hhh != NULL)
+   *hhh = tmphhh;
+   else
+   refcount_release(tmphhh-hhh_refcount);
+
return (0);
 }
 

Modified: stable/9/sys/kern/kern_khelp.c
==
--- stable/9/sys/kern/kern_khelp.c  Wed Jul  3 05:47:28 2013
(r252538)
+++ stable/9/sys/kern/kern_khelp.c  Wed Jul  3 05:48:46 2013
(r252539)
@@ -40,7 +40,6 @@ __FBSDID($FreeBSD$);
 #include sys/param.h
 #include sys/kernel.h
 #include sys/hhook.h
-#include sys/jail.h
 #include sys/khelp.h
 #include sys/lock.h
 #include sys/malloc.h
@@ -52,8 +51,6 @@ __FBSDID($FreeBSD$);
 #include sys/rwlock.h
 #include sys/systm.h
 
-#include net/vnet.h
-
 static struct rwlock khelp_list_lock;
 RW_SYSINIT(khelplistlock, khelp_list_lock, helper list lock);
 
@@ -61,6 +58,7 @@ static TAILQ_HEAD(helper_head, helper) h
 
 /* Private function prototypes. */
 static inline void khelp_remove_osd(struct helper *h, struct osd *hosd);
+void khelp_new_hhook_registered(struct hhook_head *hhh, uint32_t flags);
 
 #defineKHELP_LIST_WLOCK() rw_wlock(khelp_list_lock)
 #defineKHELP_LIST_WUNLOCK() rw_wunlock(khelp_list_lock)
@@ -289,6 +287,36 @@ khelp_remove_hhook(struct hookinfo *hki)
return (error);
 }
 
+/*
+ * Private KPI between hhook and khelp that allows khelp modules to insert hook
+ * functions into hhook points which register after the modules were loaded.
+ */
+void
+khelp_new_hhook_registered(struct hhook_head *hhh, uint32_t flags)
+{
+   struct helper *h;
+   int error, i;
+
+   KHELP_LIST_RLOCK();
+   TAILQ_FOREACH(h, helpers, h_next) {
+   for (i = 0; i  h-h_nhooks; i++) {
+   if (hhh-hhh_type != h-h_hooks[i].hook_type ||
+   hhh-hhh_id != h-h_hooks[i].hook_id)
+   continue;
+   error = hhook_add_hook(hhh, h-h_hooks[i], flags);
+   if (error) {
+   printf(%s: \%s\ khelp module unable to 
+   hook type %d id %d due to error %d\n,
+   __func__, h-h_name,
+   h-h_hooks[i].hook_type,
+   h-h_hooks[i].hook_id, error);
+   error = 0;
+   }
+   }
+   }
+   KHELP_LIST_RUNLOCK();
+}
+
 int
 khelp_modevent(module_t mod, int event_type, void *data)
 {
@@ -348,95 +376,3 @@ khelp_modevent(module_t mod, int event_t
 
return (error);
 }
-
-/*
- * This function is called in two separate situations:
- *
- * - When the kernel is booting, it is called directly by the SYSINIT framework
- * to allow Khelp modules which were compiled into the kernel or loaded by the
- * boot loader to insert their non-virtualised hook functions into the kernel.
- *
- * - When the kernel is booting or a vnet is created, this function is also
- * called indirectly through khelp_vnet_init() by the vnet initialisation code.
- * In this situation, Khelp modules are able to insert their virtualised hook
- * functions into the virtualised 

svn commit: r252540 - head/usr.sbin/bsnmpd/modules/snmp_hast

2013-07-02 Thread Mikolaj Golub
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r252516 - head/usr.sbin/bsnmpd/modules/snmp_hast

2013-07-02 Thread Mikolaj Golub
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org