Re: include netinet/in_var.h in arch/dev
On 8/16/2013 7:44 PM, Alexander Bluhm wrote: On Wed, Aug 07, 2013 at 03:39:59AM +0200, Alexander Bluhm wrote: Hi, I have just removed a bunch of useless include netinet/in_var.h from the machine independent drivers. I suspect that they are also not needed in the architecture specific network drivers. Unfortunately I don't have any of these machines. So if you have access to one of macppc mvme68k octeon sgi sparc vax could you please test if this diff compiles. These architectures are still not tested: mvme68k octeon sgi sparc Could you please compile this diff, if you posses one of these machines? This compiles on octeon. ok. ~Brian bluhm Index: arch/mvme68k/dev/if_ie.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/mvme68k/dev/if_ie.c,v retrieving revision 1.40 diff -u -p -u -p -r1.40 if_ie.c --- arch/mvme68k/dev/if_ie.c10 Oct 2012 04:52:16 - 1.40 +++ arch/mvme68k/dev/if_ie.c16 Aug 2013 23:27:02 - @@ -120,7 +120,6 @@ Mode of operation: #ifdef INET #include #include -#include #include #include #endif Index: arch/mvme88k/dev/if_ie.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/mvme88k/dev/if_ie.c,v retrieving revision 1.45 diff -u -p -u -p -r1.45 if_ie.c --- arch/mvme88k/dev/if_ie.c10 Oct 2012 04:52:16 - 1.45 +++ arch/mvme88k/dev/if_ie.c16 Aug 2013 23:27:02 - @@ -119,7 +119,6 @@ Mode of operation: #ifdef INET #include #include -#include #include #include #endif Index: arch/octeon/dev/if_cnmac.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/octeon/dev/if_cnmac.c,v retrieving revision 1.10 diff -u -p -u -p -r1.10 if_cnmac.c --- arch/octeon/dev/if_cnmac.c 12 Apr 2013 15:22:26 - 1.10 +++ arch/octeon/dev/if_cnmac.c 16 Aug 2013 23:27:02 - @@ -66,7 +66,6 @@ #include #include -#include #include #include Index: arch/sgi/dev/if_iec.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sgi/dev/if_iec.c,v retrieving revision 1.8 diff -u -p -u -p -r1.8 if_iec.c --- arch/sgi/dev/if_iec.c 22 May 2012 19:24:59 - 1.8 +++ arch/sgi/dev/if_iec.c 16 Aug 2013 23:27:02 - @@ -101,7 +101,6 @@ #ifdef INET #include #include -#include #include #endif Index: arch/sgi/dev/if_mec.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sgi/dev/if_mec.c,v retrieving revision 1.25 diff -u -p -u -p -r1.25 if_mec.c --- arch/sgi/dev/if_mec.c 3 Oct 2012 22:46:09 - 1.25 +++ arch/sgi/dev/if_mec.c 16 Aug 2013 23:27:02 - @@ -85,7 +85,6 @@ #ifdef INET #include #include -#include #include #endif Index: arch/sgi/hpc/if_sq.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sgi/hpc/if_sq.c,v retrieving revision 1.8 diff -u -p -u -p -r1.8 if_sq.c --- arch/sgi/hpc/if_sq.c28 May 2012 17:03:35 - 1.8 +++ arch/sgi/hpc/if_sq.c16 Aug 2013 23:27:02 - @@ -57,7 +57,6 @@ #ifdef INET #include #include -#include #include #endif Index: arch/sparc/dev/be.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/be.c,v retrieving revision 1.43 diff -u -p -u -p -r1.43 be.c --- arch/sparc/dev/be.c 28 Nov 2008 02:44:17 - 1.43 +++ arch/sparc/dev/be.c 16 Aug 2013 23:27:02 - @@ -46,7 +46,6 @@ #ifdef INET #include #include -#include #include #include #endif Index: arch/sparc/dev/hme.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/hme.c,v retrieving revision 1.62 diff -u -p -u -p -r1.62 hme.c --- arch/sparc/dev/hme.c13 Aug 2009 17:01:31 - 1.62 +++ arch/sparc/dev/hme.c16 Aug 2013 23:27:02 - @@ -59,7 +59,6 @@ #ifdef INET #include #include -#include #include #include #include Index: arch/sparc/dev/if_gem_sbus.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/if_gem_sbus.c,v retrieving revision 1.1 diff -u -p -u -p -r1.1 if_gem_sbus.c --- arch/sparc/dev/if_gem_sbus.c13 Jul 2009 19:53:58 - 1.1 +++ arch/sparc/dev/if_gem_sbus.c16 Aug 2013 23:27:02 - @@ -48,7 +48,6 @@ #ifdef INET #include #include -#include #include #include #endif Index: arch/sparc/dev/if_ie.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/if_ie.c,v retrieving revision 1.42 diff -u -p -u -p -r1.42 if_ie.c --- arch/sparc/dev/if_ie.c 10 Oct 2
Re: include netinet/in_var.h in arch/dev
On Wed, Aug 07, 2013 at 03:39:59AM +0200, Alexander Bluhm wrote: > Hi, > > I have just removed a bunch of useless include netinet/in_var.h > from the machine independent drivers. I suspect that they are also > not needed in the architecture specific network drivers. Unfortunately > I don't have any of these machines. So if you have access to one > of > > macppc mvme68k octeon sgi sparc vax > > could you please test if this diff compiles. These architectures are still not tested: mvme68k octeon sgi sparc Could you please compile this diff, if you posses one of these machines? bluhm Index: arch/mvme68k/dev/if_ie.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/mvme68k/dev/if_ie.c,v retrieving revision 1.40 diff -u -p -u -p -r1.40 if_ie.c --- arch/mvme68k/dev/if_ie.c10 Oct 2012 04:52:16 - 1.40 +++ arch/mvme68k/dev/if_ie.c16 Aug 2013 23:27:02 - @@ -120,7 +120,6 @@ Mode of operation: #ifdef INET #include #include -#include #include #include #endif Index: arch/mvme88k/dev/if_ie.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/mvme88k/dev/if_ie.c,v retrieving revision 1.45 diff -u -p -u -p -r1.45 if_ie.c --- arch/mvme88k/dev/if_ie.c10 Oct 2012 04:52:16 - 1.45 +++ arch/mvme88k/dev/if_ie.c16 Aug 2013 23:27:02 - @@ -119,7 +119,6 @@ Mode of operation: #ifdef INET #include #include -#include #include #include #endif Index: arch/octeon/dev/if_cnmac.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/octeon/dev/if_cnmac.c,v retrieving revision 1.10 diff -u -p -u -p -r1.10 if_cnmac.c --- arch/octeon/dev/if_cnmac.c 12 Apr 2013 15:22:26 - 1.10 +++ arch/octeon/dev/if_cnmac.c 16 Aug 2013 23:27:02 - @@ -66,7 +66,6 @@ #include #include -#include #include #include Index: arch/sgi/dev/if_iec.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sgi/dev/if_iec.c,v retrieving revision 1.8 diff -u -p -u -p -r1.8 if_iec.c --- arch/sgi/dev/if_iec.c 22 May 2012 19:24:59 - 1.8 +++ arch/sgi/dev/if_iec.c 16 Aug 2013 23:27:02 - @@ -101,7 +101,6 @@ #ifdef INET #include #include -#include #include #endif Index: arch/sgi/dev/if_mec.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sgi/dev/if_mec.c,v retrieving revision 1.25 diff -u -p -u -p -r1.25 if_mec.c --- arch/sgi/dev/if_mec.c 3 Oct 2012 22:46:09 - 1.25 +++ arch/sgi/dev/if_mec.c 16 Aug 2013 23:27:02 - @@ -85,7 +85,6 @@ #ifdef INET #include #include -#include #include #endif Index: arch/sgi/hpc/if_sq.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sgi/hpc/if_sq.c,v retrieving revision 1.8 diff -u -p -u -p -r1.8 if_sq.c --- arch/sgi/hpc/if_sq.c28 May 2012 17:03:35 - 1.8 +++ arch/sgi/hpc/if_sq.c16 Aug 2013 23:27:02 - @@ -57,7 +57,6 @@ #ifdef INET #include #include -#include #include #endif Index: arch/sparc/dev/be.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/be.c,v retrieving revision 1.43 diff -u -p -u -p -r1.43 be.c --- arch/sparc/dev/be.c 28 Nov 2008 02:44:17 - 1.43 +++ arch/sparc/dev/be.c 16 Aug 2013 23:27:02 - @@ -46,7 +46,6 @@ #ifdef INET #include #include -#include #include #include #endif Index: arch/sparc/dev/hme.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/hme.c,v retrieving revision 1.62 diff -u -p -u -p -r1.62 hme.c --- arch/sparc/dev/hme.c13 Aug 2009 17:01:31 - 1.62 +++ arch/sparc/dev/hme.c16 Aug 2013 23:27:02 - @@ -59,7 +59,6 @@ #ifdef INET #include #include -#include #include #include #include Index: arch/sparc/dev/if_gem_sbus.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/if_gem_sbus.c,v retrieving revision 1.1 diff -u -p -u -p -r1.1 if_gem_sbus.c --- arch/sparc/dev/if_gem_sbus.c13 Jul 2009 19:53:58 - 1.1 +++ arch/sparc/dev/if_gem_sbus.c16 Aug 2013 23:27:02 - @@ -48,7 +48,6 @@ #ifdef INET #include #include -#include #include #include #endif Index: arch/sparc/dev/if_ie.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/sparc/dev/if_ie.c,v retrieving revision 1.42 diff -u -p -u -p -r1.42 if_ie.c --- arch/sparc/dev/if_ie.c 10 Oct 2012 04:52:16 - 1.42 +++ arch/sparc/dev/if_ie.c 16 Aug 2013 23:27:02 - @@ -126,7 +126,6 @@ Mode o
Re: threaded prof signals
> Date: Thu, 15 Aug 2013 23:39:36 -0700
> From: Philip Guenther
>
> On Fri, 16 Aug 2013, Ted Unangst wrote:
> > As per http://research.swtch.com/macpprof
> >
> > We deliver all prof signals to the main thread, which is unlikely to
> > result in accurate profiling info. I think the diff below fixes things.
>
> Making ITIMER_PROF per-thread like that matches neither what other OS's do
> nor POSIX. jsing@ pinged about this last week and my comment then was
> that this seems like a bug in signal delivery, not in the triggering of
> the profile timer: when SIGPROF is delivered, it should go to the current
> thread if it's a possible candidate. Indeed, that should always be true:
> picking some other thread delays delivery, breaks profiling, and violates
> the requirements on kill(2).
>
> So, I proposed the diff below to jsing, which seemed to solve the
> profiling problem...and then got really busy with some time related
> stuff...
>
> Most of the diff below is reindenting of the TAILQ_FOREACH() loop.
>
> To forestall a question: if some other thread is sigwait()ing but the
> current thread doesn't have the signal blocked, then we currently prefer
> to deliver to the sigwait()ing thread, but this diff prefers the current
> thread. That's legal as the behavior is unspecified if you sigwait()
> while the signal isn't blocked in all threads.
>
> opinions?
Wonder if this fixes/alleviates the problem with the excessive ipi's
that people have been complaining about.
Can't find the text in POSIX that says you shouldn't call sigwait()
without blocking signals in *all* threads, but it doesn't say you
shouldn't call it without blocking them. And the rationale part
clearly does say that the specification of signals is deliberately
vague to allow implementations to deliver signals in the most
convenient way.
Do wonder if we should do the same in the loop over all threads though
to be consistent.
> Index: kern/kern_sig.c
> ===
> RCS file: /cvs/src/sys/kern/kern_sig.c,v
> retrieving revision 1.152
> diff -u -p -r1.152 kern_sig.c
> --- kern/kern_sig.c 1 Jun 2013 04:05:26 - 1.152
> +++ kern/kern_sig.c 16 Aug 2013 01:02:52 -
> @@ -811,27 +811,39 @@ ptsignal(struct proc *p, int signum, enu
> }
>
> /*
> - * A process-wide signal can be diverted to a different
> - * thread that's in sigwait() for this signal. If there
> - * isn't such a thread, then pick a thread that doesn't
> - * have it blocked so that the stop/kill consideration
> - * isn't delayed. Otherwise, mark it pending on the
> - * main thread.
> + * If the current thread can process the signal
> + * immediately, either because it's sigwait()ing
> + * on it or has it unblocked, then have it take it.
>*/
> - TAILQ_FOREACH(q, &pr->ps_threads, p_thr_link) {
> - /* ignore exiting threads */
> - if (q->p_flag & P_WEXIT)
> - continue;
> + q = curproc
> + if (q != NULL && q->p_p == pr && (q->p_flag & P_WEXIT) == 0 &&
> + ((q->p_sigdivert & mask) || (q->p_sigmask & mask) == 0))
> + p = q;
> + else {
> + /*
> + * A process-wide signal can be diverted to a
> + * different thread that's in sigwait() for this
> + * signal. If there isn't such a thread, then
> + * pick a thread that doesn't have it blocked so
> + * that the stop/kill consideration isn't
> + * delayed. Otherwise, mark it pending on the
> + * main thread.
> + */
> + TAILQ_FOREACH(q, &pr->ps_threads, p_thr_link) {
> + /* ignore exiting threads */
> + if (q->p_flag & P_WEXIT)
> + continue;
>
> - /* sigwait: definitely go to this thread */
> - if (q->p_sigdivert & mask) {
> - p = q;
> - break;
> - }
> + /* sigwait: definitely go to this thread */
> + if (q->p_sigdivert & mask) {
> + p = q;
> + break;
> + }
>
> - /* unblocked: possibly go to this thread */
> - if ((q->p_sigmask & mask) == 0)
> - p = q;
> + /* unblocked: possibly go to this thread */
> + if ((q->p_sigmask & mask) == 0)
> +
Re: threaded prof signals
On Fri, Aug 16, 2013 at 12:33, Mike Belopuhov wrote: > On 16 August 2013 09:23, Ted Unangst wrote: >> Actually, here's my concern. There's only one timeout for the process. >> What happens when two threads are running on two CPUs? Is there a >> guarantee that cpu0 will both set and execute the timeout before cpu1 >> sets it, or is there a race where cpu1 will fail to send the signal to >> its thread because cpu0 has already processed the timeout? >> > > softclock and hence the timeout processing is done only by the cpu0 > currently. That's really good to know. I couldn't remember if it was hardclock or softclock or what exactly. In that case, guenther, I think your diff is incorrect. The thread running on cpu0 may not have been the thread running when the timer expired. And if the thread on cpu0 is an unrelated process, we're back to semi random delivery. If you look at my diff again, I didn't actually create a timer per thread, only a timeout, and the timeout is only used as a trampoline to get the proc argument from hardclock to psignal. (I think your diff may make sense for other reasons, but it's not always going to send sigprof to the right thread.)
Re: threaded prof signals
On 16 August 2013 09:23, Ted Unangst wrote: > Actually, here's my concern. There's only one timeout for the process. > What happens when two threads are running on two CPUs? Is there a > guarantee that cpu0 will both set and execute the timeout before cpu1 > sets it, or is there a race where cpu1 will fail to send the signal to > its thread because cpu0 has already processed the timeout? > softclock and hence the timeout processing is done only by the cpu0 currently.
SNMPv3 engine id discovery
Hi,
in SNMPv3 engine id discovery is done by sending a noAuthNoPriv request
to the SNMP agent. The agent should reply with a usmStatsUnknownEngineIDs
report containing the authoritative engine id.
In case snmpd was configured with a minimum seclevel higher than none,
a usmStatsUnsupportedSecLevels report was generated instead.
The fix below delays checking the required seclevel until after engine
id discovery has been handled.
Ok?
Gerhard
Index: usr.sbin/snmpd/snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.33
diff -u -p -u -p -r1.33 snmpe.c
--- usr.sbin/snmpd/snmpe.c 29 Mar 2013 12:53:41 - 1.33
+++ usr.sbin/snmpd/snmpe.c 16 Aug 2013 08:05:19 -
@@ -530,8 +530,7 @@ snmpe_parse(struct sockaddr_storage *ss,
goto parsefail;
msg->sm_flags = *flagstr;
- if (MSG_SECLEVEL(msg) < env->sc_min_seclevel ||
- msg->sm_secmodel != SNMP_SEC_USM) {
+ if (msg->sm_secmodel != SNMP_SEC_USM) {
/* XXX currently only USM supported */
errstr = "unsupported security model";
stats->snmp_usmbadseclevel++;
Index: usr.sbin/snmpd/usm.c
===
RCS file: /cvs/src/usr.sbin/snmpd/usm.c,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 usm.c
--- usr.sbin/snmpd/usm.c24 Jan 2013 09:30:27 - 1.6
+++ usr.sbin/snmpd/usm.c16 Aug 2013 08:05:19 -
@@ -287,6 +287,13 @@ usm_decode(struct snmp_message *msg, str
msg->sm_engine_boots = (u_int32_t)engine_boots;
msg->sm_engine_time = (u_int32_t)engine_time;
+ if (MSG_SECLEVEL(msg) < env->sc_min_seclevel) {
+ *errp = "security level too low";
+ msg->sm_usmerr = OIDVAL_usmErrSecLevel;
+ stats->snmp_usmbadseclevel++;
+ goto done;
+ }
+
memcpy(msg->sm_username, user, userlen);
msg->sm_username[userlen] = '\0';
msg->sm_user = usm_finduser(msg->sm_username);
Re: threaded prof signals
On Fri, Aug 16, 2013 at 12:23 AM, Ted Unangst wrote: > On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote: > > Making ITIMER_PROF per-thread like that matches neither what other OS's > do > > nor POSIX. jsing@ pinged about this last week and my comment then was > > that this seems like a bug in signal delivery, not in the triggering of > > the profile timer: when SIGPROF is delivered, it should go to the current > > thread if it's a possible candidate. Indeed, that should always be true: > > picking some other thread delays delivery, breaks profiling, and violates > > the requirements on kill(2). > > Actually, here's my concern. There's only one timeout for the process. > What happens when two threads are running on two CPUs? Is there a > guarantee that cpu0 will both set and execute the timeout before cpu1 > sets it, or is there a race where cpu1 will fail to send the signal to > its thread because cpu0 has already processed the timeout? > You get one signal, which is correct: the criteria is that the process is supposed to be sent one signal after the process, totaling across threads, consumes it_value of CPU-time, and then another every time that total accumulates another it_interval again. When your process with two threads has its total crossover while two threads are running, it only crossed *once*, not twice, so it should only get one signal. (Well, if it_interval is small enough, smaller than a tick, then I suppose it's possible for the total to "cross twice" and generate two signals, but I don't think that's what you had in mind...) Philip Guenther
Re: threaded prof signals
On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote: > Making ITIMER_PROF per-thread like that matches neither what other OS's do > nor POSIX. jsing@ pinged about this last week and my comment then was > that this seems like a bug in signal delivery, not in the triggering of > the profile timer: when SIGPROF is delivered, it should go to the current > thread if it's a possible candidate. Indeed, that should always be true: > picking some other thread delays delivery, breaks profiling, and violates > the requirements on kill(2). Actually, here's my concern. There's only one timeout for the process. What happens when two threads are running on two CPUs? Is there a guarantee that cpu0 will both set and execute the timeout before cpu1 sets it, or is there a race where cpu1 will fail to send the signal to its thread because cpu0 has already processed the timeout?
Re: threaded prof signals
On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote: > opinions? I knew if I made a broken diff I could trick you into fixing it right. :)
