Re: nextafterl(3) possible bug
>> >> confirming that this patch fixes the failing numpy regress test on i386. >> >> let me know if you want me to test a different diff. > > Here's a better diff, inspired by what FreeBSD has. > > ok? > > ok with me. numpy works with this diff too.
Re: 9p
> Matthew, you obviously did not spot the evil 9p/util.h yet. This file > ought to be named ozymandias.h. > > Also, I am vetoing the addition of -fms-extensions to the kernel build > options. Whatever files require this option to build needs to be fixed > to be proper, unambiguous, C99, instead. I feel I need to go further with commentary. This will strike some as mean. I believe I found one line in the diff which didn't violate community standards, and it was a blank line. The rest... sorry, but it is off our map. This entire diff feels like it is being thrown at us to distract some developer from more important work. Congratulations, it has worked! For a bit... and I hope at this point it ends.
LibreSSL: is there any reason to keep opaque_prf_input?
Hello, I just noticed r1.44 to t1_lib.c. I'm not sure that auditing opaque_prf_input is a good use of anyone's time -- I think it might be better to just run "unifdef -U TLSEXT_TYPE_opaque_prf_input" and be done with it. Here's the history of opaque_prf_input as I understand it: - In 2006, the Department of Defense wanted a TLS extension that could provide extra random inputs for generating the master secret. A draft was produced for an extension that would let the client and server each contribute up to 64 KB of extra "random" material to the PRF. [1] - The draft was abandoned and expired in June of 2007. No extension type was ever assigned. - In September 2007, OpenSSL added support for the expired draft. [2] Of course, since there's no assigned extension type, users need to define one and recompile the library to use the extension. Given that the extension was dead on arrival and implemented post-mortem, I wouldn't be surprised to discover that opaque_prf_input has as many users as big-endian amd64 support. Brendan MacDonell [1] http://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-input-00 [2] https://github.com/openssl/openssl/commit/761772d7e19145fa9afb2a0c830ead69a33f3fa5
Re: 9p
On Wed, 4 Jun 2014, Philip Guenther wrote: > On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck wrote: > > Matthew Dempsky wrote: > > > Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces > > around "->" > > > > Not in cited document, but noted. > > Read more of the existing kernel code. (stupid gmail control-enter binding) Your code should be styled on the existing kernel code. > > All I need are anonymous struct or union members, also legal under > > gnu99 and plan9. Alas, gcc seems to lack an option to enable these > > alone. Then do without them and use _foo and such as the structure members, as seen in structures like struct sigaction and siginfo_t. > > Next version awaits pronunciation on rwlocked sleep. Use tsleep(). Given your first attempt at writing a new synchronization primitive, I'm not interested in reading another without demonstration of greater understanding of the existing primitives. Philip Guenther
Re: 9p
On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck wrote: > Matthew Dempsky wrote: > > Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces > around "->" > > Not in cited document, but noted. > Read more of the existing kernel code. > Oh, and no "static" functions in the kernel. They cause problems with > ddb. > > Even inline functions? > > Miod Vallat wrote: > > Matthew, you obviously did not spot the evil 9p/util.h yet. This file > > ought to be named ozymandias.h. > > I could do that ☺ > > I copied that file from earlier work of mine. I only actually need a > few macros in it, so I shall strip it down for the next version. > > > Also, I am vetoing the addition of -fms-extensions to the kernel build > > options. Whatever files require this option to build needs to be fixed > > to be proper, unambiguous, C99, instead. > > All I need are anonymous struct or union members, also legal under > gnu99 and plan9. Alas, gcc seems to lack an option to enable these > alone. > > Next version awaits pronunciation on rwlocked sleep. > >
Re: 9p
Matthew Dempsky wrote: > Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces around > "->" Not in cited document, but noted. > Oh, and no "static" functions in the kernel. They cause problems with ddb. Even inline functions? Miod Vallat wrote: > Matthew, you obviously did not spot the evil 9p/util.h yet. This file > ought to be named ozymandias.h. I could do that ☺ I copied that file from earlier work of mine. I only actually need a few macros in it, so I shall strip it down for the next version. > Also, I am vetoing the addition of -fms-extensions to the kernel build > options. Whatever files require this option to build needs to be fixed > to be proper, unambiguous, C99, instead. All I need are anonymous struct or union members, also legal under gnu99 and plan9. Alas, gcc seems to lack an option to enable these alone. Next version awaits pronunciation on rwlocked sleep.
Re: nextafterl(3) possible bug
On 6/4/14, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 21:18:26 -0400
>> From: Daniel Dickman
>>
>> >
>> > Another bug. Intel chose an extended precision format with an
>> > explicit integer bit, and the code doesn't handle that. Assuming we
>> > don't support machines with extended precision format that have an
>> > implicit integer bit, the following diff (an adaptation of the code in
>> > glibc) should fix things. Not entirely happy with the fix though, so
>> > I'm still thinking about improvements.
>>
>> confirming that this patch fixes the failing numpy regress test on i386.
>>
>> let me know if you want me to test a different diff.
>
> Here's a better diff, inspired by what FreeBSD has.
>
> ok?
I like it better than the other diff; OK martynas@.
> Index: s_nextafterl.c
> ===
> RCS file: /cvs/src/lib/libm/src/ld80/s_nextafterl.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 s_nextafterl.c
> --- s_nextafterl.c12 Nov 2013 21:07:28 - 1.4
> +++ s_nextafterl.c4 Jun 2014 10:05:17 -
> @@ -32,8 +32,8 @@ nextafterl(long double x, long double y)
> ix = esx&0x7fff;/* |x| */
> iy = esy&0x7fff;/* |y| */
>
> - if (((ix==0x7fff)&&((hx|lx)!=0)) || /* x is nan */
> - ((iy==0x7fff)&&((hy|ly)!=0))) /* y is nan */
> + if (((ix==0x7fff)&&((hx&0x7fff|lx)!=0)) || /* x is nan */
> + ((iy==0x7fff)&&((hy&0x7fff|ly)!=0))) /* y is nan */
> return x+y;
> if(x==y) return y; /* x=y, return y */
> if((ix|hx|lx)==0) { /* x == 0 */
> @@ -47,31 +47,30 @@ nextafterl(long double x, long double y)
> if(ix>iy||((ix==iy) && (hx>hy||((hx==hy)&&(lx>ly) {
> /* x > y, x -= ulp */
> if(lx==0) {
> - if (hx==0) esx -= 1;
> - hx -= 1;
> + if ((hx&0x7fff)==0) esx -= 1;
> + hx = (hx - 1) | (hx & 0x8000);
> }
> lx -= 1;
> } else {/* x < y, x += ulp */
> lx += 1;
> if(lx==0) {
> - hx += 1;
> - if (hx==0)
> - esx += 1;
> + hx = (hx + 1) | (hx & 0x8000);
> + if ((hx&0x7fff)==0) esx += 1;
> }
> }
> } else {/* x < 0 */
> if(esy>=0||(ix>iy||((ix==iy)&&(hx>hy||((hx==hy)&&(lx>ly)){
> /* x < y, x -= ulp */
> if(lx==0) {
> - if (hx==0) esx -= 1;
> - hx -= 1;
> + if ((hx&0x7fff)==0) esx -= 1;
> + hx = (hx - 1) | (hx & 0x8000);
> }
> lx -= 1;
> } else {/* x > y, x += ulp */
> lx += 1;
> if(lx==0) {
> - hx += 1;
> - if (hx==0) esx += 1;
> + hx = (hx + 1) | (hx & 0x8000);
> + if ((hx&0x7fff)==0) esx += 1;
> }
> }
> }
>
Re: 9p
Matthew, you obviously did not spot the evil 9p/util.h yet. This file ought to be named ozymandias.h. Also, I am vetoing the addition of -fms-extensions to the kernel build options. Whatever files require this option to build needs to be fixed to be proper, unambiguous, C99, instead.
Re: 9p
On Wed, Jun 4, 2014 at 2:00 PM, M Farkas-Dyck wrote: > Would a rwlock do? The sender and recver operate asynchronously, so > the sender needs to hold a lock while sending and release it when > asleep, but it can't be a mutex as the send operation may sleep, so I > used requ.ready as the lock, but a rwlock seems appropriate. msleep() unlocks the mutex after the process is placed on the sleep queue, and then relocks the mutex after being woken up. I would expect that should be sufficient for your use case, but I haven't looked close enough. Style nits: Please keep source files ASCII; i.e., "Copyright (C)" instead of the Unicode copyright character. Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces around "->" and we keep lines under 80 characters long. Oh, and no "static" functions in the kernel. They cause problems with ddb.
Re: 9p
On 04/06/2014, Philip Guenther wrote: > The only reason to care whether another kernel thread had made it far > enough into tlseep as to be on a sleep queue is if it's calling wakeup() > on that thread's wait channel, but you MUST use some sort of lock to > protect that shared condition that the tsleeping thread is waiting for, > period. For tsleep(), the involved lock is the kernel lock (aka "big > lock"), while for msleep() it's the passed mutex. Would a rwlock do? The sender and recver operate asynchronously, so the sender needs to hold a lock while sending and release it when asleep, but it can't be a mutex as the send operation may sleep, so I used requ.ready as the lock, but a rwlock seems appropriate.
Re: syncing libc and libkern
> It seems the correct thing to do here is to put the shared part in libc,
> list the file in KSRCS in lib/libc/Makefile.inc, and make copy-to-libkern.
> This allows for only one copy to need to be maintained, and avoids hard
> build-time dependency tentacles between lib/ and sys/.
> (If this is not correct, let me know what's better.)
>
> Unfortunately, libc and libkern haven't been kept in sync for many years
> and I don't see a technical reason why not, so lets bring them together?
That's a slippery slope you're walking on.
>From a theoretical point of view, the routines common to libc and
libkern should be identical.
>From a practical point of view, this is not always the case. I'll only
cite the two most important reasons:
1. libc is a library, and is required to provide entry points for all
its interfaces (such as htonl), so that their address may be used for
function pointers, even if the function itself is a no-op or would
better be an inline; libkern has no such constraints.
2. libc is intended to run in userland, and libkern, well, in the
kernel; running in the kernel might require different code constructs
and/or will allow for privileged instructions to be used (especially
if address spaces are kept completely separate between kernel space
and user space)
> First, str{cat,cpy} were vehemently expunged from the kernel many years ago,
> so stop trying to keep them around.
>
> Index: lib/libc/Makefile.inc
Hello, this is libc you are butchering in. I'm afraid strcat and strcpy
are still required to be in libc by the current C and POSIX standards.
> Next, __P is dead. Theo just removed the mention of it from style(9), and
> this happens to be the last one in libc. It was removed from the libkern
> copy 9 years ago, but that change never made it "upstream" to libc.
>
> Index: lib/libc/quad/qdivrem.c
This one I agree with.
> bcmp(3) was cleaned up in libc, but that never propogated to libkern.
> While here, remove a comment that doesn't belong in the MI version.
>
> This does change the functionality a bit, but anything relying on undefined
> behavior or specific value of "non-zero" here is fundamentally broken, and
> I didn't see anything making such assumptions on a quick grep through sys/.
>
> Index: sys/lib/libkern/bcmp.c
This one brings bad memories, as memcmp() in the kernel used to map to
bcmp() on vax, and this broke red-black trees. But having libkern here
match libc (at least on the platforms where the kernel bcmp() is
provided by this file) will not hurt.
> {h,n}to{n,h}{l,s} and bswap32 have been broken up into different files in
> libc,
> but I'm not sure how to properly break that up into MI/MD components for
> libkern
> and include it in the right places without breaking anything, does somebody
> else
> want to take a look?
See comment about different rules between libc and libkern. Kernels for
platforms with the right byte order need not actually contain these
symbols.
> Also, for future reference, would these patches be preferred in separate
> emails?
Preferrably (and lines trimmed to the usual 72 columns). Although for
simple diffs, this may be acceptable.
Re: LibreSSL memory leak fix
> Hi All,
>
> >From OpenSSL RT:
> http://rt.openssl.org/Ticket/Display.html?id=3278&user=guest&pass=guest
>
> len can be 0 as well, and in which case, memory isn't freed.
Correct. If successful, data is actually a malloc(len + 1), thus if
len == 0, we leak a \0 byte...
> Patch from Frantisek Boranek:
>
> Index: lib/libssl/src/crypto/pkcs12/p12_kiss.c
> ===
> RCS file: /cvs/src/lib/libssl/src/crypto/pkcs12/p12_kiss.c,v
> retrieving revision 1.12
> diff -u -p -u -p -r1.12 p12_kiss.c
> --- lib/libssl/src/crypto/pkcs12/p12_kiss.c 17 Apr 2014 13:37:49 -
> 1.12
> +++ lib/libssl/src/crypto/pkcs12/p12_kiss.c 4 Jun 2014 09:08:37 -
> @@ -269,7 +269,7 @@ static int parse_bag(PKCS12_SAFEBAG *bag
> int len, r;
> unsigned char *data;
> len = ASN1_STRING_to_UTF8(&data, fname);
> - if(len > 0) {
> + if(len >= 0) {
> r = X509_alias_set1(x509, data, len);
> free(data);
> if (!r)
>
Re: LibreSSL SRP fix
On Wed, Jun 04, 2014 at 18:17, Florian Zumbiehl wrote: > Hi all, > > may I draw your attention to this (my) ticket in the OpenSSL bug tracker? > > http://rt.openssl.org/Ticket/Display.html?id=3226&user=guest&pass=guest > > The patch adds various error checks and fixes an undefined return value in > case of error that could happen despite the error checking that's in place > in the SRP implementation. Hi, thanks. We haven't paid much attention to SRP ourselves (and it's not being built atm), but no reason not to make it better. That said, I think the DigestUpdate and similar checks are unnecessary and complicate the code more than they help. Those functions really can't fail. However, I think maybe the free() and BN_clear_free() fixes are still applicable?
LibreSSL SRP fix
Hi all, may I draw your attention to this (my) ticket in the OpenSSL bug tracker? http://rt.openssl.org/Ticket/Display.html?id=3226&user=guest&pass=guest The patch adds various error checks and fixes an undefined return value in case of error that could happen despite the error checking that's in place in the SRP implementation. It's not a nice patch, and it only fixes those parts of the code that I actually need - why bother with polishing a patch for an ugly codebase that is not going to be applied anyhow? Also, it probably won't apply to LibreSSL anymore as-is. If you are interested in pulling it in, I would be willing to clean it up and make it apply to LibreSSL, just let me know. Oh, and thanks for the effort! It's great to see someone finally tackle this, especially when it's people who can reasonably be expected to actually improve things ;-) Regards, Florian
usr.bin/man: use getlist(char *) instead of hand-rolled equivalent in config(char *)
config(char *) contains a hand-rolled version of getlist(char *). The only
difference
is that the hand-rolled version includes a NULL check before the strcmp.
Replace this
with a call to getlist(char *) instead, and move the NULL check there to
protect other
callers as well.
I think we can probably drop the NULL check altogether because we already check
p is not
NULL as the loop condition in the for-loop. However, since the original code
had an
explicit check I decided to preserve it. I'm ok dropping the second hunk of
this diff
if others agree it's unnecessary.
Index: usr.bin/man/config.c
===
RCS file: /work/cvsroot/src/usr.bin/man/config.c,v
retrieving revision 1.9
diff -p -u -r1.9 config.c
--- usr.bin/man/config.c27 Oct 2009 23:59:40 - 1.9
+++ usr.bin/man/config.c4 Jun 2014 14:51:10 -
@@ -92,8 +92,7 @@ config(char *fname)
continue;
*t = '\0';
- for (tp = TAILQ_FIRST(&head); /* Find any matching tag. */
- tp != NULL && strcmp(p, tp->s); tp = TAILQ_NEXT(tp, q));
+ tp = getlist(p);/* Find any matching tag. */
if (tp == NULL) /* Create a new tag. */
tp = addlist(p);
@@ -147,6 +146,9 @@ TAG *
getlist(char *name)
{
TAG *tp;
+
+ if (name == NULL)
+ return (NULL);
TAILQ_FOREACH(tp, &head, q)
if (!strcmp(name, tp->s))
Patch: fix run(4) support for rt5592 devices
RT5592 devices have a larger TXWI and RXWI than other adapters supported
by run(4). The following patch adds the offset adjustments that were
overlooked in r1.98.
Using the patch, I can connect to 11g and 11b APs, though there's still
one nit: after scanning channels in the 5GHz range, the adapter can't
reliably transmit and receive on 2.4GHz channels. Until I figure out
what isn't being reset properly, I'm working around it by specifying
"media OFDM54 mode 11g".
(Sent with a DWA 160 rev. B2.)
Index: if_run.c
===
RCS file: /home/cvsync/openbsd/src/sys/dev/usb/if_run.c,v
retrieving revision 1.98
diff -u -p -r1.98 if_run.c
--- if_run.c24 May 2014 10:10:17 - 1.98
+++ if_run.c4 Jun 2014 15:31:31 -
@@ -781,6 +781,11 @@ run_alloc_tx_ring(struct run_softc *sc,
{
struct run_tx_ring *txq = &sc->txq[qid];
int i, error;
+ uint16_t txwisize;
+
+ txwisize = sizeof(struct rt2860_txwi);
+ if (sc->mac_ver == 0x5592)
+ txwisize += sizeof(uint32_t);
txq->cur = txq->queued = 0;
@@ -805,8 +810,7 @@ run_alloc_tx_ring(struct run_softc *sc,
goto fail;
}
/* zeroize the TXD + TXWI part */
- memset(data->buf, 0, sizeof (struct rt2870_txd) +
- sizeof (struct rt2860_txwi));
+ memset(data->buf, 0, sizeof(struct rt2870_txd) + txwisize);
}
if (error != 0)
fail: run_free_tx_ring(sc, qid);
@@ -2312,6 +2316,13 @@ run_rxeof(struct usbd_xfer *xfer, void *
uint8_t *buf;
uint32_t dmalen;
int xferlen;
+ uint16_t rxwisize;
+
+ rxwisize = sizeof(struct rt2860_rxwi);
+ if (sc->mac_ver == 0x5592)
+ rxwisize += sizeof(uint64_t);
+ else if (sc->mac_ver == 0x3593)
+ rxwisize += sizeof(uint32_t);
if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
DPRINTF(("RX status=%d\n", status));
@@ -2323,8 +2334,8 @@ run_rxeof(struct usbd_xfer *xfer, void *
}
usbd_get_xfer_status(xfer, NULL, NULL, &xferlen, NULL);
- if (__predict_false(xferlen < sizeof (uint32_t) +
- sizeof (struct rt2860_rxwi) + sizeof (struct rt2870_rxd))) {
+ if (__predict_false(xferlen < sizeof (uint32_t) + rxwisize +
+ sizeof(struct rt2870_rxd))) {
DPRINTF(("xfer too short %d\n", xferlen));
goto skip;
}
@@ -2394,6 +2405,7 @@ run_tx(struct run_softc *sc, struct mbuf
struct rt2870_txd *txd;
struct rt2860_txwi *txwi;
uint16_t qos, dur;
+ uint16_t txwisize;
uint8_t type, mcs, tid, qid;
int error, hasqos, ridx, ctl_ridx, xferlen;
@@ -2429,7 +2441,11 @@ run_tx(struct run_softc *sc, struct mbuf
/* get MCS code from rate index */
mcs = rt2860_rates[ridx].mcs;
- xferlen = sizeof (*txwi) + m->m_pkthdr.len;
+ txwisize = sizeof(struct rt2860_txwi);
+ if (sc->mac_ver == 0x5592)
+ txwisize += sizeof(uint32_t);
+ xferlen = txwisize + m->m_pkthdr.len;
+
/* roundup to 32-bit alignment */
xferlen = (xferlen + 3) & ~3;
@@ -2489,7 +2505,7 @@ run_tx(struct run_softc *sc, struct mbuf
}
#endif
- m_copydata(m, 0, m->m_pkthdr.len, (caddr_t)(txwi + 1));
+ m_copydata(m, 0, m->m_pkthdr.len, (caddr_t)txwi + txwisize);
m_freem(m);
xferlen += sizeof (*txd) + 4;
Re: ftp.fr mirror is going down
The ftp.fr mirror is going down for an undefined period of time (could be forever). Please migrate to another mirror for the time being. Hi. So, ftp.fr should be back in about 10 days in full shape on a much much better hardware for a long time hopefully ;-) Sorry for the inconvenience. -- Antoine
Re: in_pcbbind() and in_broadcast/in_iawithaddr
On 3 June 2014 09:18, Martin Pieuchot wrote: > On 02/06/14(Mon) 15:45, Martin Pieuchot wrote: >> This diff is similar to the one that has been committed to handle the >> SOCK_RAW binding. I'd like to stop using in_iawithaddr() *and* >> in_broadcast(). Since these functions are just doing an iteration on >> all the addresses present in the RB-tree (or equivalent), let's use >> ifa_ifwithaddr() instead. >> >> This diff should not introduce any behavior change concerning SOCK_DGRAM >> and binding to multicast addresses. > > As pointed out by jca@ this diff breaks on loopback. This is because > the loopback IPv4 addresses are abusing the dstaddr field to be able to > create a route to their address. Hopefully this hack can be removed > once the local route diff is in, but in the meantime let's use the less > intuitive but equivalent idiom: > > sin->sin_addr.s_addr != ia->ia_addr.s_addr > > Update diff below, is this one ok? > OK
Re: Remove a global variable in ip_input
On 4 June 2014 12:30, Martin Pieuchot wrote: > ok? > sure
Re: Remove a global variable in ip_input
On 04/06/14(Wed) 12:45, Bret Lambert wrote:
> On Wed, Jun 04, 2014 at 12:30:58PM +0200, Martin Pieuchot wrote:
> > ok?
>
> Seems reasonable enough; are there any alignment issues placing
> it on the stack?
Nop, it's just a structure used to do some address lookups, it's already
done like that in other places :)
> > Index: netinet/ip_input.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
> > retrieving revision 1.233
> > diff -u -p -r1.233 ip_input.c
> > --- netinet/ip_input.c 10 May 2014 12:30:27 - 1.233
> > +++ netinet/ip_input.c 4 Jun 2014 10:28:29 -
> > @@ -190,7 +190,6 @@ ip_init(void)
> > strlcpy(ipsec_def_comp, IPSEC_DEFAULT_DEF_COMP, sizeof(ipsec_def_comp));
> > }
> >
> > -struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET };
> > struct route ipforward_rt;
> >
> > void
> > @@ -1003,6 +1002,7 @@ int
> > ip_dooptions(struct mbuf *m, struct ifnet *ifp)
> > {
> > struct ip *ip = mtod(m, struct ip *);
> > + struct sockaddr_in ipaddr;
> > u_char *cp;
> > struct ip_timestamp ipt;
> > struct in_ifaddr *ia;
> > @@ -1057,6 +1057,9 @@ ip_dooptions(struct mbuf *m, struct ifne
> > code = &cp[IPOPT_OFFSET] - (u_char *)ip;
> > goto bad;
> > }
> > + memset(&ipaddr, 0, sizeof(ipaddr));
> > + ipaddr.sin_family = AF_INET;
> > + ipaddr.sin_len = sizeof(ipaddr);
> > ipaddr.sin_addr = ip->ip_dst;
> > ia = ifatoia(ifa_ifwithaddr(sintosa(&ipaddr),
> > m->m_pkthdr.ph_rtableid));
> > @@ -1084,6 +1087,9 @@ ip_dooptions(struct mbuf *m, struct ifne
> > /*
> > * locate outgoing interface
> > */
> > + memset(&ipaddr, 0, sizeof(ipaddr));
> > + ipaddr.sin_family = AF_INET;
> > + ipaddr.sin_len = sizeof(ipaddr);
> > memcpy(&ipaddr.sin_addr, cp + off,
> > sizeof(ipaddr.sin_addr));
> > if (opt == IPOPT_SSRR) {
> > @@ -1126,8 +1132,10 @@ ip_dooptions(struct mbuf *m, struct ifne
> > off--; /* 0 origin */
> > if ((off + sizeof(struct in_addr)) > optlen)
> > break;
> > - memcpy(&ipaddr.sin_addr, &ip->ip_dst,
> > - sizeof(ipaddr.sin_addr));
> > + memset(&ipaddr, 0, sizeof(ipaddr));
> > + ipaddr.sin_family = AF_INET;
> > + ipaddr.sin_len = sizeof(ipaddr);
> > + ipaddr.sin_addr = ip->ip_dst;
> > /*
> > * locate outgoing interface; if we're the destination,
> > * use the incoming interface (should be same).
> > @@ -1168,6 +1176,9 @@ ip_dooptions(struct mbuf *m, struct ifne
> > if (ipt.ipt_ptr - 1 + sizeof(n_time) +
> > sizeof(struct in_addr) > ipt.ipt_len)
> > goto bad;
> > + memset(&ipaddr, 0, sizeof(ipaddr));
> > + ipaddr.sin_family = AF_INET;
> > + ipaddr.sin_len = sizeof(ipaddr);
> > ipaddr.sin_addr = dst;
> > ia = ifatoia(ifaof_ifpforaddr(sintosa(&ipaddr),
> > ifp));
> > @@ -1182,8 +1193,10 @@ ip_dooptions(struct mbuf *m, struct ifne
> > if (ipt.ipt_ptr - 1 + sizeof(n_time) +
> > sizeof(struct in_addr) > ipt.ipt_len)
> > goto bad;
> > - memcpy(&ipaddr.sin_addr, &sin,
> > - sizeof(struct in_addr));
> > + memset(&ipaddr, 0, sizeof(ipaddr));
> > + ipaddr.sin_family = AF_INET;
> > + ipaddr.sin_len = sizeof(ipaddr);
> > + ipaddr.sin_addr = sin;
> > if (ifa_ifwithaddr(sintosa(&ipaddr),
> > m->m_pkthdr.ph_rtableid) == 0)
> > continue;
> >
>
Re: Remove a global variable in ip_input
On Wed, Jun 04, 2014 at 12:30:58PM +0200, Martin Pieuchot wrote:
> ok?
Seems reasonable enough; are there any alignment issues placing
it on the stack?
>
> Index: netinet/ip_input.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
> retrieving revision 1.233
> diff -u -p -r1.233 ip_input.c
> --- netinet/ip_input.c10 May 2014 12:30:27 - 1.233
> +++ netinet/ip_input.c4 Jun 2014 10:28:29 -
> @@ -190,7 +190,6 @@ ip_init(void)
> strlcpy(ipsec_def_comp, IPSEC_DEFAULT_DEF_COMP, sizeof(ipsec_def_comp));
> }
>
> -struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET };
> struct route ipforward_rt;
>
> void
> @@ -1003,6 +1002,7 @@ int
> ip_dooptions(struct mbuf *m, struct ifnet *ifp)
> {
> struct ip *ip = mtod(m, struct ip *);
> + struct sockaddr_in ipaddr;
> u_char *cp;
> struct ip_timestamp ipt;
> struct in_ifaddr *ia;
> @@ -1057,6 +1057,9 @@ ip_dooptions(struct mbuf *m, struct ifne
> code = &cp[IPOPT_OFFSET] - (u_char *)ip;
> goto bad;
> }
> + memset(&ipaddr, 0, sizeof(ipaddr));
> + ipaddr.sin_family = AF_INET;
> + ipaddr.sin_len = sizeof(ipaddr);
> ipaddr.sin_addr = ip->ip_dst;
> ia = ifatoia(ifa_ifwithaddr(sintosa(&ipaddr),
> m->m_pkthdr.ph_rtableid));
> @@ -1084,6 +1087,9 @@ ip_dooptions(struct mbuf *m, struct ifne
> /*
>* locate outgoing interface
>*/
> + memset(&ipaddr, 0, sizeof(ipaddr));
> + ipaddr.sin_family = AF_INET;
> + ipaddr.sin_len = sizeof(ipaddr);
> memcpy(&ipaddr.sin_addr, cp + off,
> sizeof(ipaddr.sin_addr));
> if (opt == IPOPT_SSRR) {
> @@ -1126,8 +1132,10 @@ ip_dooptions(struct mbuf *m, struct ifne
> off--; /* 0 origin */
> if ((off + sizeof(struct in_addr)) > optlen)
> break;
> - memcpy(&ipaddr.sin_addr, &ip->ip_dst,
> - sizeof(ipaddr.sin_addr));
> + memset(&ipaddr, 0, sizeof(ipaddr));
> + ipaddr.sin_family = AF_INET;
> + ipaddr.sin_len = sizeof(ipaddr);
> + ipaddr.sin_addr = ip->ip_dst;
> /*
>* locate outgoing interface; if we're the destination,
>* use the incoming interface (should be same).
> @@ -1168,6 +1176,9 @@ ip_dooptions(struct mbuf *m, struct ifne
> if (ipt.ipt_ptr - 1 + sizeof(n_time) +
> sizeof(struct in_addr) > ipt.ipt_len)
> goto bad;
> + memset(&ipaddr, 0, sizeof(ipaddr));
> + ipaddr.sin_family = AF_INET;
> + ipaddr.sin_len = sizeof(ipaddr);
> ipaddr.sin_addr = dst;
> ia = ifatoia(ifaof_ifpforaddr(sintosa(&ipaddr),
> ifp));
> @@ -1182,8 +1193,10 @@ ip_dooptions(struct mbuf *m, struct ifne
> if (ipt.ipt_ptr - 1 + sizeof(n_time) +
> sizeof(struct in_addr) > ipt.ipt_len)
> goto bad;
> - memcpy(&ipaddr.sin_addr, &sin,
> - sizeof(struct in_addr));
> + memset(&ipaddr, 0, sizeof(ipaddr));
> + ipaddr.sin_family = AF_INET;
> + ipaddr.sin_len = sizeof(ipaddr);
> + ipaddr.sin_addr = sin;
> if (ifa_ifwithaddr(sintosa(&ipaddr),
> m->m_pkthdr.ph_rtableid) == 0)
> continue;
>
Remove a global variable in ip_input
ok?
Index: netinet/ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.233
diff -u -p -r1.233 ip_input.c
--- netinet/ip_input.c 10 May 2014 12:30:27 - 1.233
+++ netinet/ip_input.c 4 Jun 2014 10:28:29 -
@@ -190,7 +190,6 @@ ip_init(void)
strlcpy(ipsec_def_comp, IPSEC_DEFAULT_DEF_COMP, sizeof(ipsec_def_comp));
}
-struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET };
struct route ipforward_rt;
void
@@ -1003,6 +1002,7 @@ int
ip_dooptions(struct mbuf *m, struct ifnet *ifp)
{
struct ip *ip = mtod(m, struct ip *);
+ struct sockaddr_in ipaddr;
u_char *cp;
struct ip_timestamp ipt;
struct in_ifaddr *ia;
@@ -1057,6 +1057,9 @@ ip_dooptions(struct mbuf *m, struct ifne
code = &cp[IPOPT_OFFSET] - (u_char *)ip;
goto bad;
}
+ memset(&ipaddr, 0, sizeof(ipaddr));
+ ipaddr.sin_family = AF_INET;
+ ipaddr.sin_len = sizeof(ipaddr);
ipaddr.sin_addr = ip->ip_dst;
ia = ifatoia(ifa_ifwithaddr(sintosa(&ipaddr),
m->m_pkthdr.ph_rtableid));
@@ -1084,6 +1087,9 @@ ip_dooptions(struct mbuf *m, struct ifne
/*
* locate outgoing interface
*/
+ memset(&ipaddr, 0, sizeof(ipaddr));
+ ipaddr.sin_family = AF_INET;
+ ipaddr.sin_len = sizeof(ipaddr);
memcpy(&ipaddr.sin_addr, cp + off,
sizeof(ipaddr.sin_addr));
if (opt == IPOPT_SSRR) {
@@ -1126,8 +1132,10 @@ ip_dooptions(struct mbuf *m, struct ifne
off--; /* 0 origin */
if ((off + sizeof(struct in_addr)) > optlen)
break;
- memcpy(&ipaddr.sin_addr, &ip->ip_dst,
- sizeof(ipaddr.sin_addr));
+ memset(&ipaddr, 0, sizeof(ipaddr));
+ ipaddr.sin_family = AF_INET;
+ ipaddr.sin_len = sizeof(ipaddr);
+ ipaddr.sin_addr = ip->ip_dst;
/*
* locate outgoing interface; if we're the destination,
* use the incoming interface (should be same).
@@ -1168,6 +1176,9 @@ ip_dooptions(struct mbuf *m, struct ifne
if (ipt.ipt_ptr - 1 + sizeof(n_time) +
sizeof(struct in_addr) > ipt.ipt_len)
goto bad;
+ memset(&ipaddr, 0, sizeof(ipaddr));
+ ipaddr.sin_family = AF_INET;
+ ipaddr.sin_len = sizeof(ipaddr);
ipaddr.sin_addr = dst;
ia = ifatoia(ifaof_ifpforaddr(sintosa(&ipaddr),
ifp));
@@ -1182,8 +1193,10 @@ ip_dooptions(struct mbuf *m, struct ifne
if (ipt.ipt_ptr - 1 + sizeof(n_time) +
sizeof(struct in_addr) > ipt.ipt_len)
goto bad;
- memcpy(&ipaddr.sin_addr, &sin,
- sizeof(struct in_addr));
+ memset(&ipaddr, 0, sizeof(ipaddr));
+ ipaddr.sin_family = AF_INET;
+ ipaddr.sin_len = sizeof(ipaddr);
+ ipaddr.sin_addr = sin;
if (ifa_ifwithaddr(sintosa(&ipaddr),
m->m_pkthdr.ph_rtableid) == 0)
continue;
Re: nextafterl(3) possible bug
> Date: Mon, 2 Jun 2014 21:18:26 -0400
> From: Daniel Dickman
>
> >
> > Another bug. Intel chose an extended precision format with an
> > explicit integer bit, and the code doesn't handle that. Assuming we
> > don't support machines with extended precision format that have an
> > implicit integer bit, the following diff (an adaptation of the code in
> > glibc) should fix things. Not entirely happy with the fix though, so
> > I'm still thinking about improvements.
>
> confirming that this patch fixes the failing numpy regress test on i386.
>
> let me know if you want me to test a different diff.
Here's a better diff, inspired by what FreeBSD has.
ok?
Index: s_nextafterl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_nextafterl.c,v
retrieving revision 1.4
diff -u -p -r1.4 s_nextafterl.c
--- s_nextafterl.c 12 Nov 2013 21:07:28 - 1.4
+++ s_nextafterl.c 4 Jun 2014 10:05:17 -
@@ -32,8 +32,8 @@ nextafterl(long double x, long double y)
ix = esx&0x7fff;/* |x| */
iy = esy&0x7fff;/* |y| */
- if (((ix==0x7fff)&&((hx|lx)!=0)) || /* x is nan */
- ((iy==0x7fff)&&((hy|ly)!=0))) /* y is nan */
+ if (((ix==0x7fff)&&((hx&0x7fff|lx)!=0)) || /* x is nan */
+ ((iy==0x7fff)&&((hy&0x7fff|ly)!=0))) /* y is nan */
return x+y;
if(x==y) return y; /* x=y, return y */
if((ix|hx|lx)==0) { /* x == 0 */
@@ -47,31 +47,30 @@ nextafterl(long double x, long double y)
if(ix>iy||((ix==iy) && (hx>hy||((hx==hy)&&(lx>ly) {
/* x > y, x -= ulp */
if(lx==0) {
- if (hx==0) esx -= 1;
- hx -= 1;
+ if ((hx&0x7fff)==0) esx -= 1;
+ hx = (hx - 1) | (hx & 0x8000);
}
lx -= 1;
} else {/* x < y, x += ulp */
lx += 1;
if(lx==0) {
- hx += 1;
- if (hx==0)
- esx += 1;
+ hx = (hx + 1) | (hx & 0x8000);
+ if ((hx&0x7fff)==0) esx += 1;
}
}
} else {/* x < 0 */
if(esy>=0||(ix>iy||((ix==iy)&&(hx>hy||((hx==hy)&&(lx>ly)){
/* x < y, x -= ulp */
if(lx==0) {
- if (hx==0) esx -= 1;
- hx -= 1;
+ if ((hx&0x7fff)==0) esx -= 1;
+ hx = (hx - 1) | (hx & 0x8000);
}
lx -= 1;
} else {/* x > y, x += ulp */
lx += 1;
if(lx==0) {
- hx += 1;
- if (hx==0) esx += 1;
+ hx = (hx + 1) | (hx & 0x8000);
+ if ((hx&0x7fff)==0) esx += 1;
}
}
}
LibreSSL memory leak fix
Hi All,
>From OpenSSL RT:
http://rt.openssl.org/Ticket/Display.html?id=3278&user=guest&pass=guest
len can be 0 as well, and in which case, memory isn't freed.
Patch from Frantisek Boranek:
Index: lib/libssl/src/crypto/pkcs12/p12_kiss.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/pkcs12/p12_kiss.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 p12_kiss.c
--- lib/libssl/src/crypto/pkcs12/p12_kiss.c 17 Apr 2014 13:37:49 -
1.12
+++ lib/libssl/src/crypto/pkcs12/p12_kiss.c 4 Jun 2014 09:08:37 -
@@ -269,7 +269,7 @@ static int parse_bag(PKCS12_SAFEBAG *bag
int len, r;
unsigned char *data;
len = ASN1_STRING_to_UTF8(&data, fname);
- if(len > 0) {
+ if(len >= 0) {
r = X509_alias_set1(x509, data, len);
free(data);
if (!r)
Re: 9p
On 2014 Jun 04 (Wed) at 02:19:49 -0500 (-0500), strake...@gmail.com wrote: :On Tue, Jun 03, 2014 at 10:44:57PM -0700, Philip Guenther wrote: :> > Yes, some code I copied verbatim from plan9port or earlier work of mine, :> > so that's fully in plan9 or my habitual style. :> :> IF YOU COPIED MORE THAN TRIVIAL CODE FROM plan9port YOU MUST ACKNOWLEDGE :> IT BY INCLUDING THEIR COPYRIGHT ON IT AND ABIDING BY THEIR LICENSE :> RESTRICTIONS. : :Erratum: I copied part of 9p.h from libixp, not plan9port. The license seems equivalent to ISC. I include it in latest version below. : :Too, I copied some functions from userspace libc to libkern. : :The rest is mine. : :> In case you are able to resolve the copyright and license issues with :> this, here are some comments on the synchronization logic in it: : :Thanks. I have to sleep myself soon, so I shall leave this until after that. : You need to add the (correct) copyright statements to EACH AND EVERY FILE. Period. For files that have copied lines, you need to also copy their entire copyright statement from the file. For lines that you wrote, you need to add your own copyright statement. -- Children are unpredictable. You never know what inconsistency they're going to catch you in next. -- Franklin P. Jones
