Re: faq/current.html: Mention sudo removal

2015-07-08 Thread Max Fillinger
On Sat, Jul 04, 2015 at 01:40:00PM +1000, Steven McDonald wrote:
 +sudo(8) has been removed from the base OS.
 +The old binaries and manual pages should be removed:
 +pre
 +   rm -f /usr/bin/sudo /usr/bin/sudoedit /usr/sbin/visudo
 +   rm -f /usr/share/man/man8/sudo.8 /usr/share/man/man8/sudoedit.8
 +   rm -f /usr/share/man/man8/visudo.8 /usr/share/man/man5/sudoers.5
 +/pre

There's also /usr/libexec/sudo_noexec.so



[patch] xlocale part 2: move current_categories from setlocale.c to locale_t

2015-07-08 Thread Sebastien Marie
Here a simple patch to move current_categories[][] array, that embed the
current locale names for each categories (LC_CTYPE, LC_MESSAGES, LC_..),
from global static variable in locale/setlocale.c to the struct _locale_t.

All the logic is to move the reference of static global variable to
global state locale, as setlocale(1) function only operate on global
state.

Later patches will change slightly that to reuse code for creating new
locale state.

-- 
Sebastien Marie


Index: b/lib/libc/locale/setlocale.c
===
--- a/lib/libc/locale/setlocale.c   2015-07-04 12:04:02.003065887 +0200
+++ b/lib/libc/locale/setlocale.c   2015-07-04 14:04:40.894950518 +0200
@@ -42,6 +42,8 @@
 
 #include rune.h
 #include rune_local.h
+#include xlocale_private.h
+
 /*
  * Category names for getenv()
  */
@@ -55,19 +57,6 @@
 LC_MESSAGES
 };
 
-/*
- * Current locales for each category
- */
-static char current_categories[_LC_LAST][32] = {
-C,
-C,
-C,
-C,
-C,
-C,
-C
-};
-
 static char current_locale_string[_LC_LAST * 33];
 
 static char*currentlocale(void);
@@ -89,13 +78,15 @@
 
if (!locale)
return (category ?
-   current_categories[category] : currentlocale());
+   _lc_global_locale.categories[category]
+   : currentlocale());
 
/*
 * Default to the current locale for everything.
 */
