[PATCH] orders.html 5.6 - 5.7
Hi all, Just noticed that 'orders.html' page escaped the 5.6 - 5.7 update. WARNING!: I had also updated the path to the CD cover small GIF file but this one is yet to be created. I had not created one as I wasn't sure whether you'd simply use http://www.openbsd.org/images/bluefish.jpg as the source to create the mini GIF version or use another file. Regards, Raf Index: orders.html === RCS file: /cvs/www/orders.html,v retrieving revision 1.580 diff -u -p -r1.580 orders.html --- orders.html 5 Feb 2015 06:20:56 - 1.580 +++ orders.html 5 May 2015 12:31:11 - @@ -18,10 +18,10 @@ table tr td align=center width=150 - OpenBSD 5.6br - Nov 1, 2014br + OpenBSD 5.7br + May 1, 2015br a href=https://openbsdstore.com; - img height=127 width=90 src=images/cd56-s.gif/a + img height=127 width=90 src=images/cd57-s.gif/a /td td Every six months (around May 1 and Nov 1) OpenBSD makes an official software release.
Re: seccomp system call
On Mon, 4 May 2015, Todd C. Miller wrote: On Sun, 03 May 2015 20:44:25 -, Loganaden Velvindron wrote: OpenBSD already has systrace. Last I checked, systrace doesn't work well with multi-threaded programs and was trivial to bypass. The basic design where you have a userland monitor process is flawed. Something where a policy is pushed into (and enforced by) the kernel would be better. seccomp-bpf doesn't offer inspection of indirect syscall arguments either, so in that regard it's no better than systrace. AFAIK it would be less intrusive, have fewer knobs and not need a persistent root-privileged monitor process though. -d
Re: seccomp system call
On Mon, 4 May 2015, Theo de Raadt wrote: Personally, I think seccomp-bpf could be a superior alternative to systrace and I'd love to see an implementation. Other developers (inc. Theo) are skeptical though, but this is probably a case where the argument won't be settled without a concrete implementation to look at. I am very skeptical about a bpf-style model, because: People are currently writing policies specific to what glibc does; or what they believe it is doing. I don't think we could expect to use syscall policies written for Linux as anything more than rough guidance (or perhaps cautionary example) Those policies will be wide open, or too strict. If we adopt this into our world, the next step after that is going to be wide use of #ifdef within bpf rulesets. I don't think that's necessarily true, OpenSSH only uses ifdef in the systrace rulesets for new/deprecated syscalls and the bpf rulesets would be identical. Most other privsep daemons would be in a similar boat I expect. -d
Re: [PATCH] orders.html 5.6 - 5.7
Hi Raf, Raf Czlonka wrote on Tue, May 05, 2015 at 01:41:17PM +0100: Just noticed that 'orders.html' page escaped the 5.6 - 5.7 update. Done, thanks for mentioning it. WARNING!: I had also updated the path to the CD cover small GIF file but this one is yet to be created. I had not created one as I wasn't sure whether you'd simply use http://www.openbsd.org/images/bluefish.jpg as the source to create the mini GIF version or use another file. Well, for now, i have simply generated a thumbnail of the usual size from an image of the CD packaging; i guess that's good enough. Otherwise, any developer who knows better can improve the image. Yours, Ingo Index: orders.html === RCS file: /cvs/www/orders.html,v retrieving revision 1.580 diff -u -p -r1.580 orders.html --- orders.html 5 Feb 2015 06:20:56 - 1.580 +++ orders.html 5 May 2015 12:31:11 - @@ -18,10 +18,10 @@ table tr td align=center width=150 - OpenBSD 5.6br - Nov 1, 2014br + OpenBSD 5.7br + May 1, 2015br a href=https://openbsdstore.com; - img height=127 width=90 src=images/cd56-s.gif/a + img height=127 width=90 src=images/cd57-s.gif/a /td td Every six months (around May 1 and Nov 1) OpenBSD makes an official software release.
Re: getprogname(3) manpage fix
Hi Kaspars, committed, thanks. Ingo Kaspars Bankovskis wrote on Mon, May 04, 2015 at 11:45:17PM +0300: Index: getprogname.3 === RCS file: /cvs/src/lib/libc/gen/getprogname.3,v retrieving revision 1.4 diff -u -p -r1.4 getprogname.3 --- getprogname.3 31 Jul 2013 16:43:27 - 1.4 +++ getprogname.3 4 May 2015 20:34:35 - @@ -55,7 +55,7 @@ or other diagnostic output. The .Fn setprogname function sets the name of the program to be the last path component of the -.Fa progname +.Fa name argument. Internally, only the pointer to the given string is kept as the program name, so it should not be modified and the storage for the string must remain valid @@ -65,9 +65,9 @@ for the rest of the program's lifetime. .Xr setproctitle 3 .Sh HISTORY The -.Nm getprogname +.Fn getprogname and -.Nm setprogname +.Fn setprogname functions first appeared in .Ox 5.4 as function-based wrappers around the
trunk is out, special offer with LACP included!
Now that the stack is ready, here's a diff to take the first victim,
trunk(4), out of ether_input().
If you glanced over previous versions of this diff, the differences
are mostly in sys/net/trunklacp.c and include some printf(9) fixes
in bonus.
Ok?
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.195
diff -u -p -r1.195 if_ethersubr.c
--- net/if_ethersubr.c 4 May 2015 10:24:08 - 1.195
+++ net/if_ethersubr.c 5 May 2015 12:10:25 -
@@ -463,9 +463,6 @@ ether_input(struct mbuf *m, void *hdr)
int llcfound = 0;
struct llc *l;
struct arpcom *ac;
-#if NTRUNK 0
- int i = 0;
-#endif
#if NPPPOE 0
struct ether_header *eh_tmp;
#endif
@@ -480,21 +477,6 @@ ether_input(struct mbuf *m, void *hdr)
m_adj(m, ETHER_HDR_LEN);
}
-#if NTRUNK 0
- /* Handle input from a trunk port */
- while (ifp-if_type == IFT_IEEE8023ADLAG) {
- if (++i TRUNK_MAX_STACKING) {
- m_freem(m);
- return (1);
- }
- if (trunk_input(ifp, eh, m) != 0)
- return (1);
-
- /* Has been set to the trunk interface */
- ifp = m-m_pkthdr.rcvif;
- }
-#endif
-
if ((ifp-if_flags IFF_UP) == 0) {
m_freem(m);
return (1);
@@ -518,17 +500,9 @@ ether_input(struct mbuf *m, void *hdr)
else
m-m_flags |= M_MCAST;
ifp-if_imcasts++;
-#if NTRUNK 0
- if (ifp != ifp0)
- ifp0-if_imcasts++;
-#endif
}
ifp-if_ibytes += m-m_pkthdr.len + sizeof(*eh);
-#if NTRUNK 0
- if (ifp != ifp0)
- ifp0-if_ibytes += m-m_pkthdr.len + sizeof(*eh);
-#endif
etype = ntohs(eh-ether_type);
Index: net/if_trunk.c
===
RCS file: /cvs/src/sys/net/if_trunk.c,v
retrieving revision 1.95
diff -u -p -r1.95 if_trunk.c
--- net/if_trunk.c 14 Mar 2015 03:38:51 - 1.95
+++ net/if_trunk.c 5 May 2015 13:09:53 -
@@ -94,14 +94,14 @@ int trunk_rr_detach(struct trunk_softc
voidtrunk_rr_port_destroy(struct trunk_port *);
int trunk_rr_start(struct trunk_softc *, struct mbuf *);
int trunk_rr_input(struct trunk_softc *, struct trunk_port *,
- struct ether_header *, struct mbuf *);
+ struct mbuf *);
/* Active failover */
int trunk_fail_attach(struct trunk_softc *);
int trunk_fail_detach(struct trunk_softc *);
int trunk_fail_start(struct trunk_softc *, struct mbuf *);
int trunk_fail_input(struct trunk_softc *, struct trunk_port *,
- struct ether_header *, struct mbuf *);
+ struct mbuf *);
/* Loadbalancing */
int trunk_lb_attach(struct trunk_softc *);
@@ -110,7 +110,7 @@ int trunk_lb_port_create(struct trunk_p
voidtrunk_lb_port_destroy(struct trunk_port *);
int trunk_lb_start(struct trunk_softc *, struct mbuf *);
int trunk_lb_input(struct trunk_softc *, struct trunk_port *,
- struct ether_header *, struct mbuf *);
+ struct mbuf *);
int trunk_lb_porttable(struct trunk_softc *, struct trunk_port *);
/* Broadcast mode */
@@ -118,14 +118,14 @@ inttrunk_bcast_attach(struct trunk_sof
int trunk_bcast_detach(struct trunk_softc *);
int trunk_bcast_start(struct trunk_softc *, struct mbuf *);
int trunk_bcast_input(struct trunk_softc *, struct trunk_port *,
- struct ether_header *, struct mbuf *);
+ struct mbuf *);
/* 802.3ad LACP */
int trunk_lacp_attach(struct trunk_softc *);
int trunk_lacp_detach(struct trunk_softc *);
int trunk_lacp_start(struct trunk_softc *, struct mbuf *);
int trunk_lacp_input(struct trunk_softc *, struct trunk_port *,
- struct ether_header *, struct mbuf *);
+ struct mbuf *);
/* Trunk protocol table */
static const struct {
@@ -288,6 +288,7 @@ trunk_port_create(struct trunk_softc *tr
{
struct trunk_softc *tr_ptr;
struct trunk_port *tp;
+ struct ifih *trunk_ifih;
int error = 0;
/* Limit the maximal number of trunk ports */
@@ -326,12 +327,19 @@ trunk_port_create(struct trunk_softc *tr
M_DEVBUF, M_NOWAIT|M_ZERO)) == NULL)
return (ENOMEM);
+ trunk_ifih = malloc(sizeof(*trunk_ifih), M_DEVBUF, M_NOWAIT);
+ if (trunk_ifih == NULL) {
+ free(tp, M_DEVBUF, 0);
+ return (ENOMEM);
+ }
+
/* Check if port is a stacked trunk */
SLIST_FOREACH(tr_ptr, trunk_list, tr_entries) {
if (ifp == tr_ptr-tr_ac.ac_if) {
tp-tp_flags |= TRUNK_PORT_STACK;
if (trunk_port_checkstacking(tr_ptr) =
Re: msleep(9) should handle cold and panics just like tsleep does
On Tue, May 5, 2015 at 9:35 AM, Mike Belopuhov m...@belopuhov.com wrote: ... Here's a diff to remedy this. This is the same chunk as in the tsleep, except it uses semantics of msleep. IPL dance is there to negate the IPL changing effect of mtx_enter/mtx_leave so that splx(safepri) operation is actually changing IPL level from HIGH to safepri and then back to the mutex IPL level. ... + spl = MUTEX_OLDIPL(mtx); + MUTEX_OLDIPL(mtx) = splhigh(); + mtx_leave(mtx); + + splx(safepri); Hmm, since mtx_leave() effectively ends with splx(MUTEX_OLDIPL(mtx));, can't we just say: spl = MUTEX_OLDIPL(mtx); MUTEX_OLDIPL(mtx) = safepri; mtx_leave(mtx); (The tsleep() version needs splhigh() because that's the only safe way to get the current spl level so that it can be restored before returning. Here in msleep() the mutex's MUTEX_OLDIPL() already has the value we need.) Philip Guenther
msleep(9) should handle cold and panics just like tsleep does
Now that we have mutexes in our I/O path (SCSI, mfi, etc)
vfs_shutdown codepath is no longer safe since it still doesn't
disable process scheduling and relies on tsleep and now msleep
not to get into the mi_switch by accident. Unfortunately msleep
doesn't provide such guarantees yet.
Here's a diff to remedy this. This is the same chunk as in the
tsleep, except it uses semantics of msleep. IPL dance is there
to negate the IPL changing effect of mtx_enter/mtx_leave so that
splx(safepri) operation is actually changing IPL level from HIGH
to safepri and then back to the mutex IPL level.
This fixes up hangs seen in vfs_shutdown (sys_sync) on panics.
Tested with SP and MP kernels on amd64. OK?
diff --git sys/kern/kern_synch.c sys/kern/kern_synch.c
index fbf7684..6fe2b61 100644
--- sys/kern/kern_synch.c
+++ sys/kern/kern_synch.c
@@ -142,7 +142,7 @@ tsleep(const volatile void *ident, int priority, const char
*wmesg, int timo)
}
/*
- * Same as tsleep, but if we have a mutex provided, then once we've
+ * Same as tsleep, but if we have a mutex provided, then once we've
* entered the sleep queue we drop the mutex. After sleeping we re-lock.
*/
int
@@ -155,12 +155,33 @@ msleep(const volatile void *ident, struct mutex *mtx, int
priority,
KASSERT((priority ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
KASSERT(mtx != NULL);
+ if (cold || panicstr) {
+ /*
+* After a panic, or during autoconfiguration,
+* just give interrupts a chance, then just return;
+* don't run any other procs or panic below,
+* in case this is the idle process and already asleep.
+*/
+ spl = MUTEX_OLDIPL(mtx);
+ MUTEX_OLDIPL(mtx) = splhigh();
+ mtx_leave(mtx);
+
+ splx(safepri);
+
+ if ((priority PNORELOCK) == 0) {
+ mtx_enter(mtx);
+ MUTEX_OLDIPL(mtx) = spl;
+ } else
+ splx(spl);
+ return (0);
+ }
+
sleep_setup(sls, ident, priority, wmesg);
sleep_setup_timeout(sls, timo);
sleep_setup_signal(sls, priority);
/* XXX - We need to make sure that the mutex doesn't
-* unblock splsched. This can be made a bit more
+* unblock splsched. This can be made a bit more
* correct when the sched_lock is a mutex.
*/
spl = MUTEX_OLDIPL(mtx);
Re: seccomp system call
On Mon May 04, Damien Miller wrote: Personally, I think seccomp-bpf could be a superior alternative to systrace and I'd love to see an implementation. Other developers (inc. Theo) are skeptical though, but this is probably a case where the argument won't be settled without a concrete implementation to look at. I'd welcome any work you do on it. I'm going to start working on the bpf part and I will let you know if I succeed at implementing the SECCOMP_SET_MODE_FILTER operation.
Re: How to tie up p_tid with pthread_self's thread ID
Stuart Henderson st...@openbsd.org writes: I am trying to track down some threads which are seeing high cpu use in top(1), but can't work out how to track back from any information available from struct kinfo_proc back to a thread ID as returned by pthread_self(). The threaded program can print a nice display of its own internal concept of thread name, with the value returned by pthread_self(), and on some OS it also stores what I think is their equivalent of our p_tid, e.g. on linux it uses syscall(SYS_gettid). Do we have a way within a threaded program to determine the current thread's p_tid? If I'm not mistaken that would be getthrid(2). Or is there a way to go from p_tid (or something else available in struct kinfo_proc) back to a thread ID returned by pthread_self()? No idea. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
How to tie up p_tid with pthread_self's thread ID
I am trying to track down some threads which are seeing high cpu use in top(1), but can't work out how to track back from any information available from struct kinfo_proc back to a thread ID as returned by pthread_self(). The threaded program can print a nice display of its own internal concept of thread name, with the value returned by pthread_self(), and on some OS it also stores what I think is their equivalent of our p_tid, e.g. on linux it uses syscall(SYS_gettid). Do we have a way within a threaded program to determine the current thread's p_tid? Or is there a way to go from p_tid (or something else available in struct kinfo_proc) back to a thread ID returned by pthread_self()? Thanks.
Re: PATCH: bring crypto(9) up to speed with crypto/cryptodev.h
On 2 May 2015 at 22:07, Vincent Gross dermi...@kilob.yt wrote: Hi folks, crypto(9) describes functions and constants that are not part of crypto/cryptodev.h anymore (see 1.58 - 1.60), this patch fixes that. Cheers, committed a tweaked version. thanks.
Re: [patch] rtl8188eu support for urtwn(4)
On Mon, May 04, 2015 at 01:51:28PM +0200, Stefan Sperling wrote: On Mon, May 04, 2015 at 01:23:59PM +0200, Stefan Sperling wrote: Unfortunately, this patch doesn't still fix the performance problem for me. How are you testing performance? I'm using tcpbench(1). I've committed your patch so we can work on the remaining issues in smaller chunks. Thanks a lot for your work so far. It's always great to see someone new help us out with wireless. For the record: The speed issue happens only with an AP in 11b mode (the 88E firmware retries every data frame at 5Mbit/s). OFDM (11g) works.
