Re: malloc freelists
On Thu, 1 May 2014, Ted Unangst wrote: > What's better than a freelist? Four freelists! Apart from moar = better, what's the motivation? Do you have a particular attack in mind? The only thing I can think of where this change might help is an attack that speculatively spams small offsets from the overflow and hopes it doesn't run off the end of the page, and this seems fairly contrived... -d
malloc freelists
What's better than a freelist? Four freelists!
For each chunk size, pick one of four freelists at random. This
scatters allocations about some more and eliminates the guarantee that
consecutive allocations will always be on the same page.
Technically, there is no bound to how much memory will be used, but in
practice, it will be 3 pages per bucket. (Worst case would be you
somehow always allocate from one list and always free to a different
one, in which case the freed pages "leak". In practice, this is so
unlikely I don't think it's worth writing code to handle.)
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.159
diff -u -p -r1.159 malloc.c
--- malloc.c1 May 2014 04:08:13 - 1.159
+++ malloc.c1 May 2014 04:30:50 -
@@ -64,6 +64,7 @@
#define MALLOC_DELAYED_CHUNK_MASK 15
#define MALLOC_INITIAL_REGIONS 512
#define MALLOC_DEFAULT_CACHE 64
+#defineMALLOC_CHUNK_LISTS 4
/*
* When the P option is active, we move allocations between half a page
@@ -110,7 +111,7 @@ struct dir_info {
/* lists of free chunk info structs */
struct chunk_head chunk_info_list[MALLOC_MAXSHIFT + 1];
/* lists of chunks with free slots */
- struct chunk_head chunk_dir[MALLOC_MAXSHIFT + 1];
+ struct chunk_head chunk_dir[MALLOC_MAXSHIFT + 1][MALLOC_CHUNK_LISTS];
size_t free_regions_size; /* free pages cached */
/* free pages cache */
struct region_info free_regions[MALLOC_MAXCACHE];
@@ -621,7 +622,8 @@ omalloc_init(struct dir_info **dp)
}
for (i = 0; i <= MALLOC_MAXSHIFT; i++) {
LIST_INIT(&d->chunk_info_list[i]);
- LIST_INIT(&d->chunk_dir[i]);
+ for (j = 0; j < MALLOC_CHUNK_LISTS; j++)
+ LIST_INIT(&d->chunk_dir[i][j]);
}
malloc_used += regioninfo_size;
d->canary1 = mopts.malloc_canary ^ (u_int32_t)(uintptr_t)d;
@@ -816,7 +818,7 @@ delete(struct dir_info *d, struct region
* Allocate a page of chunks
*/
static struct chunk_info *
-omalloc_make_chunks(struct dir_info *d, int bits)
+omalloc_make_chunks(struct dir_info *d, int bits, int listnum)
{
struct chunk_info *bp;
void*pp;
@@ -867,7 +869,7 @@ omalloc_make_chunks(struct dir_info *d,
for (; i < k; i++)
bp->bits[i / MALLOC_BITS] |= (u_short)1U << (i % MALLOC_BITS);
- LIST_INSERT_HEAD(&d->chunk_dir[bits], bp, entries);
+ LIST_INSERT_HEAD(&d->chunk_dir[bits][listnum], bp, entries);
bits++;
if ((uintptr_t)pp & bits)
@@ -884,7 +886,7 @@ omalloc_make_chunks(struct dir_info *d,
static void *
malloc_bytes(struct dir_info *d, size_t size, void *f)
{
- int i, j;
+ int i, j, listnum;
size_t k;
u_short u, *lp;
struct chunk_info *bp;
@@ -907,13 +909,13 @@ malloc_bytes(struct dir_info *d, size_t
j++;
}
+ listnum = getrbyte() % MALLOC_CHUNK_LISTS;
/* If it's empty, make a page more of that size chunks */
- if (LIST_EMPTY(&d->chunk_dir[j])) {
- bp = omalloc_make_chunks(d, j);
+ if ((bp = LIST_FIRST(&d->chunk_dir[j][listnum])) == NULL) {
+ bp = omalloc_make_chunks(d, j, listnum);
if (bp == NULL)
return NULL;
- } else
- bp = LIST_FIRST(&d->chunk_dir[j]);
+ }
if (bp->canary != d->canary1)
wrterror("chunk info corrupted", NULL);
@@ -973,7 +975,7 @@ free_bytes(struct dir_info *d, struct re
{
struct chunk_head *mp;
struct chunk_info *info;
- int i;
+ int i, listnum;
info = (struct chunk_info *)r->size;
if (info->canary != d->canary1)
@@ -994,16 +996,18 @@ free_bytes(struct dir_info *d, struct re
info->bits[i / MALLOC_BITS] |= 1U << (i % MALLOC_BITS);
info->free++;
- if (info->size != 0)
- mp = d->chunk_dir + info->shift;
- else
- mp = d->chunk_dir;
-
if (info->free == 1) {
/* Page became non-full */
+ listnum = getrbyte() % MALLOC_CHUNK_LISTS;
+ if (info->size != 0)
+ mp = &d->chunk_dir[info->shift][listnum];
+ else
+ mp = &d->chunk_dir[0][listnum];
+
LIST_INSERT_HEAD(mp, info, entries);
return;
}
+
if (info->free != info->total)
return;
small bcrypt diff
Clean up a few things.
1. Drop support for no minor. This variant doesn't exist anymore.
2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4. Slightly more consistent style between various parse and check and
increment operations on salt.
Index: bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.39
diff -u -p -r1.39 bcrypt.c
--- bcrypt.c19 Apr 2014 15:19:20 - 1.39
+++ bcrypt.c1 May 2014 03:28:36 -
@@ -94,45 +94,44 @@ bcrypt_hashpass(const char *key, const c
u_int8_t ciphertext[4 * BCRYPT_BLOCKS] = "OrpheanBeholderScryDoubt";
u_int8_t csalt[BCRYPT_MAXSALT];
u_int32_t cdata[BCRYPT_BLOCKS];
- char arounds[3];
- /* Discard "$" identifier */
- if (*salt != '$')
+ /* Check and discard "$" identifier */
+ if (salt[0] != '$')
return -1;
- salt++;
+ salt += 1;
- if (*salt != BCRYPT_VERSION)
+ if (salt[0] != BCRYPT_VERSION)
return -1;
/* Check for minor versions */
- if (salt[1] != '$') {
-switch (salt[1]) {
-case 'a': /* 'ab' should not yield the same as 'abab' */
-case 'b': /* cap input length at 72 bytes */
-minor = salt[1];
-salt++;
-if (salt[1] != '$')
-return -1;
-break;
-default:
-return -1;
-}
- } else
-minor = 0;
-
- /* Discard version + "$" identifier */
- salt += 2;
-
+ switch ((minor = salt[1])) {
+ case 'a':
+ key_len = (u_int8_t)(strlen(key) + 1);
+ break;
+ case 'b':
+ /* strlen() returns a size_t, but the function calls
+* below result in implicit casts to a narrower integer
+* type, so cap key_len at the actual maximum supported
+* length here to avoid integer wraparound */
+ key_len = strlen(key);
+ if (key_len > 72)
+ key_len = 72;
+ key_len++; /* include the NUL */
+ break;
+ default:
+return -1;
+ }
if (salt[2] != '$')
- /* Out of sync with passwd entry */
return -1;
+ /* Discard version + "$" identifier */
+ salt += 3;
- memcpy(arounds, salt, sizeof(arounds));
- if (arounds[sizeof(arounds) - 1] != '$')
+ /* Check and parse num rounds */
+ if (!isdigit((unsigned char)salt[0]) ||
+ !isdigit((unsigned char)salt[1]) || salt[2] != '$')
return -1;
- arounds[sizeof(arounds) - 1] = 0;
- logr = strtonum(arounds, BCRYPT_MINLOGROUNDS, 31, NULL);
- if (logr == 0)
+ logr = atoi(salt);
+ if (logr < BCRYPT_MINLOGROUNDS || logr > 31)
return -1;
/* Computer power doesn't increase linearly, 2^x should be fine */
rounds = 1U << logr;
@@ -147,18 +146,6 @@ bcrypt_hashpass(const char *key, const c
if (decode_base64(csalt, BCRYPT_MAXSALT, salt))
return -1;
salt_len = BCRYPT_MAXSALT;
- if (minor <= 'a')
- key_len = (u_int8_t)(strlen(key) + (minor >= 'a' ? 1 : 0));
- else {
- /* strlen() returns a size_t, but the function calls
-* below result in implicit casts to a narrower integer
-* type, so cap key_len at the actual maximum supported
-* length here to avoid integer wraparound */
- key_len = strlen(key);
- if (key_len > 72)
- key_len = 72;
- key_len++; /* include the NUL */
- }
/* Setting up S-Boxes and Subkeys */
Blowfish_initstate(&state);
@@ -192,8 +179,7 @@ bcrypt_hashpass(const char *key, const c
i = 0;
encrypted[i++] = '$';
encrypted[i++] = BCRYPT_VERSION;
- if (minor)
- encrypted[i++] = minor;
+ encrypted[i++] = minor;
encrypted[i++] = '$';
snprintf(encrypted + i, 4, "%2.2u$", logr);
Re: IPv6 by default
On 2014/04/29 23:12, Stuart Henderson wrote: > On 2014/04/29 22:25, Paul de Weerd wrote: > > Disabling IPv6 should not be necessary: it shouldn't be enabled by > > default, even link-local addresses. > > If doing this, then we need a way to enable link-local, like the opposite > of "ifconfig $if -inet6". Current process to re-enable just the link-local > is to configure some other v6 address and delete it again, which is > acceptable when the option to remove the link-local is just used by people > who explicitly don't want v6 at all, but is a bit too ugly if it's > something that people need to use just to enable v6. > > I also wonder about blocking all-nodes mcast in the sample pf.conf... > (personally there are places I find them very useful but I think this is > a saner default - it's always fun doing a node-name query on conference > wifi/etc). > > Index: pf.conf > === > RCS file: /cvs/src/etc/pf.conf,v > retrieving revision 1.53 > diff -u -p -r1.53 pf.conf > --- pf.conf 25 Jan 2014 10:28:36 - 1.53 > +++ pf.conf 29 Apr 2014 21:35:03 - > @@ -19,6 +19,8 @@ set skip on lo > block return # block stateless traffic > pass # establish keep-state > > +block in inet6 proto icmp6 to ff02::1# block all-nodes multicast > queries > + doh. this is not quite targetted enough ;) maybe drop types 128 and 139 - any others?
Re: umodem.c: debug message fix
Il giorno 30/apr/2014 23.11, "SASANO Takayoshi" ha
scritto:
>
> Hello,
>
> I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
> Can I commit the diff?
Ok dcoppa@
>
> SASANO Takayoshi
>
> Index: umodem.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umodem.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 umodem.c
> --- umodem.c30 Jan 2014 20:37:03 - 1.55
> +++ umodem.c30 Apr 2014 19:50:23 -
> @@ -576,7 +576,7 @@ umodem_ioctl(void *addr, int portno, u_l
> if (usbd_is_dying(sc->sc_udev))
> return (EIO);
>
> - DPRINTF(("umodemioctl: cmd=0x%08lx\n", cmd));
> + DPRINTF(("umodem_ioctl: cmd=0x%08lx\n", cmd));
>
> switch (cmd) {
> case USB_GET_CM_OVER_DATA:
> @@ -590,7 +590,7 @@ umodem_ioctl(void *addr, int portno, u_l
> break;
>
> default:
> - DPRINTF(("umodemioctl: unknown\n"));
> + DPRINTF(("umodem_ioctl: unknown\n"));
> error = ENOTTY;
> break;
> }
> @@ -601,7 +601,7 @@ umodem_ioctl(void *addr, int portno, u_l
> void
> umodem_dtr(struct umodem_softc *sc, int onoff)
> {
> - DPRINTF(("umodem_modem: onoff=%d\n", onoff));
> + DPRINTF(("umodem_dtr: onoff=%d\n", onoff));
>
> if (sc->sc_dtr == onoff)
> return;
> @@ -613,7 +613,7 @@ umodem_dtr(struct umodem_softc *sc, int
> void
> umodem_rts(struct umodem_softc *sc, int onoff)
> {
> - DPRINTF(("umodem_modem: onoff=%d\n", onoff));
> + DPRINTF(("umodem_rts: onoff=%d\n", onoff));
>
> if (sc->sc_rts == onoff)
> return;
>
>
Re: [PATCH] xenocara/app/cwm: don't require quotes in autogroup configuration
On Wed, Apr 30, 2014 at 05:12:44PM -0400, Okan Demirmen wrote: > Thank you; I'm aware of these (along with others). If anyone is > waiting for me, please be patient while I find a working > laptop/desktop setup. Ah, ok, sorry to pile on. Thanks for acknowledging my diffs!
Re: [PATCH] xenocara/app/cwm: don't require quotes in autogroup configuration
Thank you; I'm aware of these (along with others). If anyone is
waiting for me, please be patient while I find a working
laptop/desktop setup.
On Wed, Apr 30, 2014 at 5:07 PM, Kent R. Spillner wrote:
> Ping.
>
> On Wed, Apr 23, 2014 at 12:44:38PM -0500, Kent R. Spillner wrote:
>> I think I sent this out a long time ago but never followed up on it. :(
>>
>> According to cwmrc(5) you can configure an autogroup like so:
>>
>> autogroup group windowname,windowclass
>>
>> However, parse.y doesn't actually accept that syntax; you have to put
>> quotes around windowname,windowclass so they're recognized as a single
>> string value, and then conf_autogroup() splits them apart later.
>>
>> This diff adds support to parse.y for recognizing the literal syntax
>> as specified in the man page without the need for quotes (while
>> retaining support for the quoted values for backwards compatibility).
>>
>> For example, today you have to put this in your .cwmrc:
>>
>> autogroup 2 "Navigator,Firefox"
>>
>> But with this diff you could use the following instead:
>>
>> autogroup 2 Navigator,Firefox
>>
>>
>> Index: calmwm.h
>> ===
>> RCS file: /work/cvsroot/xenocara/app/cwm/calmwm.h,v
>> retrieving revision 1.259
>> diff -p -u -r1.259 calmwm.h
>> --- calmwm.h 8 Feb 2014 02:49:30 - 1.259
>> +++ calmwm.h 23 Apr 2014 17:32:02 -
>> @@ -500,7 +500,8 @@ void menuq_clear(struct menu_q *);
>> int parse_config(const char *, struct conf *);
>>
>> void conf_atoms(void);
>> -void conf_autogroup(struct conf *, int, const char *);
>> +void conf_autogroup(struct conf *, int, const char *,
>> + const char *);
>> int conf_bind_kbd(struct conf *, const char *,
>>const char *);
>> int conf_bind_mouse(struct conf *, const char *,
>> Index: conf.c
>> ===
>> RCS file: /work/cvsroot/xenocara/app/cwm/conf.c,v
>> retrieving revision 1.173
>> diff -p -u -r1.173 conf.c
>> --- conf.c21 Apr 2014 12:52:14 - 1.173
>> +++ conf.c23 Apr 2014 17:18:11 -
>> @@ -78,19 +78,31 @@ conf_cmd_remove(struct conf *c, const ch
>> }
>> }
>> void
>> -conf_autogroup(struct conf *c, int no, const char *val)
>> +conf_autogroup(struct conf *c, int no, const char *class, const char *name)
>> {
>> struct autogroupwin *aw;
>> char*p;
>> + const char *tmp;
>>
>> aw = xcalloc(1, sizeof(*aw));
>>
>> - if ((p = strchr(val, ',')) == NULL) {
>> - aw->name = NULL;
>> - aw->class = xstrdup(val);
>> + if ((p = strchr(class, ',')) == NULL) {
>> + if (name == NULL)
>> + aw->name = NULL;
>> + else
>> + aw->name = xstrdup(name);
>> +
>> + aw->class = xstrdup(class);
>> } else {
>> + tmp = class;
>> +
>> *(p++) = '\0';
>> - aw->name = xstrdup(val);
>> +
>> + if (name == NULL)
>> + aw->name = xstrdup(tmp);
>> + else
>> + aw->name = xstrdup(name);
>> +
>> aw->class = xstrdup(p);
>> }
>> aw->num = no;
>> Index: parse.y
>> ===
>> RCS file: /work/cvsroot/xenocara/app/cwm/parse.y,v
>> retrieving revision 1.58
>> diff -p -u -r1.58 parse.y
>> --- parse.y 30 Jan 2014 22:41:16 - 1.58
>> +++ parse.y 23 Apr 2014 17:10:49 -
>> @@ -152,8 +152,18 @@ main : FONTNAME STRING {
>> yyerror("invalid autogroup: %d", $2);
>> YYERROR;
>> }
>> - conf_autogroup(conf, $2, $3);
>> + conf_autogroup(conf, $2, $3, NULL);
>> free($3);
>> + }
>> + | AUTOGROUP NUMBER STRING ',' STRING{
>> + if ($2 < 0 || $2 > 9) {
>> + free($3);
>> + yyerror("invalid autogroup: %d", $2);
>> + YYERROR;
>> + }
>> + conf_autogroup(conf, $2, $5, $3);
>> + free($3);
>> + free($5);
>> }
>> | IGNORE STRING {
>> conf_ignore(conf, $2);
>>
>
umodem.c: debug message fix
Hello,
I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
Can I commit the diff?
SASANO Takayoshi
Index: umodem.c
===
RCS file: /cvs/src/sys/dev/usb/umodem.c,v
retrieving revision 1.55
diff -u -p -r1.55 umodem.c
--- umodem.c30 Jan 2014 20:37:03 - 1.55
+++ umodem.c30 Apr 2014 19:50:23 -
@@ -576,7 +576,7 @@ umodem_ioctl(void *addr, int portno, u_l
if (usbd_is_dying(sc->sc_udev))
return (EIO);
- DPRINTF(("umodemioctl: cmd=0x%08lx\n", cmd));
+ DPRINTF(("umodem_ioctl: cmd=0x%08lx\n", cmd));
switch (cmd) {
case USB_GET_CM_OVER_DATA:
@@ -590,7 +590,7 @@ umodem_ioctl(void *addr, int portno, u_l
break;
default:
- DPRINTF(("umodemioctl: unknown\n"));
+ DPRINTF(("umodem_ioctl: unknown\n"));
error = ENOTTY;
break;
}
@@ -601,7 +601,7 @@ umodem_ioctl(void *addr, int portno, u_l
void
umodem_dtr(struct umodem_softc *sc, int onoff)
{
- DPRINTF(("umodem_modem: onoff=%d\n", onoff));
+ DPRINTF(("umodem_dtr: onoff=%d\n", onoff));
if (sc->sc_dtr == onoff)
return;
@@ -613,7 +613,7 @@ umodem_dtr(struct umodem_softc *sc, int
void
umodem_rts(struct umodem_softc *sc, int onoff)
{
- DPRINTF(("umodem_modem: onoff=%d\n", onoff));
+ DPRINTF(("umodem_rts: onoff=%d\n", onoff));
if (sc->sc_rts == onoff)
return;
Re: [PATCH] xenocara/app/cwm: remove unnecessary zero size check from xmalloc()
Ping.
On Wed, Apr 23, 2014 at 10:48:38PM -0500, Kent R. Spillner wrote:
> The diff below removes the check for siz == 0 in xmalloc() because it is
> unnecessary.
>
> I was curious about the check for siz == 0 in xmalloc() when I first saw
> it, so I dug in further and came to the conclusion it's unnecessary:
>
> * It errors out immediately, so aside from the "zero size" specific error
> message (which users won't see anyways if they start cwm from .xinitrc
> or .xsession) it's not offering any benefit
> * malloc() accepts size zero and returns a pointer to memory that will
> SEGFAULT when accessed anyways, so removing this check isn't going to
> hide any errors
> * All but one of the existing calls to xmalloc() uses sizeof anyways, so
> there's actually very little chance of siz == 0 in practice
> * In fact, there's currently zero chance siz == 0 because the other call
> (in kbfunc_ssh(), kbfunc.c:335) actually passes the value len + 1, so
> even if len was zero -- which it isn't: the value of len comes from
> the fgetln() call on line 330, and fgetln guarantees len > 0 on
> success -- the argument to xmalloc() will always be >= 1 (Unless a
> user has line in ~/.ssh/known_hosts that is SIZE_MAX bytes long, but
> then the memcpy() on the very next line will SEGFAULT anyways)
>
>
> Index: xmalloc.c
> ===
> RCS file: /work/cvsroot/xenocara/app/cwm/xmalloc.c,v
> retrieving revision 1.12
> diff -p -u -r1.12 xmalloc.c
> --- xmalloc.c 17 Dec 2013 16:12:18 - 1.12
> +++ xmalloc.c 24 Apr 2014 03:24:01 -
> @@ -37,8 +37,6 @@ xmalloc(size_t siz)
> {
> void*p;
>
> - if (siz == 0)
> - errx(1, "xmalloc: zero size");
> if ((p = malloc(siz)) == NULL)
> err(1, "malloc");
>
>
Re: [PATCH] xenocara/app/cwm: don't require quotes in autogroup configuration
Ping.
On Wed, Apr 23, 2014 at 12:44:38PM -0500, Kent R. Spillner wrote:
> I think I sent this out a long time ago but never followed up on it. :(
>
> According to cwmrc(5) you can configure an autogroup like so:
>
> autogroup group windowname,windowclass
>
> However, parse.y doesn't actually accept that syntax; you have to put
> quotes around windowname,windowclass so they're recognized as a single
> string value, and then conf_autogroup() splits them apart later.
>
> This diff adds support to parse.y for recognizing the literal syntax
> as specified in the man page without the need for quotes (while
> retaining support for the quoted values for backwards compatibility).
>
> For example, today you have to put this in your .cwmrc:
>
> autogroup 2 "Navigator,Firefox"
>
> But with this diff you could use the following instead:
>
> autogroup 2 Navigator,Firefox
>
>
> Index: calmwm.h
> ===
> RCS file: /work/cvsroot/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.259
> diff -p -u -r1.259 calmwm.h
> --- calmwm.h 8 Feb 2014 02:49:30 - 1.259
> +++ calmwm.h 23 Apr 2014 17:32:02 -
> @@ -500,7 +500,8 @@ void menuq_clear(struct menu_q *);
> int parse_config(const char *, struct conf *);
>
> void conf_atoms(void);
> -void conf_autogroup(struct conf *, int, const char *);
> +void conf_autogroup(struct conf *, int, const char *,
> + const char *);
> int conf_bind_kbd(struct conf *, const char *,
>const char *);
> int conf_bind_mouse(struct conf *, const char *,
> Index: conf.c
> ===
> RCS file: /work/cvsroot/xenocara/app/cwm/conf.c,v
> retrieving revision 1.173
> diff -p -u -r1.173 conf.c
> --- conf.c21 Apr 2014 12:52:14 - 1.173
> +++ conf.c23 Apr 2014 17:18:11 -
> @@ -78,19 +78,31 @@ conf_cmd_remove(struct conf *c, const ch
> }
> }
> void
> -conf_autogroup(struct conf *c, int no, const char *val)
> +conf_autogroup(struct conf *c, int no, const char *class, const char *name)
> {
> struct autogroupwin *aw;
> char*p;
> + const char *tmp;
>
> aw = xcalloc(1, sizeof(*aw));
>
> - if ((p = strchr(val, ',')) == NULL) {
> - aw->name = NULL;
> - aw->class = xstrdup(val);
> + if ((p = strchr(class, ',')) == NULL) {
> + if (name == NULL)
> + aw->name = NULL;
> + else
> + aw->name = xstrdup(name);
> +
> + aw->class = xstrdup(class);
> } else {
> + tmp = class;
> +
> *(p++) = '\0';
> - aw->name = xstrdup(val);
> +
> + if (name == NULL)
> + aw->name = xstrdup(tmp);
> + else
> + aw->name = xstrdup(name);
> +
> aw->class = xstrdup(p);
> }
> aw->num = no;
> Index: parse.y
> ===
> RCS file: /work/cvsroot/xenocara/app/cwm/parse.y,v
> retrieving revision 1.58
> diff -p -u -r1.58 parse.y
> --- parse.y 30 Jan 2014 22:41:16 - 1.58
> +++ parse.y 23 Apr 2014 17:10:49 -
> @@ -152,8 +152,18 @@ main : FONTNAME STRING {
> yyerror("invalid autogroup: %d", $2);
> YYERROR;
> }
> - conf_autogroup(conf, $2, $3);
> + conf_autogroup(conf, $2, $3, NULL);
> free($3);
> + }
> + | AUTOGROUP NUMBER STRING ',' STRING{
> + if ($2 < 0 || $2 > 9) {
> + free($3);
> + yyerror("invalid autogroup: %d", $2);
> + YYERROR;
> + }
> + conf_autogroup(conf, $2, $5, $3);
> + free($3);
> + free($5);
> }
> | IGNORE STRING {
> conf_ignore(conf, $2);
>
Re: [PATCH] xenocara/app/cwm: kill unnecessary memset in conf.c
Ping.
On Wed, Apr 23, 2014 at 10:15:10PM -0500, Kent R. Spillner wrote:
> The diff below removes an unncessary memset() on line 253 of conf.c.
>
> cwm used to support reloading the config file, but okan@ removed that
> functionality about a year ago in favor of simply restarting the whole
> thing. So while it used to be possible to call conf_init() multiple
> times, it is now only ever called once when cwm first starts. The
> memset in conf_init() (conf.c:253) was necessary for re-zero'ing out
> the configuration each time it was reloaded. However, now conf_init()
> is only ever called once (in main(), calmwm.c:110), and since Conf
> is a static variable (calmwm.c:47) the compiler has already initialized
> it zero'ed out for us.
>
>
> Index: conf.c
> ===
> RCS file: /work/cvsroot/xenocara/app/cwm/conf.c,v
> retrieving revision 1.173
> diff -p -u -r1.173 conf.c
> --- conf.c21 Apr 2014 12:52:14 - 1.173
> +++ conf.c24 Apr 2014 02:53:40 -
> @@ -250,8 +250,6 @@ conf_init(struct conf *c)
> {
> unsigned inti;
>
> - (void)memset(c, 0, sizeof(*c));
> -
> c->bwidth = CONF_BWIDTH;
> c->mamount = CONF_MAMOUNT;
> c->snapdist = CONF_SNAPDIST;
>
Re: Questions about LibreSSL
>> I have been following the recent LibreSSL developments quite active and >> would like to contribute. >> >> I have some questions: >> >> - The accelerated assembly code for the crypto, is that gonna stay? > >Of course. Why do you think anyone would try to break code which works? Because it is a huge amount of code. I am naieve about this subject and *thought* that todays compilers do a lot better optimising than in the past and that therefore the assembly code is a hurden instead of an asset. >> - Why not use uint32_t and uint64_t all over (incl the APIs) instead of >> custom XX_ULONG stuff? > > I believe Miod is working at improving this. It situation is far more > complex than you could believe. My brain recoiled when I started to > understand the classes of theoretical machines being supported. > >> AFAIK uint32_t and uint64_t are guaranteed 4 and 8 bytes long. > > Sigh. You don't see to understand the OpenSSL tree. It contains support > for machines that have already turned into gas at the bottom of garbage > dumps. I thought that the idea of LibreSSL was to get rid of all the obsolete OpenSSL stuff. With (u)int*_t that could work. But I agree with the sigh. >> - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, >> des etc.)? > > What problem are you trying to solve? Eliminating #ifdefs. That's all. >> - The FULL_UNROLL macro in aes_locl.h is that gonna stay? > > Why not? What is broken with it? Is this on the critical path? Do > you think that introduces scary risk for people? It is just a question. I looked at aes_locl.h and found that 4 #defines are not used (MAXKC, MAXKB, MAXNR and u16) and it also #includes 3 header files that aren't used in this header file. So I thought that maybe this macros is something of the past and could be eliminated also. With it is a lot of code. That's why I asked. > Please read the current commit logs to understand the focus of the task. Ok. @Miod Vallat, thanks for the info.
Re: data modified on freelist, tmpfs-related?
> I'm not comfortable with introducing more APIs. So
> perhaps we should just punt on the optimization and remove/insert all
> list items. Removing the trap comments that pedro set up...
Since the removal macros poison pointers which should no longer be
dereferenced after the operation, I'm strongly in favour of sticking to
these operations, even if it costs a bit more, timewise.
> Index: uvm_aobj.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 uvm_aobj.c
> --- uvm_aobj.c13 Apr 2014 23:14:15 - 1.61
> +++ uvm_aobj.c30 Apr 2014 14:52:33 -
> @@ -431,6 +431,7 @@ uao_shrink_hash(struct uvm_object *uobj,
> {
> struct uvm_aobj *aobj = (struct uvm_aobj *)uobj;
> struct uao_swhash *new_swhash;
> + struct uao_swhash_elt *elt;
> unsigned long new_hashmask;
> int i;
>
> @@ -456,8 +457,13 @@ uao_shrink_hash(struct uvm_object *uobj,
>* Even though the hash table size is changing, the hash of the buckets
>* we are interested in copying should not change.
>*/
> - for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++)
> - LIST_FIRST(&new_swhash[i]) = LIST_FIRST(&aobj->u_swhash[i]);
> + for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
> + while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
> + elt = LIST_FIRST(&aobj->u_swhash[i]);
> + LIST_REMOVE(elt, list);
> + LIST_INSERT_HEAD(&new_swhash[i], elt, list);
> + }
> + }
>
> free(aobj->u_swhash, M_UVMAOBJ);
>
> @@ -609,7 +615,6 @@ uao_grow_hash(struct uvm_object *uobj, i
> return ENOMEM;
>
> for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
> - /* XXX pedro: shouldn't copying the list pointers be enough? */
> while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
> elt = LIST_FIRST(&aobj->u_swhash[i]);
> LIST_REMOVE(elt, list);
>
>
>
Re: Questions about LibreSSL
Speaking for myself here, but as far as LibreSSL is concerned, I'd say my opinion has a certain weight. > - The accelerated assembly code for the crypto, is that gonna stay? Yes. Including existing code for platforms OpenBSD itself does not run on (e.g. s390). > - Why not use uint32_t and uint64_t all over (incl the APIs) instead of > custom XX_ULONG stuff? I am undecided about this. I have started doing this in one of my trees, and found the result no more readable than the initial code. These ALGORITHM_LONG types stress the fact that they are internal to the algorithm and should not be used (or scarcely used) in public interfaces. > - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, > des etc.)? In the apps, yes, eventually, at least for the algorithms no serious crypto library can afford not embedding. > - The FULL_UNROLL macro in aes_locl.h is that gonna stay? Yes. I am currently working on benchmarking the various code generation option, algorithm by algorithm and platform by platform, to pick the best possible defaults, and it is likely that some platforms will perform better with that define, while some platforms won't. On the other hand, I am seriously considering getting rid of MD32_XARRAY (which was only used for HP's compiler on HP-UX), but, again, not until I've checked the generated code and its performance. Miod
Re: Questions about LibreSSL
> I have been following the recent LibreSSL developments quite active and > would like to contribute. > > I have some questions: > > - The accelerated assembly code for the crypto, is that gonna stay? Of course. Why do you think anyone would try to break code which works? > - Why not use uint32_t and uint64_t all over (incl the APIs) instead of > custom XX_ULONG stuff? I believe Miod is working at improving this. It situation is far more complex than you could believe. My brain recoiled when I started to understand the classes of theoretical machines being supported. > AFAIK uint32_t and uint64_t are guaranteed 4 and 8 bytes long. Sigh. You don't see to understand the OpenSSL tree. It contains support for machines that have already turned into gas at the bottom of garbage dumps. > - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, > des etc.)? What problem are you trying to solve? > - The FULL_UNROLL macro in aes_locl.h is that gonna stay? Why not? What is broken with it? Is this on the critical path? Do you think that introduces scary risk for people? Please read the current commit logs to understand the focus of the task.
Re: polling SSL kerberos and srp support
If I had to guess at this point - SRP may have a future. I'm betting kssl does not, and this should probably go away. On Tue, Apr 29, 2014 at 4:06 PM, Stefan Fritsch wrote: > Am Montag, 28. April 2014, 21:40:30 schrieb Ted Unangst: >> Also note that I'm not really interested in rumors or whispers. You >> don't need to tell me that it's possible somebody else uses >> Kerberos. I know it's possible, that's why I'm asking. I'd like to >> know who. > > One data point: Apache HTTPD 2.4 supports SRP. >
Re: data modified on freelist, tmpfs-related?
> On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote: > > > Date: Wed, 30 Apr 2014 13:39:20 +0100 > > > From: Stuart Henderson > > > > > > Seen when running e2fsprogs regression tests with /tmp on tmpfs > > > > I'm not surprised; tmpfs contains some serious bugs. I recommend not > > using it until those are fixed. > > On the other hand, if we don't use it, we won't find bugs... ;-) That particular bug has been found before. Re-discoverering it is not getting it fixed. Like everything, tmpfs has to be fixed by those who care.
Re: data modified on freelist, tmpfs-related?
On 30 April 2014 16:55, Mark Kettenis wrote: >> From: Mike Belopuhov >> Date: Wed, 30 Apr 2014 16:00:45 +0200 >> >> On 30 April 2014 15:55, Mark Kettenis wrote: >> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST) >> >> From: Mark Kettenis >> >> >> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100 >> >> > From: Stuart Henderson >> >> > >> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs >> >> >> >> I'm not surprised; tmpfs contains some serious bugs. I recommend not >> >> using it until those are fixed. >> > >> > Which means, I'd like somebody else besides espie@ to comment on my >> > uvm_aobj.c list manipulation hack diff. >> > >> >> Diff made sense to me when I looked at it, but I would rather hide >> direct pointer access :/ Perhaps LIST_SWAP does a tiny bit more, >> but it's cleaner and perhaps can be useful in the future. > > I'm not comfortable with introducing more APIs. So > perhaps we should just punt on the optimization and remove/insert all > list items. Removing the trap comments that pedro set up... > I agree.
Re: data modified on freelist, tmpfs-related?
This is probably the simplest way to solve the problem for now.
if we want to mess with sys/queue we can do that separately.
On Wed, Apr 30, 2014 at 8:55 AM, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 30 Apr 2014 16:00:45 +0200
>>
>> On 30 April 2014 15:55, Mark Kettenis wrote:
>> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> >> From: Mark Kettenis
>> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >> > From: Stuart Henderson
>> >> >
>> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>> >>
>> >> I'm not surprised; tmpfs contains some serious bugs. I recommend not
>> >> using it until those are fixed.
>> >
>> > Which means, I'd like somebody else besides espie@ to comment on my
>> > uvm_aobj.c list manipulation hack diff.
>> >
>>
>> Diff made sense to me when I looked at it, but I would rather hide
>> direct pointer access :/ Perhaps LIST_SWAP does a tiny bit more,
>> but it's cleaner and perhaps can be useful in the future.
>
> I'm not comfortable with introducing more APIs. So
> perhaps we should just punt on the optimization and remove/insert all
> list items. Removing the trap comments that pedro set up...
>
> Index: uvm_aobj.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 uvm_aobj.c
> --- uvm_aobj.c 13 Apr 2014 23:14:15 - 1.61
> +++ uvm_aobj.c 30 Apr 2014 14:52:33 -
> @@ -431,6 +431,7 @@ uao_shrink_hash(struct uvm_object *uobj,
> {
> struct uvm_aobj *aobj = (struct uvm_aobj *)uobj;
> struct uao_swhash *new_swhash;
> + struct uao_swhash_elt *elt;
> unsigned long new_hashmask;
> int i;
>
> @@ -456,8 +457,13 @@ uao_shrink_hash(struct uvm_object *uobj,
> * Even though the hash table size is changing, the hash of the
> buckets
> * we are interested in copying should not change.
> */
> - for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++)
> - LIST_FIRST(&new_swhash[i]) = LIST_FIRST(&aobj->u_swhash[i]);
> + for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
> + while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
> + elt = LIST_FIRST(&aobj->u_swhash[i]);
> + LIST_REMOVE(elt, list);
> + LIST_INSERT_HEAD(&new_swhash[i], elt, list);
> + }
> + }
>
> free(aobj->u_swhash, M_UVMAOBJ);
>
> @@ -609,7 +615,6 @@ uao_grow_hash(struct uvm_object *uobj, i
> return ENOMEM;
>
> for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
> - /* XXX pedro: shouldn't copying the list pointers be enough?
> */
> while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
> elt = LIST_FIRST(&aobj->u_swhash[i]);
> LIST_REMOVE(elt, list);
>
>
>
Re: data modified on freelist, tmpfs-related?
On 30 April 2014 10:55, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 30 Apr 2014 16:00:45 +0200
>>
>> On 30 April 2014 15:55, Mark Kettenis wrote:
>> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> >> From: Mark Kettenis
>> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >> > From: Stuart Henderson
>> >> >
>> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>> >>
>> >> I'm not surprised; tmpfs contains some serious bugs. I recommend not
>> >> using it until those are fixed.
>> >
>> > Which means, I'd like somebody else besides espie@ to comment on my
>> > uvm_aobj.c list manipulation hack diff.
>> >
>>
>> Diff made sense to me when I looked at it, but I would rather hide
>> direct pointer access :/ Perhaps LIST_SWAP does a tiny bit more,
>> but it's cleaner and perhaps can be useful in the future.
>
> I'm not comfortable with introducing more APIs. So
> perhaps we should just punt on the optimization and remove/insert all
> list items. Removing the trap comments that pedro set up...
>
> Index: uvm_aobj.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 uvm_aobj.c
> --- uvm_aobj.c 13 Apr 2014 23:14:15 - 1.61
> +++ uvm_aobj.c 30 Apr 2014 14:52:33 -
> @@ -431,6 +431,7 @@ uao_shrink_hash(struct uvm_object *uobj,
> {
> struct uvm_aobj *aobj = (struct uvm_aobj *)uobj;
> struct uao_swhash *new_swhash;
> + struct uao_swhash_elt *elt;
> unsigned long new_hashmask;
> int i;
>
> @@ -456,8 +457,13 @@ uao_shrink_hash(struct uvm_object *uobj,
> * Even though the hash table size is changing, the hash of the
> buckets
> * we are interested in copying should not change.
> */
> - for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++)
> - LIST_FIRST(&new_swhash[i]) = LIST_FIRST(&aobj->u_swhash[i]);
> + for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
> + while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
> + elt = LIST_FIRST(&aobj->u_swhash[i]);
> + LIST_REMOVE(elt, list);
> + LIST_INSERT_HEAD(&new_swhash[i], elt, list);
> + }
> + }
>
> free(aobj->u_swhash, M_UVMAOBJ);
>
> @@ -609,7 +615,6 @@ uao_grow_hash(struct uvm_object *uobj, i
> return ENOMEM;
>
> for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
> - /* XXX pedro: shouldn't copying the list pointers be enough?
> */
> while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
> elt = LIST_FIRST(&aobj->u_swhash[i]);
> LIST_REMOVE(elt, list);
>
>
>
I like this approach better. ok krw@
Ken
Re: data modified on freelist, tmpfs-related?
> From: Mike Belopuhov
> Date: Wed, 30 Apr 2014 16:00:45 +0200
>
> On 30 April 2014 15:55, Mark Kettenis wrote:
> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
> >> From: Mark Kettenis
> >>
> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
> >> > From: Stuart Henderson
> >> >
> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
> >>
> >> I'm not surprised; tmpfs contains some serious bugs. I recommend not
> >> using it until those are fixed.
> >
> > Which means, I'd like somebody else besides espie@ to comment on my
> > uvm_aobj.c list manipulation hack diff.
> >
>
> Diff made sense to me when I looked at it, but I would rather hide
> direct pointer access :/ Perhaps LIST_SWAP does a tiny bit more,
> but it's cleaner and perhaps can be useful in the future.
I'm not comfortable with introducing more APIs. So
perhaps we should just punt on the optimization and remove/insert all
list items. Removing the trap comments that pedro set up...
Index: uvm_aobj.c
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
retrieving revision 1.61
diff -u -p -r1.61 uvm_aobj.c
--- uvm_aobj.c 13 Apr 2014 23:14:15 - 1.61
+++ uvm_aobj.c 30 Apr 2014 14:52:33 -
@@ -431,6 +431,7 @@ uao_shrink_hash(struct uvm_object *uobj,
{
struct uvm_aobj *aobj = (struct uvm_aobj *)uobj;
struct uao_swhash *new_swhash;
+ struct uao_swhash_elt *elt;
unsigned long new_hashmask;
int i;
@@ -456,8 +457,13 @@ uao_shrink_hash(struct uvm_object *uobj,
* Even though the hash table size is changing, the hash of the buckets
* we are interested in copying should not change.
*/
- for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++)
- LIST_FIRST(&new_swhash[i]) = LIST_FIRST(&aobj->u_swhash[i]);
+ for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
+ while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
+ elt = LIST_FIRST(&aobj->u_swhash[i]);
+ LIST_REMOVE(elt, list);
+ LIST_INSERT_HEAD(&new_swhash[i], elt, list);
+ }
+ }
free(aobj->u_swhash, M_UVMAOBJ);
@@ -609,7 +615,6 @@ uao_grow_hash(struct uvm_object *uobj, i
return ENOMEM;
for (i = 0; i < UAO_SWHASH_BUCKETS(aobj->u_pages); i++) {
- /* XXX pedro: shouldn't copying the list pointers be enough? */
while (LIST_EMPTY(&aobj->u_swhash[i]) == 0) {
elt = LIST_FIRST(&aobj->u_swhash[i]);
LIST_REMOVE(elt, list);
Re: data modified on freelist, tmpfs-related?
On 30 April 2014 15:55, Mark Kettenis wrote: >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST) >> From: Mark Kettenis >> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100 >> > From: Stuart Henderson >> > >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs >> >> I'm not surprised; tmpfs contains some serious bugs. I recommend not >> using it until those are fixed. > > Which means, I'd like somebody else besides espie@ to comment on my > uvm_aobj.c list manipulation hack diff. > Diff made sense to me when I looked at it, but I would rather hide direct pointer access :/ Perhaps LIST_SWAP does a tiny bit more, but it's cleaner and perhaps can be useful in the future.
Re: data modified on freelist, tmpfs-related?
> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST) > From: Mark Kettenis > > > Date: Wed, 30 Apr 2014 13:39:20 +0100 > > From: Stuart Henderson > > > > Seen when running e2fsprogs regression tests with /tmp on tmpfs > > I'm not surprised; tmpfs contains some serious bugs. I recommend not > using it until those are fixed. Which means, I'd like somebody else besides espie@ to comment on my uvm_aobj.c list manipulation hack diff.
Re: data modified on freelist, tmpfs-related?
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote: > > Date: Wed, 30 Apr 2014 13:39:20 +0100 > > From: Stuart Henderson > > > > Seen when running e2fsprogs regression tests with /tmp on tmpfs > > I'm not surprised; tmpfs contains some serious bugs. I recommend not > using it until those are fixed. On the other hand, if we don't use it, we won't find bugs... ;-) -- Antoine
Re: data modified on freelist, tmpfs-related?
> Date: Wed, 30 Apr 2014 13:39:20 +0100
> From: Stuart Henderson
>
> Seen when running e2fsprogs regression tests with /tmp on tmpfs
I'm not surprised; tmpfs contains some serious bugs. I recommend not
using it until those are fixed.
> Data modified on freelist: word -35183628471970 of object 0x80d36c00
> size 0x400 previous type free (invalid addr 0xf40858de1f81cbe9)
> panic: Data modified on freelist: word 4 of object 0x80d36c00 size
> 0x400 previous type free (0x0 != 0xdeafbead)
>
> Stopped at Debugger+0x5: leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb{1}> Debugger() at Debugger+0x5
> panic() at panic+0xfe
> malloc() at malloc+0x697
> hashinit() at hashinit+0x3b
> uao_grow_hash() at uao_grow_hash+0x70
> tmpfs_reg_resize() at tmpfs_reg_resize+0xe4
> tmpfs_write() at tmpfs_write+0xfd
> VOP_WRITE() at VOP_WRITE+0x3f
> vn_write() at vn_write+0x98
> dofilewritev() at dofilewritev+0x1c5
> sys_write() at sys_write+0xaa
> syscall() at syscall+0x297
> --- syscall (number 4) ---
> end of kernel
> end trace frame: 0x7f7cfd50, count: -12
> 0xb25a740770a:
> ddb{1}> ds 0x296
> es0x6930
> fs0x6900
> gs0xd1ee
> rdi 0x1
> rsi0x296
> rbp 0x800033276920
> rbx 0x817dac70seltrue_filtops+0xa10
> rdx0
> rcx 0x801c7000
> rax 0x1
> r80x800033276840
> r9 0
> r100
> r110
> r120x100
> r13 0x800033276930
> r14 0xa
> r15 0x5
> rip 0x813403e5Debugger+0x5
> cs 0x8
> rflags 0x202
> rsp 0x800033276920
> ss 0x10
> Debugger+0x5: leave
>
> The end of the dmesg buffer was overwritten by kernel output from
> the following boot, but I have screenshots of bcstats, uvmexp and
> the first page of ps output (active process is gunzip) here:
>
> https://drive.google.com/folderview?id=0B8t-sinTZPnucERodGdCcTc2Mmc&usp=sharing
>
> OpenBSD 5.5-current (GENERIC.MP) #6: Sun Apr 27 14:42:50 BST 2014
> st...@bamboo.spacehopper.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8451125248 (8059MB)
> avail mem = 8217436160 (7836MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries)
> bios0: vendor LENOVO version "8DET63WW (1.33 )" date 07/19/2012
> bios0: LENOVO 4287CTO
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA
> SSDT SSDT UEFI UEFI UEFI
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3)
> EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2791.30 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (applicatio
data modified on freelist, tmpfs-related?
Seen when running e2fsprogs regression tests with /tmp on tmpfs
...
Data modified on freelist: word -35183628471970 of object 0x80d36c00
size 0x400 previous type free (invalid addr 0xf40858de1f81cbe9)
panic: Data modified on freelist: word 4 of object 0x80d36c00 size
0x400 previous type free (0x0 != 0xdeafbead)
Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1}> Debugger() at Debugger+0x5
panic() at panic+0xfe
malloc() at malloc+0x697
hashinit() at hashinit+0x3b
uao_grow_hash() at uao_grow_hash+0x70
tmpfs_reg_resize() at tmpfs_reg_resize+0xe4
tmpfs_write() at tmpfs_write+0xfd
VOP_WRITE() at VOP_WRITE+0x3f
vn_write() at vn_write+0x98
dofilewritev() at dofilewritev+0x1c5
sys_write() at sys_write+0xaa
syscall() at syscall+0x297
--- syscall (number 4) ---
end of kernel
end trace frame: 0x7f7cfd50, count: -12
0xb25a740770a:
ddb{1}> ds 0x296
es0x6930
fs0x6900
gs0xd1ee
rdi 0x1
rsi0x296
rbp 0x800033276920
rbx 0x817dac70seltrue_filtops+0xa10
rdx0
rcx 0x801c7000
rax 0x1
r80x800033276840
r9 0
r100
r110
r120x100
r13 0x800033276930
r14 0xa
r15 0x5
rip 0x813403e5Debugger+0x5
cs 0x8
rflags 0x202
rsp 0x800033276920
ss 0x10
Debugger+0x5: leave
The end of the dmesg buffer was overwritten by kernel output from
the following boot, but I have screenshots of bcstats, uvmexp and
the first page of ps output (active process is gunzip) here:
https://drive.google.com/folderview?id=0B8t-sinTZPnucERodGdCcTc2Mmc&usp=sharing
OpenBSD 5.5-current (GENERIC.MP) #6: Sun Apr 27 14:42:50 BST 2014
st...@bamboo.spacehopper.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8451125248 (8059MB)
avail mem = 8217436160 (7836MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries)
bios0: vendor LENOVO version "8DET63WW (1.33 )" date 07/19/2012
bios0: LENOVO 4287CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT
SSDT UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2791.30 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu3: 256KB 64b/l
Re: IPv6 by default
Le 2014-04-29 22:04, Theo de Raadt a écrit : > measurements all over the world show that IPv4 is better > in every respect. Not disagreeing, but I would like to have access to more data backing this up. I'm not satisfied with what I found (see other post). > Change that, then we can talk. Working on it. ;) http://tools.ietf.org/html/rfc6888 Simon
Questions about LibreSSL
Hello everyone, I have been following the recent LibreSSL developments quite active and would like to contribute. I have some questions: - The accelerated assembly code for the crypto, is that gonna stay? - Why not use uint32_t and uint64_t all over (incl the APIs) instead of custom XX_ULONG stuff? AFAIK uint32_t and uint64_t are guaranteed 4 and 8 bytes long. - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, des etc.)? - The FULL_UNROLL macro in aes_locl.h is that gonna stay? Regards, Gerard
Re: patch: use a lookup table in BIO_get_port()
On Tue, Apr 29, 2014 at 07:57:32PM -0600, Theo de Raadt wrote: > Don't bother with diffs to b_sock.c. Instead, if you have code > which uses it, talk to krw. > > There is a monster diff coming which rewrites it all. > > And by the way, all that code disapears and is replaced by 2 lines. That's great! I am just looking for some work to do the for OpenBSD project. I am skimming through some source code, hopefully I will come up with some patches.