for (i = 1; i  _LC_LAST; ++i)
-   (void)strlcpy(new_categories[i], current_categories[i],
+   (void)strlcpy(new_categories[i],
+   _lc_global_locale.categories[i],
sizeof(new_categories[i]));
 
/*
@@ -172,16 +163,21 @@
 {
int i;
 
-   (void)strlcpy(current_locale_string, current_categories[1],
+   (void)strlcpy(current_locale_string,
+   _lc_global_locale.categories[1],
sizeof(current_locale_string));
 
for (i = 2; i  _LC_LAST; ++i)
-   if (strcmp(current_categories[1], current_categories[i])) {
+   if (strcmp(_lc_global_locale.categories[1],
+  _lc_global_locale.categories[i])) {
(void)snprintf(current_locale_string,
sizeof(current_locale_string), %s/%s/%s/%s/%s/%s,
-   current_categories[1], current_categories[2],
-   current_categories[3], current_categories[4],
-   current_categories[5], current_categories[6]);
+   _lc_global_locale.categories[1],
+   _lc_global_locale.categories[2],
+   _lc_global_locale.categories[3],
+   _lc_global_locale.categories[4],
+   _lc_global_locale.categories[5],
+   _lc_global_locale.categories[6]);
break;
}
return (current_locale_string);
@@ -269,13 +265,14 @@
 static char *
 loadlocale(int category, const char *locname)
 {
-   if (strcmp(locname, current_categories[category]) == 0)
-   return (current_categories[category]);
+   if (strcmp(locname, _lc_global_locale.categories[category]) == 0)
+   return (_lc_global_locale.categories[category]);
 
if (!load_locale_sub(category, locname)) {
-   (void)strlcpy(current_categories[category],
-   locname, sizeof(current_categories[category]));
-   return current_categories[category];
+   (void)strlcpy(_lc_global_locale.categories[category],
+   locname,
+   sizeof(_lc_global_locale.categories[category]));
+   return _lc_global_locale.categories[category];
} else {
return NULL;
}
Index: b/lib/libc/locale/xlocale.c
===
--- a/lib/libc/locale/xlocale.c 2015-07-04 14:00:24.042939553 +0200
+++ b/lib/libc/locale/xlocale.c 2015-07-04 14:05:26.015229706 +0200
@@ -24,7 +24,8 @@
  * hold the global state
  */
 struct _locale_t _lc_global_locale = {
-   XLOCALE_INSTALLED
+   XLOCALE_INSTALLED,
+   {C, C, C, C, C, C, C}
 };
 
 
Index: b/lib/libc/locale/xlocale_private.h
===
--- a/lib/libc/locale/xlocale_private.h 2015-07-04 12:04:02.003065887 +0200
+++ b/lib/libc/locale/xlocale_private.h 2015-07-04 14:04:40.904950281 +0200
@@ -18,9 +18,11 @@
 #define _XLOCALE_PRIVATE_H_
 
 #include sys/cdefs.h
+#include locale.h
 
 struct _locale_t {
int flags;
+   charcategories[_LC_LAST][32];
 };
 
 #define XLOCALE_INSTALLED(1  0)



Unused arguments in nd6_nud_hint()

2015-07-08 Thread Martin Pieuchot
I'd like to remove unused/NULL arguments from nd6_nud_hint() in order to
get rid of a nd6_lookup().

Ok?

Index: netinet/tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.293
diff -u -p -r1.293 tcp_input.c
--- netinet/tcp_input.c 16 Jun 2015 11:09:40 -  1.293
+++ netinet/tcp_input.c 8 Jul 2015 08:59:08 -
@@ -146,7 +146,7 @@ struct timeval tcp_ackdrop_ppslim_last;
 do { \
if (tp  tp-t_inpcb  (tp-t_inpcb-inp_flags  INP_IPV6)  \
tp-t_inpcb-inp_route6.ro_rt) { \
-   nd6_nud_hint(tp-t_inpcb-inp_route6.ro_rt, NULL, 0, \
+   nd6_nud_hint(tp-t_inpcb-inp_route6.ro_rt, \
tp-t_inpcb-inp_rtableid); \
} \
 } while (0)
Index: netinet6/nd6.c
===
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.139
diff -u -p -r1.139 nd6.c
--- netinet6/nd6.c  16 Jun 2015 11:09:40 -  1.139
+++ netinet6/nd6.c  8 Jul 2015 08:59:08 -
@@ -891,20 +891,12 @@ nd6_free(struct rtentry *rt, int gc)
  * XXX cost-effective methods?
  */
 void
-nd6_nud_hint(struct rtentry *rt, struct in6_addr *dst6, int force,
-u_int rtableid)
+nd6_nud_hint(struct rtentry *rt, u_int rtableid)
 {
struct llinfo_nd6 *ln;
 
-   /*
-* If the caller specified rt, use that.  Otherwise, resolve the
-* routing table by supplied dst6.
-*/
-   if (!rt) {
-   if (!dst6)
-   return;
-   if (!(rt = nd6_lookup(dst6, 0, NULL, rtableid)))
-   return;
+   if (rt == NULL) {
+   return;
}
 
if ((rt-rt_flags  RTF_GATEWAY) != 0 ||
@@ -923,11 +915,9 @@ nd6_nud_hint(struct rtentry *rt, struct 
 * if we get upper-layer reachability confirmation many times,
 * it is possible we have false information.
 */
-   if (!force) {
-   ln-ln_byhint++;
-   if (ln-ln_byhint  nd6_maxnudhint)
-   return;
-   }
+   ln-ln_byhint++;
+   if (ln-ln_byhint  nd6_maxnudhint)
+   return;
 
ln-ln_state = ND6_LLINFO_REACHABLE;
if (!ND6_LLINFO_PERMANENT(ln)) {
Index: netinet6/nd6.h
===
RCS file: /cvs/src/sys/netinet6/nd6.h,v
retrieving revision 1.41
diff -u -p -r1.41 nd6.h
--- netinet6/nd6.h  20 Nov 2014 13:54:24 -  1.41
+++ netinet6/nd6.h  8 Jul 2015 08:59:08 -
@@ -276,7 +276,7 @@ void nd6_setmtu(struct ifnet *);
 void nd6_llinfo_settimer(struct llinfo_nd6 *, long);
 void nd6_timer(void *);
 void nd6_purge(struct ifnet *);
-void nd6_nud_hint(struct rtentry *, struct in6_addr *, int, u_int);
+void nd6_nud_hint(struct rtentry *, u_int);
 int nd6_resolve(struct ifnet *, struct rtentry *,
struct mbuf *, struct sockaddr *, u_char *);
 void nd6_rtrequest(int, struct rtentry *);



Re: Add 5th gen Intel HD Graphics (GT1)

2015-07-08 Thread Jonathan Gray
On Wed, Jul 08, 2015 at 09:48:36AM +0200, Mark Patruck wrote:
 Intel HD Graphics (GT1) found on the 5th gen Broadwells.
 
 We already have the bigger ones but the smallest GT1 with 12EUs
 is missing. Test on my board OK (no drm right now of course)

I was hoping marketing names would appear for the others as well.

Currently we have:

product INTEL CORE5G_M_GT2_10x1616  HD Graphics 5500
product INTEL CORE5G_M_GT2_20x161e  HD Graphics 5300
product INTEL CORE5G_M_GT3_15W  0x1626  HD Graphics 6000
product INTEL CORE5G_M_GT3_28W  0x162b  Iris Graphics 6100

The latest xf86-video-intel further mentions the following
including the id you have (src/intel_module.c)

{0x1602, HD Graphics},
{0x1606, HD Graphics},
{0x160B, HD Graphics},
{0x160A, HD Graphics},
{0x160D, HD Graphics},
{0x160E, HD Graphics},
{0x1612, HD Graphics 5600},
{0x161B, HD Graphics},
{0x161A, HD Graphics},
{0x161D, HD Graphics},
{0x1622, Iris Pro Graphics 6200},
{0x162A, Iris Pro Graphics P6300},
{0x162D, HD Graphics},
{0x162E, HD Graphics},
{0x1632, HD Graphics},
{0x1636, HD Graphics},
{0x163B, HD Graphics},
{0x163A, HD Graphics},
{0x163D, HD Graphics},
{0x163E, HD Graphics},

The GT engineering names appear as comments in src/i915_pciids.h:

#define INTEL_BDW_GT12M_IDS(info)  \
INTEL_VGA_DEVICE(0x1602, info), /* GT1 ULT */ \
INTEL_VGA_DEVICE(0x1606, info), /* GT1 ULT */ \
INTEL_VGA_DEVICE(0x160B, info), /* GT1 Iris */ \
INTEL_VGA_DEVICE(0x160E, info), /* GT1 ULX */ \
INTEL_VGA_DEVICE(0x1612, info), /* GT2 Halo */ \
INTEL_VGA_DEVICE(0x1616, info), /* GT2 ULT */ \
INTEL_VGA_DEVICE(0x161B, info), /* GT2 ULT */ \
INTEL_VGA_DEVICE(0x161E, info)  /* GT2 ULX */

#define INTEL_BDW_GT12D_IDS(info) \
INTEL_VGA_DEVICE(0x160A, info), /* GT1 Server */ \
INTEL_VGA_DEVICE(0x160D, info), /* GT1 Workstation */ \
INTEL_VGA_DEVICE(0x161A, info), /* GT2 Server */ \
INTEL_VGA_DEVICE(0x161D, info)  /* GT2 Workstation */

#define INTEL_BDW_GT3M_IDS(info) \
INTEL_VGA_DEVICE(0x1622, info), /* ULT */ \
INTEL_VGA_DEVICE(0x1626, info), /* ULT */ \
INTEL_VGA_DEVICE(0x162B, info), /* Iris */ \
INTEL_VGA_DEVICE(0x162E, info)  /* ULX */

#define INTEL_BDW_GT3D_IDS(info) \
INTEL_VGA_DEVICE(0x162A, info), /* Server */ \
INTEL_VGA_DEVICE(0x162D, info)  /* Workstation */

#define INTEL_BDW_RSVDM_IDS(info) \
INTEL_VGA_DEVICE(0x1632, info), /* ULT */ \
INTEL_VGA_DEVICE(0x1636, info), /* ULT */ \
INTEL_VGA_DEVICE(0x163B, info), /* Iris */ \
INTEL_VGA_DEVICE(0x163E, info)  /* ULX */

#define INTEL_BDW_RSVDD_IDS(info) \
INTEL_VGA_DEVICE(0x163A, info), /* Server */ \
INTEL_VGA_DEVICE(0x163D, info)  /* Workstation */

#define INTEL_BDW_M_IDS(info) \
INTEL_BDW_GT12M_IDS(info), \
INTEL_BDW_GT3M_IDS(info), \
INTEL_BDW_RSVDM_IDS(info)

#define INTEL_BDW_D_IDS(info) \
INTEL_BDW_GT12D_IDS(info), \
INTEL_BDW_GT3D_IDS(info), \
INTEL_BDW_RSVDD_IDS(info)

It seems the RSVDM_IDS/RSVDD_IDS are for unreleased products
and the rest actually exist?



[patch] xlocale part 3: move _CurrentRuneLocale to locale_t (ctype)

2015-07-08 Thread Sebastien Marie
The patch move _CurrentRuneLocale global variable (which hold ctype
support) to locale_t.

- remove the global variable
- move initialisation to struct _locale_t
- add locale_t parameter to several internal functions
- use _current_locale() for get the current locale when using iswalpha(3)
  and co.
- pass LC_GLOBAL_LOCALE to configure ctype with setlocale(3).

Please note this patch is the bigger of the serie, as it combines
removing the global _CurrentRuneLocale variable with use a dynamic
locale state (_current_locale()).

If need, I could split it.
-- 
Sebastien Marie


Index: b/lib/libc/locale/runetable.c
===
--- a/lib/libc/locale/runetable.c   2015-07-08 09:15:00.593677755 +0200
+++ b/lib/libc/locale/runetable.c   2015-07-08 09:30:32.330646182 +0200
@@ -270,5 +270,3 @@
 },
 NULL
 };
-
-_RuneLocale *_CurrentRuneLocale = _DefaultRuneLocale;
Index: b/lib/libc/locale/xlocale.c
===
--- a/lib/libc/locale/xlocale.c 2015-07-08 09:30:11.430429064 +0200
+++ b/lib/libc/locale/xlocale.c 2015-07-08 11:38:50.581670856 +0200
@@ -17,6 +17,7 @@
 
 #include sys/types.h
 
+#include rune.h
 #include thread_private.h
 #include xlocale_private.h
 
@@ -25,7 +26,8 @@
  */
 struct _locale_t _lc_global_locale = {
XLOCALE_INSTALLED,
-   {C, C, C, C, C, C, C}
+   {C, C, C, C, C, C, C},
+   _DefaultRuneLocale
 };
 
 
Index: b/lib/libc/locale/xlocale_private.h
===
--- a/lib/libc/locale/xlocale_private.h 2015-07-08 09:30:11.430429064 +0200
+++ b/lib/libc/locale/xlocale_private.h 2015-07-08 11:39:01.331759641 +0200
@@ -20,9 +20,12 @@
 #include sys/cdefs.h
 #include locale.h
 
+#include runetype.h
+
 struct _locale_t {
int flags;
charcategories[_LC_LAST][32];
+   _RuneLocale *lc_ctype;
 };
 
 #define XLOCALE_INSTALLED(1  0)
Index: b/lib/libc/locale/___runetype_mb.c
===
--- a/lib/libc/locale/___runetype_mb.c  2015-07-08 09:15:00.593677755 +0200
+++ b/lib/libc/locale/___runetype_mb.c  2015-07-08 09:30:32.340645321 +0200
@@ -36,9 +36,10 @@
 #include wctype.h
 #include rune.h
 #include rune_local.h
+#include xlocale_private.h
 
 _RuneType
-___runetype_mb(wint_t c)
+___runetype_mb(wint_t c, locale_t locale)
 {
rune_t c0;
uint32_t x;
@@ -49,7 +50,7 @@
return (0U);
 
c0 = (rune_t)c; /* XXX assumes wint_t = int */
-   rr = _CurrentRuneLocale-rl_runetype_ext;
+   rr = locale-lc_ctype-rl_runetype_ext;
base = rr-rr_rune_ranges;
for (x = rr-rr_nranges; x; x = 1) {
re = base + (x  1);
Index: b/lib/libc/locale/iswctype.c
===
--- a/lib/libc/locale/iswctype.c2015-07-08 09:15:00.593677755 +0200
+++ b/lib/libc/locale/iswctype.c2015-07-08 11:42:27.553495230 +0200
@@ -40,132 +40,136 @@
 #include ctype.h
 #include errno.h
 #include string.h
+
 #include rune.h
 #include runetype.h
 #include rune_local.h
+#include xlocale_private.h
 #include _wctrans_local.h
 
-static __inline _RuneType __runetype_w(wint_t);
-static __inline int __isctype_w(wint_t, _RuneType);
-static __inline wint_t __toupper_w(wint_t);
-static __inline wint_t __tolower_w(wint_t);
+static __inline _RuneType __runetype_w(wint_t, locale_t);
+static __inline int __isctype_w(wint_t, _RuneType, locale_t);
+static __inline wint_t __toupper_w(wint_t, locale_t);
+static __inline wint_t __tolower_w(wint_t, locale_t);
 
 static __inline _RuneType
-__runetype_w(wint_t c)
+__runetype_w(wint_t c, locale_t locale)
 {
-   _RuneLocale *rl = _CurrentRuneLocale;
+   _RuneLocale *rl = locale-lc_ctype;
 
return (_RUNE_ISCACHED(c) ?
-   rl-rl_runetype[c] : ___runetype_mb(c));
+   rl-rl_runetype[c] : ___runetype_mb(c, locale));
 }
 
 static __inline int
-__isctype_w(wint_t c, _RuneType f)
+__isctype_w(wint_t c, _RuneType f, locale_t locale)
 {
-   return (!!(__runetype_w(c)  f));
+   return (!!(__runetype_w(c, locale)  f));
 }
 
 static __inline wint_t
-__toupper_w(wint_t c)
+__toupper_w(wint_t c, locale_t locale)
 {
-   return (_towctrans(c, _wctrans_upper(_CurrentRuneLocale)));
+   return (_towctrans(c, _wctrans_upper(locale-lc_ctype)));
 }
 
 static __inline wint_t
-__tolower_w(wint_t c)
+__tolower_w(wint_t c, locale_t locale)
 {
-   return (_towctrans(c, _wctrans_lower(_CurrentRuneLocale)));
+   return (_towctrans(c, _wctrans_lower(locale-lc_ctype)));
 }
 
 int
 iswalnum(wint_t c)
 {
-   return (__isctype_w((c), _CTYPE_A|_CTYPE_D));
+   return (__isctype_w((c), _CTYPE_A|_CTYPE_D, _current_locale()));
 }
 
 int
 iswalpha(wint_t c)
 {
-   return (__isctype_w((c), _CTYPE_A));
+   return (__isctype_w((c), _CTYPE_A, _current_locale()));
 }
 
 

doubled words in libcrypto manuals

2015-07-08 Thread Theo Buehler
While dabbling with J. Friedl's script for detecting doubled words in his
Mastering Regular Expressions book, I found these four instances of
doubled words.

Three of these are completely straightforward:

EC_GROUP_copy.pod: the the
EC_KEY_new.pod: have have
d2i_X509_NAME.pod: the the

However, the doubled 'not' in EVP_DigestVerifyInit.pod reverses the
meaning of the sentence.  The context indicates that the word
doubling is unintended.

Index: lib/libssl/src/doc/crypto/EC_GROUP_copy.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/EC_GROUP_copy.pod,v
retrieving revision 1.1
diff -u -p -r1.1 EC_GROUP_copy.pod
--- lib/libssl/src/doc/crypto/EC_GROUP_copy.pod 11 Jul 2014 16:18:14 -  
1.1
+++ lib/libssl/src/doc/crypto/EC_GROUP_copy.pod 8 Jul 2015 08:21:24 -
@@ -158,7 +158,7 @@ EC_GROUP_get0_seed returns a pointer to 
 specified. EC_GROUP_get_seed_len returns the length of the seed or 0 if the 
seed is not specified.
 
 EC_GROUP_set_seed returns the length of the seed that has been set. If the 
supplied seed is NULL, or the supplied seed length is
-0, the the return value will be 1. On error 0 is returned.
+0, the return value will be 1. On error 0 is returned.
 
 EC_GROUP_cmp returns 0 if the curves are equal, 1 if they are not equal, or -1 
on error.
 
Index: lib/libssl/src/doc/crypto/EC_KEY_new.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/EC_KEY_new.pod,v
retrieving revision 1.1
diff -u -p -r1.1 EC_KEY_new.pod
--- lib/libssl/src/doc/crypto/EC_KEY_new.pod11 Jul 2014 16:18:14 -  
1.1
+++ lib/libssl/src/doc/crypto/EC_KEY_new.pod8 Jul 2015 08:21:24 -
@@ -78,7 +78,7 @@ The functions EC_KEY_get_conv_form and E
 of point_conversion_forms please refer to LEC_POINT_new(3)|EC_POINT_new(3).
 
 EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller 
to associate arbitary additional data specific to the
-elliptic curve scheme being used with the EC_KEY object. This data is treated 
as a black box by the ec library. The data to be stored by 
EC_KEY_insert_key_method_data is provided in the Bdata parameter, which must 
have have associated functions for duplicating, freeing and clear_freeing the 
data item. If a subsequent EC_KEY_get_key_method_data call is issued, the 
functions for duplicating, freeing and clear_freeing the data item must be 
provided again, and they must be the same as they were when the data item was 
inserted.
+elliptic curve scheme being used with the EC_KEY object. This data is treated 
as a black box by the ec library. The data to be stored by 
EC_KEY_insert_key_method_data is provided in the Bdata parameter, which must 
have associated functions for duplicating, freeing and clear_freeing the data 
item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions 
for duplicating, freeing and clear_freeing the data item must be provided 
again, and they must be the same as they were when the data item was inserted.
 
 EC_KEY_set_flags sets the flags in the Bflags parameter on the EC_KEY 
object. Any flags that are already set are left set. The currently defined 
standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition 
there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is 
defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for 
this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the Bflags 
parameter. All other flags are left in their existing state.
 
Index: lib/libssl/src/doc/crypto/EVP_DigestVerifyInit.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/EVP_DigestVerifyInit.pod,v
retrieving revision 1.5
diff -u -p -r1.5 EVP_DigestVerifyInit.pod
--- lib/libssl/src/doc/crypto/EVP_DigestVerifyInit.pod  20 Jun 2015 01:07:25 
-  1.5
+++ lib/libssl/src/doc/crypto/EVP_DigestVerifyInit.pod  8 Jul 2015 08:21:24 
-
@@ -39,7 +39,7 @@ or a negative value for failure. In part
 the operation is not supported by the public key algorithm.
 
 Unlike other functions the return value 0 from EVP_DigestVerifyFinal() only
-indicates that the signature did not not verify successfully (that is tbs did
+indicates that the signature did not verify successfully (that is tbs did
 not match the original data or the signature was of invalid form) it is not an
 indication of a more serious error.
 
Index: lib/libssl/src/doc/crypto/d2i_X509_NAME.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/d2i_X509_NAME.pod,v
retrieving revision 1.2
diff -u -p -r1.2 d2i_X509_NAME.pod
--- lib/libssl/src/doc/crypto/d2i_X509_NAME.pod 10 Jul 2014 13:53:11 -  
1.2
+++ lib/libssl/src/doc/crypto/d2i_X509_NAME.pod 8 Jul 2015 08:21:24 -
@@ -14,7 +14,7 @@ d2i_X509_NAME, i2d_X509_NAME - X509_NAME
 =head1 DESCRIPTION

Add 5th gen Intel HD Graphics (GT1)

2015-07-08 Thread Mark Patruck
Intel HD Graphics (GT1) found on the 5th gen Broadwells.

We already have the bigger ones but the smallest GT1 with 12EUs
is missing. Test on my board OK (no drm right now of course)


Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1766
diff -u -p -r1.1766 pcidevs
--- pcidevs 5 Jun 2015 05:24:08 -   1.1766
+++ pcidevs 8 Jul 2015 07:36:03 -
@@ -3329,6 +3329,7 @@ product INTEL I218_LM_3   0x15a2  I218-LM
 product INTEL I218_V_3 0x15a3  I218-V
 product INTEL CORE5G_HB_1  0x1604  Core 5G Host
 product INTEL CORE5G_HDA_1 0x160c  Core 5G HD Audio
+product INTEL CORE5G_M_GT1 0x1606  HD Graphics (GT1)
 product INTEL CORE5G_M_GT2_1   0x1616  HD Graphics 5500
 product INTEL CORE5G_M_GT2_2   0x161e  HD Graphics 5300
 product INTEL CORE5G_M_GT3_15W 0x1626  HD Graphics 6000
Index: pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1759
diff -u -p -r1.1759 pcidevs.h
--- pcidevs.h   5 Jun 2015 05:24:19 -   1.1759
+++ pcidevs.h   8 Jul 2015 07:36:12 -
@@ -3334,6 +3334,7 @@
 #definePCI_PRODUCT_INTEL_I218_V_3  0x15a3  /* I218-V */
 #definePCI_PRODUCT_INTEL_CORE5G_HB_1   0x1604  /* Core 5G Host 
*/
 #definePCI_PRODUCT_INTEL_CORE5G_HDA_1  0x160c  /* Core 5G HD 
Audio */
+#definePCI_PRODUCT_INTEL_CORE5G_M_GT1  0x1606  /* HD Graphics 
(GT1) */
 #definePCI_PRODUCT_INTEL_CORE5G_M_GT2_10x1616  /* HD 
Graphics 5500 */
 #definePCI_PRODUCT_INTEL_CORE5G_M_GT2_20x161e  /* HD 
Graphics 5300 */
 #definePCI_PRODUCT_INTEL_CORE5G_M_GT3_15W  0x1626  /* HD 
Graphics 6000 */
Index: pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1754
diff -u -p -r1.1754 pcidevs_data.h
--- pcidevs_data.h  5 Jun 2015 05:24:19 -   1.1754
+++ pcidevs_data.h  8 Jul 2015 07:36:22 -
@@ -10864,6 +10864,10 @@ static const struct pci_known_product pc
Core 5G HD Audio,
},
{
+   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_CORE5G_M_GT1,
+   HD Graphics (GT1),
+   },
+   {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_CORE5G_M_GT2_1,
HD Graphics 5500,
},



-- 
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74  F644 0D3C F66F F286 5E51

http://www.wrapped.cx



[patch] xlocale part 1: minimal locale_t support

2015-07-08 Thread Sebastien Marie
Hi,

I have a serie of patches for adding support of xlocale in libc (10
currently, but not completely terminated) I want to be reviewed for
comments and OK.

I intend to commit them all at same time and after 5.8 lock I think.
They will need a libc major bump, and some bluk build of ports too
before commiting.

These patches add gradually xlocale support in libc. Each commit should
be compilable and produce a usable libc.so (but you will need previous
patches in the serie).

Please note the patches aren't cvs diff but plain text patches (I used
quilt).


This first commit add minimal locale_t support. The function naming mainly
follows NetBSD notation.

locale_t is an opaque pointer to struct _locale_t, which, with this
commit, only contains flags member (others members will be added
gradually by others patches).

The flag is (will be) used to discriminate installed state (used by one
thread) from unused one. A state is installed only on one thread at a
time (if you intend to call uselocale(3) repetively with one thread_t,
it will be silenciously duplicated). 

LC_GLOBAL_LOCALE is, like NetBSD, a pointer on _lc_global_locale which
will contains the global state for locale.

The implementation of global/per-thread state use _THREAD_PRIVATE macros
from thread_private.h, which allow to manage different code path for
program linked with or without pthread:

  - _current_locale() is used to retreive the current state: per-thread
thread if exists, else the global one.

  - _set_current_locale() is used to change the current state: restore
global state in thread or change the per-thread state.

Thanks for your comments.
-- 
Sebastien Marie


Index: b/lib/libc/locale/Makefile.inc
===
--- a/lib/libc/locale/Makefile.inc  2015-07-03 13:15:19.0 +0200
+++ b/lib/libc/locale/Makefile.inc  2015-07-03 13:16:23.563565923 +0200
@@ -12,7 +12,7 @@
wcstombs.c wctob.c wctomb.c wcstof.c wcstod.c wcstold.c wcstol.c \
wcstoul.c wcstoll.c wcstoull.c wcstoimax.c wcstoumax.c \
setrunelocale.c runeglue.c rune.c runetable.c ___runetype_mb.c \
-   _wctrans.c wcsxfrm.c
+   _wctrans.c wcsxfrm.c xlocale.c
 
 MAN+=  nl_langinfo.3 setlocale.3 iswalnum.3 towlower.3 \
btowc.3 mblen.3 mbrlen.3 mbrtowc.3 mbsinit.3 mbsrtowcs.3 \
Index: b/lib/libc/locale/xlocale.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ b/lib/libc/locale/xlocale.c 2015-07-05 06:52:14.054110929 +0200
@@ -0,0 +1,72 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2015 Sebastien Marie sema...@openbsd.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys/types.h
+
+#include thread_private.h
+#include xlocale_private.h
+
+/*
+ * hold the global state
+ */
+struct _locale_t _lc_global_locale = {
+   XLOCALE_INSTALLED
+};
+
+
+/*
+ * global storage for per-thread locale state
+ */
+_THREAD_PRIVATE_KEY(xlocale_storage);
+static struct _locale_t * xlocale_storage;
+
+/*
+ * return the current locale
+ */
+struct _locale_t *
+_current_locale()
+{
+   struct _locale_t ** loc_storage = _THREAD_PRIVATE(xlocale_storage,
+   xlocale_storage, NULL);
+
+   if ((loc_storage == NULL) || (*loc_storage == NULL))
+   return (_lc_global_locale);
+   else
+   return (*loc_storage);
+}
+
+
+/*
+ * set the current locale, and return the previous one.
+ * will return NULL on error.
+ */
+struct _locale_t *
+_set_current_locale(struct _locale_t * newloc)
+{
+   struct _locale_t ** loc_storage = _THREAD_PRIVATE(xlocale_storage,
+   xlocale_storage, NULL);
+   struct _locale_t * oldloc = _current_locale();
+
+   if (newloc == _lc_global_locale)
+   newloc = NULL;
+
+   if (loc_storage != NULL) {
+   *loc_storage = newloc;
+   return (oldloc);
+   } else
+   return (NULL);
+}
Index: b/include/locale.h
===
--- a/include/locale.h  2015-07-03 13:12:37.351814997 +0200
+++ b/include/locale.h  2015-07-03 13:16:23.573565344 +0200
@@ -87,6 +87,15 @@
 __BEGIN_DECLS
 struct lconv   *localeconv(void);
 char  

Microsoft Now OpenBSD Foundation Gold Contributor

2015-07-08 Thread Kenneth R Westerback
The OpenBSD Foundation is happy to announce that Microsoft has made
a significant financial donation to the Foundation. This donation
is in recognition of the role of the Foundation in supporting the
OpenSSH project. This donation makes Microsoft the first Gold level
contributor in the OpenBSD Foundation's 2015 fundraising campaign.

Donations to the Foundation can be made on our Donations Page at

www.openbsdfoundation.org/donations.html

We can be contacted regarding corporate sponsorship at

fundrais...@openbsdfoundation.org.



Unlock the reaper

2015-07-08 Thread Mark Kettenis
I'm looking for testers for this diff.  This should be safe to run on
amd64, i386 and sparc64.  But has been reported to lock up i386
machines.  I can't reproduce this on any of my own systems.  So I'm
looking for help.  I'm looking for people that are able to build a
kernel with this diff and the MP_LOCKDEBUG option enabled
(uncommented) in their GENERIC.MP kernel, run it on an MP machine and
put some load on it to see if it locks up and/or panics.

Being able to move forward with this would make OpenBSD run
significantly better on MP systems.

Thanks,

Mark


Index: uvm_addr.c
===
RCS file: /home/cvs/src/sys/uvm/uvm_addr.c,v
retrieving revision 1.13
diff -u -p -r1.13 uvm_addr.c
--- uvm_addr.c  30 Mar 2015 21:08:40 -  1.13
+++ uvm_addr.c  4 Apr 2015 11:08:49 -
@@ -287,14 +287,19 @@ uvm_addr_init(void)
 {
pool_init(uaddr_pool, sizeof(struct uvm_addr_state),
0, 0, PR_WAITOK, uaddr, NULL);
+   pool_setipl(uaddr_pool, IPL_VM);
pool_init(uaddr_hint_pool, sizeof(struct uaddr_hint_state),
0, 0, PR_WAITOK, uaddrhint, NULL);
+   pool_setipl(uaddr_hint_pool, IPL_VM);
pool_init(uaddr_bestfit_pool, sizeof(struct uaddr_bestfit_state),
0, 0, PR_WAITOK, uaddrbest, NULL);
+   pool_setipl(uaddr_bestfit_pool, IPL_VM);
pool_init(uaddr_pivot_pool, sizeof(struct uaddr_pivot_state),
0, 0, PR_WAITOK, uaddrpivot, NULL);
+   pool_setipl(uaddr_pivot_pool, IPL_VM);
pool_init(uaddr_rnd_pool, sizeof(struct uaddr_rnd_state),
0, 0, PR_WAITOK, uaddrrnd, NULL);
+   pool_setipl(uaddr_rnd_pool, IPL_VM);
 
uaddr_kbootstrap.uaddr_minaddr = PAGE_SIZE;
uaddr_kbootstrap.uaddr_maxaddr = -(vaddr_t)PAGE_SIZE;
Index: uvm_map.c
===
RCS file: /home/cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.191
diff -u -p -r1.191 uvm_map.c
--- uvm_map.c   23 Apr 2015 00:49:37 -  1.191
+++ uvm_map.c   28 Apr 2015 20:55:03 -
@@ -1842,8 +1842,10 @@ uvm_unmap_kill_entry(struct vm_map *map,
 {
/* Unwire removed map entry. */
if (VM_MAPENT_ISWIRED(entry)) {
+   KERNEL_LOCK();
entry-wired_count = 0;
uvm_fault_unwire_locked(map, entry-start, entry-end);
+   KERNEL_UNLOCK();
}
 
/* Entry-type specific code. */
@@ -2422,18 +2424,20 @@ void
 uvm_map_teardown(struct vm_map *map)
 {
struct uvm_map_deadq dead_entries;
-   int  i, waitok = 0;
struct vm_map_entry *entry, *tmp;
 #ifdef VMMAP_DEBUG
size_t   numq, numt;
 #endif
+   int  i;
 
-   if ((map-flags  VM_MAP_INTRSAFE) == 0)
-   waitok = 1;
-   if (waitok) {
-   if (rw_enter(map-lock, RW_NOSLEEP | RW_WRITE) != 0)
-   panic(uvm_map_teardown: rw_enter failed on free map);
-   }
+   KERNEL_ASSERT_LOCKED();
+   KERNEL_UNLOCK();
+   KERNEL_ASSERT_UNLOCKED();
+
+   KASSERT((map-flags  VM_MAP_INTRSAFE) == 0);
+
+   if (rw_enter(map-lock, RW_NOSLEEP | RW_WRITE) != 0)
+   panic(uvm_map_teardown: rw_enter failed on free map);
 
/* Remove address selectors. */
uvm_addr_destroy(map-uaddr_exe);
@@ -2466,8 +2470,7 @@ uvm_map_teardown(struct vm_map *map)
if ((entry = RB_ROOT(map-addr)) != NULL)
DEAD_ENTRY_PUSH(dead_entries, entry);
while (entry != NULL) {
-   if (waitok)
-   uvm_pause();
+   sched_pause();
uvm_unmap_kill_entry(map, entry);
if ((tmp = RB_LEFT(entry, daddrs.addr_entry)) != NULL)
DEAD_ENTRY_PUSH(dead_entries, tmp);
@@ -2477,8 +2480,7 @@ uvm_map_teardown(struct vm_map *map)
entry = TAILQ_NEXT(entry, dfree.deadq);
}
 
-   if (waitok)
-   rw_exit(map-lock);
+   rw_exit(map-lock);
 
 #ifdef VMMAP_DEBUG
numt = numq = 0;
@@ -2488,7 +2490,10 @@ uvm_map_teardown(struct vm_map *map)
numq++;
KASSERT(numt == numq);
 #endif
-   uvm_unmap_detach(dead_entries, waitok ? UVM_PLA_WAITOK : 0);
+   uvm_unmap_detach(dead_entries, UVM_PLA_WAITOK);
+
+   KERNEL_LOCK();
+
pmap_destroy(map-pmap);
map-pmap = NULL;
 }
@@ -3185,6 +3190,8 @@ void
 uvmspace_init(struct vmspace *vm, struct pmap *pmap, vaddr_t min, vaddr_t max,
 boolean_t pageable, boolean_t remove_holes)
 {
+   KASSERT(pmap == NULL || pmap == pmap_kernel());
+
if (pmap)
pmap_reference(pmap);
else



Re: Unlock the reaper

2015-07-08 Thread Mark Kettenis
 Date: Wed, 8 Jul 2015 15:17:46 +0100
 From: Stuart Henderson st...@openbsd.org
 
 On 2015/07/08 15:53, Mark Kettenis wrote:
  Index: uvm_map.c
 ..
  @@ -2466,8 +2470,7 @@ uvm_map_teardown(struct vm_map *map)
  if ((entry = RB_ROOT(map-addr)) != NULL)
  DEAD_ENTRY_PUSH(dead_entries, entry);
  while (entry != NULL) {
  -   if (waitok)
  -   uvm_pause();
  +   sched_pause();
 
 ah, slightly different than the one I've tried before which
 had uvm_pause instead of sched_pause here plus an extra change
 in uvm_glue.c.

Just a bit of a cleanup though.  Not going to make a difference.

 I'll give this a spin on i386 after my current build finishes.
 FWIW I've been running the previous version on amd64 for ages with
 very positive results.

I won't stop you ;).  But my goal was to trick others into testing
this diff such that this doesn't hamper the i386 ports builds.



hppa pmap diff

2015-07-08 Thread Mark Kettenis
This is a first step towards making the hppa pmap mpsafe.  Don't have
an MP hppa system myself, so I would appreciate it someone can give
this a go.

It also enables some debug printfs.  So if you give this a spin,
please check if you see any pmap_destroy messages in dmesg.


Index: hppa/pmap.c
===
RCS file: /cvs/src/sys/arch/hppa/hppa/pmap.c,v
retrieving revision 1.165
diff -u -p -r1.165 pmap.c
--- hppa/pmap.c 11 Feb 2015 01:58:57 -  1.165
+++ hppa/pmap.c 8 Jul 2015 14:42:18 -
@@ -34,6 +34,7 @@
 
 #include sys/param.h
 #include sys/systm.h
+#include sys/atomic.h
 #include sys/proc.h
 #include sys/user.h
 #include sys/pool.h
@@ -111,11 +112,25 @@ void   pmap_pte_flush(struct pmap *pmap,
 voidpmap_dump_table(pa_space_t space, vaddr_t sva);
 voidpmap_dump_pv(paddr_t pa);
 #endif
-int pmap_check_alias(struct pv_entry *pve, vaddr_t va,
+int pmap_check_alias(struct vm_page *pg, vaddr_t va,
pt_entry_t pte);
 
 #defineIS_IOPAGE(pa)   ((pa) = HPPA_IOBEGIN)
 
+static inline void
+pmap_lock(struct pmap *pmap)
+{
+   if (pmap != pmap_kernel())
+   mtx_enter(pmap-pm_mtx);
+}
+
+static inline void
+pmap_unlock(struct pmap *pmap)
+{
+   if (pmap != pmap_kernel())
+   mtx_leave(pmap-pm_mtx);
+}
+
 struct vm_page *
 pmap_pagealloc(struct uvm_object *obj, voff_t off)
 {
@@ -192,13 +207,24 @@ static __inline pt_entry_t *
 pmap_pde_alloc(struct pmap *pm, vaddr_t va, struct vm_page **pdep)
 {
struct vm_page *pg;
+   volatile pt_entry_t *pde;
paddr_t pa;
 
DPRINTF(PDB_FOLLOW|PDB_VP,
(pmap_pde_alloc(%p, 0x%lx, %p)\n, pm, va, pdep));
 
-   if ((pg = pmap_pagealloc(pm-pm_obj, va)) == NULL)
+   pmap_unlock(pm);
+   pg = pmap_pagealloc(pm-pm_obj, va);
+   pmap_lock(pm);
+   if (pg == NULL)
return (NULL);
+   pde = pmap_pde_get(pm-pm_pdir, va);
+   if (pde) {
+   pmap_unlock(pm);
+   uvm_pagefree(pg);
+   pmap_lock(pm);
+   return (pt_entry_t *)pde;
+   }
 
pa = VM_PAGE_TO_PHYS(pg);
 
@@ -363,12 +389,14 @@ pmap_dump_pv(paddr_t pa)
 #endif
 
 int
-pmap_check_alias(struct pv_entry *pve, vaddr_t va, pt_entry_t pte)
+pmap_check_alias(struct vm_page *pg, vaddr_t va, pt_entry_t pte)
 {
-   int ret;
+   struct pv_entry *pve;
+   int ret = 0;
 
/* check for non-equ aliased mappings */
-   for (ret = 0; pve; pve = pve-pv_next) {
+   mtx_enter(pg-mdpage.pvh_mtx);
+   for (pve = pg-mdpage.pvh_list; pve; pve = pve-pv_next) {
pte |= pmap_vp_find(pve-pv_pmap, pve-pv_va);
if ((va  HPPA_PGAOFF) != (pve-pv_va  HPPA_PGAOFF) 
(pte  PTE_PROT(TLB_WRITE))) {
@@ -380,6 +408,7 @@ pmap_check_alias(struct pv_entry *pve, v
ret++;
}
}
+   mtx_leave(pg-mdpage.pvh_mtx);
 
return (ret);
 }
@@ -416,8 +445,10 @@ pmap_pv_enter(struct vm_page *pg, struct
pve-pv_pmap = pm;
pve-pv_va = va;
pve-pv_ptp = pdep;
+   mtx_enter(pg-mdpage.pvh_mtx);
pve-pv_next = pg-mdpage.pvh_list;
pg-mdpage.pvh_list = pve;
+   mtx_leave(pg-mdpage.pvh_mtx);
 }
 
 static __inline struct pv_entry *
@@ -425,12 +456,14 @@ pmap_pv_remove(struct vm_page *pg, struc
 {
struct pv_entry **pve, *pv;
 
+   mtx_enter(pg-mdpage.pvh_mtx);
for (pv = *(pve = pg-mdpage.pvh_list);
pv; pv = *(pve = (*pve)-pv_next))
if (pv-pv_pmap == pmap  pv-pv_va == va) {
*pve = pv-pv_next;
break;
}
+   mtx_leave(pg-mdpage.pvh_mtx);
return (pv);
 }
 
@@ -602,6 +635,7 @@ pmap_init(void)
pool_allocator_nointr);
pool_init(pmap_pv_pool, sizeof(struct pv_entry), 0, 0, 0, pmappv,
NULL);
+   pool_setipl(pmap_pv_pool, IPL_VM);
pool_setlowat(pmap_pv_pool, pmap_pvlowat);
pool_sethiwat(pmap_pv_pool, pmap_pvlowat * 32);
 
@@ -643,6 +677,8 @@ pmap_create(void)
 
pmap = pool_get(pmap_pmap_pool, PR_WAITOK);
 
+   mtx_init(pmap-pm_mtx, IPL_VM);
+
uvm_objinit(pmap-pm_obj, NULL, 1);
 
for (space = 1 + arc4random_uniform(hppa_sid_max);
@@ -674,7 +710,7 @@ pmap_destroy(struct pmap *pmap)
 
DPRINTF(PDB_FOLLOW|PDB_PMAP, (pmap_destroy(%p)\n, pmap));
 
-   refs = --pmap-pm_obj.uo_refs;
+   refs = atomic_dec_int_nv(pmap-pm_obj.uo_refs);
if (refs  0)
return;
 
@@ -686,7 +722,7 @@ pmap_destroy(struct pmap *pmap)
 
KASSERT(pg != pmap-pm_pdir_pg);
pa = VM_PAGE_TO_PHYS(pg);
-#ifdef PMAPDEBUG
+#ifndef PMAPDEBUG
printf(pmap_destroy(%p): stray ptp 0x%lx w/ %u ents:,
pmap, pa, pg-wire_count - 1);
 #endif
@@ -703,7 +739,7 @@ 

Food costs rising? See what Taylor Street Pizza did about it

2015-07-08 Thread Jennifer Smith
Bright Window Signs Attract More Customers.

As with most restaurateurs, increasing costs had Shaun Kanchwala facing some 
very tough choices: use cheaper ingredients, accept reduced profits, or 
increase prices and risk losing customers.

“If you think about it, I really had no alternative,” says Shaun, owner of 
Taylor Street Pizza in Carpentersville, IL. “Lower food quality and you are 
sure to lose customers.  Continually accept reduced profit and you go out of 
business.  I had to raise prices, but I also had to do it in a way that would 
minimize customer defections.”

A critical part of Shaun’s solution was SpellBrite – a brand new, click 
together LED signage system that looks more professional than neon and has 
none of the drawbacks.  Shaun had seen other restaurants using SpellBrite 
successfully to promote their specials and unique offerings.  Since SpellBrite 
helped the other business owners increase their sales, Shaun figured it could 
help his business too.


Shaun bought two SpellBrite signs that said, “ANY 2 SLICES $5.50” – one for the 
front window and one for the side – to launch the price increase from $5 to 
$5.50. Since SpellBrite is modular, if the test failed or costs changed, Shaun 
could easily change the price on the sign or the entire message.

Shaun was ecstatic with the results: unit sales did not drop, they actually 
increased over 10%.  “A bright sign of a compelling message really does pull in 
more customers. The price increase of 10% plus the unit increase of 10%+ led to 
an increase in slice sales of more than 20%, and most of this went to the 
bottom line. And the draw for slices also increased sales of other food and 
beverage items.  We definitely will buy SpellBrite signs for all 10 of our 
stores.”



Many store owners have used SpellBrite signs to increase their sales. Our signs 
deliver the stopping power of neon at about half the cost – with all the 
benefits of LEDs: longer life, lower energy costs, and high durability. If you 
are unsatisfied with your sign for any reason, you can return it for a full 
refund, and we’ll even pay for the return shipping.  That’s how confident we 
are that you will get value from SpellBrite.

To learn more go to ww.SpellBrite.com/?couponcode=newbiz15 and use Coupon Code 
NEWBIZ15 to save 25% on all SpellBrite products.

Sincerely,

Jennifer Smith
Customer Service
SpellBrite by Optiva Signs
118 S Clinton, Ste 370
Chicago, IL 60661
312-575-9620
jenni...@spellbrite.com


© 2015 iLight Technologies, Inc. All rights reserved.  SpellBrite and 
Optiva are trademarks of iLight Technologies, Inc.

If you wish to unsubscribe to all future emails from SpellBrite, e-mail us at 
jenni...@spellbrite.com with the title unsubscribe.

LibreSSL 2.2.1 released

2015-07-08 Thread Brent Cook
We have released LibreSSL 2.2.1, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.

This release continues from the OpenBSD 5.8 development tree, featuring
expanded OS support, code improvements, and feature removal. Also note
that SSLv3 support has not been removed yet, but it should happen soon.

Notable changes in this release are:

  * Assorted build fixes for musl, HP-UX, Mingw, and Solaris.

  * Initial support for Windows 2009, 2003, and XP.

  * Protocol parsing conversions to BoringSSL's CRYPTO ByteString (CBS) API

  * Added EC_curve_nid2nist and EC_curve_nist2nid from OpenSSL

  * Removed Dynamic Engine support

  * Removed MDC-2DES support

The LibreSSL project continues improvement of the codebase to reflect modern,
safe programming practices. We welcome feedback and improvements from the
broader community. Thanks to all of the contributors who helped make this
release possible.



Re: Unlock the reaper

2015-07-08 Thread Stuart Henderson
On 2015/07/08 15:53, Mark Kettenis wrote:
 Index: uvm_map.c
..
 @@ -2466,8 +2470,7 @@ uvm_map_teardown(struct vm_map *map)
   if ((entry = RB_ROOT(map-addr)) != NULL)
   DEAD_ENTRY_PUSH(dead_entries, entry);
   while (entry != NULL) {
 - if (waitok)
 - uvm_pause();
 + sched_pause();

ah, slightly different than the one I've tried before which
had uvm_pause instead of sched_pause here plus an extra change
in uvm_glue.c.

I'll give this a spin on i386 after my current build finishes.
FWIW I've been running the previous version on amd64 for ages with
very positive results.



Re: Unlock the reaper

2015-07-08 Thread Max Fillinger
On Wed, Jul 08, 2015 at 03:53:46PM +0200, Mark Kettenis wrote:
 I'm looking for testers for this diff.  This should be safe to run on
 amd64, i386 and sparc64.  But has been reported to lock up i386
 machines.  I can't reproduce this on any of my own systems.  So I'm
 looking for help.  I'm looking for people that are able to build a
 kernel with this diff and the MP_LOCKDEBUG option enabled
 (uncommented) in their GENERIC.MP kernel, run it on an MP machine and
 put some load on it to see if it locks up and/or panics.
 
 Being able to move forward with this would make OpenBSD run
 significantly better on MP systems.
 
 Thanks,
 
 Mark

I just finished compiling the kernel for amd64; I might test i386 later.
What kind of load would be required to give useful feedback? Would
building the userland or some of the bigger ports be a useful test?



Re: Unlock the reaper

2015-07-08 Thread Timo Myyrä
Mark Kettenis mark.kette...@xs4all.nl writes:

 I'm looking for testers for this diff.  This should be safe to run on
 amd64, i386 and sparc64.  But has been reported to lock up i386
 machines.  I can't reproduce this on any of my own systems.  So I'm
 looking for help.  I'm looking for people that are able to build a
 kernel with this diff and the MP_LOCKDEBUG option enabled
 (uncommented) in their GENERIC.MP kernel, run it on an MP machine and
 put some load on it to see if it locks up and/or panics.

 Being able to move forward with this would make OpenBSD run
 significantly better on MP systems.

 Thanks,

 Mark


 Index: uvm_addr.c
 ===
 RCS file: /home/cvs/src/sys/uvm/uvm_addr.c,v
 retrieving revision 1.13
 diff -u -p -r1.13 uvm_addr.c
 --- uvm_addr.c30 Mar 2015 21:08:40 -  1.13
 +++ uvm_addr.c4 Apr 2015 11:08:49 -
 @@ -287,14 +287,19 @@ uvm_addr_init(void)
  {
   pool_init(uaddr_pool, sizeof(struct uvm_addr_state),
   0, 0, PR_WAITOK, uaddr, NULL);
 + pool_setipl(uaddr_pool, IPL_VM);
   pool_init(uaddr_hint_pool, sizeof(struct uaddr_hint_state),
   0, 0, PR_WAITOK, uaddrhint, NULL);
 + pool_setipl(uaddr_hint_pool, IPL_VM);
   pool_init(uaddr_bestfit_pool, sizeof(struct uaddr_bestfit_state),
   0, 0, PR_WAITOK, uaddrbest, NULL);
 + pool_setipl(uaddr_bestfit_pool, IPL_VM);
   pool_init(uaddr_pivot_pool, sizeof(struct uaddr_pivot_state),
   0, 0, PR_WAITOK, uaddrpivot, NULL);
 + pool_setipl(uaddr_pivot_pool, IPL_VM);
   pool_init(uaddr_rnd_pool, sizeof(struct uaddr_rnd_state),
   0, 0, PR_WAITOK, uaddrrnd, NULL);
 + pool_setipl(uaddr_rnd_pool, IPL_VM);
  
   uaddr_kbootstrap.uaddr_minaddr = PAGE_SIZE;
   uaddr_kbootstrap.uaddr_maxaddr = -(vaddr_t)PAGE_SIZE;
 Index: uvm_map.c
 ===
 RCS file: /home/cvs/src/sys/uvm/uvm_map.c,v
 retrieving revision 1.191
 diff -u -p -r1.191 uvm_map.c
 --- uvm_map.c 23 Apr 2015 00:49:37 -  1.191
 +++ uvm_map.c 28 Apr 2015 20:55:03 -
 @@ -1842,8 +1842,10 @@ uvm_unmap_kill_entry(struct vm_map *map,
  {
   /* Unwire removed map entry. */
   if (VM_MAPENT_ISWIRED(entry)) {
 + KERNEL_LOCK();
   entry-wired_count = 0;
   uvm_fault_unwire_locked(map, entry-start, entry-end);
 + KERNEL_UNLOCK();
   }
  
   /* Entry-type specific code. */
 @@ -2422,18 +2424,20 @@ void
  uvm_map_teardown(struct vm_map *map)
  {
   struct uvm_map_deadq dead_entries;
 - int  i, waitok = 0;
   struct vm_map_entry *entry, *tmp;
  #ifdef VMMAP_DEBUG
   size_t   numq, numt;
  #endif
 + int  i;
  
 - if ((map-flags  VM_MAP_INTRSAFE) == 0)
 - waitok = 1;
 - if (waitok) {
 - if (rw_enter(map-lock, RW_NOSLEEP | RW_WRITE) != 0)
 - panic(uvm_map_teardown: rw_enter failed on free map);
 - }
 + KERNEL_ASSERT_LOCKED();
 + KERNEL_UNLOCK();
 + KERNEL_ASSERT_UNLOCKED();
 +
 + KASSERT((map-flags  VM_MAP_INTRSAFE) == 0);
 +
 + if (rw_enter(map-lock, RW_NOSLEEP | RW_WRITE) != 0)
 + panic(uvm_map_teardown: rw_enter failed on free map);
  
   /* Remove address selectors. */
   uvm_addr_destroy(map-uaddr_exe);
 @@ -2466,8 +2470,7 @@ uvm_map_teardown(struct vm_map *map)
   if ((entry = RB_ROOT(map-addr)) != NULL)
   DEAD_ENTRY_PUSH(dead_entries, entry);
   while (entry != NULL) {
 - if (waitok)
 - uvm_pause();
 + sched_pause();
   uvm_unmap_kill_entry(map, entry);
   if ((tmp = RB_LEFT(entry, daddrs.addr_entry)) != NULL)
   DEAD_ENTRY_PUSH(dead_entries, tmp);
 @@ -2477,8 +2480,7 @@ uvm_map_teardown(struct vm_map *map)
   entry = TAILQ_NEXT(entry, dfree.deadq);
   }
  
 - if (waitok)
 - rw_exit(map-lock);
 + rw_exit(map-lock);
  
  #ifdef VMMAP_DEBUG
   numt = numq = 0;
 @@ -2488,7 +2490,10 @@ uvm_map_teardown(struct vm_map *map)
   numq++;
   KASSERT(numt == numq);
  #endif
 - uvm_unmap_detach(dead_entries, waitok ? UVM_PLA_WAITOK : 0);
 + uvm_unmap_detach(dead_entries, UVM_PLA_WAITOK);
 +
 + KERNEL_LOCK();
 +
   pmap_destroy(map-pmap);
   map-pmap = NULL;
  }
 @@ -3185,6 +3190,8 @@ void
  uvmspace_init(struct vmspace *vm, struct pmap *pmap, vaddr_t min, vaddr_t 
 max,
  boolean_t pageable, boolean_t remove_holes)
  {
 + KASSERT(pmap == NULL || pmap == pmap_kernel());
 +
   if (pmap)
   pmap_reference(pmap);
   else

Hi,

Compiled kernel with this on my Thinkpad X201 (amd64).
I run few compilations in parallel (kernel + few ports) in background with 
normal desktop use and
got load bumped to ~8.0.
So far no regressions 

Re: Unlock the reaper

2015-07-08 Thread Adam Wolk
On Wed, 8 Jul 2015 22:20:49 +0100
Stuart Henderson st...@openbsd.org wrote:

 On 2015/07/08 20:00, Max Fillinger wrote:
  On Wed, Jul 08, 2015 at 03:53:46PM +0200, Mark Kettenis wrote:
   I'm looking for testers for this diff.  This should be safe to
   run on amd64, i386 and sparc64.  But has been reported to lock up
   i386 machines.  I can't reproduce this on any of my own systems.
   So I'm looking for help.  I'm looking for people that are able to
   build a kernel with this diff and the MP_LOCKDEBUG option enabled
   (uncommented) in their GENERIC.MP kernel, run it on an MP machine
   and put some load on it to see if it locks up and/or panics.
   
   Being able to move forward with this would make OpenBSD run
   significantly better on MP systems.
   
   Thanks,
   
   Mark
  
  I just finished compiling the kernel for amd64; I might test i386
  later. What kind of load would be required to give useful feedback?
  Would building the userland or some of the bigger ports be a useful
  test?
 

I have been running with the patch for ~2h with a decent load on amd64
applied to a Jul 8 snapshot. No crashes, no panics and dmesg doesn't
show anything unusual.

 Building base with the reaper unlock diff on i386 doesn't seem to
 trigger problems, or at least I haven't run into them in a few
 attempts.
 
 I do see problems when building ports on a dpb cluster, quite quickly
 in some cases - I just did a run and one node locked after 261s,
 another after 756s (dpb master stayed up FWIW).
 

Stuart, do you think the issue could be memory related and more easily
triggered when the system is forced to swap?

My amd64 box has 8 gigs of ram though the i386 device I used before was
always a *lot* easier to memory starve to say the least. The patches
apply to the uvm which is responsible handling virtual memory 
swapping.

That could be a good reason for a hard to reproduce bug on a memory
starved i386 device wouldn't it?

I can slap a new snaphost on my old i386 box and try memory starving it
tomorrow. Will appreciate any debunking of this train thought of course
or pointers on what type of load to put on the system (cpu, memory,
io?).

 If you're trying to reproduce, make sure you set ddb.console=1 and
 check that you can break into ddb under normal conditions. If you
 manage to trigger a hang, see if you can break into ddb and get
 the usual things (backtrace, ps, sh reg, etc).
 
 I've been unable to get into ddb after a hang, including on this
 most recent run with MP_LOCKDEBUG.
 
 Nothing particular special was being built during the last hang;
 from dpb term-report, the last entry before i386-2- appeared
 (indicating that the host is no longer contactable) showed these
 
 archivers/libzip
 audio/libogg
 archivers/lzo2
 
 Looking at build logs (which are streamed over ssh and logged
 on the dpb master) lzo2 and libzip were compiling (cc from base)
 and libogg was doing pkg_create/gzip when contact was lost.
 So I don't think it's going to be triggered by any particular
 ports, there is nothing out of the ordinary about these, and
 no funny autoconf checks were occurring at the time.
 
 The main other build-related active process would be sshd,
 and since pkg_create was running it would also most likely
 have been writing to nfs at the time.



Re: Unlock the reaper

2015-07-08 Thread Stuart Henderson
On 2015/07/08 20:00, Max Fillinger wrote:
 On Wed, Jul 08, 2015 at 03:53:46PM +0200, Mark Kettenis wrote:
  I'm looking for testers for this diff.  This should be safe to run on
  amd64, i386 and sparc64.  But has been reported to lock up i386
  machines.  I can't reproduce this on any of my own systems.  So I'm
  looking for help.  I'm looking for people that are able to build a
  kernel with this diff and the MP_LOCKDEBUG option enabled
  (uncommented) in their GENERIC.MP kernel, run it on an MP machine and
  put some load on it to see if it locks up and/or panics.
  
  Being able to move forward with this would make OpenBSD run
  significantly better on MP systems.
  
  Thanks,
  
  Mark
 
 I just finished compiling the kernel for amd64; I might test i386 later.
 What kind of load would be required to give useful feedback? Would
 building the userland or some of the bigger ports be a useful test?

Building base with the reaper unlock diff on i386 doesn't seem to
trigger problems, or at least I haven't run into them in a few attempts.

I do see problems when building ports on a dpb cluster, quite quickly
in some cases - I just did a run and one node locked after 261s, another
after 756s (dpb master stayed up FWIW).

If you're trying to reproduce, make sure you set ddb.console=1 and
check that you can break into ddb under normal conditions. If you
manage to trigger a hang, see if you can break into ddb and get
the usual things (backtrace, ps, sh reg, etc).

I've been unable to get into ddb after a hang, including on this
most recent run with MP_LOCKDEBUG.

Nothing particular special was being built during the last hang;
from dpb term-report, the last entry before i386-2- appeared
(indicating that the host is no longer contactable) showed these

archivers/libzip
audio/libogg
archivers/lzo2

Looking at build logs (which are streamed over ssh and logged
on the dpb master) lzo2 and libzip were compiling (cc from base)
and libogg was doing pkg_create/gzip when contact was lost.
So I don't think it's going to be triggered by any particular
ports, there is nothing out of the ordinary about these, and
no funny autoconf checks were occurring at the time.

The main other build-related active process would be sshd,
and since pkg_create was running it would also most likely
have been writing to nfs at the time.