Re: netcat service lookup

2016-05-31 Thread Theo de Raadt
> On Tue, May 31, 2016 at 10:17 PM, Theo de Raadt  
> wrote:
> >> This diff allows users to use the name of a service in /etc/services
> >> instead of a port number when using netcat. Hopefully, this will make
> >> using netcat easier for some users.
> >
> > I don't see how it makes it easier.  There are a number of netcat
> > versions out there, mostly trying to be somewhat compatible.  On a
> > whim, this introduces an incompatibility --> scripts become less
> > portable.
> 
> Well, we would rather that people use nc than openssl s_client or
> telnet ...and both those do service name lookup...

I have changed my mind.  Original hobbit netcat used getservbyname.

Everyone please move the drinks near your keyboards a bit further
away


  case 'p': /* local source port */
o_lport = getportpoop (optarg, 0);
...

/* getportpoop :
   Same general idea as gethostpoop -- look up a port in /etc/services, fill
   in global port_poop, but return the actual port *number*.  Pass ONE of:
pstring to resolve stuff like "23" or "exec";
pnum to reverse-resolve something that's already a number.
   If o_nflag is on, fill in what we can but skip the getservby??? stuff.
   Might as well have consistent behavior here, and it *is* faster. */
USHORT getportpoop (pstring, pnum)
  char * pstring;
  unsigned int pnum;
{
  struct servent * servent;
...
servent = getservbyport (y, whichp);
if (servent) {



It is strange that none of the other derivatives did so.  I guess this
shows they are really clones of the Eric Jackson / OpenBSD variant.



ancient relics in newsyslog

2016-05-31 Thread Ted Unangst
Let's make the defaults be the defaults.

Index: Makefile
===
RCS file: /cvs/src/usr.bin/newsyslog/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile30 Mar 2016 06:38:46 -  1.6
+++ Makefile1 Jun 2016 05:42:06 -
@@ -2,14 +2,6 @@
 
 PROG=  newsyslog
 
-CFLAGS+= -DCONF=\"/etc/newsyslog.conf\"
-CFLAGS+= -DPIDFILE=\"/var/run/syslog.pid\"
-CFLAGS+= -DCOMPRESS=\"/usr/bin/gzip\"
-CFLAGS+= -DCOMPRESS_POSTFIX=\".gz\"
-CFLAGS+= -DSTATS_DIR=\"/var/run\"
-CFLAGS+= -DSENDMAIL=\"/usr/sbin/sendmail\"
-CFLAGS+= -DQUAD_OFF_T
-
 BINOWN=root
 
 MAN=   newsyslog.8
Index: newsyslog.c
===
RCS file: /cvs/src/usr.bin/newsyslog/newsyslog.c,v
retrieving revision 1.100
diff -u -p -r1.100 newsyslog.c
--- newsyslog.c 11 Jan 2016 19:26:04 -  1.100
+++ newsyslog.c 1 Jun 2016 05:41:59 -
@@ -71,24 +71,12 @@
  *
  */
 
-#ifndef CONF
-#define CONF "/etc/newsyslog.conf" /* Configuration file */
-#endif
-#ifndef PIDFILE
-#define PIDFILE "/etc/syslog.pid"
-#endif
-#ifndef COMPRESS
-#define COMPRESS "/usr/bin/compress" /* File compression program */
-#endif
-#ifndef COMPRESS_POSTFIX
-#define COMPRESS_POSTFIX ".Z"
-#endif
-#ifndef STATS_DIR
-#define STATS_DIR "/etc"
-#endif
-#ifndef SENDMAIL
-#define SENDMAIL "/usr/lib/sendmail"
-#endif
+#define CONF "/etc/newsyslog.conf"
+#define PIDFILE "/var/run/syslog.pid"
+#define COMPRESS "/usr/bin/gzip"
+#define COMPRESS_POSTFIX ".gz"
+#define STATS_DIR "/var/run"
+#define SENDMAIL "/usr/sbin/sendmail"
 
 #include  /* DEV_BSIZE */
 #include 
@@ -1002,11 +990,7 @@ domonitor(struct conf_entry *ent)
warn("%s", fname);
goto cleanup;
}
-#ifdef QUAD_OFF_T
if (fscanf(fp, "%lld\n", ) != 1) {
-#else
-   if (fscanf(fp, "%ld\n", ) != 1) {
-#endif /* QUAD_OFF_T */
fclose(fp);
goto update;
}
@@ -1060,11 +1044,7 @@ update:
warn("%s", fname);
goto cleanup;
}
-#ifdef QUAD_OFF_T
fprintf(fp, "%lld\n", (long long)sb.st_size);
-#else
-   fprintf(fp, "%ld\n", (long)sb.st_size);
-#endif /* QUAD_OFF_T */
fclose(fp);
 
 cleanup:



Re: sqlite3 update

2016-05-31 Thread Landry Breuil
On Tue, May 31, 2016 at 11:36:35PM +0100, Stuart Henderson wrote:
> Thanks for the pointer Ingo..
> 
> I'll be doing tests (including a bulk ports build) with this,
> but here's an update to sqlite 3.10.2 (the version which is
> in Firefox 46) in the hope it will let us get rid of the
> conflicting sqlite3 versions in firefox.

Back to square one, when i need to pester someone to update sqlite3 in
base each time mozilla updates its copy/dependencies ? :)

Technically, i could also relax the version check in configure, but i'm
never sure when firefox really depends on features from newer sqlite. It
seems development is closely followed for valid reasons...

> If this is the wrong version to be targetting (Landry?) please
> let me know.

Firefox trunk/49 ships 3.13... see
http://hg.mozilla.org/mozilla-central/log/tip/db/sqlite3/src/sqlite3.h
for the history of updates.

> If anyone has anything in particular they'd like to test,
> could you try it please.

To test it with firefox, you should just need to comment out
MOZILLA_USE_BUNDLED_SQLITE = Yes in www/mozilla-firefox/Makefile.

> A shlib_version update is included, four symbols were removed so
> it's a major bump.
> 
> I modified addopcodes.awk by hand based on the changes in the
> upstream version which has now switched to a Tcl script.
> 
> (I don't really understand how things are working in Firefox on
> other OS, there are two different versions of sqlite in their
> tree...even in the one firefox tarball)..

Nss is considered a third-party library in firefox, and thus has to be
self-contained. We dont build the copy of sqlite bundled in nss bundled
in firefox since we build against systemwide nss...

Landry



make art_table_delete scrub the heap on all deletes

2016-05-31 Thread David Gwynne
currently it leaves early if it is the last entry being removed,
which is an optimisation. in the future it is possible for another
cpu to have a reference to the table while the last reference is
being dropped, so we need to scrub it in case it gets read.

ok?

