Re: add m_defrag to pcn driver

2015-04-01 Thread Kimberley Manning 
Martin Pieuchot mpi at openbsd.org writes:

 On 31/03/15(Tue) 21:56, Kimberley Manning wrote:
  Hi,
  
  This diff makes the pcn driver use m_defrag for fragmented mbuf chains,
 
 I like this kind of cleanups.  As for vio(4) could you try the diff or
 are you looking for testers?

Thanks. I've tried both the vio and pcn diffs and they worked for me, so dlg
told me to write here. I'm not sure what happens to diffs after this point
to be honest.

 Are you after something specific or are you changing the drivers for
 coherency reason?

Just coherency.

kernel with gif(4)

2015-04-01 Thread Martin Pieuchot 
I'd like to be able to easily identify how deep are the tentacles of a
pseudo-driver in your network stack.  This diff takes the example of
gif(4) and move all the remaining blocks checking for IFT_GIF under
the appropriate #ifdef dance.

The #ifdef I'm adding below are not strictly needed to compile a kernel
without gif(4) but they act as markers to limit code chunks that do not
need to be executed without the corresponding interface.

Ok?

Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.232
diff -u -p -r1.232 if_bridge.c
--- net/if_bridge.c 6 Feb 2015 22:10:43 -   1.232
+++ net/if_bridge.c 1 Apr 2015 12:00:11 -
@@ -1377,6 +1377,7 @@ bridge_input(struct ifnet *ifp, struct e
IF_ENQUEUE(sc-sc_if.if_snd, mc);
splx(s);
schednetisr(NETISR_BRIDGE);
+#if NGIF  0
if (ifp-if_type == IFT_GIF) {
TAILQ_FOREACH(ifl, sc-sc_iflist, next) {
if (ifl-ifp-if_type == IFT_ETHER)
@@ -1396,6 +1397,7 @@ bridge_input(struct ifnet *ifp, struct e
m = NULL;
}
}
+#endif /* NGIF */
return (m);
}
 
@@ -1446,11 +1448,13 @@ bridge_input(struct ifnet *ifp, struct e
 
m-m_pkthdr.rcvif = ifl-ifp;
m-m_pkthdr.ph_rtableid = ifl-ifp-if_rdomain;
+#if NGIF  0
if (ifp-if_type == IFT_GIF) {
m-m_flags |= M_PROTO1;
ether_input(ifl-ifp, eh, m);
m = NULL;
}
+#endif /* NGIF */
return (m);
}
if (bcmp(ac-ac_enaddr, eh-ether_shost, ETHER_ADDR_LEN) == 0
Index: netinet6/in6_ifattach.c
===
RCS file: /cvs/src/sys/netinet6/in6_ifattach.c,v
retrieving revision 1.86
diff -u -p -r1.86 in6_ifattach.c
--- netinet6/in6_ifattach.c 14 Mar 2015 03:38:52 -  1.86
+++ netinet6/in6_ifattach.c 1 Apr 2015 11:58:55 -
@@ -30,6 +30,8 @@
  * SUCH DAMAGE.
  */
 
+#include gif.h
+
 #include sys/param.h
 #include sys/systm.h
 #include sys/socket.h
@@ -198,6 +200,7 @@ get_hw_ifid(struct ifnet *ifp, struct in
}
break;
 
+#if NGIF  0
case IFT_GIF:
/*
 * RFC2893 says: SHOULD use IPv4 address as ifid source.
@@ -206,6 +209,7 @@ get_hw_ifid(struct ifnet *ifp, struct in
 * we don't do this.
 */
return -1;
+#endif /* NGIF */
 
default:
return -1;
Index: netinet6/nd6.c
===
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.133
diff -u -p -r1.133 nd6.c
--- netinet6/nd6.c  25 Mar 2015 17:39:33 -  1.133
+++ netinet6/nd6.c  1 Apr 2015 12:02:14 -
@@ -30,6 +30,8 @@
  * SUCH DAMAGE.
  */
 
+#include gif.h
+
 #include sys/param.h
 #include sys/systm.h
 #include sys/timeout.h
@@ -1817,7 +1819,10 @@ nd6_need_cache(struct ifnet *ifp)
case IFT_PROPVIRTUAL:
case IFT_IEEE80211:
case IFT_CARP:
-   case IFT_GIF:   /* XXX need more cases? */
+#if NGIF  0
+   case IFT_GIF:
+#endif /* NGIF */
+   /* XXX need more cases? */
return (1);
default:
return (0);

Re: Use LIST for upd(4) sensors

2015-04-01 Thread Martin Pieuchot 
On 31/03/15(Tue) 23:06, David Higgs wrote:
 This was much more straightforward than expected.
 
 - Replace an array with a LIST of allocated sensors.
 - Remove or rescope variables counting sensors.
 - Allocated sensors are always attached.
 - Drop an unnecessary size calculation.

Do you need this for an upcoming change?  I fail to see the benefit to
have a malloc(9) call per item, afaik theses items are really small and
you have at most 10 of them...

 Thanks.
 
 --david
 
 --- a/upd.c
 +++ b/upd.c
 @@ -23,6 +23,7 @@
  #include sys/kernel.h
  #include sys/malloc.h
  #include sys/device.h
 +#include sys/queue.h
  #include sys/sensors.h
  
  #include dev/usb/hid.h
 @@ -77,20 +78,18 @@ struct upd_report {
  struct upd_sensor {
   struct ksensor  ksensor;
   struct hid_item hitem;
 - int attached;
 + LIST_ENTRY(upd_sensor)  next;
  };
  
  struct upd_softc {
   struct uhidevsc_hdev;
 - int  sc_num_sensors;
   u_intsc_max_repid;
 - u_intsc_max_sensors;
  
   /* sensor framework */
   struct ksensordevsc_sensordev;
   struct sensor_task  *sc_sensortask;
   struct upd_report   *sc_reports;
 - struct upd_sensor   *sc_sensors;
 + LIST_HEAD(, upd_sensor)  sc_sensors;
  };
  
  int  upd_match(struct device *, void *, void *);
 @@ -155,14 +154,14 @@ upd_attach(struct device *parent, struct
   struct hid_data  *hdata;
   struct upd_usage_entry   *entry;
   struct upd_sensor*sensor;
 + int   num_sensors;
   int   size;
   void *desc;
  
   sc-sc_hdev.sc_intr = upd_intr;
   sc-sc_hdev.sc_parent = uha-parent;
   sc-sc_reports = NULL;
 - sc-sc_sensors = NULL;
 - sc-sc_max_sensors = nitems(upd_usage_table);
 + LIST_INIT(sc-sc_sensors);
  
   strlcpy(sc-sc_sensordev.xname, sc-sc_hdev.sc_dev.dv_xname,
   sizeof(sc-sc_sensordev.xname));
 @@ -173,14 +172,11 @@ upd_attach(struct device *parent, struct
  
   sc-sc_reports = mallocarray(sc-sc_max_repid,
   sizeof(struct upd_report), M_USBDEV, M_WAITOK | M_ZERO);
 - sc-sc_sensors = mallocarray(sc-sc_max_sensors,
 - sizeof(struct upd_sensor), M_USBDEV, M_WAITOK | M_ZERO);
 - size = sc-sc_max_sensors * sizeof(struct upd_sensor);
 - sc-sc_num_sensors = 0;
 + num_sensors = 0;
   uhidev_get_report_desc(uha-parent, desc, size);
   for (hdata = hid_start_parse(desc, size, hid_feature);
hid_get_item(hdata, item) 
 -  sc-sc_num_sensors  sc-sc_max_sensors; ) {
 +  num_sensors  nitems(upd_usage_table); ) {
   DPRINTF((upd: repid=%d\n, item.report_ID));
   if (item.kind != hid_feature ||
   item.report_ID  0 ||
 @@ -196,7 +192,8 @@ upd_attach(struct device *parent, struct
   if (sensor != NULL)
   continue;
  
 - sensor = sc-sc_sensors[sc-sc_num_sensors];
 + sensor = malloc(sizeof(struct upd_sensor), M_USBDEV,
 + M_WAITOK | M_ZERO);
   memcpy(sensor-hitem, item, sizeof(struct hid_item));
   strlcpy(sensor-ksensor.desc, entry-usage_name,
   sizeof(sensor-ksensor.desc));
 @@ -205,8 +202,8 @@ upd_attach(struct device *parent, struct
   sensor-ksensor.status = SENSOR_S_UNKNOWN;
   sensor-ksensor.value = 0;
   sensor_attach(sc-sc_sensordev, sensor-ksensor);
 - sensor-attached = 1;
 - sc-sc_num_sensors++;
 + LIST_INSERT_HEAD(sc-sc_sensors, sensor, next);
 + num_sensors++;
  
   if (sc-sc_reports[item.report_ID].enabled)
   continue;
 @@ -216,7 +213,7 @@ upd_attach(struct device *parent, struct
   sc-sc_reports[item.report_ID].enabled = 1;
   }
   hid_end_parse(hdata);
 - DPRINTF((upd: sc_num_sensors=%d\n, sc-sc_num_sensors));
 + DPRINTF((upd: num_sensors=%d\n, num_sensors));
  
   sc-sc_sensortask = sensor_task_register(sc, upd_refresh, 6);
   if (sc-sc_sensortask == NULL) {
 @@ -235,7 +232,7 @@ upd_detach(struct device *self, int flag
  {
   struct upd_softc*sc = (struct upd_softc *)self;
   struct upd_sensor   *sensor;
 - int  i;
 + struct upd_sensor   *t;
  
   if (sc-sc_sensortask != NULL) {
   wakeup(sc-sc_sensortask);
 @@ -244,15 +241,14 @@ upd_detach(struct device *self, int flag
  
   sensordev_deinstall(sc-sc_sensordev);
  
 - for (i = 0; i  sc-sc_num_sensors; i++) {
 - sensor = sc-sc_sensors[i];
 - if (sensor-attached)
 - sensor_detach(sc-sc_sensordev, sensor-ksensor);
 + LIST_FOREACH_SAFE(sensor, sc-sc_sensors, next, t) {
 + sensor_detach(sc-sc_sensordev,

Re: add m_defrag to pcn driver

2015-04-01 Thread Martin Pieuchot 
On 31/03/15(Tue) 21:56, Kimberley Manning wrote:
 Hi,
 
 This diff makes the pcn driver use m_defrag for fragmented mbuf chains,

I like this kind of cleanups.  As for vio(4) could you try the diff or
are you looking for testers?

Are you after something specific or are you changing the drivers for
coherency reason?


 
 cheers,
 Kim
 
 Index: if_pcn.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_pcn.c,v
 retrieving revision 1.36
 diff -u -p -r1.36 if_pcn.c
 --- if_pcn.c  14 Mar 2015 03:38:48 -  1.36
 +++ if_pcn.c  27 Mar 2015 12:17:24 -
 @@ -851,25 +851,23 @@ pcn_start(struct ifnet *ifp)
* were short on resources.  In this case, we'll copy
* and try again.
*/
 - if (bus_dmamap_load_mbuf(sc-sc_dmat, dmamap, m0,
 - BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) {
 - MGETHDR(m, M_DONTWAIT, MT_DATA);
 - if (m == NULL)
 - break;
 - if (m0-m_pkthdr.len  MHLEN) {
 - MCLGET(m, M_DONTWAIT);
 - if ((m-m_flags  M_EXT) == 0) {
 - m_freem(m);
 - break;
 - }
 - }
 - m_copydata(m0, 0, m0-m_pkthdr.len, mtod(m, caddr_t));
 - m-m_pkthdr.len = m-m_len = m0-m_pkthdr.len;
 - error = bus_dmamap_load_mbuf(sc-sc_dmat, dmamap,
 - m, BUS_DMA_WRITE|BUS_DMA_NOWAIT);
 - if (error)
 - break;
 - }
 +error = bus_dmamap_load_mbuf(sc-sc_dmat, dmamap, m0,
 +BUS_DMA_WRITE|BUS_DMA_NOWAIT);
 +switch (error) {
 +case 0:
 +break; 
 +case EFBIG:
 +if ((error = m_defrag(m0, M_DONTWAIT)) == 0 
 +(error = bus_dmamap_load_mbuf(sc-sc_dmat, 
 dmamap,
 + m0, BUS_DMA_WRITE|BUS_DMA_NOWAIT)) == 0)
 +break;
 +
 +/* FALLTHROUGH */
 +default:
 + IFQ_DEQUEUE(ifp-if_snd, m0);
 + m_freem(m);
 + continue;
 +}
  
   /*
* Ensure we have enough descriptors free to describe

Re: Use LIST for upd(4) sensors

2015-04-01 Thread David Higgs 
On Wed, Apr 1, 2015 at 7:52 AM, Martin Pieuchot m...@openbsd.org wrote:

 On 31/03/15(Tue) 23:06, David Higgs wrote:
  This was much more straightforward than expected.
 
  - Replace an array with a LIST of allocated sensors.
  - Remove or rescope variables counting sensors.
  - Allocated sensors are always attached.
  - Drop an unnecessary size calculation.

 Do you need this for an upcoming change?  I fail to see the benefit to
 have a malloc(9) call per item, afaik theses items are really small and
 you have at most 10 of them...

 No, I just extrapolated too much from your suggestion to put attached
sensors on a LIST.  I'll adjust and resubmit.

Thanks.

--david

if_input() and `rcvif`

2015-04-01 Thread Martin Pieuchot 
When if_input_process() will pass a mbuf to pseudo-interface handlers,
they will change the `rcvif` pointer in the packet header.  That's why
we should not pass a ifp pointer to the handlers and instead let them
look at the value of `rcvif`.

Diff below change if_input() and ether_input() to no longer take an
ifp as argument.

Ok?

Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.325
diff -u -p -r1.325 if.c
--- net/if.c1 Apr 2015 04:00:55 -   1.325
+++ net/if.c1 Apr 2015 14:09:39 -
@@ -496,7 +496,7 @@ if_input_process(void *xmq)
 
ifp = m-m_pkthdr.rcvif;
SLIST_FOREACH(ifih, ifp-if_inputs, ifih_next) {
-   if ((*ifih-ifih_input)(ifp, NULL, m))
+   if ((*ifih-ifih_input)(m, NULL))
break;
}
}
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.232
diff -u -p -r1.232 if_bridge.c
--- net/if_bridge.c 6 Feb 2015 22:10:43 -   1.232
+++ net/if_bridge.c 1 Apr 2015 14:11:00 -
@@ -1391,7 +1391,7 @@ bridge_input(struct ifnet *ifp, struct e
BPF_DIRECTION_IN);
 #endif
m-m_flags |= M_PROTO1;
-   ether_input(ifl-ifp, eh, m);
+   ether_input(m, eh);
ifl-ifp-if_ipackets++;
m = NULL;
}
@@ -1448,7 +1448,7 @@ bridge_input(struct ifnet *ifp, struct e
m-m_pkthdr.ph_rtableid = ifl-ifp-if_rdomain;
if (ifp-if_type == IFT_GIF) {
m-m_flags |= M_PROTO1;
-   ether_input(ifl-ifp, eh, m);
+   ether_input(m, eh);
m = NULL;
}
return (m);
@@ -1624,7 +1624,7 @@ bridge_localbroadcast(struct bridge_soft
BPF_DIRECTION_IN);
 #endif
 
-   ether_input(ifp, NULL, m1);
+   ether_input(m1, NULL);
ifp-if_ipackets++;
 }
 
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.190
diff -u -p -r1.190 if_ethersubr.c
--- net/if_ethersubr.c  17 Mar 2015 14:51:27 -  1.190
+++ net/if_ethersubr.c  1 Apr 2015 14:11:13 -
@@ -454,15 +454,15 @@ bad:
  * the ether header, which is provided separately.
  */
 int
-ether_input(struct ifnet *ifp0, void *hdr, struct mbuf *m)
+ether_input(struct mbuf *m, void *hdr)
 {
+   struct ifnet *ifp0, *ifp;
struct ether_header *eh = hdr;
struct ifqueue *inq;
u_int16_t etype;
int s, llcfound = 0;
struct llc *l;
struct arpcom *ac;
-   struct ifnet *ifp = ifp0;
 #if NTRUNK  0
int i = 0;
 #endif
@@ -470,7 +470,9 @@ ether_input(struct ifnet *ifp0, void *hd
struct ether_header *eh_tmp;
 #endif
 
+
/* mark incoming routing table */
+   ifp = ifp0 = m-m_pkthdr.rcvif;
m-m_pkthdr.ph_rtableid = ifp-if_rdomain;
 
if (eh == NULL) {
Index: net/if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.113
diff -u -p -r1.113 if_vlan.c
--- net/if_vlan.c   31 Mar 2015 11:47:09 -  1.113
+++ net/if_vlan.c   1 Apr 2015 14:05:23 -
@@ -352,7 +352,7 @@ vlan_input(struct ether_header *eh, stru
}
 
ifv-ifv_if.if_ipackets++;
-   ether_input(ifv-ifv_if, eh, m);
+   ether_input(m, eh);
 
return (0);
 }
Index: net/if_vxlan.c
===
RCS file: /cvs/src/sys/net/if_vxlan.c,v
retrieving revision 1.22
diff -u -p -r1.22 if_vxlan.c
--- net/if_vxlan.c  14 Mar 2015 03:38:51 -  1.22
+++ net/if_vxlan.c  1 Apr 2015 14:05:36 -
@@ -537,7 +537,7 @@ vxlan_lookup(struct mbuf *m, struct udph
 #endif
 
ifp-if_ipackets++;
-   ether_input(ifp, eh, m);
+   ether_input(m, eh);
 
/* success */
return (1);
Index: net/if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1.23
diff -u -p -r1.23 if_var.h
--- net/if_var.h1 Apr 2015 04:00:55 -   1.23
+++ net/if_var.h1 Apr 2015 14:09:30 -
@@ -114,7 +114,7 @@ struct  ifqueue {
  */
 struct ifih {
SLIST_ENTRY(ifih) ifih_next;
-   int (*ifih_input)(struct ifnet *, void *, struct mbuf *);
+   int (*ifih_input)(struct mbuf *, void *);
 };
 
 /*
@@ -422,7 +422,7 @@ voidether_input_mbuf(struct ifnet *, st
 void

Re: add support for crc_enabled Elantech v3 touchpads

2015-04-01 Thread Stefan Sperling 
On Wed, Apr 01, 2015 at 05:44:16PM +0200, Fasse wrote:
 This diff adds support for Elantech v3 touchpads using the crc_enabled
 integrity check. I tested this patch with my Elantech v3 touchpad using
 firmware version 0x454f00, it now works correctly. 
 Other hardware versions should not be affected by this change. I could
 not check if this introduces regression with other firmware versions.
 If you have an elantech touchpad, particularly v3, could you please try
 this diff and see if it causes any issues.

Interesting, thanks.

If you don't hear from anyone else about this please ask me again in
a week from now. I can test on v3 hardware by then but not any earlier.

Please write this as if-else instead of switch:

 @@ -2271,11 +2284,18 @@ pms_proc_elantech_v3(struct pms_softc *s
* and a tail packet. We report a single event and ignore
* the tail packet.
*/
 - if ((sc-packet[0]  0x0c) != 0x04 
 - (sc-packet[3]  0xcf) != 0x02) {
 - /* not the head packet -- ignore */
 - return;
 + switch (elantech-flags  ELANTECH_F_CRC_ENABLED) {
 + case 0:
 + if ((sc-packet[0]  0x0c) != 0x04 
 + (sc-packet[3]  0xcf) != 0x02) {
 + /* not the head packet -- ignore */
 + return;
 + }
 + case ELANTECH_F_CRC_ENABLED:
 + if ((sc-packet[3]  0x09) != 0x08)
 + return;
   }

add support for crc_enabled Elantech v3 touchpads

2015-04-01 Thread Fasse 
This diff adds support for Elantech v3 touchpads using the crc_enabled
integrity check. I tested this patch with my Elantech v3 touchpad using
firmware version 0x454f00, it now works correctly. 
Other hardware versions should not be affected by this change. I could
not check if this introduces regression with other firmware versions.
If you have an elantech touchpad, particularly v3, could you please try
this diff and see if it causes any issues.

Index: sys/dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.58
diff -u -p -r1.58 pms.c
--- sys/dev/pckbc/pms.c 26 Mar 2015 01:30:22 -  1.58
+++ sys/dev/pckbc/pms.c 1 Apr 2015 14:22:10 -
@@ -137,6 +137,7 @@ struct elantech_softc {
 #define ELANTECH_F_HAS_ROCKER  0x02
 #define ELANTECH_F_2FINGER_PACKET  0x04
 #define ELANTECH_F_HW_V1_OLD   0x08
+#define ELANTECH_F_CRC_ENABLED 0x10
int fw_version;
 
int min_x, min_y;
@@ -1812,6 +1813,9 @@ elantech_get_hwinfo_v3(struct pms_softc 
elantech-fw_version = fw_version;
elantech-flags |= ELANTECH_F_REPORTS_PRESSURE;
 
+   if ((fw_version  0x4000) == 0x4000)
+   elantech-flags |= ELANTECH_F_CRC_ENABLED;
+
if (elantech_set_absolute_mode_v3(sc))
return (-1);
 
@@ -2164,14 +2168,23 @@ pms_sync_elantech_v2(struct pms_softc *s
 int
 pms_sync_elantech_v3(struct pms_softc *sc, int data)
 {
+   struct elantech_softc *elantech = sc-elantech;
+
switch (sc-inputstate) {
case 0:
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED)
+   break;
if ((data  0x0c) != 0x04  (data  0x0c) != 0x0c)
return (-1);
break;
case 3:
-   if ((data  0xcf) != 0x02  (data  0xce) != 0x0c)
-   return (-1);
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED) {
+   if ((data  0x09) != 0x08  (data  0x09) != 0x09)
+   return (-1);
+   } else {
+   if ((data  0xcf) != 0x02  (data  0xce) != 0x0c)
+   return (-1);
+   }
break;
}
 
@@ -2271,11 +2284,18 @@ pms_proc_elantech_v3(struct pms_softc *s
 * and a tail packet. We report a single event and ignore
 * the tail packet.
 */
-   if ((sc-packet[0]  0x0c) != 0x04 
-   (sc-packet[3]  0xcf) != 0x02) {
-   /* not the head packet -- ignore */
-   return;
+   switch (elantech-flags  ELANTECH_F_CRC_ENABLED) {
+   case 0:
+   if ((sc-packet[0]  0x0c) != 0x04 
+   (sc-packet[3]  0xcf) != 0x02) {
+   /* not the head packet -- ignore */
+   return;
+   }
+   case ELANTECH_F_CRC_ENABLED:
+   if ((sc-packet[3]  0x09) != 0x08)
+   return;
}
+   
}
 
/* Prevent juming cursor if pad isn't touched or reports garbage. */

Re: libtls manpage diff

2015-04-01 Thread Joel Sing 
On Tuesday 31 March 2015, Tim van der Molen wrote:
 - Correct title.
 - tls_accept_socket() also may return TLS_{READ,WRITE}_AGAIN.

I've committed a slightly different version of this and fixed the title - 
thanks for the diff.

 Index: tls_init.3
 ===
 RCS file: /cvs/src/lib/libtls/tls_init.3,v
 retrieving revision 1.18
 diff -u -r1.18 tls_init.3
 --- tls_init.322 Feb 2015 15:09:54 -  1.18
 +++ tls_init.330 Mar 2015 16:36:47 -
 @@ -15,7 +15,7 @@
  .\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  .\
  .Dd $Mdocdate: February 22 2015 $
 -.Dt TLS 3
 +.Dt TLS_INIT 3
  .Os
  .Sh NAME
  .Nm tls_init ,
 @@ -391,9 +391,10 @@
  Functions that return a pointer will return NULL on error.
  .Pp
  The
 -.Fn tls_read
 -and
 +.Fn tls_read ,
  .Fn tls_write
 +and
 +.Fn tls_accept_socket
  functions and the
  .Fn tls_connect
  family of functions have two special return values.



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

if_input() design and next step

2015-04-01 Thread Martin Pieuchot 
One of the interesting things we've done during s2k15 was to redesign
ether_input().  The name of this function is clearly misleading.  Back
in the old days [0] it was simply used to put a packet on a protocol
queue.  Today ether_input() still does that, but before it does a lot
of different hacks to determine if a packet should be feed to a pseudo-
interface like vlan(4), carp(4), brige(4), etc.

ether_input() is now *the* entry point of our network stack and that's
what we need to change.

The main issues that we analysed about the current plumbing are:

 1) None of the pseudo-driver is (almost) self-contained which increase
the risk of regressions due to code complexity.  See the recent vlan
example.

 2) They are all plugged differently and most of the time feeding packets
or copies of them recursively.

 3) Every packet has to go through all the pseudo-driver checks even if
you're not using any of them.

So we came up with an architecture that should allow us to solve these
issues while preserving all the existing features that we all enjoy.

In the end, having self-contained, transparent and non-recursive pseudo-
driver code path to feed packets to the network stack will allow us to
work on one driver at a time to make it MP-safe.  Right now it's just to
many spaghetti in the same plate.

So the idea of if_input() is that an interface (ifp) can have multiple
input packet handlers.  These handlers are all on a list and act as
filters.  You give a mbuf to the first one, if it does not return an
error, you give it to the second one, etc.

Now by default every Ethernet driver has a single handler: ether_input().

So what's next?  Well the diff below introduces a new filter for trunk.
Instead of calling ether_input() which will then call trunk_input() for
every interface part of a trunk(4), a new handler is added in the list.

Since this handler is now executed *before* ether_input() we do not call
m_adj() on the mbuf we're currently filtering.  That's a crucial point!

Apart from that, everything should be straightforward.  Please note that
the diff below depends on the recent if_input() and `rcvif` tweak I
just sent.

I'm happily running with it, please let me know how it goes on your
setup.

[0] https://github.com/jonathangray/csrg/blob/master/sys/net/if_ethersubr.c#L299

diff --git sys/net/if_ethersubr.c sys/net/if_ethersubr.c
index bbc9246..1d964dd 100644
--- sys/net/if_ethersubr.c
+++ sys/net/if_ethersubr.c
@@ -463,9 +463,6 @@ ether_input(struct mbuf *m, void *hdr)
int s, llcfound = 0;
struct llc *l;
struct arpcom *ac;
-#if NTRUNK  0
-   int i = 0;
-#endif
 #if NPPPOE  0
struct ether_header *eh_tmp;
 #endif
@@ -480,21 +477,6 @@ ether_input(struct mbuf *m, void *hdr)
m_adj(m, ETHER_HDR_LEN);
}
 
-#if NTRUNK  0
-   /* Handle input from a trunk port */
-   while (ifp-if_type == IFT_IEEE8023ADLAG) {
-   if (++i  TRUNK_MAX_STACKING) {
-   m_freem(m);
-   return (1);
-   }
-   if (trunk_input(ifp, eh, m) != 0)
-   return (1);
-
-   /* Has been set to the trunk interface */
-   ifp = m-m_pkthdr.rcvif;
-   }
-#endif
-
if ((ifp-if_flags  IFF_UP) == 0) {
m_freem(m);
return (1);
@@ -518,17 +500,9 @@ ether_input(struct mbuf *m, void *hdr)
else
m-m_flags |= M_MCAST;
ifp-if_imcasts++;
-#if NTRUNK  0
-   if (ifp != ifp0)
-   ifp0-if_imcasts++;
-#endif
}
 
ifp-if_ibytes += m-m_pkthdr.len + sizeof(*eh);
-#if NTRUNK  0
-   if (ifp != ifp0)
-   ifp0-if_ibytes += m-m_pkthdr.len + sizeof(*eh);
-#endif
 
etype = ntohs(eh-ether_type);
 
diff --git sys/net/if_trunk.c sys/net/if_trunk.c
index e364648..514f77d 100644
--- sys/net/if_trunk.c
+++ sys/net/if_trunk.c
@@ -94,14 +94,14 @@ int  trunk_rr_detach(struct trunk_softc *);
 voidtrunk_rr_port_destroy(struct trunk_port *);
 int trunk_rr_start(struct trunk_softc *, struct mbuf *);
 int trunk_rr_input(struct trunk_softc *, struct trunk_port *,
-   struct ether_header *, struct mbuf *);
+   struct mbuf *);
 
 /* Active failover */
 int trunk_fail_attach(struct trunk_softc *);
 int trunk_fail_detach(struct trunk_softc *);
 int trunk_fail_start(struct trunk_softc *, struct mbuf *);
 int trunk_fail_input(struct trunk_softc *, struct trunk_port *,
-   struct ether_header *, struct mbuf *);
+   struct mbuf *);
 
 /* Loadbalancing */
 int trunk_lb_attach(struct trunk_softc *);
@@ -110,7 +110,7 @@ int  trunk_lb_port_create(struct trunk_port *);
 voidtrunk_lb_port_destroy(struct trunk_port *);
 int trunk_lb_start(struct trunk_softc *, struct mbuf *);
 int trunk_lb_input(struct trunk_softc *, struct trunk_port *,
-   struct

Re: add support for crc_enabled Elantech v3 touchpads

2015-04-01 Thread Fasse 
On Wed, 01 Apr 2015 20:05:46 +0200
Ulf Brosziewski ulf.brosziew...@t-online.de wrote:

 Hi,
 
 there might be a problem. The Linux driver for that touchpad type also
 accepts debounce packets, which have the same format as for the
 non-crc version. I have no idea whether that is correct and if those
 packets do occur in practice, but if they do they wouldn't pass this
 version of sync() (byte 3 would be 0x02 then).
 

You are right. I haven't had issues so far with debounce packets
missing but I obviously only have a very small sample size so there is
that. Since the debounce packet is ignored anyways I don't know if it
matters that it is thrown out early. Although if it didn't matter there
probably wouldn't even be a debounce packet? We could allow byte 3 to 
pass if its value after the check is 0x02 but that kind of defeats the 
purpose  of the integrity check I guess. 
Fortunately the values of debounce and head packets match up for non crc
elantech v3 touchpads. I don't think there is an elegant way to solve
this problem because pms_sync_elantech_v3 is called before the packet is
complete and you need the whole packet to check if it is a debounce
packet. To solve this we would have to do somthing similar to the linux
driver by only checking complete packets.

Re: add support for crc_enabled Elantech v3 touchpads

2015-04-01 Thread Fasse 
On Wed, 1 Apr 2015 18:02:59 +0200
Stefan Sperling s...@stsp.name wrote:
 Interesting, thanks.
 
 If you don't hear from anyone else about this please ask me again in
 a week from now. I can test on v3 hardware by then but not any earlier.
 
 Please write this as if-else instead of switch:
 
  @@ -2271,11 +2284,18 @@ pms_proc_elantech_v3(struct pms_softc *s
   * and a tail packet. We report a single event and ignore
   * the tail packet.
   */
  -   if ((sc-packet[0]  0x0c) != 0x04 
  -   (sc-packet[3]  0xcf) != 0x02) {
  -   /* not the head packet -- ignore */
  -   return;
  +   switch (elantech-flags  ELANTECH_F_CRC_ENABLED) {
  +   case 0:
  +   if ((sc-packet[0]  0x0c) != 0x04 
  +   (sc-packet[3]  0xcf) != 0x02) {
  +   /* not the head packet -- ignore */
  +   return;
  +   }
  +   case ELANTECH_F_CRC_ENABLED:
  +   if ((sc-packet[3]  0x09) != 0x08)
  +   return;
  }

Thanks for the offer I will propably take you up on that.
Below is the modified diff with the switch statement transformed.

Index: sys/dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.58
diff -u -p -r1.58 pms.c
--- sys/dev/pckbc/pms.c 26 Mar 2015 01:30:22 -  1.58
+++ sys/dev/pckbc/pms.c 1 Apr 2015 16:31:33 -
@@ -137,6 +137,7 @@ struct elantech_softc {
 #define ELANTECH_F_HAS_ROCKER  0x02
 #define ELANTECH_F_2FINGER_PACKET  0x04
 #define ELANTECH_F_HW_V1_OLD   0x08
+#define ELANTECH_F_CRC_ENABLED 0x10
int fw_version;
 
int min_x, min_y;
@@ -1812,6 +1813,9 @@ elantech_get_hwinfo_v3(struct pms_softc 
elantech-fw_version = fw_version;
elantech-flags |= ELANTECH_F_REPORTS_PRESSURE;
 
+   if ((fw_version  0x4000) == 0x4000)
+   elantech-flags |= ELANTECH_F_CRC_ENABLED;
+
if (elantech_set_absolute_mode_v3(sc))
return (-1);
 
@@ -2164,14 +2168,23 @@ pms_sync_elantech_v2(struct pms_softc *s
 int
 pms_sync_elantech_v3(struct pms_softc *sc, int data)
 {
+   struct elantech_softc *elantech = sc-elantech;
+
switch (sc-inputstate) {
case 0:
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED)
+   break;
if ((data  0x0c) != 0x04  (data  0x0c) != 0x0c)
return (-1);
break;
case 3:
-   if ((data  0xcf) != 0x02  (data  0xce) != 0x0c)
-   return (-1);
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED) {
+   if ((data  0x09) != 0x08  (data  0x09) != 0x09)
+   return (-1);
+   } else {
+   if ((data  0xcf) != 0x02  (data  0xce) != 0x0c)
+   return (-1);
+   }
break;
}
 
@@ -2271,10 +2284,15 @@ pms_proc_elantech_v3(struct pms_softc *s
 * and a tail packet. We report a single event and ignore
 * the tail packet.
 */
-   if ((sc-packet[0]  0x0c) != 0x04 
-   (sc-packet[3]  0xcf) != 0x02) {
-   /* not the head packet -- ignore */
-   return;
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED) {
+   if ((sc-packet[3]  0x09) != 0x08)
+   return;
+   } else {
+   if ((sc-packet[0]  0x0c) != 0x04 
+   (sc-packet[3]  0xcf) != 0x02) {
+   /* not the head packet -- ignore */
+   return;
+   }
}
}

Re: add m_defrag to pcn driver

2015-04-01 Thread Stefan Fritsch 
On Wednesday 01 April 2015 12:46:47, Kimberley Manning wrote:
   This diff makes the pcn driver use m_defrag for fragmented mbuf
   chains,
  
 
  I like this kind of cleanups.  As for vio(4) could you try the
  diff or are you looking for testers?
 
 Thanks. I've tried both the vio and pcn diffs and they worked for
 me, so dlg told me to write here. I'm not sure what happens to
 diffs after this point to be honest.

I can take a look at the vio diff and commit it in a few days.

BTW, is there a way to trigger heavily fragmented mbufs in order to 
test the code path?

Re: add support for crc_enabled Elantech v3 touchpads

2015-04-01 Thread Ulf Brosziewski 

On 04/01/2015 08:46 PM, Fasse wrote:

On Wed, 01 Apr 2015 20:05:46 +0200
Ulf Brosziewskiulf.brosziew...@t-online.de  wrote:


Hi,

there might be a problem. The Linux driver for that touchpad type also
accepts debounce packets, which have the same format as for the
non-crc version. I have no idea whether that is correct and if those
packets do occur in practice, but if they do they wouldn't pass this
version of sync() (byte 3 would be 0x02 then).



You are right. I haven't had issues so far with debounce packets
missing but I obviously only have a very small sample size so there is
that. Since the debounce packet is ignored anyways I don't know if it
matters that it is thrown out early. Although if it didn't matter there
probably wouldn't even be a debounce packet? We could allow byte 3 to
pass if its value after the check is 0x02 but that kind of defeats the
purpose  of the integrity check I guess.
Fortunately the values of debounce and head packets match up for non crc
elantech v3 touchpads. I don't think there is an elegant way to solve
this problem because pms_sync_elantech_v3 is called before the packet is
complete and you need the whole packet to check if it is a debounce
packet. To solve this we would have to do somthing similar to the linux
driver by only checking complete packets.




Yes, without some refactoring there won't be an elegant way.
pms_sync_elantech_v2 encodes some sync state in the 'flags' field
(ELANTECH_F_2FINGER_PACKET), but doing the same in the v3/CRC case might
be ugly.

Re: add support for crc_enabled Elantech v3 touchpads

2015-04-01 Thread Ulf Brosziewski 

Hi,

there might be a problem. The Linux driver for that touchpad type also
accepts debounce packets, which have the same format as for the
non-crc version. I have no idea whether that is correct and if those
packets do occur in practice, but if they do they wouldn't pass this
version of sync() (byte 3 would be 0x02 then).

On 04/01/2015 05:44 PM, Fasse wrote:

This diff adds support for Elantech v3 touchpads using the crc_enabled
integrity check. I tested this patch with my Elantech v3 touchpad using
firmware version 0x454f00, it now works correctly.
Other hardware versions should not be affected by this change. I could
not check if this introduces regression with other firmware versions.
If you have an elantech touchpad, particularly v3, could you please try
this diff and see if it causes any issues.

Index: sys/dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.58
diff -u -p -r1.58 pms.c
--- sys/dev/pckbc/pms.c 26 Mar 2015 01:30:22 -  1.58
+++ sys/dev/pckbc/pms.c 1 Apr 2015 14:22:10 -
@@ -137,6 +137,7 @@ struct elantech_softc {
  #define ELANTECH_F_HAS_ROCKER 0x02
  #define ELANTECH_F_2FINGER_PACKET 0x04
  #define ELANTECH_F_HW_V1_OLD  0x08
+#define ELANTECH_F_CRC_ENABLED 0x10
int fw_version;

int min_x, min_y;
@@ -1812,6 +1813,9 @@ elantech_get_hwinfo_v3(struct pms_softc
elantech-fw_version = fw_version;
elantech-flags |= ELANTECH_F_REPORTS_PRESSURE;

+   if ((fw_version  0x4000) == 0x4000)
+   elantech-flags |= ELANTECH_F_CRC_ENABLED;
+
if (elantech_set_absolute_mode_v3(sc))
return (-1);

@@ -2164,14 +2168,23 @@ pms_sync_elantech_v2(struct pms_softc *s
  int
  pms_sync_elantech_v3(struct pms_softc *sc, int data)
  {
+   struct elantech_softc *elantech = sc-elantech;
+
switch (sc-inputstate) {
case 0:
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED)
+   break;
if ((data  0x0c) != 0x04  (data  0x0c) != 0x0c)
return (-1);
break;
case 3:
-   if ((data  0xcf) != 0x02  (data  0xce) != 0x0c)
-   return (-1);
+   if (elantech-flags  ELANTECH_F_CRC_ENABLED) {
+   if ((data  0x09) != 0x08  (data  0x09) != 0x09)
+   return (-1);
+   } else {
+   if ((data  0xcf) != 0x02  (data  0xce) != 0x0c)
+   return (-1);
+   }
break;
}

@@ -2271,11 +2284,18 @@ pms_proc_elantech_v3(struct pms_softc *s
 * and a tail packet. We report a single event and ignore
 * the tail packet.
 */
-   if ((sc-packet[0]  0x0c) != 0x04
-   (sc-packet[3]  0xcf) != 0x02) {
-   /* not the head packet -- ignore */
-   return;
+   switch (elantech-flags  ELANTECH_F_CRC_ENABLED) {
+   case 0:
+   if ((sc-packet[0]  0x0c) != 0x04
+   (sc-packet[3]  0xcf) != 0x02) {
+   /* not the head packet -- ignore */
+   return;
+   }
+   case ELANTECH_F_CRC_ENABLED:
+   if ((sc-packet[3]  0x09) != 0x08)
+   return;
}
+   
}

/* Prevent juming cursor if pad isn't touched or reports garbage. */

sort: another mkstemp use case

2015-04-01 Thread Tobias Stoeckmann 
When creating a new temporary file name, use mkstemp instead of just
taking a rather predictable path, which could even be a symlink by
a malicious user (granted, that is very unlikely).

Index: file.c
===
RCS file: /cvs/src/usr.bin/sort/file.c,v
retrieving revision 1.6
diff -u -p -r1.6 file.c
--- file.c  1 Apr 2015 19:06:18 -   1.6
+++ file.c  1 Apr 2015 19:48:25 -
@@ -167,12 +167,13 @@ file_is_tmp(const char *fn)
 char *
 new_tmp_file_name(void)
 {
-   static size_t tfcounter = 0;
-   static const char *fn = .bsdsort.;
char *ret;
+   int fd;
 
-   sort_asprintf(ret, %s/%s%d.%lu, tmpdir, fn, (int)getpid(),
-   (unsigned long)(tfcounter++));
+   sort_asprintf(ret, %s/.bsdsort.XX, tmpdir);
+   if ((fd = mkstemp(ret)) == -1)
+   err(2, %s, ret);
+   close(fd);
tmp_file_atexit(ret);
return ret;
 }

Re: sort: another mkstemp use case

2015-04-01 Thread Todd C. Miller 
On Wed, 01 Apr 2015 21:55:14 +0200, Tobias Stoeckmann wrote:

 When creating a new temporary file name, use mkstemp instead of just
 taking a rather predictable path, which could even be a symlink by
 a malicious user (granted, that is very unlikely).

Heh, you beat me to that one.  I'm going to revisit how temp files
are used at some later point but this is OK for now.

With this change I think we no longer need the umask dance in
openfile().

 - todd