Index: art.c
===
RCS file: /cvs/src/sys/net/art.c,v
retrieving revision 1.14
diff -u -p -r1.14 art.c
--- art.c   13 Apr 2016 08:04:14 -  1.14
+++ art.c   1 Jun 2016 05:26:51 -
@@ -490,10 +490,6 @@ art_table_delete(struct art_root *ar, st
KASSERT(prev == node);
 #endif
 
-   /* We are removing an entry from this table. */
-   if (art_table_free(ar, at))
-   return (node);
-
/* Get the next most specific route for the index `i'. */
if ((i >> 1) > 1)
next = at->at_heap[i >> 1].node;
@@ -512,6 +508,9 @@ art_table_delete(struct art_root *ar, st
else
at->at_heap[i].node = next;
 
+   /* We have removed an entry from this table. */
+   art_table_free(ar, at);
+
return (node);
 }
 



Re: netcat service lookup

2016-05-31 Thread Bob Beck
Honestly, I care little about the incompatibility because we are
already different.

However I do not think this is any "easier" - I never use
/etc/services because frankly I can't
predict what other non-openbsd systems will have in it.

even openssl s_client doens't add code complexity to do this - and
that's saying something ;)

so frankly, I'd rather not. /etc/services is frankly IMO, obsolete..
nobody looks up shit by name
out of there anymore


On Tue, May 31, 2016 at 11:17 PM, Theo de Raadt  wrote:
>> This diff allows users to use the name of a service in /etc/services
>> instead of a port number when using netcat. Hopefully, this will make
>> using netcat easier for some users.
>
> I don't see how it makes it easier.  There are a number of netcat
> versions out there, mostly trying to be somewhat compatible.  On a
> whim, this introduces an incompatibility --> scripts become less
> portable.
>



Re: netcat service lookup

2016-05-31 Thread Philip Guenther
On Tue, May 31, 2016 at 10:17 PM, Theo de Raadt  wrote:
>> This diff allows users to use the name of a service in /etc/services
>> instead of a port number when using netcat. Hopefully, this will make
>> using netcat easier for some users.
>
> I don't see how it makes it easier.  There are a number of netcat
> versions out there, mostly trying to be somewhat compatible.  On a
> whim, this introduces an incompatibility --> scripts become less
> portable.

Well, we would rather that people use nc than openssl s_client or
telnet ...and both those do service name lookup...


Philip Guenther



prepare art_node for immediate use in rtable_insert

2016-05-31 Thread David Gwynne
this reorders the code so a functioning art_node is inserted into
the table instead of an empty node.

if we move art to use srps, an insert will make the node available
for lookups immediately. having a functional node in that situation
is useful.

this includes previous diffz so it can apply and work.

ok?

Index: rtable.c
===
RCS file: /cvs/src/sys/net/rtable.c,v
retrieving revision 1.42
diff -u -p -r1.42 rtable.c
--- rtable.c18 May 2016 03:46:03 -  1.42
+++ rtable.c1 Jun 2016 05:17:51 -
@@ -666,6 +666,7 @@ rtable_insert(unsigned int rtableid, str
struct art_node *an, *prev;
uint8_t *addr;
int  plen;
+   unsigned int rt_flags;
 
KERNEL_ASSERT_LOCKED();
 
@@ -704,18 +705,23 @@ rtable_insert(unsigned int rtableid, str
if (an == NULL)
return (ENOBUFS);
 
-   SRPL_INIT(>an_rtlist);
+   /* prepare for immediate operation if insert succeeds */
+   rt_flags = rt->rt_flags;
+   rt->rt_flags &= ~RTF_MPATH;
+   rt->rt_dest = dst;
+   rt->rt_plen = plen;
+   SRPL_INSERT_HEAD_LOCKED(_rc, >an_rtlist, rt, rt_next);
 
prev = art_insert(ar, an, addr, plen);
-   if (prev == NULL) {
+   if (prev != an) {
+   SRPL_REMOVE_LOCKED(_rc, >an_rtlist, rt, rtentry,
+   rt_next);
+   rt->rt_flags = rt_flags;
art_put(an);
-   return (ESRCH);
-   }
 
-   if (prev == an) {
-   rt->rt_flags &= ~RTF_MPATH;
-   } else {
-   art_put(an);
+   if (prev == NULL)
+   return ESRCH;
+
 #ifndef SMALL_KERNEL
an = prev;
 
@@ -740,21 +746,16 @@ rtable_insert(unsigned int rtableid, str
}
}
}
+
+   SRPL_INSERT_HEAD_LOCKED(_rc, >an_rtlist, rt, rt_next);
+
+   /* Put newly inserted entry at the right place. */
+   rtable_mpath_reprio(rtableid, dst, mask, rt->rt_priority, rt);
 #else
return (EEXIST);
 #endif /* SMALL_KERNEL */
}
 
-   rt->rt_dest = dst;
-   rt->rt_plen = plen;
-   rtref(rt);
-   SRPL_INSERT_HEAD_LOCKED(_rc, >an_rtlist, rt, rt_next);
-
-#ifndef SMALL_KERNEL
-   /* Put newly inserted entry at the right place. */
-   rtable_mpath_reprio(rtableid, dst, mask, rt->rt_priority, rt);
-#endif /* SMALL_KERNEL */
-
return (0);
 }
 
@@ -813,7 +814,6 @@ rtable_delete(unsigned int rtableid, str
 
KASSERT(rt->rt_refcnt >= 2);
SRPL_REMOVE_LOCKED(_rc, >an_rtlist, rt, rtentry, rt_next);
-   rtfree(rt);
 
art_put(an);
return (0);
@@ -899,6 +899,7 @@ rtable_mpath_reprio(unsigned int rtablei
 
KERNEL_ASSERT_LOCKED();
 
+   rtref(rt); /* keep rt alive in between remove and add */
SRPL_REMOVE_LOCKED(_rc, >an_rtlist, rt, rtentry, rt_next);
rt->rt_priority = prio;
 
@@ -931,6 +932,7 @@ rtable_mpath_reprio(unsigned int rtablei
} else {
SRPL_INSERT_HEAD_LOCKED(_rc, >an_rtlist, rt, rt_next);
}
+   rtfree(rt);
 
return (0);
 }
Index: art.c
===
RCS file: /cvs/src/sys/net/art.c,v
retrieving revision 1.14
diff -u -p -r1.14 art.c
--- art.c   13 Apr 2016 08:04:14 -  1.14
+++ art.c   1 Jun 2016 05:17:51 -
@@ -803,6 +803,7 @@ art_get(struct sockaddr *dst, uint8_t pl
 
an->an_dst = dst;
an->an_plen = plen;
+   SRPL_INIT(>an_rtlist);
 
return (an);
 }



Re: netcat service lookup

2016-05-31 Thread Andras Farkas
Ah, okay.
> I don't see how it makes it easier.  There are a number of netcat
> versions out there, mostly trying to be somewhat compatible.  On a
> whim, this introduces an incompatibility --> scripts become less
> portable.



Re: netcat service lookup

2016-05-31 Thread Theo de Raadt
> This diff allows users to use the name of a service in /etc/services 
> instead of a port number when using netcat. Hopefully, this will make 
> using netcat easier for some users.

I don't see how it makes it easier.  There are a number of netcat
versions out there, mostly trying to be somewhat compatible.  On a
whim, this introduces an incompatibility --> scripts become less
portable.



Re: utvfu driver port

2016-05-31 Thread Theo de Raadt
> If it's entirely new code, I think the top option is better because it allows
> separation later. We have some files where all the [code 1] gets deleted, but
> the copyright remains, somewhat dubious.

Sounds like shoulders of giants stuff.  It is exceedingly rare for us
to remove a name or copyright.  Only happens when it is a totally fresh
rewrite.



Re: utvfu driver port

2016-05-31 Thread Ted Unangst
Marcus Glocker wrote:
> Me too.  Would it be ok to merge utvfu.c and utvfu_ops.c by including
> both Copyrights in this file?  Should it be
> 
>   [Copyright 1]
>   [Code 1]
>   [Copyright 2]
>   [Code 2]
> 
> or
> 
>   [Copyright 1]
>   [Copyright 2]
>   [Code 1]
>   [Code 2]
> 

Historically, the second has been popular, but that's also when the new code is
mixed in with old.

If it's entirely new code, I think the top option is better because it allows
separation later. We have some files where all the [code 1] gets deleted, but
the copyright remains, somewhat dubious.



less rthread debug noise

2016-05-31 Thread Ted Unangst
since changing the malloc spinlock to a mutex, it gets roped into the
rthread_debug print outs, which contribute massive noise. bypass the logging.

Index: rthread.h
===
RCS file: /cvs/src/lib/librthread/rthread.h,v
retrieving revision 1.58
diff -u -p -r1.58 rthread.h
--- rthread.h   7 May 2016 19:05:22 -   1.58
+++ rthread.h   1 Jun 2016 04:29:59 -
@@ -210,6 +210,11 @@ void   _rthread_dl_lock(int what);
 #endif
 void   _thread_malloc_reinit(void);
 
+int _rthread_mutex_lock(pthread_mutex_t *mutexp, int trywait,
+const struct timespec *abstime, int internal);
+int _rthread_mutex_unlock(pthread_mutex_t *mutexp, int internal);
+
+
 extern int _threads_ready;
 extern size_t _thread_pagesize;
 extern LIST_HEAD(listhead, pthread) _thread_list;
Index: rthread_libc.c
===
RCS file: /cvs/src/lib/librthread/rthread_libc.c,v
retrieving revision 1.14
diff -u -p -r1.14 rthread_libc.c
--- rthread_libc.c  7 May 2016 19:05:22 -   1.14
+++ rthread_libc.c  1 Jun 2016 04:30:41 -
@@ -166,13 +166,13 @@ static pthread_mutex_t malloc_mutex = 
 void
 _thread_malloc_lock(void)
 {
-   pthread_mutex_lock(_mutex);
+   _rthread_mutex_lock(_mutex, 0, NULL, 1);
 }
 
 void
 _thread_malloc_unlock(void)
 {
-   pthread_mutex_unlock(_mutex);
+   _rthread_mutex_unlock(_mutex, 1);
 }
 
 void
Index: rthread_sync.c
===
RCS file: /cvs/src/lib/librthread/rthread_sync.c,v
retrieving revision 1.42
diff -u -p -r1.42 rthread_sync.c
--- rthread_sync.c  7 May 2016 19:05:22 -   1.42
+++ rthread_sync.c  1 Jun 2016 04:28:23 -
@@ -83,9 +83,9 @@ pthread_mutex_destroy(pthread_mutex_t *m
 }
 DEF_STD(pthread_mutex_destroy);
 
-static int
+int
 _rthread_mutex_lock(pthread_mutex_t *mutexp, int trywait,
-const struct timespec *abstime)
+const struct timespec *abstime, int internal)
 {
struct pthread_mutex *mutex;
pthread_t self = pthread_self();
@@ -107,7 +107,8 @@ _rthread_mutex_lock(pthread_mutex_t *mut
}
mutex = (struct pthread_mutex *)*mutexp;
 
-   _rthread_debug(5, "%p: mutex_lock %p\n", (void *)self, (void *)mutex);
+   if (!internal)
+   _rthread_debug(5, "%p: mutex_lock %p\n", (void *)self, (void 
*)mutex);
_spinlock(>lock);
if (mutex->owner == NULL && TAILQ_EMPTY(>lockers)) {
assert(mutex->count == 0);
@@ -171,30 +172,31 @@ _rthread_mutex_lock(pthread_mutex_t *mut
 int
 pthread_mutex_lock(pthread_mutex_t *p)
 {
-   return (_rthread_mutex_lock(p, 0, NULL));
+   return (_rthread_mutex_lock(p, 0, NULL, 0));
 }
 DEF_STD(pthread_mutex_lock);
 
 int
 pthread_mutex_trylock(pthread_mutex_t *p)
 {
-   return (_rthread_mutex_lock(p, 1, NULL));
+   return (_rthread_mutex_lock(p, 1, NULL, 0));
 }
 
 int
 pthread_mutex_timedlock(pthread_mutex_t *p, const struct timespec *abstime)
 {
-   return (_rthread_mutex_lock(p, 0, abstime));
+   return (_rthread_mutex_lock(p, 0, abstime, 0));
 }
 
 int
-pthread_mutex_unlock(pthread_mutex_t *mutexp)
+_rthread_mutex_unlock(pthread_mutex_t *mutexp, int internal)
 {
pthread_t self = pthread_self();
struct pthread_mutex *mutex = (struct pthread_mutex *)*mutexp;
 
-   _rthread_debug(5, "%p: mutex_unlock %p\n", (void *)self,
-   (void *)mutex);
+   if (!internal)
+   _rthread_debug(5, "%p: mutex_unlock %p\n", (void *)self,
+   (void *)mutex);
 
if (mutex == NULL)
 #if PTHREAD_MUTEX_DEFAULT == PTHREAD_MUTEX_ERRORCHECK
@@ -237,6 +239,12 @@ pthread_mutex_unlock(pthread_mutex_t *mu
}
 
return (0);
+}
+
+int
+pthread_mutex_unlock(pthread_mutex_t *p)
+{
+   return (_rthread_mutex_unlock(p, 0));
 }
 DEF_STD(pthread_mutex_unlock);
 



Re: utvfu driver port

2016-05-31 Thread Marcus Glocker
On Mon, May 30, 2016 at 04:22:56PM +0200, Martin Pieuchot wrote:

> On 26/05/16(Thu) 16:09, patrick keshishian wrote:
> > 
> > Included is my initial effort to port the dual-licensed driver
> > for Fushicai Audio-Video Grabber (vendor 0x1b71 product 0x3002).
> 
> Nice.  Did you test both bulk and iso? Some comments inline.
> 
> > Index: dev/usb/files.usb
> > ===
> > RCS file: /cvs/obsd/src/sys/dev/usb/files.usb,v
> > retrieving revision 1.126
> > diff -u -p -u -p -r1.126 files.usb
> > --- dev/usb/files.usb   8 Jan 2016 15:54:13 -   1.126
> > +++ dev/usb/files.usb   26 May 2016 22:34:38 -
> > @@ -35,6 +35,12 @@ device   uvideo: video, firmload
> >  attach uvideo at uhub
> >  file   dev/usb/uvideo.cuvideo
> >  
> > +# USBTV007 devices
> > +device utvfu: video, audio
> > +attach utvfu at uhub
> > +file   dev/usb/utvfu.c utvfu
> > +file   dev/usb/utvfu_ops.c utvfu
> 
> I'd appreciate if we can keep the driver in one file, when the license
> issue is solved, this is coherent with the rest of our tree.

Me too.  Would it be ok to merge utvfu.c and utvfu_ops.c by including
both Copyrights in this file?  Should it be

[Copyright 1]
[Code 1]
[Copyright 2]
[Code 2]

or

[Copyright 1]
[Copyright 2]
[Code 1]
[Code 2]

then?
 
> > +#ifndef _UTVFU_H_
> > +#define _UTVFU_H_
> 
> Is there any hardware reference for this device or everything is reverse
> engineered?  I mean the values below are specified somewhere?
> 
> > +
> > +#include 
> > +#include 
> > +
> > +/* Hardware. */
> > +#define UTVFU_VIDEO_ENDP   0x81
> > +#define UTVFU_AUDIO_ENDP   0x83
> > +#define UTVFU_BASE 0xc000
> > +#define UTVFU_REQUEST_REG  12
> > +
> > +/* Number of concurrent isochronous urbs submitted.
> > + * Higher numbers was seen to overly saturate the USB bus. */
> 
> This comment does not respect style(9).
> 
> > +#define UTVFU_ISOC_TRANSFERS   16
> > +#define UTVFU_ISOC_PACKETS 8
> > +
> > +#define UTVFU_CHUNK_SIZE   256
> > +#define UTVFU_CHUNK240
> > +
> > +#define UTVFU_AUDIO_URBSIZE20480
> > +#define UTVFU_AUDIO_HDRSIZE4
> > +#define UTVFU_AUDIO_BUFFER 65536
> > +
> > +#defineUTVFU_COMPOSITE_INPUT   0
> > +#defineUTVFU_SVIDEO_INPUT  1
> ^^
> We try to avoid mixing space and tab after "#define"
> 
> > +/* Chunk header. */
> > +#define UTVFU_MAGIC(hdr)   (hdr & 0xff00U)
> > +#define UTVFU_MAGIC_OK(hdr)((hdr & 0xff00U) == 0x8800U)
> > +#define UTVFU_FRAME_ID(hdr)((hdr & 0x00ffU) >> 16)
> > +#define UTVFU_ODD(hdr) ((hdr & 0xf000U) >> 15)
> > +#define UTVFU_CHUNK_NO(hdr)(hdr & 0x0fffU)
> > +
> > +#define UTVFU_TV_STD  (V4L2_STD_525_60 | V4L2_STD_PAL)
> > +
> > +/* parameters for supported TV norms */
> > +struct utvfu_norm_params {
> > +   v4l2_std_id norm;
> > +   int cap_width,
> > +   cap_height,
> > +   frame_len;
> 
> Please one type per line.
> 
> > +};
> 
> > +extern struct utvfu_norm_paramsutvfu_norm_params[];
> > +
> > +#defineUTVFU_MAX_BUFFERS   32
> > +struct utvfu_mmap {
> > +   SIMPLEQ_ENTRY(utvfu_mmap)   q_frames;
> > +   uint8_t *buf;
> > +   struct v4l2_buffer  v4l2_buf;
> > +};
> > +typedef SIMPLEQ_HEAD(, utvfu_mmap) q_mmap;
> > +
> > +struct utvfu_frame_buf {
> > +   uintoff;
> > +   uintsize;
> > +   uint16_tchunks_done;
> > +   uint8_t fid; 
> > +   uint8_t last_odd;
> > +   uint8_t *buf;
> > +};
> > +
> > +#defineUTVFU_NFRAMES_MAX   40
> > +struct utvfu_isoc_xfer {
> > +   struct utvfu_softc  *sc;
> > +   struct usbd_xfer*xfer;
> > +   void*buf;
> > +   uint16_tsize[UTVFU_NFRAMES_MAX];
> > +};
> > +
> > +struct utvfu_bulk_xfer {
> > +   struct usbd_xfer*xfer;
> > +   void*buf;
> 
> I'd use the simpler approach of using KERNADDR(>dmabuf, 0) instead
> of defining another structure to abstract an USB xfer.  You can look at
> uhidev_get_report_async_cb() for an example.
> 
> > +};
> > +
> > +struct utvfu_vs_iface {
> > +   struct usbd_pipe*pipeh;
> > +   int endpoint;
> > +   uint32_tpsize;
> > +   struct utvfu_isoc_xfer  ixfer[UTVFU_ISOC_TRANSFERS];
> > +};
> > +
> > +struct utvfu_as_iface {
> > +   struct usbd_pipe*pipeh;
> > +   int endpoint;
> > +   struct utvfu_bulk_xfer  bxfer;
> > +};
> > +
> > +struct utvfu_audio_chan {
> > +   uint8_t *start;
> > +   uint8_t *end;
> > +   uint8_t *cur;
> > +   int blksize;
> > +   void*intr_arg;
> > +   void(*intr)(void *);
> > +   

init art nodes in the one place

2016-05-31 Thread David Gwynne
ok?

Index: art.c
===
RCS file: /cvs/src/sys/net/art.c,v
retrieving revision 1.14
diff -u -p -r1.14 art.c
--- art.c   13 Apr 2016 08:04:14 -  1.14
+++ art.c   1 Jun 2016 03:40:34 -
@@ -803,6 +803,7 @@ art_get(struct sockaddr *dst, uint8_t pl
 
an->an_dst = dst;
an->an_plen = plen;
+   SRPL_INIT(>an_rtlist);
 
return (an);
 }
Index: rtable.c
===
RCS file: /cvs/src/sys/net/rtable.c,v
retrieving revision 1.42
diff -u -p -r1.42 rtable.c
--- rtable.c18 May 2016 03:46:03 -  1.42
+++ rtable.c1 Jun 2016 03:40:34 -
@@ -703,8 +705,6 @@ rtable_insert(unsigned int rtableid, str
an = art_get(dst, plen);
if (an == NULL)
return (ENOBUFS);
-
-   SRPL_INIT(>an_rtlist);
 
prev = art_insert(ar, an, addr, plen);
if (prev == NULL) {



netcat service lookup

2016-05-31 Thread Andras Farkas

Evening!
This diff allows users to use the name of a service in /etc/services 
instead of a port number when using netcat. Hopefully, this will make 
using netcat easier for some users.



? nc
Index: nc.1
===
RCS file: /cvs/src/usr.bin/nc/nc.1,v
retrieving revision 1.71
diff -u -p -r1.71 nc.1
--- nc.125 Sep 2015 14:56:33 -  1.71
+++ nc.11 Jun 2016 02:56:09 -
@@ -51,7 +51,7 @@
 .Op Fl X Ar proxy_protocol
 .Op Fl x Ar proxy_address Ns Op : Ns Ar port
 .Op Ar destination
-.Op Ar port
+.Op Ar port | service
 .Sh DESCRIPTION
 The
 .Nm
@@ -344,6 +344,10 @@ a destination port must be specified,
 unless the
 .Fl U
 option is given.
+.Pp
+.Ar service
+is the name of a service in
+.Pa /etc/services
 .Sh CLIENT/SERVER MODEL
 It is quite simple to build a very basic client/server model using
 .Nm .
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.152
diff -u -p -r1.152 netcat.c
--- netcat.c28 May 2016 20:14:58 -  1.152
+++ netcat.c1 Jun 2016 02:56:09 -
@@ -1291,22 +1291,43 @@ atelnet(int nfd, unsigned char *buf, uns
 void
 build_ports(char *p)
 {
+   struct servent *entry;
const char *errstr;
char *n;
+   char *proto;
int hi, lo, cp;
int x = 0;

+   if (uflag == 1)
+   proto = "udp";
+   else
+   proto = "tcp";
+
if ((n = strchr(p, '-')) != NULL) {
*n = '\0';
n++;

/* Make sure the ports are in order: lowest->highest. */
hi = strtonum(n, 1, PORT_MAX, );
-   if (errstr)
-   errx(1, "port number %s: %s", errstr, n);
+   if (errstr) {
+   if (errno == EINVAL) {
+   entry = getservbyname(n, proto);
+   if (entry == NULL)
+   errx(1, "service \"%s\" unknown", n);
+   hi = ntohs(entry->s_port);
+   } else
+   errx(1, "port number %s: %s", errstr, n);
+   }
lo = strtonum(p, 1, PORT_MAX, );
-   if (errstr)
-   errx(1, "port number %s: %s", errstr, p);
+   if (errstr) {
+   if (errno == EINVAL) {
+   entry = getservbyname(p, proto);
+   if (entry == NULL)
+   errx(1, "service \"%s\" unknown", p);
+   hi = ntohs(entry->s_port);
+   } else
+   errx(1, "port number %s: %s", errstr, p);
+   }

if (lo > hi) {
cp = hi;
@@ -1334,8 +1355,15 @@ build_ports(char *p)
}
} else {
hi = strtonum(p, 1, PORT_MAX, );
-   if (errstr)
-   errx(1, "port number %s: %s", errstr, p);
+   if (errstr) {
+   if (errno == EINVAL) {
+   entry = getservbyname(p, proto);
+   if (entry == NULL)
+   errx(1, "service \"%s\" unknown", p);
+   hi = ntohs(entry->s_port);
+   } else
+   errx(1, "port number %s: %s", errstr, p);
+   }
portlist[0] = strdup(p);
if (portlist[0] == NULL)
err(1, NULL);



LibreSSL 2.4.0/2.3.5/2.2.8 Released

2016-05-31 Thread Brent Cook
We have released a first development snapshot of LibreSSL 2.4.0 along
with two stable builds, 2.3.5 and 2.2.8. These should be arriving in
the LibreSSL directory of your local OpenBSD mirror soon.

The 2.3.5 and 2.2.8 releases contain a reliability fix, correcting an
error when parsing certain ASN.1 elements over 16k in size.

The 2.4.0 release contains the following additional changes:

* Implemented the IETF ChaCha20-Poly1305 cipher suites.

* Changed default EVP_aead_chacha20_poly1305() implementation to the
  IETF version, which is now the default.

* Many improvements to the CMake build infrastructure, including
  Solaris, mingw-w64, Cygwin, and HP-UX support. Thanks to Kinichiro
  Inoguchi for this work.

* Reworked error handling in libtls so that configuration errors are
  more visible.

* Added missing error handling around bn_wexpand() calls.

* Added explicit_bzero calls for freed ASN.1 objects.

* Fixed X509_*set_object functions to return 0 on allocation failure.

* Fixed password prompts from openssl(1) to properly handle ^C.

* Deprecated internal use of EVP_[Cipher|Encrypt|Decrypt]_Final.

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



kdump small timespecs

2016-05-31 Thread Ted Unangst
Small timespecs print funny:

 57686 chrome   CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7f0028)
 57686 chrome   STRU  struct timespec { 15411<"Dec 31 23:16:51 1969">.584609082 
}
 57686 chrome   RET   clock_gettime 0
 57686 chrome   CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7eff48)
 57686 chrome   STRU  struct timespec { 15411<"Dec 31 23:16:51 1969">.584623819 
}
 57686 chrome   RET   clock_gettime 0

Here's a simple heuristic which makes this output a little easier to read,
without the meaningless 1969 dates.

 57686 chrome   CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7f0028)
 57686 chrome   STRU  struct timespec { 15411.584609082 }
 57686 chrome   RET   clock_gettime 0
 57686 chrome   CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7eff48)
 57686 chrome   STRU  struct timespec { 15411.584623819 }
 57686 chrome   RET   clock_gettime 0


Index: ktrstruct.c
===
RCS file: /cvs/src/usr.bin/kdump/ktrstruct.c,v
retrieving revision 1.19
diff -u -p -r1.19 ktrstruct.c
--- ktrstruct.c 22 May 2016 23:02:28 -  1.19
+++ ktrstruct.c 1 Jun 2016 01:41:59 -
@@ -147,7 +147,8 @@ print_time(time_t t, int relative, int h
} else
printf("%jd", (intmax_t)t);
 
-   if (!relative) {
+   /* small timespecs are probably relative */
+   if (!relative && t > 86400) {
tm = localtime();
if (tm != NULL) {
(void)strftime(timestr, sizeof(timestr), TIME_FORMAT,



Kill sysctl net.inet6.ip6.rr_prune

2016-05-31 Thread Jeremie Courreges-Anglas

We don't support Router Renumbering (RFC2894).

ok?

Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.259
diff -u -p -r1.259 sysctl.3
--- lib/libc/gen/sysctl.3   29 May 2016 17:01:07 -  1.259
+++ lib/libc/gen/sysctl.3   1 Jun 2016 00:21:08 -
@@ -1676,7 +1676,6 @@ The currently defined protocols and name
 .It ip6 Ta multipath Ta integer Ta yes
 .It ip6 Ta neighborgcthresh Ta integer Ta yes
 .It ip6 Ta redirect Ta integer Ta yes
-.It ip6 Ta rr_prune Ta integer Ta yes
 .It ip6 Ta use_deprecated Ta integer Ta yes
 .El
 .Pp
@@ -1871,10 +1870,6 @@ The default value is 2048.
 Returns 1 when ICMPv6 redirects may be sent by the node.
 This option is ignored unless the node is routing IP packets,
 and should normally be enabled on all systems.
-.Pp
-.It Li ip6.rr_prune
-This variable specifies the interval between IPv6 router renumbering prefix
-babysitting in seconds.
 .Pp
 .It Li ip6.use_deprecated
 This variable controls the use of deprecated addresses, specified in
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.196
diff -u -p -r1.196 sysctl.8
--- sbin/sysctl/sysctl.829 May 2016 17:01:07 -  1.196
+++ sbin/sysctl/sysctl.81 Jun 2016 00:21:08 -
@@ -295,7 +295,6 @@ and a few require a kernel compiled with
 .It net.inet6.ip6.auto_flowlabel Ta integer Ta yes
 .It net.inet6.ip6.defmcasthlim Ta integer Ta yes
 .It net.inet6.ip6.use_deprecated Ta integer Ta yes
-.It net.inet6.ip6.rr_prune Ta integer Ta yes
 .It net.inet6.ip6.maxfrags Ta integer Ta yes
 .It net.inet6.ip6.mforwarding Ta integer Ta yes
 .It net.inet6.ip6.multipath Ta integer Ta yes
Index: sys/netinet6/in6.h
===
RCS file: /cvs/src/sys/netinet6/in6.h,v
retrieving revision 1.88
diff -u -p -r1.88 in6.h
--- sys/netinet6/in6.h  19 May 2016 11:34:39 -  1.88
+++ sys/netinet6/in6.h  1 Jun 2016 00:21:08 -
@@ -576,7 +576,6 @@ ifatoia6(struct ifaddr *ifa)
 #define IPV6CTL_AUTO_FLOWLABEL 17
 #define IPV6CTL_DEFMCASTHLIM   18
 #define IPV6CTL_USE_DEPRECATED 21  /* use deprecated addr (RFC2462 5.5.4) 
*/
-#define IPV6CTL_RR_PRUNE   22  /* walk timer for router renumbering */
 /* 24 to 40: reserved */
 #define IPV6CTL_MAXFRAGS   41  /* max fragments */
 #define IPV6CTL_MFORWARDING42
@@ -619,7 +618,7 @@ ifatoia6(struct ifaddr *ifa)
{ 0, 0 }, \
{ 0, 0 }, \
{ "use_deprecated", CTLTYPE_INT }, \
-   { "rr_prune", CTLTYPE_INT }, \
+   { 0, 0 }, \
{ 0, 0 }, \
{ 0, 0 }, \
{ 0, 0 }, \
@@ -676,7 +675,7 @@ ifatoia6(struct ifaddr *ifa)
NULL, \
NULL, \
_use_deprecated, \
-   _rr_prune, \
+   NULL, \
NULL, \
NULL, \
NULL, \
Index: sys/netinet6/in6_proto.c
===
RCS file: /cvs/src/sys/netinet6/in6_proto.c,v
retrieving revision 1.85
diff -u -p -r1.85 in6_proto.c
--- sys/netinet6/in6_proto.c19 May 2016 11:34:40 -  1.85
+++ sys/netinet6/in6_proto.c1 Jun 2016 00:21:08 -
@@ -279,8 +279,6 @@ int ip6_dad_count = 1;  /* DupAddrDetecti
 intip6_dad_pending;/* number of currently running DADs */
 intip6_auto_flowlabel = 1;
 intip6_use_deprecated = 1; /* allow deprecated addr (RFC2462 5.5.4) */
-intip6_rr_prune = 5;   /* router renumbering prefix
-* walk list every 5 sec.*/
 intip6_mcast_pmtu = 0; /* enable pMTU discovery for multicast? */
 intip6_neighborgcthresh = 2048; /* Threshold # of NDP entries for GC */
 intip6_maxifprefixes = 16; /* Max acceptable prefixes via RA per IF */
Index: sys/netinet6/ip6_var.h
===
RCS file: /cvs/src/sys/netinet6/ip6_var.h,v
retrieving revision 1.59
diff -u -p -r1.59 ip6_var.h
--- sys/netinet6/ip6_var.h  19 May 2016 11:34:40 -  1.59
+++ sys/netinet6/ip6_var.h  1 Jun 2016 00:21:08 -
@@ -219,8 +219,6 @@ extern int  ip6_mforwarding;/* act as mu
 extern int ip6_multipath;  /* use multipath routes */
 extern int ip6_sendredirect;   /* send ICMPv6 redirect? */
 extern int ip6_use_deprecated; /* allow deprecated addr as source */
-extern int ip6_rr_prune;   /* router renumbering prefix
-* walk list every 5 sec.*/
 extern int ip6_mcast_pmtu; /* path MTU discovery for multicast */
 extern int ip6_neighborgcthresh; /* Threshold # of NDP entries for GC */
 extern int ip6_maxifprefixes; /* Max acceptable prefixes via RA per IF */


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: sqlite3 update

2016-05-31 Thread James Turner
On Tue, May 31, 2016 at 11:36:35PM +0100, Stuart Henderson wrote:
> Thanks for the pointer Ingo..
> 
> I'll be doing tests (including a bulk ports build) with this,
> but here's an update to sqlite 3.10.2 (the version which is
> in Firefox 46) in the hope it will let us get rid of the
> conflicting sqlite3 versions in firefox.
> 
> If this is the wrong version to be targetting (Landry?) please
> let me know.
> 
> If anyone has anything in particular they'd like to test,
> could you try it please.
> 
> A shlib_version update is included, four symbols were removed so
> it's a major bump.
> 
> I modified addopcodes.awk by hand based on the changes in the
> upstream version which has now switched to a Tcl script.
> 
> (I don't really understand how things are working in Firefox on
> other OS, there are two different versions of sqlite in their

Stuart,

This looks good. I've tested with mandoc and fossil in ports. ok
jturner.

-- 
James Turner



removing wsmouse_input [2]: zts, hilms, uts

2016-05-31 Thread Ulf Brosziewski
zts, hilms, and uts are the drivers that still use wsmouse_input
with absolute coordinates (or with both types of coordinates).
The new, "flag-less" interface of wsmouse requires calls of
wsmouse_position, and, possibly, of wsmouse_touch in this case.

Questions, tests and OKs would be welcome.


Index: arch/zaurus/dev/zts.c
===
RCS file: /cvs/src/sys/arch/zaurus/dev/zts.c,v
retrieving revision 1.16
diff -u -p -r1.16 zts.c
--- arch/zaurus/dev/zts.c   29 Mar 2014 18:09:30 -  1.16
+++ arch/zaurus/dev/zts.c   31 May 2016 19:23:10 -
@@ -544,10 +544,9 @@ zts_irq(void *v)
DPRINTF(("%s: tp.z = %d, tp.x = %d, tp.y = %d\n",
sc->sc_dev.dv_xname, tp.z, tp.x, tp.y));
 
-   wsmouse_input(sc->sc_wsmousedev, down, tp.x, tp.y,
-   0 /* z */, 0 /* w */,
-   WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
-   WSMOUSE_INPUT_ABSOLUTE_Z);
+   wsmouse_buttons(sc->sc_wsmousedev, down);
+   wsmouse_position(sc->sc_wsmousedev, tp.x, tp.y);
+   wsmouse_input_sync(sc->sc_wsmousedev);
sc->sc_buttons = down;
sc->sc_oldx = tp.x;
sc->sc_oldy = tp.y;
Index: dev/hil/hilms.c
===
RCS file: /cvs/src/sys/dev/hil/hilms.c,v
retrieving revision 1.5
diff -u -p -r1.5 hilms.c
--- dev/hil/hilms.c 10 Apr 2007 22:37:17 -  1.5
+++ dev/hil/hilms.c 31 May 2016 19:23:10 -
@@ -219,7 +219,7 @@ void
 hilms_callback(struct hildev_softc *dev, u_int buflen, u_int8_t *buf)
 {
struct hilms_softc *sc = (struct hilms_softc *)dev;
-   int type, flags;
+   int type;
int dx, dy, dz, button;
 #ifdef DIAGNOSTIC
int minlen;
@@ -256,9 +256,6 @@ hilms_callback(struct hildev_softc *dev,
 */
 
if (type & HIL_MOUSEMOTION) {
-   flags = sc->sc_features & HIL_ABSOLUTE ?
-   WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
-   WSMOUSE_INPUT_ABSOLUTE_Z : WSMOUSE_INPUT_DELTA;
if (sc->sc_features & HIL_16_BITS) {
dx = *buf++;
dx |= (*buf++) << 8;
@@ -302,8 +299,7 @@ hilms_callback(struct hildev_softc *dev,
if ((sc->sc_features & HIL_ABSOLUTE) == 0 &&
sc->sc_buttons == 0)
dy = -dy;
-   } else
-   dx = dy = dz = flags = 0;
+   }
 
if (type & HIL_MOUSEBUTTON) {
button = *buf;
@@ -332,7 +328,18 @@ hilms_callback(struct hildev_softc *dev,
/* buf++; */
}

-   if (sc->sc_wsmousedev != NULL)
-   wsmouse_input(sc->sc_wsmousedev,
-   sc->sc_buttonstate, dx, dy, dz, 0, flags);
+   if (sc->sc_wsmousedev == NULL)
+   return;
+
+   wsmouse_buttons(sc->sc_wsmousedev, sc->sc_buttonstate);
+   if (type & HIL_MOUSEMOTION) {
+   if ((sc->sc_features & HIL_ABSOLUTE) == 0) {
+   wsmouse_motion(sc->sc_wsmousedev, dx, dy, dz, 0);
+   } else {
+   wsmouse_position(sc->sc_wsmousedev, dx, dy);
+   if (sc->sc_axes > 2)
+   wsmouse_touch(sc->sc_wsmousedev, dz, 0);
+   }
+   }
+   wsmouse_input_sync(sc->sc_wsmousedev);
 }
Index: dev/usb/uts.c
===
RCS file: /cvs/src/sys/dev/usb/uts.c,v
retrieving revision 1.37
diff -u -p -r1.37 uts.c
--- dev/usb/uts.c   10 Feb 2016 05:49:50 -  1.37
+++ dev/usb/uts.c   31 May 2016 19:23:12 -
@@ -476,9 +476,7 @@ uts_intr(struct usbd_xfer *xfer, void *a
DPRINTF(("%s: tp.down = %d, tp.z = %d, tp.x = %d, tp.y = %d\n",
sc->sc_dev.dv_xname, tp.down, tp.z, tp.x, tp.y));
 
-   wsmouse_input(sc->sc_wsmousedev, tp.down, tp.x, tp.y, tp.z, 0,
-   WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
-   WSMOUSE_INPUT_ABSOLUTE_Z);
+   WSMOUSE_TOUCH(sc->sc_wsmousedev, tp.down, tp.x, tp.y, tp.z, 0);
sc->sc_oldy = tp.y;
sc->sc_oldx = tp.x;
 



removing wsmouse_input [1]

2016-05-31 Thread Ulf Brosziewski
These diffs adapt various drivers to the new input functions of
wsmouse, namely
arch/i386/isa/lms.c,
arch/i386/isa/mms.c,
arch/luna88k/dev/lunaws.c,
arch/sgi/hpc/z8530ms.c,
dev/adb/ams.c,
dev/sun/sunms.c, and
dev/usb/utpms.c.
Each of the diffs just replaces wsmouse_input with the WSMOUSE_INPUT
macro, which reports inputs with relative coordinates to wsmouse
(I will post a second set of diffs for drivers that handle absolute
coordinates).

Tests and/or OKs would be welcome.


Index: arch/i386/isa/lms.c
===
RCS file: /cvs/src/sys/arch/i386/isa/lms.c,v
retrieving revision 1.20
diff -u -p -r1.20 lms.c
--- arch/i386/isa/lms.c 10 Apr 2007 22:37:17 -  1.20
+++ arch/i386/isa/lms.c 31 May 2016 19:23:09 -
@@ -235,8 +235,7 @@ lmsintr(void *arg)
sc->oldbuttons = buttons;
 
if (dx || dy || changed)
-   wsmouse_input(sc->sc_wsmousedev,
- buttons, dx, dy, 0, 0, WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->sc_wsmousedev, buttons, dx, dy, 0, 0);
 
return -1;
 }
Index: arch/i386/isa/mms.c
===
RCS file: /cvs/src/sys/arch/i386/isa/mms.c,v
retrieving revision 1.19
diff -u -p -r1.19 mms.c
--- arch/i386/isa/mms.c 10 Apr 2007 22:37:17 -  1.19
+++ arch/i386/isa/mms.c 31 May 2016 19:23:09 -
@@ -229,8 +229,7 @@ mmsintr(void *arg)
changed = status & 0x38;
 
if (dx || dy || changed)
-   wsmouse_input(sc->sc_wsmousedev,
- buttons, dx, dy, 0, 0, WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->sc_wsmousedev, buttons, dx, dy, 0, 0);
 
return -1;
 }
Index: arch/luna88k/dev/lunaws.c
===
RCS file: /cvs/src/sys/arch/luna88k/dev/lunaws.c,v
retrieving revision 1.11
diff -u -p -r1.11 lunaws.c
--- arch/luna88k/dev/lunaws.c   7 Jun 2014 11:55:35 -   1.11
+++ arch/luna88k/dev/lunaws.c   31 May 2016 19:23:09 -
@@ -260,9 +260,8 @@ wsintr(int chan)
else if (sc->sc_msreport == 2) {
sc->dy = (signed char)code;
if (sc->sc_wsmousedev != NULL)
-   wsmouse_input(sc->sc_wsmousedev,
-   sc->buttons, sc->dx, sc->dy, 0, 0,
-   WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->sc_wsmousedev,
+   sc->buttons, sc->dx, sc->dy, 0, 0);
sc->sc_msreport = 0;
}
 #else
Index: arch/sgi/hpc/z8530ms.c
===
RCS file: /cvs/src/sys/arch/sgi/hpc/z8530ms.c,v
retrieving revision 1.1
diff -u -p -r1.1 z8530ms.c
--- arch/sgi/hpc/z8530ms.c  17 Apr 2012 22:06:33 -  1.1
+++ arch/sgi/hpc/z8530ms.c  31 May 2016 19:23:09 -
@@ -296,7 +296,7 @@ zsms_wsmouse_input(struct zsms_softc *sc
x = (int)sc->packet[ZSMS_PACKET_X1] + (int)sc->packet[ZSMS_PACKET_X2];
y = (int)sc->packet[ZSMS_PACKET_Y1] + (int)sc->packet[ZSMS_PACKET_Y2];
 
-   wsmouse_input(sc->wsmousedev, btns, x, y, 0, 0, WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->wsmousedev, btns, x, y, 0, 0);
 }
 
 int
Index: dev/adb/ams.c
===
RCS file: /cvs/src/sys/dev/adb/ams.c,v
retrieving revision 1.6
diff -u -p -r1.6 ams.c
--- dev/adb/ams.c   15 Jun 2011 21:32:05 -  1.6
+++ dev/adb/ams.c   31 May 2016 19:23:10 -
@@ -501,8 +501,7 @@ ms_processevent(adb_event_t *event, stru
((event->bytes[0] & 0x40) ? 64 : 0);
 
if (sc->sc_wsmousedev)
-   wsmouse_input(sc->sc_wsmousedev, buttons, dx, -dy, 0, 0,
-   WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->sc_wsmousedev, buttons, dx, -dy, 0, 0);
 }
 
 int
Index: dev/sun/sunms.c
===
RCS file: /cvs/src/sys/dev/sun/sunms.c,v
retrieving revision 1.1
diff -u -p -r1.1 sunms.c
--- dev/sun/sunms.c 20 May 2009 18:22:33 -  1.1
+++ dev/sun/sunms.c 31 May 2016 19:23:12 -
@@ -220,8 +220,8 @@ sunms_input(struct sunms_softc *sc, int 
if (sc->sc_byteno == sc->sc_pktlen) {
timeout_del(>sc_abort_tmo);
sc->sc_byteno = -1;
-   wsmouse_input(sc->sc_wsmousedev, sc->sc_mb,
-   sc->sc_dx, sc->sc_dy, 0, 0, WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->sc_wsmousedev,
+   sc->sc_mb, sc->sc_dx, sc->sc_dy, 0, 0);
sc->sc_dx = sc->sc_dy = 0;
}
 }
Index: dev/usb/utpms.c
===
RCS file: /cvs/src/sys/dev/usb/utpms.c,v

Re: lib/libsqlite3/src/sqlite3.h

2016-05-31 Thread Marc Espie
On Tue, May 31, 2016 at 11:02:30PM +0100, Stuart Henderson wrote:
> Does anyone know/remember how src/sqlite3.h is generated?

By the target called "header" in the Makefile



Re: lib/libsqlite3/src/sqlite3.h

2016-05-31 Thread Ingo Schwarze
Hi Stuart,

Stuart Henderson wrote on Tue, May 31, 2016 at 11:02:30PM +0100:

> Does anyone know/remember how src/sqlite3.h is generated?

/usr/src/lib/libsqlite3/Makefile:
  .PHONY: header
  header:
cd ${.CURDIR} && perl tsrc/header_regen VERSION \
src/sqlite.h.in src/sqlite3.h sqlite3.pc.in sqlite3.pc

/usr/src/lib/libsqlite3/tsrc/header_regen:
  # Written by Marc Espie 2012, Public Domain

Yours,
  Ingo



Re: MBIM Patch - Part 2 of 4

2016-05-31 Thread Theo de Raadt
> But using SIOCAIFADDR/SIOCDIFADDR seems rather awkward since in_control()
> requires a 'struct socket *so' argument (even though it does nothing with
> it, except checking 'so->so_state & SS_PRIV'). Creating a socket inside
> the driver for this sole purpose seems just as weird as setting up a
> fake struct socket.
> 
> Are you really sure, this is the better way to go?

No.  This particular layer violation does not belong inside this
driver.  Instead, the driver should probably generate a route socket
message, and then something on the outside would cause that effect of
configuring addresses, routes, etc etc.

But anyways, this conversation is not getting any code commited.

The driver -- minus the contentious bits -- should be be shown, in
just good enough form to compile.  Then the contentious bits can be
argued about and worked on together as a team...




lib/libsqlite3/src/sqlite3.h

2016-05-31 Thread Stuart Henderson
Does anyone know/remember how src/sqlite3.h is generated?



Re: uvideo patches: V4L2_BUF_FLAG_{DONE,QUEUED} [4/4]

2016-05-31 Thread Marcus Glocker
On Tue, May 17, 2016 at 05:20:14PM -0700, patrick keshishian wrote:

> 4/4: I don't believe V4L2_BUF_FLAG_QUEUED and V4L2_BUF_FLAG_DONE
>  flags are handled correctly in our uvideo driver.

Agreed.

> According to linuxtv.org Buffers Chap 3. Input/Output Table 3.4
> Buffer Flags:
> 
> https://www.linuxtv.org/downloads/legacy/video4linux/API/V4L2_API/spec-single/v4l2.html#buffer-flags
> 
> V4L2_BUF_FLAG_QUEUED
>   [The buffer] automatically moves to the outgoing queue
>   after the buffer has been filled or displayed. Drivers
>   set or clear this flag when the _QUERYBUF ioctl is
>   called.
>   After (successful) calling the _QBUF ioctl it is always
>   set and after _DQBUF alwyas cleared
> 
> V4L2_BUF_FLAG_DONE
>   When this flag is set, the buffer is currently on the
>   outgoing queue, ready to be dequeued from the driver.
>   Drivers set or clear this flag when the _QUERYBUF ioctl
>   is called.
>   After calling the _QBUF or _DQBUF it is always cleared.
>   Of course a buffer cannot be on both queues at the same
>   time, the _QUEUED and _DONE flag are mutually exclusive.
>   They can be both cleared however, then the buffer is in
>   "dequeued" state, in the application domain so to say.
> 
> This patch I'm a bit lukewarm on.
> 
> It gets rid of sc_mmap_cur used mainly in uvideo_mmap_queue()
> looking to find a buffer which can be "queued".
> 
> Since the _QUEUE flag is never cleared in this driver, is it
> potentially reusing a buffer which the client/consumer may not
> yet be done with?
> 
> Also, I couldn't convince myself that the while()-loop searching
> for this buffer, once the _QUEUE flag clearing is fixed, would
> not end up in a situation where it would equal to sc_mmap_count
> and never get past returning ENOMEM.
> 
> I think (but am not sure) the intent of sc_mmap_cur is to give
> each buffer a fair chance at getting used. Where, w/o it, and
> a fast client/consumer, it is possible that only the first few
> buffers would get all the attention.
> 
> Or maybe I'm reading all this incorrectly.
> 
> Thoughts?

I think by fixing the flags it's right to get rid of sc_mmap_cur and
query the buffer queue just based on the flags.  Indeed this will lead
to less buffers beeing used.  I did some tests and up to a resolution of
800x600 just one buffer got used.  With 1600x1200 I could see 4 buffers
beeing used.  But this is fine IMO.  When the client is fast enough to
fetch the buffers it's ok when the driver doesn't need to build up a
long queue.  Also it gives us more transparency about under which
conditions the driver queue gets utilized.

I made some inline comments and attached an updated diff based on the
comments.

> Index: uvideo.c
> ===
> RCS file: /cvs/obsd/src/sys/dev/usb/uvideo.c,v
> retrieving revision 1.185
> diff -u -p -u -p -r1.185 uvideo.c
> --- uvideo.c  17 May 2016 08:27:17 -  1.185
> +++ uvideo.c  17 May 2016 23:08:32 -
> @@ -78,7 +78,6 @@ struct uvideo_softc {
>   size_t   sc_mmap_buffer_size;
>   q_mmap   sc_mmap_q;
>   int  sc_mmap_count;
> - int  sc_mmap_cur;
>   int  sc_mmap_flag;
>  
>   struct vnode*sc_vp;
> @@ -590,7 +589,6 @@ uvideo_attach_hook(struct device *self)
>  
>   /* init mmap queue */
>   SIMPLEQ_INIT(>sc_mmap_q);
> - sc->sc_mmap_cur = -1;
>   sc->sc_mmap_count = 0;
>  
>   DPRINTF(1, "uvideo_attach: doing video_attach_mi\n");
> @@ -1695,7 +1693,6 @@ uvideo_vs_free_frame(struct uvideo_softc
>   while (!SIMPLEQ_EMPTY(>sc_mmap_q))
>   SIMPLEQ_REMOVE_HEAD(>sc_mmap_q, q_frames);
>  
> - sc->sc_mmap_cur = -1;
>   sc->sc_mmap_count = 0;
>  }
>  
> @@ -2208,44 +2205,45 @@ uvideo_vs_decode_stream_header_isight(st
>  }
>  
>  int
> +uvideo_find_queued(struct uvideo_softc *sc)
> +{
> + int i;
> + for (i = 0; i < sc->sc_mmap_count; ++i) {
> + if (sc->sc_mmap[i].v4l2_buf.flags & V4L2_BUF_FLAG_DONE)
> + continue;
> + if (sc->sc_mmap[i].v4l2_buf.flags & V4L2_BUF_FLAG_QUEUED)
> + break;
> + }
> + return (i == sc->sc_mmap_count) ? -1 : i;
> +}

I don't think we need to introduce a new function to query a free buffer
and can leave it in uvideo_mmap_queue() instead.  Also I think it's not 
required to additionally check for V4L2_BUF_FLAG_DONE.  Either
V4L2_BUF_FLAG_QUEUED is set or not.

> +int
>  uvideo_mmap_queue(struct uvideo_softc *sc, uint8_t *buf, int len)
>  {
> - if (sc->sc_mmap_cur < 0 || sc->sc_mmap_count == 0 ||
> - sc->sc_mmap_buffer == NULL)
> + int i;
> +
> + if (sc->sc_mmap_count == 0 || sc->sc_mmap_buffer == NULL)
>   panic("%s: mmap buffers not 

Re: ifa_ifwithroute() fix

2016-05-31 Thread Vincent Gross
On Tue, 31 May 2016 09:51:10 +0200
Martin Pieuchot  wrote:

> On 19/04/16(Tue) 10:43, Martin Pieuchot wrote:
> > Mart Tõnso reported [0] a weird case related to the use of
> > ifa_ifwithnet().
> > 
> > The problem is that ifa_ifwithroute() does not always use route
> > entries but the poor's man routing table: ifa_ifwithnet().  This is
> > misleading because one cannot understand why "# route add" is not
> > coherent with "# route get".
> > 
> > So I'd like to commit the diff below which always use the route
> > table unless an interface index is specified in the gateway.  Mart
> > Tõnso confirmed it fixes his issue.
> > 
> > ok?  
> 
> Anyone?

ok vgross@

> 
> > 
> > [0] https://marc.info/?l=openbsd-misc=146046751201006=2
> > 
> > 
> > Index: net/route.c
> > ===
> > RCS file: /cvs/src/sys/net/route.c,v
> > retrieving revision 1.298
> > diff -u -p -r1.298 route.c
> > --- net/route.c 26 Mar 2016 21:56:04 -  1.298
> > +++ net/route.c 13 Apr 2016 07:38:11 -
> > @@ -740,20 +740,16 @@ ifa_ifwithroute(int flags, struct sockad
> > ifa = ifaof_ifpforaddr(dst, ifp);
> > if_put(ifp);
> > } else {
> > -   ifa = ifa_ifwithnet(gateway, rtableid);
> > -   }
> > -   }
> > -   if (ifa == NULL) {
> > -   struct rtentry  *rt = rtalloc(gateway, 0,
> > rtableid);
> > -   /* The gateway must be local if the same address
> > family. */
> > -   if (!rtisvalid(rt) || ((rt->rt_flags &
> > RTF_GATEWAY) &&
> > -   rt_key(rt)->sa_family == dst->sa_family)) {
> > +   struct rtentry *rt;
> > +
> > +   rt = rtalloc(gateway, RT_RESOLVE,
> > rtableid);
> > +   if (rt != NULL)
> > +   ifa = rt->rt_ifa;
> > rtfree(rt);
> > -   return (NULL);
> > }
> > -   ifa = rt->rt_ifa;
> > -   rtfree(rt);
> > }
> > +   if (ifa == NULL)
> > +   return (NULL);
> > if (ifa->ifa_addr->sa_family != dst->sa_family) {
> > struct ifaddr   *oifa = ifa;
> > ifa = ifaof_ifpforaddr(dst, ifa->ifa_ifp);
> >   
> 



Re: ptrace PT_IO write bug

2016-05-31 Thread Mathieu -
Mark Kettenis wrote:
> > > The documentation may have been wrong for some time on some archs, it
> > > feels like making PT_WRITE_D and PT_WRITE_I equivalent was deemed
> > > useful at one point.  Given that Free and NetBSD document the same
> > > guarantee, I personally don't feel comfortable changing that, but YMMV.
> > 
> > This is a trap designed to make code work on amd64 and fail on hppa.
> > But if kettenis cares more about hppa than most people, maybe we should let
> > him be the one to decide. :)
> 
> I'm not really worried about this; ptrace(2) is only used by gdb and
> people writing exploits ;).

Hi guys,

I see Ted did commit an update to the docs, the root issue is still
present though and is adressed in the latest version of my patch, what's
the status on that one?



Re: xhci(4) vs BIOS

2016-05-31 Thread David Hill
On Tue, May 31, 2016 at 06:43:16PM +0200, Martin Pieuchot wrote:
> I finally got my hands on a DELL Optiplex 3020.  The BIOS on this
> machines uses the xHCI controller to handle the keyboard and mouse.
> 
> Turns out that I badly copy/pasted the ehci(4) code to take over the
> HC from the BIOS.  With the diff below I can now route all my ports
> to xhci(4) and the machine no longer hang at boot.
> 
> ok?
> 

Fixes my Dell Latitude.

Thanks!
David



delete OSIOCGIFCONF

2016-05-31 Thread Ted Unangst
it's dead.

Index: sockio.h
===
RCS file: /cvs/src/sys/sys/sockio.h,v
retrieving revision 1.63
diff -u -p -r1.63 sockio.h
--- sockio.h2 Mar 2016 00:00:16 -   1.63
+++ sockio.h31 May 2016 18:56:49 -
@@ -54,7 +54,6 @@
 #defineSIOCGIFFLAGS_IOWR('i', 17, struct ifreq)/* get ifnet 
flags */
 #defineSIOCGIFBRDADDR  _IOWR('i', 35, struct ifreq)/* get 
broadcast addr */
 #defineSIOCSIFBRDADDR   _IOW('i', 19, struct ifreq)/* set 
broadcast addr */
-#defineOSIOCGIFCONF_IOWR('i', 20, struct ifconf)   /* get ifnet 
list */
 #defineSIOCGIFCONF _IOWR('i', 36, struct ifconf)   /* get ifnet 
list */
 #defineSIOCGIFNETMASK  _IOWR('i', 37, struct ifreq)/* get net addr 
mask */
 #defineSIOCSIFNETMASK   _IOW('i', 22, struct ifreq)/* set net addr 
mask */



Re: lockmgr() api removal

2016-05-31 Thread Theo de Raadt
> Martin Natano wrote:
> > It is time for the lockmgr() api to die. The api is only used by
> > filesystems, where it is a trivial change to use rrw locks instead. All
> > it needs is LK_* defines for the RW_* flags. (See the sys/lock.h hunk in
> > the diff below.)
> > 
> > The ffs regress tests display the same number of fail/ok results before
> > and after applying diff below, and I have done some manual testing with
> > various filesystems on amd64 and macppc.
> > 
> > Again, the purpose is to make filesystem code less scary and more
> > comprehensible.
> 
> Yes, I'm concerned this needs lots of testing, but it is the right thing to
> do.

I won't be testing this in snapshots, because there is too much churn
in ports at the moment.



Re: lockmgr() api removal

2016-05-31 Thread Ted Unangst
Martin Natano wrote:
> It is time for the lockmgr() api to die. The api is only used by
> filesystems, where it is a trivial change to use rrw locks instead. All
> it needs is LK_* defines for the RW_* flags. (See the sys/lock.h hunk in
> the diff below.)
> 
> The ffs regress tests display the same number of fail/ok results before
> and after applying diff below, and I have done some manual testing with
> various filesystems on amd64 and macppc.
> 
> Again, the purpose is to make filesystem code less scary and more
> comprehensible.

Yes, I'm concerned this needs lots of testing, but it is the right thing to
do.



Re: ptrace PT_IO write bug

2016-05-31 Thread Mark Kettenis
> From: "Ted Unangst" 
> Date: Tue, 31 May 2016 13:57:04 -0400
> 
> Jeremie Courreges-Anglas wrote:
> > >> 
> > >> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
> > >> since rev. 1.1, I doubt that such an optimization is a good idea.
> > >
> > > A clear case where the documentation is wrong.
> > 
> > 
> > The documentation may have been wrong for some time on some archs, it
> > feels like making PT_WRITE_D and PT_WRITE_I equivalent was deemed
> > useful at one point.  Given that Free and NetBSD document the same
> > guarantee, I personally don't feel comfortable changing that, but YMMV.
> 
> This is a trap designed to make code work on amd64 and fail on hppa.
> But if kettenis cares more about hppa than most people, maybe we should let
> him be the one to decide. :)

I'm not really worried about this; ptrace(2) is only used by gdb and
people writing exploits ;).



Re: xhci(4) vs BIOS

2016-05-31 Thread Mark Kettenis
> Date: Tue, 31 May 2016 18:43:16 +0200
> From: Martin Pieuchot 
> 
> I finally got my hands on a DELL Optiplex 3020.  The BIOS on this
> machines uses the xHCI controller to handle the keyboard and mouse.
> 
> Turns out that I badly copy/pasted the ehci(4) code to take over the
> HC from the BIOS.  With the diff below I can now route all my ports
> to xhci(4) and the machine no longer hang at boot.
> 
> ok?

ok kettenis@

> Index: xhci_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 xhci_pci.c
> --- xhci_pci.c2 Nov 2015 14:53:10 -   1.7
> +++ xhci_pci.c31 May 2016 16:36:14 -
> @@ -258,8 +258,9 @@ xhci_pci_takecontroller(struct xhci_pci_
>   eec = -1;
>  
>   /* Synchronise with the BIOS if it owns the controller. */
> - for (xecp = XHCI_HCC_XECP(cparams) << 2; xecp != 0;
> - xecp = XHCI_XECP_NEXT(eec) << 2) {
> + for (xecp = XHCI_HCC_XECP(cparams) << 2;
> + xecp != 0 && XHCI_XECP_NEXT(eec);
> + xecp += XHCI_XECP_NEXT(eec) << 2) {
>   eec = XREAD4(>sc, xecp);
>   if (XHCI_XECP_ID(eec) != XHCI_ID_USB_LEGACY)
>   continue;
> 
> 



Re: ptrace PT_IO write bug

2016-05-31 Thread Ted Unangst
Jeremie Courreges-Anglas wrote:
> >> 
> >> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
> >> since rev. 1.1, I doubt that such an optimization is a good idea.
> >
> > A clear case where the documentation is wrong.
> 
> 
> The documentation may have been wrong for some time on some archs, it
> feels like making PT_WRITE_D and PT_WRITE_I equivalent was deemed
> useful at one point.  Given that Free and NetBSD document the same
> guarantee, I personally don't feel comfortable changing that, but YMMV.

This is a trap designed to make code work on amd64 and fail on hppa.
But if kettenis cares more about hppa than most people, maybe we should let
him be the one to decide. :)



Re: poll magic for pflogd

2016-05-31 Thread Ted Unangst
Tobias Ulmer wrote:
> On Tue, Sep 22, 2015 at 11:46:08AM -0400, Ted Unangst wrote:
> > Todd C. Miller wrote:
> > > On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote:
> > > 
> > > > We can put a "long" poll() in front of pcap to wait until there are 
> > > > packets
> > > > (maybe never if you aren't using pf logging), and then let the timeout 
> > > > work
> > > > it's magic.
> > > 
> > > This:
> > > 
> > > > +   if (poll(, 1, INFTIM) == 1) {
> > > 
> > > will also match POLLHUP and POLLERR which doesn't appear to be what
> > > you want.  You need to explicitly check for pfd.revents & POLLIN.
> > 
> > poll, you sneaky bastard. I wonder if this program could also benefit from
> > handling signals via kevent, but that's a bigger change.
> > 
> 
> WIP:

Do you have an udpated version of this? I let it drop, but I think we should
try moving ahead.

> 
> Index: pflogd.c
> ===
> RCS file: /home/vcs/cvs/openbsd/src/sbin/pflogd/pflogd.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 pflogd.c
> --- pflogd.c  7 Feb 2015 02:09:13 -   1.51
> +++ pflogd.c  23 Sep 2015 03:47:37 -
> @@ -32,6 +32,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -57,8 +58,6 @@ int Debug = 0;
>  static int snaplen = DEF_SNAPLEN;
>  static int cur_snaplen = DEF_SNAPLEN;
>  
> -volatile sig_atomic_t gotsig_close, gotsig_alrm, gotsig_hup, gotsig_usr1;
> -
>  char *filename = PFLOGD_LOG_FILE;
>  char *interface = PFLOGD_DEFAULT_IF;
>  char *filter = NULL;
> @@ -66,7 +65,6 @@ char *filter = NULL;
>  char errbuf[PCAP_ERRBUF_SIZE];
>  
>  int log_debug = 0;
> -unsigned int delay = FLUSH_DELAY;
>  
>  char *copy_argv(char * const *);
>  void  dump_packet(u_char *, const struct pcap_pkthdr *, const u_char *);
> @@ -81,10 +79,6 @@ int   reset_dump(int);
>  int   scan_dump(FILE *, off_t);
>  int   set_snaplen(int);
>  void  set_suspended(int);
> -void  sig_alrm(int);
> -void  sig_usr1(int);
> -void  sig_close(int);
> -void  sig_hup(int);
>  void  usage(void);
>  
>  static int try_reset_dump(int);
> @@ -95,6 +89,7 @@ static intbuflen = 0;   /* allocated s
>  static char  *buffer = NULL; /* packet buffer */
>  static char  *bufpos = NULL; /* position in buffer */
>  static intbufleft = 0;   /* bytes left in buffer */
> +static intbuftimer = 0; /* periodic buffer flush on/off */
>  
>  /* if error, stop logging but count dropped packets */
>  static int suspended = -1;
> @@ -162,30 +157,6 @@ usage(void)
>  }
>  
>  void
> -sig_close(int sig)
> -{
> - gotsig_close = 1;
> -}
> -
> -void
> -sig_hup(int sig)
> -{
> - gotsig_hup = 1;
> -}
> -
> -void
> -sig_alrm(int sig)
> -{
> - gotsig_alrm = 1;
> -}
> -
> -void
> -sig_usr1(int sig)
> -{
> - gotsig_usr1 = 1;
> -}
> -
> -void
>  set_pcap_filter(void)
>  {
>   struct bpf_program bprog;
> @@ -224,7 +195,7 @@ if_exists(char *ifname)
>  int
>  init_pcap(void)
>  {
> - hpcap = pcap_open_live(interface, snaplen, 1, PCAP_TO_MS, errbuf);
> + hpcap = pcap_open_live(interface, snaplen, 1, 0, errbuf);
>   if (hpcap == NULL) {
>   logmsg(LOG_ERR, "Failed to initialize: %s", errbuf);
>   return (-1);
> @@ -439,6 +410,7 @@ void
>  dump_packet_nobuf(u_char *user, const struct pcap_pkthdr *h, const u_char 
> *sp)
>  {
>   FILE *f = (FILE *)user;
> + fprintf(stderr, "%s called\n", __func__);
>  
>   if (suspended) {
>   packets_dropped++;
> @@ -453,7 +425,7 @@ dump_packet_nobuf(u_char *user, const st
>   ftruncate(fileno(f), pos - sizeof(*h))) {
>   logmsg(LOG_ERR, "Write failed, corrupted logfile!");
>   set_suspended(1);
> - gotsig_close = 1;
> + raise(SIGTERM);
>   return;
>   }
>   goto error;
> @@ -499,6 +471,7 @@ flush_buffer(FILE *f)
>   bufpos = buffer;
>   bufleft = buflen;
>   bufpkt = 0;
> + buftimer = 0;
>  
>   return (0);
>  }
> @@ -512,6 +485,7 @@ purge_buffer(void)
>   bufpos = buffer;
>   bufleft = buflen;
>   bufpkt = 0;
> + buftimer = 0;
>  }
>  
>  /* append packet to the buffer, flushing if necessary */
> @@ -521,6 +495,8 @@ dump_packet(u_char *user, const struct p
>   FILE *f = (FILE *)user;
>   size_t len = sizeof(*h) + h->caplen;
>  
> + fprintf(stderr, "%s called\n", __func__);
> +
>   if (len < sizeof(*h) || h->caplen > (size_t)cur_snaplen) {
>   logmsg(LOG_NOTICE, "invalid size %zu (%d/%d), packet dropped",
>  len, cur_snaplen, snaplen);
> @@ -553,6 +529,7 @@ dump_packet(u_char *user, const struct p
>   bufpos += len;
>   bufleft -= len;
>   bufpkt++;
> + buftimer = 1;
>  
>   return;
>  }
> @@ -575,6 +552,9 @@ main(int argc, char **argv)
>   int ch, np, ret, Xflag = 0;
>   pcap_handler phandler = dump_packet;
>   

Re: ptrace PT_IO write bug

2016-05-31 Thread Jeremie Courreges-Anglas
Mark Kettenis  writes:

>> From: Jeremie Courreges-Anglas 
>> Date: Mon, 30 May 2016 19:30:27 +0200
>> 
>> Mark Kettenis  writes:
>> 
>> > Mathieu - schreef op 2016-05-28 13:05:
>> >> Martin Natano wrote:
>> >>> The diff reads fine to me, however it is incomplete. There are some
>> >>> callers of process_domem() in arch/. They will need to be changed too.
>> >>> req seems to be in sync with uio_rw in all the cases, so just removing
>> >>> the last argument should do it.
>> >>>
>> >>
>> >> Thanks for the feedback. The missing callers where an overlook on my
>> >> part, sorry for that.
>> >>
>> >> Here is a regenerated diff including all the call site. As a side note,
>> >> obviously every one of them was using PT_WRITE_I, that's why it went
>> >> unnoticed.
>> >
>> > The thing you guys are missing is that on some architectures making
>> > changes to instructions (PT_WRITE_I) requires some additional operations
>> > to guarantee that the CPU actually sees those updated instructions.
>> > Typically this is the case on architectures with separate data and
>> > instruction caches, where the instruction cache doesn't snoop the data
>> > cache.  On such architectures (powerpc and arm are examples) you need to
>> > flush the data cache and invalidate the instruction cache.  That may be
>> > a somewhat expensive operation.
>> > As you probably guessed, pmap_proc_iflush() is the function that takes
>> > care of this.  Since you still call pmap_proc_iflush(), the diff isn't
>> > wrong from a correctness point of view, but I think we should keep the
>> > optimization of not calling pmap_proc_iflush() for PT_WRITE_D.
>> 
>> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
>> since rev. 1.1, I doubt that such an optimization is a good idea.
>
> A clear case where the documentation is wrong.

It is wrong since the change that happened in rev. 1.33; before,
procfs_domem() used:

error = uvm_io(>p_vmspace->vm_map, uio,
uio->uio_rw == UIO_WRITE ? UVM_IO_FIXPROT : 0);
uvmspace_free(p->p_vmspace);

if (error == 0 && uio->uio_rw == UIO_WRITE)
pmap_proc_iflush(p, addr, len);

Looks like you are the one who added the pmap_proc_iflush call, btw.

The documentation may have been wrong for some time on some archs, it
feels like making PT_WRITE_D and PT_WRITE_I equivalent was deemed
useful at one point.  Given that Free and NetBSD document the same
guarantee, I personally don't feel comfortable changing that, but YMMV.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



xhci(4) vs BIOS

2016-05-31 Thread Martin Pieuchot
I finally got my hands on a DELL Optiplex 3020.  The BIOS on this
machines uses the xHCI controller to handle the keyboard and mouse.

Turns out that I badly copy/pasted the ehci(4) code to take over the
HC from the BIOS.  With the diff below I can now route all my ports
to xhci(4) and the machine no longer hang at boot.

ok?

Index: xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
retrieving revision 1.7
diff -u -p -r1.7 xhci_pci.c
--- xhci_pci.c  2 Nov 2015 14:53:10 -   1.7
+++ xhci_pci.c  31 May 2016 16:36:14 -
@@ -258,8 +258,9 @@ xhci_pci_takecontroller(struct xhci_pci_
eec = -1;
 
/* Synchronise with the BIOS if it owns the controller. */
-   for (xecp = XHCI_HCC_XECP(cparams) << 2; xecp != 0;
-   xecp = XHCI_XECP_NEXT(eec) << 2) {
+   for (xecp = XHCI_HCC_XECP(cparams) << 2;
+   xecp != 0 && XHCI_XECP_NEXT(eec);
+   xecp += XHCI_XECP_NEXT(eec) << 2) {
eec = XREAD4(>sc, xecp);
if (XHCI_XECP_ID(eec) != XHCI_ID_USB_LEGACY)
continue;



Re: pool related crashes, but "kernel did no panic"

2016-05-31 Thread Theo de Raadt
> is exactly 80 characters long (such a long printf violates "80 chars"
> rule, isn't it?).

there is no hard and fast rule for that at all; printing extra newlines
has other downsides such as the screen scrolling sooner.




eradicate "fat diminisher system" in spamd.conf(5)

2016-05-31 Thread Sevan Janiyan
Hello,
spews.org which is referenced in spamd.conf(5) is dead & now redirects
to a dieting system.
Attached diff swaps the spews reference in the man page to nixspam list
actually found in spamd.conf

Second diff removes the pointer to spamlinks.net which is also dead.


Sevan
Index: etc/mail/spamd.conf
===
RCS file: /cvs/src/etc/mail/spamd.conf,v
retrieving revision 1.7
diff -u -p -u -r1.7 spamd.conf
--- etc/mail/spamd.conf 11 May 2016 06:33:48 -  1.7
+++ etc/mail/spamd.conf 31 May 2016 16:02:37 -
@@ -13,8 +13,6 @@
 # Lists specified with the :white: capability apply to the previous
 # list with a :black: capability.
 #
-# As of November 2004, a place to search for blacklists is
-# http://spamlinks.net/filter-bl.htm
 
 all:\
:nixspam:
Index: share/man/man5/spamd.conf.5
===
RCS file: /cvs/src/share/man/man5/spamd.conf.5,v
retrieving revision 1.15
diff -u -p -r1.15 spamd.conf.5
--- share/man/man5/spamd.conf.5 14 Sep 2015 20:06:59 -  1.15
+++ share/man/man5/spamd.conf.5 31 May 2016 16:06:25 -
@@ -53,14 +53,14 @@ follows the syntax of configuration data
 Here is an example:
 .Bd -literal -offset indent
 all:\e
-   :spews1:override:myblack:
+   :nixspam:override:myblack:
 
-spews1:\e
+nixspam:\e
:black:\e
-   :msg="SPAM. Your address \&%A is in the spews\e
-   level 1 database\ensee http://www.spews.org/ask.cgi?x=\&%A\en":\e
+   :msg="Your address %A is in the nixspam list\n\
+   See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
:method=http:\e
-   :file=www.spews.org/spews_list_level1.txt:
+   :file=www.openbsd.org/spamd/nixspam.gz
 
 override:\e
:white:\e
@@ -90,13 +90,13 @@ The addresses in such a list are removed
 In the above example,
 if an address was present in all three lists,
 blacklists
-.Ar spews1
+.Ar nixspam
 and
 .Ar myblack ,
 as well as the exceptions list
 .Ar override ,
 the address would be removed from list
-.Ar spews1
+.Ar nixspam
 by the subsequent
 .Ar override
 list.
@@ -111,7 +111,7 @@ the following configuration
 would be used instead:
 .Bd -literal -offset indent
 all:\e
-   :spews1:override:myblack:override:
+   :nixspam:override:myblack:override:
 .Ed
 .Pp
 The source of the addresses for lists is


Re: exp.3: remove ancient history and some markup tweaks

2016-05-31 Thread Ingo Schwarze
Hi Theo,

Theo Buehler wrote on Mon, May 30, 2016 at 07:33:04PM +0200:

> Fine. Here's the diff only doing the markup stuff.

No objection here if you think it reads better.  The spacing is a
matter of personal taste.  I'm not aware of any recommendation
whether to insert spacing into in-line mathematical formulae in
mdoc(7) code.

GNU eqn(1) removes the spacing even if you provide it:

  schwarze@isnote $ eqn -Tascii | nroff -mdoc -Tascii -c -p | hexdump -C
  .EQ
  x + 1
  .EN
    5f 08 78 2b 31 0a ...  |_.x+1.|

But that's not a strong argument.
Besides, mandoc(1) currently does not:

  schwarze@isnote $ mandoc | hexdump -C
  .EQ
  x + 1
  .EN
  [...]
  0050  0a 0a 78 20 2b 20 31 0a ...  |..x + 1.|

In mathematical formulae, \(mi is slightly better than \- for minus.

Yours,
  Ingo


> Index: exp.3
> ===
> RCS file: /var/cvs/src/lib/libm/man/exp.3,v
> retrieving revision 1.33
> diff -u -p -r1.33 exp.3
> --- exp.3 26 Apr 2016 19:49:22 -  1.33
> +++ exp.3 30 May 2016 17:30:40 -
> @@ -139,7 +139,7 @@ function is an extended precision versio
>  .Pp
>  The
>  .Fn expm1
> -function computes the value exp(x)\-1 accurately even for tiny argument
> +function computes the value exp(x) \(mi 1 accurately even for tiny argument
>  .Fa x .
>  The
>  .Fn expm1f
> @@ -194,7 +194,7 @@ function is an extended precision versio
>  The
>  .Fn log1p
>  function computes
> -the value of log(1+x) accurately even for tiny argument
> +the value of log(1 + x) accurately even for tiny argument
>  .Fa x .
>  The
>  .Fn log1pf
> @@ -277,12 +277,12 @@ are accurate enough that
>  .Fn pow integer integer
>  is exact until it is bigger than 2**53 for IEEE 754.
>  .Sh NOTES
> -The functions exp(x)\-1 and log(1+x) are called
> +The functions exp(x) \(mi 1 and log(1 + x) are called
>  expm1 and logp1 in BASIC on the Hewlett\-Packard HP-71B
>  and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C
>  on APPLE Macintoshes, where they have been provided to make
> -sure financial calculations of ((1+x)**n\-1)/x, namely
> -expm1(n*log1p(x))/x, will be accurate when x is tiny.
> +sure financial calculations of ((1 + x)**n \(mi 1) / x, namely
> +expm1(n * log1p(x)) / x, will be accurate when x is tiny.
>  They also provide accurate inverse hyperbolic functions.
>  .Pp
>  The function



installboot(8) form armv7

2016-05-31 Thread Mark Kettenis
Since the armv7 installer now creates an msdos filesystem for the
bootloader, here's an updated installboot(8) diff.  Besides FAT32 LBA
partitions (created by the installer), it also recognizes FAT16 LBA
and EFI System partitions.  Not sure whether we actually need to
support FAT16, but we'll probably need EFI System partition support
for machines with real EFI firmware at some point.

ok?


Index: Makefile
===
RCS file: /cvs/src/usr.sbin/installboot/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile11 May 2016 21:52:51 -  1.16
+++ Makefile31 May 2016 14:12:20 -
@@ -26,7 +26,7 @@ SRCS += stubs.c
 .endif
 
 .if ${MACHINE} == "armv7"
-SRCS += stubs.c
+SRCS += armv7_installboot.c
 .endif
 
 .if ${MACHINE} == "hppa"
Index: armv7_installboot.c
===
RCS file: armv7_installboot.c
diff -N armv7_installboot.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ armv7_installboot.c 31 May 2016 14:12:20 -
@@ -0,0 +1,266 @@
+/* $OpenBSD$   */
+/* $NetBSD: installboot.c,v 1.5 1995/11/17 23:23:50 gwr Exp $ */
+
+/*
+ * Copyright (c) 2011 Joel Sing 
+ * Copyright (c) 2010 Otto Moerbeek 
+ * Copyright (c) 2003 Tom Cosgrove 
+ * Copyright (c) 1997 Michael Shalayeff
+ * Copyright (c) 1994 Paul Kranenburg
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *must display the following acknowledgement:
+ *  This product includes software developed by Paul Kranenburg.
+ * 4. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include  /* DEV_BSIZE */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "installboot.h"
+
+static voidwrite_efisystem(struct disklabel *, char);
+static int findmbrlinux(int, struct disklabel *);
+
+void
+md_init(void)
+{
+}
+
+void
+md_loadboot(void)
+{
+}
+
+void
+md_installboot(int devfd, char *dev)
+{
+   struct disklabel dl;
+   int part;
+
+   /* Get and check disklabel. */
+   if (ioctl(devfd, DIOCGDINFO, ) != 0)
+   err(1, "disklabel: %s", dev);
+   if (dl.d_magic != DISKMAGIC)
+   errx(1, "bad disklabel magic=0x%08x", dl.d_magic);
+
+   /* Warn on unknown disklabel types. */
+   if (dl.d_type == 0)
+   warnx("disklabel type unknown");
+
+   part = findmbrlinux(devfd, );
+   if (part != -1) {
+   write_efisystem(, (char)part);
+   return;
+   }
+}
+
+
+static void
+write_efisystem(struct disklabel *dl, char part)
+{
+   static char *fsckfmt = "/sbin/fsck_msdos %s >/dev/null";
+   static char *newfsfmt ="/sbin/newfs_msdos %s >/dev/null";
+   struct ufs_args args;
+   char cmd[60];
+   char dst[PATH_MAX];
+   char *src;
+   size_t mntlen, pathlen, srclen;
+   int rslt;
+
+   src = NULL;
+
+   /* Create directory for temporary mount point. */
+   strlcpy(dst, "/tmp/installboot.XX", sizeof(dst));
+   if (mkdtemp(dst) == NULL)
+   err(1, "mkdtemp('%s') failed", dst);
+   mntlen = strlen(dst);
+
+   /* Mount . as msdos filesystem. */
+   memset(, 0, sizeof(args));
+   rslt = asprintf(,
+   "%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx.%c",
+dl->d_uid[0], dl->d_uid[1], dl->d_uid[2], dl->d_uid[3],
+dl->d_uid[4], 

Re: MBIM Patch - Part 2 of 4

2016-05-31 Thread Gerhard Roth
On Mon, 23 May 2016 17:47:28 +0200 Martin Pieuchot  wrote:
> On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
> > On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot  wrote:
> > > On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > > 
> > > This is crazy :)   No driver should ever modify `ia' directly.  This
> > > code should call in_control() via the ioctl path.
> > 
> > As mentioned in a previous mail: this was mostly copied from
> > if_spppsubr.c:sppp_set_ip_addrs(). But doing an SIOCSIFADDR
> > ioctl() from inside the kernel seems weird, too.
> 
> SIOCAIFADDR/SIOCDIFADDR It is the way to go.  The driver should not
> manipulate addresses or route entry.

Not manipulating the route entries is simple to fix. Will do that.

But using SIOCAIFADDR/SIOCDIFADDR seems rather awkward since in_control()
requires a 'struct socket *so' argument (even though it does nothing with
it, except checking 'so->so_state & SS_PRIV'). Creating a socket inside
the driver for this sole purpose seems just as weird as setting up a
fake struct socket.

Are you really sure, this is the better way to go?



Re: MBIM Patch - Part 2 of 4

2016-05-31 Thread Gerhard Roth
On Mon, 23 May 2016 17:47:28 +0200 Martin Pieuchot  wrote:
> On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
> > On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot  wrote:
> > > On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > > > This is part 2 of the MBIM patch. It adds the mbim driver to i386
> > > > +/*
> > > > + * Some devices are picky about too frequent control messages.
> > > > + * Query device state not more often than every 0.5 secs.
> > > > + */
> > > > +struct timeval mbim_update_rate = { 0, 50 };
> > > > +int mbim_delay = 4000;
> > > > +
> > > > +/*
> > > > + * Normally, MBIM devices are detected by their interface class and 
> > > > subclass.
> > > > + * But for some models that have multiple configurations, it is better 
> > > > to
> > > > + * match by vendor and product id so that we can select the desired
> > > > + * configuration ourselves.
> > > > + *
> > > > + * OTOH, some devices identifiy themself als an MBIM device but fail 
> > > > to speak
> > > > + * the MBIM protocol.
> > > > + */
> > > 
> > > Why is it better?  This is just working around usb_probe_and_attach()
> > > and require developer to add an entry for every device we need to
> > > support.
> > 
> > I just thought that some modules that are already in use say with a
> > umsm config would otherwise change to mbim and break the setup. The idea
> > was to keep existing modules first as they are now and start adding
> > new one to the list.
> 
> Well the rule is first match win.  Since umsm(4) uses a vendor/product
> table as long as you don't add your device to this table it should be
> ok.
> 

Now I remember why I needed to match on VID/PID, too. I have one
MBIM module (Sierra Wireless MC8305) that shows some strange behaviour:

If you read the configuration descriptor #1 and then set
configuration #2, the device resets itself and shortly disapears
from the USB bus.

When matching VID/PID, I can prevent usbd_probe_and_attach() from reading
configuration #1.

Without matching VID/PID, usbd_probe_and_attach() will read configuration #1
to try matching all the interfaces provided by the device. But then I not
able to switch to configuration #2 anymore.

I'm quite sure this is a firmware bug and the only workaround I have
is the match by VID/PID. That still allows to match other MBIM devices
not listed in the table to be matched by Class/SubClass.

Any suggestions?

Gerhard





Re: pool related crashes, but "kernel did no panic"

2016-05-31 Thread Alexey Suslikov
On Mon, May 30, 2016 at 9:02 PM, Ted Unangst  wrote:
> Alexey Suslikov wrote:
>> On Thu, May 12, 2016 at 4:14 PM, Bob Beck  wrote:
>> > Thank you!now that's a bug report..
>>
>> Hi.
>>
>> Moved to 6.0-beta some time ago to make crash dumps more up
>> to date. Also, removed some services to minimize their impact.
>>
>> Fresh build against today's cvs don't survived even half of the day.
>>
>> http://article.gmane.org/gmane.os.openbsd.bugs/23593
>>
>> For me, it looks like: 5.7-5.8 - rare crashes, 5.9-6.0 - more frequent
>> crashes.
>>
>> Backtrace differs from crash to crash, but this remains the same:
>>
>> Stopped at  pool_put+0x1dd: xorq0x8(%rax),%rcx
>>
>> Do you have any idea where should I look in a source code?
>
> sys/kern/subr_pool.c

Thanks for your replies. Especially Stefan who noticed "show pools"
output being truncated for some reason.

Here, kernel output is redirected to com, which is redirected to kvm,
browser with java applet is connected to kvm. This is how I get it.

amappl1: pool(0x81974640:amappl1): page inconsistency: page 0xff01e0

is exactly 80 characters long (such a long printf violates "80 chars"
rule, isn't it?).

Maybe there's a bug in kvm (java applet?) and output gets truncated.

Anyway, let's see, because now I run with the following:

Index: sys/kern/subr_pool.c
===
RCS file: /cvs/src/sys/kern/subr_pool.c,v
retrieving revision 1.194
diff -u -p -u -p -r1.194 subr_pool.c
--- sys/kern/subr_pool.c15 Jan 2016 11:21:58 -1.194
+++ sys/kern/subr_pool.c31 May 2016 09:10:21 -
@@ -1160,7 +1160,8 @@ pool_chk_page(struct pool *pp, struct po
 page = (caddr_t)((u_long)ph & pp->pr_pgmask);
 if (page != ph->ph_page && POOL_INPGHDR(pp)) {
 printf("%s: ", label);
-printf("pool(%p:%s): page inconsistency: page %p; "
+printf("pool(%p:%s):\n"
+"page inconsistency: page %p;\n"
 "at page head addr %p (p %p)\n",
 pp, pp->pr_wchan, ph->ph_page, ph, page);
 return 1;
@@ -1172,9 +1173,10 @@ pool_chk_page(struct pool *pp, struct po
 if ((caddr_t)pi < ph->ph_page ||
 (caddr_t)pi >= ph->ph_page + pp->pr_pgsize) {
 printf("%s: ", label);
-printf("pool(%p:%s): page inconsistency: page %p;"
-" item ordinal %d; addr %p\n", pp,
-pp->pr_wchan, ph->ph_page, n, pi);
+printf("pool(%p:%s):\n"
+"page inconsistency: page %p;\n"
+"item ordinal %d; addr %p\n",
+pp, pp->pr_wchan, ph->ph_page, n, pi);
 return (1);
 }

@@ -1204,16 +1206,18 @@ pool_chk_page(struct pool *pp, struct po
 #endif /* DIAGNOSTIC */
 }
 if (n + ph->ph_nmissing != pp->pr_itemsperpage) {
-printf("pool(%p:%s): page inconsistency: page %p;"
-" %d on list, %d missing, %d items per page\n", pp,
-pp->pr_wchan, ph->ph_page, n, ph->ph_nmissing,
+printf("pool(%p:%s):\n"
+"page inconsistency: page %p;\n"
+"%d on list, %d missing, %d items per page\n",
+pp, pp->pr_wchan, ph->ph_page, n, ph->ph_nmissing,
 pp->pr_itemsperpage);
 return 1;
 }
 if (expected >= 0 && n != expected) {
-printf("pool(%p:%s): page inconsistency: page %p;"
-" %d on list, %d missing, %d expected\n", pp,
-pp->pr_wchan, ph->ph_page, n, ph->ph_nmissing,
+printf("pool(%p:%s):\n"
+"page inconsistency: page %p;\n"
+"%d on list, %d missing, %d expected\n",
+pp, pp->pr_wchan, ph->ph_page, n, ph->ph_nmissing,
 expected);
 return 1;
 }



Re: ugen(4) Asynchronous USB Requests

2016-05-31 Thread Martin Pieuchot
On 30/05/16(Mon) 12:15, Phil Vachon wrote:
> On May 30, 2016 at 9:28:52 AM, Martin Pieuchot wrote:
> > On 26/05/16(Thu) 14:55, Phil Vachon wrote:
> > You should get in touch with Grant Czajkowski, he did something similar
> > during the GSoC 2015, see:
> > 
> > https://www.google-melange.com/gsoc/project/details/google/gsoc2015/coolguy1253/5649050225344512
> > 
> 
> Damn, now I wish I had looked harder before I embarked on all this. I
> will reach out to Grant and see how we could maybe work together to
> get this over the finish line to go into an upcoming release. It's
> very helpful to have! I'm guessing Grant's contact info can be found
> in the mailing list archives, so I'll have a look.

It would be *very* helpful indeed :) 

> > > Currently broken things:
> > > - The entire synchronous interface (poll-related changes)
> > 
> > That's fine as long as libusb is update accordingly. But if it doesn't
> > make sense to keep two set of ioctl(2) then, simply get rid of the old
> > ones ;)
> > 
> 
> Loud and clear. I'll see if we can keep the current interface as
> intact as possible (based on your comment below), but if there are
> 'appendices' that remain, they will be removed.

Well the current interface does not necessarily need to stay.  As long
as the following components are adapted to work with the new ABI,
there's no problem in changing it:

usr.sbin/usbdevs
usr.sbin/usbhidaction
usr.sbin/usbhidctl
lib/libusbhid

and the port devel/libusb1

I'd actually prefer to have, in the end, fewer ioctl(2), which mean
fewer different code paths and a smaller API to maintain.

> > > - Cancelling pending transfers
> > 
> > That's the hard part of the problem. Grant's work includes a working
> > solution, but modifying the HC driver for that should be avoided.
> > 
> 
> This is one thing I'm not 100% understanding -- my plan (though Grant
> has already gone through this) was to expose the pipe's abort()
> method through a similar usbi_* function. I presumed this should be
> callable safely at splusb(), since this is how a pipe goes about
> cleaning itself up? There was a change to uhci(4) that seems to insert
> a USB task for every transfer that is to be cancelled, is this the HC
> driver change you're referring to?

I'm referring to his diff.  The problem with the pipe's abort() function
is that it abort *all* the pending transfers on a given pipe and wait
until this is done.  I'm not sure that's the semantic asked by libusb.

> I am guessing that my presumption that abort() is safely callable at
> splusb() is wrong?

You don't event need to raise the SPL, usbd_abort_pipe() do it for you.

> The other thing that I was trying to avoid in cancellation was having
> complexities around identifying pending operations. Originally I
> hacked something together using the address of the source/target
> userspace buffer for identifying the operation. But the same buffer
> could be reused for multiple transactions so this does not make
> sense. The other idea I had was to provide a transaction 'handle'
> returned by the USB_ASYNC_SUBMIT ioctl(2) that would then be used to
> later reference the operation. Both approaches have lots of downsides,
> but since libusb is already doing bookkeeping on the programmer's
> behalf, the latter approach might not be too onerous.

Since you won't have a high number of in-flight transfer, iterating over
a small list to compare a cookie is perfectly ok performance wise.  So
definitively the second approach.  Once again, see how Grant solved
that.  I'm not saying that's the only or best approach, but there are
some ideas and working code.

> > > - Isochronous transfers
> > 
> > That's not important in the first place.
> > 
> 
> I didn't think so, but I was thinking of providing a kernel-managed
> queue for isochronous transfers. Then userspace would populate the
> queue with transfers to be submitted after the next isochronous
> transfer completes. Something similar could be done for interrupt
> endpoints too, which would allow for the timing 'requirements' to be
> met more readily for such things. 

I'd be happy to see a diff for that, but I believe it's bit too early
considering that there's nothing for control and bulk transfers in-tree.

> > > - Kqueue (maybe? I haven't tested it thoroughly yet)
> > 
> > Not sure if we should keep support it. If libusb's handle_event doesn't
> > need kqueue(2) support after your modifications then it can go.
> > 
> 
> It _could_ be used I suppose, since the libusb user could register to
> receive notification of all new fds, and use kqueue(2) rather than
> poll(2) to receive notification of completed operations. I was
> planning to support it, based on that.

Well you can discus that with libusb people.  They are really friendly
and I guess will be interested to offload a bit of their OpenBSD support
to somebody else ;)



Re: bgpd: filter as path with operators

2016-05-31 Thread Sebastian Benoit
Claudio Jeker(cje...@diehard.n-r-g.com) on 2016.05.31 08:10:22 +0200:
> On Mon, May 30, 2016 at 10:43:49PM +0200, Sebastian Benoit wrote:
> > Hi,
> > 
> > this allows to have
> > 
> >   allow from any AS 64512 - 65534 ...
> >   allow from any AS > 100
> > 
> > etc in bgpd.conf.
> > 
> > Ignore the example file for now, i will commit that seperatly anyway.
> > 
> > One obvious improvment would be to be able to use this in bgpctl to restrict
> > the output of "show rib" a bit more. However, that is for another commit i
> > think, the bgpctl bit in this diff is just to make it compile and work.
> > 
> > ok?
> 
> I see no reason to add the unary operators (>, <, ...). Please provide a
> real live example that makes sense. IMO there is no reason to do something
> like AS >  because the selectivity is random.

Yes, i wanted the - and ><, i put the others in because that allows me to
use them in 'bgpctl sh rib', which i thought might be nice there. I planned
to change bgpctl seperatly though.

Opinons? Its easy enough to remove them again.

> I don't mind the - and >< operators and I think they make sense to use.
> I just don't see the point of added complexity for a case that never
> happens.
> 
> more comments inline
>  
> > /Benno
> > 
> > diff --git etc/examples/bgpd.conf etc/examples/bgpd.conf
> > index 8ffa8a8..02a31f9 100644
> > --- etc/examples/bgpd.conf
> > +++ etc/examples/bgpd.conf
> > @@ -119,3 +119,14 @@ deny from any prefix fc00::/7 prefixlen >= 7   
> > # unique local unicast
> >  deny from any prefix fe80::/10 prefixlen >= 10 # link local 
> > unicast
> >  deny from any prefix fec0::/10 prefixlen >= 10 # old site 
> > local unicast
> >  deny from any prefix ff00::/8 prefixlen >= 8   # multicast
> > +
> > +# filter bogon AS numbers
> > +# http://www.iana.org/assignments/as-numbers/as-numbers.xhtml
> > +deny from any AS 23456 # AS_TRANS
> > +deny from any AS 64496 - 64511 # Reserved for use in 
> > docs and code RFC5398
> > +deny from any AS 64512 - 65534 # Reserved for Private 
> > Use RFC6996
> > +deny from any AS 65535 # Reserved RFC7300
> > +deny from any AS 65536 - 65551 # Reserved for use in 
> > docs and code RFC5398 
> > +deny from any AS 65552 - 131071# Reserved
> > +deny from any AS 42 - 4294967294   # Reserved for Private Use 
> > RFC6996
> > +deny from any AS 4294967295# Reserved RFC7300
> 
> 
> Did you check how many pathes in a regular feed hit any of those rules?

Yes, AS_TRANS is in the wild constantly, the others appear from time, probably
because spammers try things. As they are not legaly to be used on the public
net there should be a way to block them, if only to spare yourself from
public embarrassment.

> I have seen a few pathes with private or AS_TRANS ASs in them in the wild.
> For a default filterset this may be a bit too restrictive.

Thats why i said i would leave that out of the commit for seperate
discussion.

> > diff --git usr.sbin/bgpctl/bgpctl.c usr.sbin/bgpctl/bgpctl.c
> > index 62569bf..afdcf2c 100644
> > --- usr.sbin/bgpctl/bgpctl.c
> > +++ usr.sbin/bgpctl/bgpctl.c
> > @@ -1788,7 +1788,7 @@ show_mrt_dump(struct mrt_rib *mr, struct mrt_peer 
> > *mp, void *arg)
> > /* filter by AS */
> > if (req->as.type != AS_NONE &&
> >!aspath_match(mre->aspath, mre->aspath_len,
> > -  req->as.type, req->as.as))
> > +  >as, req->as.as))
> > continue;
> >  
> > if (req->flags & F_CTL_DETAIL) {
> > @@ -1853,7 +1853,7 @@ network_mrt_dump(struct mrt_rib *mr, struct mrt_peer 
> > *mp, void *arg)
> > /* filter by AS */
> > if (req->as.type != AS_NONE &&
> >!aspath_match(mre->aspath, mre->aspath_len,
> > -  req->as.type, req->as.as))
> > +  >as, req->as.as))
> 
> Would be nice if it is not required to pass both the as obj and the
> req->as.as but them matching on neighbor-as needs some work...
> Anyway this is a bikeshed problem.

It is needed in the neighbor-as case. I thought leaving it as it is makes it
obvious that there is a special case.

I will resend the diff when i know if i should throw out =,>=,> etc...

> > continue;
> >  
> > bzero(, sizeof(net));
> > diff --git usr.sbin/bgpd/bgpd.conf.5 usr.sbin/bgpd/bgpd.conf.5
> > index 84a01ed..0017124 100644
> > --- usr.sbin/bgpd/bgpd.conf.5
> > +++ usr.sbin/bgpd/bgpd.conf.5
> > @@ -1027,7 +1027,10 @@ If a parameter is specified, the rule only applies 
> > to packets with
> >  matching attributes.
> >  .Pp
> >  .Bl -tag -width Ds -compact
> > -.It Ar as-type as-number
> > +.It Xo
> > +.Ar as-type Op Ar operator
> > +.Ar as-number
> > +.Xc
> >  This rule applies only to
> >  .Em UPDATES
> >  where the
> > @@ -1038,13 +1041,7 @@ The
> 

Re: ifa_ifwithroute() fix

2016-05-31 Thread Martin Pieuchot
On 19/04/16(Tue) 10:43, Martin Pieuchot wrote:
> Mart Tõnso reported [0] a weird case related to the use of ifa_ifwithnet().
> 
> The problem is that ifa_ifwithroute() does not always use route entries but
> the poor's man routing table: ifa_ifwithnet().  This is misleading because
> one cannot understand why "# route add" is not coherent with "# route get".
> 
> So I'd like to commit the diff below which always use the route table
> unless an interface index is specified in the gateway.  Mart Tõnso
> confirmed it fixes his issue.
> 
> ok?

Anyone?

> 
> [0] https://marc.info/?l=openbsd-misc=146046751201006=2
> 
> 
> Index: net/route.c
> ===
> RCS file: /cvs/src/sys/net/route.c,v
> retrieving revision 1.298
> diff -u -p -r1.298 route.c
> --- net/route.c   26 Mar 2016 21:56:04 -  1.298
> +++ net/route.c   13 Apr 2016 07:38:11 -
> @@ -740,20 +740,16 @@ ifa_ifwithroute(int flags, struct sockad
>   ifa = ifaof_ifpforaddr(dst, ifp);
>   if_put(ifp);
>   } else {
> - ifa = ifa_ifwithnet(gateway, rtableid);
> - }
> - }
> - if (ifa == NULL) {
> - struct rtentry  *rt = rtalloc(gateway, 0, rtableid);
> - /* The gateway must be local if the same address family. */
> - if (!rtisvalid(rt) || ((rt->rt_flags & RTF_GATEWAY) &&
> - rt_key(rt)->sa_family == dst->sa_family)) {
> + struct rtentry *rt;
> +
> + rt = rtalloc(gateway, RT_RESOLVE, rtableid);
> + if (rt != NULL)
> + ifa = rt->rt_ifa;
>   rtfree(rt);
> - return (NULL);
>   }
> - ifa = rt->rt_ifa;
> - rtfree(rt);
>   }
> + if (ifa == NULL)
> + return (NULL);
>   if (ifa->ifa_addr->sa_family != dst->sa_family) {
>   struct ifaddr   *oifa = ifa;
>   ifa = ifaof_ifpforaddr(dst, ifa->ifa_ifp);
> 



Re: bgpd: filter as path with operators

2016-05-31 Thread Peter Hessler
On 2016 May 31 (Tue) at 08:10:22 +0200 (+0200), Claudio Jeker wrote:
:On Mon, May 30, 2016 at 10:43:49PM +0200, Sebastian Benoit wrote:
:> /Benno
:> 
:> diff --git etc/examples/bgpd.conf etc/examples/bgpd.conf
:> index 8ffa8a8..02a31f9 100644
:> --- etc/examples/bgpd.conf
:> +++ etc/examples/bgpd.conf
:> @@ -119,3 +119,14 @@ deny from any prefix fc00::/7 prefixlen >= 7
# unique local unicast
:>  deny from any prefix fe80::/10 prefixlen >= 10  # link local 
unicast
:>  deny from any prefix fec0::/10 prefixlen >= 10  # old site 
local unicast
:>  deny from any prefix ff00::/8 prefixlen >= 8# multicast
:> +
:> +# filter bogon AS numbers
:> +# http://www.iana.org/assignments/as-numbers/as-numbers.xhtml
:> +deny from any AS 23456  # AS_TRANS
:> +deny from any AS 64496 - 64511  # Reserved for use in 
docs and code RFC5398
:> +deny from any AS 64512 - 65534  # Reserved for Private 
Use RFC6996
:> +deny from any AS 65535  # Reserved RFC7300
:> +deny from any AS 65536 - 65551  # Reserved for use in 
docs and code RFC5398 
:> +deny from any AS 65552 - 131071 # Reserved
:> +deny from any AS 42 - 4294967294# Reserved for Private Use 
RFC6996
:> +deny from any AS 4294967295 # Reserved RFC7300
:
:
:Did you check how many pathes in a regular feed hit any of those rules?
:I have seen a few pathes with private or AS_TRANS ASs in them in the wild.
:For a default filterset this may be a bit too restrictive.
:

This feature came about because of a talk from Job at NTT during RIPE72,
where they will be introducing exactly this ruleset on all of their
links starting in July.


-- 
This life is a test.  It is only a test.  Had this been an actual life,
you would have received further instructions as to what to do and where
to go.



syslog.conf: *.emerg comment is confusing

2016-05-31 Thread Juuso Lapinlampi
Previous syslog.conf revision 1.19 changed *.emerg to be disabled by
default, but forgot to change the comment to tell to uncomment the line
to enable *.emerg.

Attached patch should fix the comment and reduce confusion.
Index: src/etc/syslog.conf
===
RCS file: /cvs/src/etc/syslog.conf,v
retrieving revision 1.19
diff -u -r1.19 syslog.conf
--- src/etc/syslog.conf 26 Nov 2015 15:25:14 -  1.19
+++ src/etc/syslog.conf 31 May 2016 06:57:08 -
@@ -20,7 +20,7 @@
 # as well as all authentication messages sent to root.
 #*.notice;auth.debug   root
 
-# Everyone gets emergency messages.
+# Uncomment to have everyone get emergency messages.
 #*.emerg   *
 
 # Uncomment to log to a central host named "loghost".  You need to run


Re: bgpd: filter as path with operators

2016-05-31 Thread Claudio Jeker
On Mon, May 30, 2016 at 10:43:49PM +0200, Sebastian Benoit wrote:
> Hi,
> 
> this allows to have
> 
>   allow from any AS 64512 - 65534 ...
>   allow from any AS > 100
> 
> etc in bgpd.conf.
> 
> Ignore the example file for now, i will commit that seperatly anyway.
> 
> One obvious improvment would be to be able to use this in bgpctl to restrict
> the output of "show rib" a bit more. However, that is for another commit i
> think, the bgpctl bit in this diff is just to make it compile and work.
> 
> ok?

I see no reason to add the unary operators (>, <, ...). Please provide a
real live example that makes sense. IMO there is no reason to do something
like AS >  because the selectivity is random.
I don't mind the - and >< operators and I think they make sense to use.
I just don't see the point of added complexity for a case that never
happens.

more comments inline
 
> /Benno
> 
> diff --git etc/examples/bgpd.conf etc/examples/bgpd.conf
> index 8ffa8a8..02a31f9 100644
> --- etc/examples/bgpd.conf
> +++ etc/examples/bgpd.conf
> @@ -119,3 +119,14 @@ deny from any prefix fc00::/7 prefixlen >= 7 
> # unique local unicast
>  deny from any prefix fe80::/10 prefixlen >= 10   # link local 
> unicast
>  deny from any prefix fec0::/10 prefixlen >= 10   # old site 
> local unicast
>  deny from any prefix ff00::/8 prefixlen >= 8 # multicast
> +
> +# filter bogon AS numbers
> +# http://www.iana.org/assignments/as-numbers/as-numbers.xhtml
> +deny from any AS 23456   # AS_TRANS
> +deny from any AS 64496 - 64511   # Reserved for use in 
> docs and code RFC5398
> +deny from any AS 64512 - 65534   # Reserved for Private 
> Use RFC6996
> +deny from any AS 65535   # Reserved RFC7300
> +deny from any AS 65536 - 65551   # Reserved for use in 
> docs and code RFC5398 
> +deny from any AS 65552 - 131071  # Reserved
> +deny from any AS 42 - 4294967294 # Reserved for Private Use 
> RFC6996
> +deny from any AS 4294967295  # Reserved RFC7300


Did you check how many pathes in a regular feed hit any of those rules?
I have seen a few pathes with private or AS_TRANS ASs in them in the wild.
For a default filterset this may be a bit too restrictive.

> diff --git usr.sbin/bgpctl/bgpctl.c usr.sbin/bgpctl/bgpctl.c
> index 62569bf..afdcf2c 100644
> --- usr.sbin/bgpctl/bgpctl.c
> +++ usr.sbin/bgpctl/bgpctl.c
> @@ -1788,7 +1788,7 @@ show_mrt_dump(struct mrt_rib *mr, struct mrt_peer *mp, 
> void *arg)
>   /* filter by AS */
>   if (req->as.type != AS_NONE &&
>  !aspath_match(mre->aspath, mre->aspath_len,
> -req->as.type, req->as.as))
> +>as, req->as.as))
>   continue;
>  
>   if (req->flags & F_CTL_DETAIL) {
> @@ -1853,7 +1853,7 @@ network_mrt_dump(struct mrt_rib *mr, struct mrt_peer 
> *mp, void *arg)
>   /* filter by AS */
>   if (req->as.type != AS_NONE &&
>  !aspath_match(mre->aspath, mre->aspath_len,
> -req->as.type, req->as.as))
> +>as, req->as.as))

Would be nice if it is not required to pass both the as obj and the
req->as.as but them matching on neighbor-as needs some work...
Anyway this is a bikeshed problem.

>   continue;
>  
>   bzero(, sizeof(net));
> diff --git usr.sbin/bgpd/bgpd.conf.5 usr.sbin/bgpd/bgpd.conf.5
> index 84a01ed..0017124 100644
> --- usr.sbin/bgpd/bgpd.conf.5
> +++ usr.sbin/bgpd/bgpd.conf.5
> @@ -1027,7 +1027,10 @@ If a parameter is specified, the rule only applies to 
> packets with
>  matching attributes.
>  .Pp
>  .Bl -tag -width Ds -compact
> -.It Ar as-type as-number
> +.It Xo
> +.Ar as-type Op Ar operator
> +.Ar as-number
> +.Xc
>  This rule applies only to
>  .Em UPDATES
>  where the
> @@ -1038,13 +1041,7 @@ The
>  is matched against a part of the
>  .Em AS path
>  specified by the
> -.Ar as-type .
> -.Ar as-number
> -may be set to
> -.Ic neighbor-as ,
> -which is expanded to the current neighbor remote AS number.
> -.Ar as-type
> -is one of the following operators:
> +.Ar as-type :
>  .Pp
>  .Bl -tag -width transmit-as -compact
>  .It Ic AS
> @@ -1057,6 +1054,33 @@ is one of the following operators:
>  (all but the rightmost AS number)
>  .El
>  .Pp
> +.Ar as-number
> +is an AS number as explained above under
> +.Sx GLOBAL CONFIGURATION .
> +It may be set to
> +.Ic neighbor-as ,
> +which is expanded to the current neighbor remote AS number.
> +.Pp
> +The
> +.Ar operator
> +can be unspecified (this case is identical to the equality operator), or one 
> of the numerical operators
> +.Bd -literal -offset indent
> +=(equal)
> +!=   (unequal)
> +<(less than)
> +<=   (less than or equal)
> +>(greater than)
> +>=   (greater than or equal)
> +-(range including boundaries)
> +><   (except