Fix cross tool build

[Masao Uebayashi]

When building 5.9 cross tools ("cross-tools" target in Makefile.cross)
on 5.8, cross tools are installed to e.g. ${CROSSDIR}/usr/*-openbsd5.9,
not .../*-openbsd5.8.

Don't use ${OSREV} which is derived from hardcoded ${OSMINOR} in
building host's /usr/share/mk/sys.mk (still 5.8), but use
${CROSSDIR}/TARGET_CANON, which comes from building target's
src/sys/conf/newvers.sh (5.9).

Index: gnu/usr.bin/cc/Makefile.inc
===
RCS file: /cvs/src/gnu/usr.bin/cc/Makefile.inc,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile.inc
--- gnu/usr.bin/cc/Makefile.inc 16 Sep 2012 20:46:35 -  1.6
+++ gnu/usr.bin/cc/Makefile.inc 9 Mar 2016 06:52:35 -
@@ -18,7 +18,11 @@ GCCDIR=  ${GCCLIB}/gcc
 
 # Machine description.
 MD_FILE=   ${GCCDIR}/config/${GCC_CPU}/${GCC_CPU}.md
+.if defined(CROSSDIR)
+GCC_TARGET!=   cat ${CROSSDIR}/TARGET_CANON
+.else
 GCC_TARGET=${TARGET_ARCH}-unknown-openbsd${OSREV}
+.endif
 
 NOPIE= Yes
 

mpsafe vlan(4)

[David Gwynne]

this is an unfortunately large reworking of vlan(4) to make tx mpsafe

it also includes the following:

- moving away from the vlan specific SIOC[SG]ETVLAN ioctls to the
SIOC[SGD]{VNETID,IFPARENT} ioctls

i did this to make the config transitions more straightforward.
with the new ioctls you either change one thing or the one thing
failed to be changed, making it more obvious what did and didnt
work.

- added compat for the legacy ioctls built out of the new ioctls

you can use an old ifconfig on top of a new kernel and it works
fine. ive been doing this on production firewalls for months now.

- added compat for the old ifconfig options.

the vlan and vlandev are mapped to vnetid and parent respectively,
allowing old configs to still work.

- made the implicit IFF_UP handling like other drivers

other drivers do IFF_UP when you configure an address on the
interface. vlan(4) did it when you configured a vlan/vlandev, but
not when you configured an interface.

- serialise changes affecting the vlan tag hashes used on input.

- restrict config changes while IFF_UP

this means you cant change the vnetid or the parent interface while
the interface is up. there are two reasons for this. firstly, moving
a vlan interface between parents is hard to do cleanly because
moving multicast group memberships is gross. secondly, moving
interfaces between parents or networks without a link state change
seems like incorrect behaviour to me.

in my mind it is best to think of config changes like this as
comparable to unplugging a cable from a switch port and moving it
to another one.

- rework multicast group membership handling

multicast group memberships could be lost before, this tries harder
to keep them.

- make transmit mpsafe

this relied on a lot of fixes on the config side to be safe, but
the changes to vlan_start are hilariously small compared to the
config changes.


it is big, but pulling it apart would be error prone and a long
process to get us to the same place this diff is already at.

i would welcome tests and eyes.

ok?

Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.316
diff -u -p -r1.316 ifconfig.c
--- sbin/ifconfig/ifconfig.c2 Mar 2016 00:00:16 -   1.316
+++ sbin/ifconfig/ifconfig.c9 Mar 2016 05:47:13 -
@@ -181,6 +181,7 @@ voidsettunnelinst(const char *, int);
 void   settunnelttl(const char *, int);
 void   setvnetid(const char *, int);
 void   delvnetid(const char *, int);
+void   getvnetid(void);
 void   setifparent(const char *, int);
 void   delifparent(const char *, int);
 void   getifparent(void);
@@ -209,12 +210,8 @@ void   setmpwencap(const char *, int);
 void   setmpwlabel(const char *, const char *);
 void   setmpwneighbor(const char *, int);
 void   setmpwcontrolword(const char *, int);
-void   setvlantag(const char *, int);
-void   setvlandev(const char *, int);
-void   unsetvlandev(const char *, int);
 void   mpe_status(void);
 void   mpw_status(void);
-void   vlan_status(void);
 void   setinstance(const char *, int);
 intmain(int, char *[]);
 intprefix(void *val, int);
@@ -350,9 +347,9 @@ const structcmd {
{ "scan",   NEXTARG0,   0,  setifscan },
{ "broadcast",  NEXTARG,0,  setifbroadaddr },
{ "prefixlen",  NEXTARG,0,  setifprefixlen},
-   { "vlan",   NEXTARG,0,  setvlantag },
-   { "vlandev",NEXTARG,0,  setvlandev },
-   { "-vlandev",   1,  0,  unsetvlandev },
+   { "vlan",   NEXTARG,0,  setvnetid },
+   { "vlandev",NEXTARG,0,  setifparent },
+   { "-vlandev",   1,  0,  delifparent },
{ "group",  NEXTARG,0,  setifgroup },
{ "-group", NEXTARG,0,  unsetifgroup },
{ "autoconf",   1,  0,  setautoconf },
@@ -2850,8 +2847,6 @@ phys_status(int force)
 
if (dstport)
printf(":%u", ntohs(dstport));
-   if (ioctl(s, SIOCGVNETID, (caddr_t)) == 0)
-   printf(" vnetid %d", ifr.ifr_vnetid);
if (ioctl(s, SIOCGLIFPHYTTL, (caddr_t)) == 0 && ifr.ifr_ttl > 0)
printf(" ttl %d", ifr.ifr_ttl);
 #ifndef SMALL
@@ -2942,7 +2937,7 @@ status(int link, struct sockaddr_dl *sdl
if_indextoname(ifrdesc.ifr_index, ifname) != NULL)
printf("\tpatch: %s\n", ifname);
 #endif
-   vlan_status();
+   getvnetid();
getifparent();
 #ifndef SMALL
carp_status();
@@ -3399,6 +3394,24 @@ delvnetid(const char *ignored, int alsoi
 }
 
 void
+getvnetid(void)
+{
+   if (strlcpy(ifr.ifr_name, name, sizeof(ifr.ifr_name)) >=
+   sizeof(ifr.ifr_name))
+   errx(1, "vnetid: name is too long");
+
+

Re: arm: purge arm8 - and maybe more?

[Jonathan Gray]

On Tue, Mar 08, 2016 at 10:59:42PM +0100, Patrick Wildt wrote:
> Hi,
> 
> I'd like to get some opinions on this.  ARM8 has probably never ever
> been used with OpenBSD, and I doubt it will ever be.  I think it also
> makes sense to remove more, like ARM9, ARM9E, ARM10, ARM11.  All the
> cruft that is not used, apart from armish, armv7 and zaurus.
> 
> In the end it will probably only make sense to support >=ARMv6, which
> does not include armish and zaurus.  Not sure how long those will still
> be around though.
> 
> This diff removes ARM8 first, I can follow up with more diffs quickly.
> 
> Thoughts?
> 
> Patrick

StrongARM is ARM8 but has it's own CPU_SA1100 that would have been used
by OpenBSD/cats.

But cats was dropped a long time ago (4.0).  It seems it may not be
possible to do eabi without requiring at least armv4t.

armish is CPU_XSCALE_80321
zaurus is CPU_XSCALE_PXA2X0

so we'd just keep the xscale variants and CPU_ARMv7?

CPU_XSCALE_80200
CPU_XSCALE_80321
CPU_XSCALE_PXA2X0
CPU_XSCALE_IXP425
CPU_ARMv7

currently the gcc configuration in base has
#define SUBTARGET_CPU_DEFAULT TARGET_CPU_strongarm
that could also change to something like TARGET_CPU_arm10tdmi
if the new baseline becomes armv5 instead of armv4.

> 
> diff --git sys/arch/arm/arm/cpu.c sys/arch/arm/arm/cpu.c
> index bc96e79..12709b1 100644
> --- sys/arch/arm/arm/cpu.c
> +++ sys/arch/arm/arm/cpu.c
> @@ -80,36 +80,10 @@ cpu_attach(struct device *dv)
>   curcpu()->ci_arm_cpuid & CPU_ID_REVISION_MASK;
>  
>   identify_arm_cpu(dv, curcpu());
> -
> -#ifdef CPU_ARM8
> - if ((curcpu()->ci_arm_cpuid & CPU_ID_CPU_MASK) == CPU_ID_ARM810) {
> - int clock = arm8_clock_config(0, 0);
> - char *fclk;
> - aprint_normal("%s: ARM810 cp15=%02x", dv->dv_xname, clock);
> - aprint_normal(" clock:%s", (clock & 1) ? " dynamic" : "");
> - aprint_normal("%s", (clock & 2) ? " sync" : "");
> - switch ((clock >> 2) & 3) {
> - case 0:
> - fclk = "bus clock";
> - break;
> - case 1:
> - fclk = "ref clock";
> - break;
> - case 3:
> - fclk = "pll";
> - break;
> - default:
> - fclk = "illegal";
> - break;
> - }
> - aprint_normal(" fclk source=%s\n", fclk);
> - }
> -#endif
>  }
>  
>  enum cpu_class {
>   CPU_CLASS_NONE,
> - CPU_CLASS_ARM8,
>   CPU_CLASS_ARM9TDMI,
>   CPU_CLASS_ARM9ES,
>   CPU_CLASS_ARM9EJS,
> @@ -219,9 +193,6 @@ struct cpuidtab {
>  };
>  
>  const struct cpuidtab cpuids[] = {
> - { CPU_ID_ARM810,CPU_CLASS_ARM8, "ARM810",
> -   generic_steppings },
> -
>   { CPU_ID_ARM920T,   CPU_CLASS_ARM9TDMI, "ARM920T",
> generic_steppings },
>   { CPU_ID_ARM922T,   CPU_CLASS_ARM9TDMI, "ARM922T",
> @@ -358,7 +329,6 @@ struct cpu_classtab {
>  
>  const struct cpu_classtab cpu_classes[] = {
>   { "unknown",NULL }, /* CPU_CLASS_NONE */
> - { "ARM8",   "CPU_ARM8" },   /* CPU_CLASS_ARM8 */
>   { "ARM9TDMI",   NULL }, /* CPU_CLASS_ARM9TDMI */
>   { "ARM9E-S","CPU_ARM9E" },  /* CPU_CLASS_ARM9ES */
>   { "ARM9EJ-S",   "CPU_ARM9E" },  /* CPU_CLASS_ARM9EJS */
> @@ -429,12 +399,6 @@ identify_arm_cpu(struct device *dv, struct cpu_info *ci)
>   printf("%s:", dv->dv_xname);
>  
>   switch (cpu_class) {
> - case CPU_CLASS_ARM8:
> - if ((ci->ci_ctrl & CPU_CONTROL_IDC_ENABLE) == 0)
> - printf(" IDC disabled");
> - else
> - printf(" IDC enabled");
> - break;
>   case CPU_CLASS_ARM9TDMI:
>   case CPU_CLASS_ARM9ES:
>   case CPU_CLASS_ARM9EJS:
> @@ -490,9 +454,6 @@ identify_arm_cpu(struct device *dv, struct cpu_info *ci)
>   skip_pcache:
>  
>   switch (cpu_class) {
> -#ifdef CPU_ARM8
> - case CPU_CLASS_ARM8:
> -#endif
>  #ifdef CPU_ARM9
>   case CPU_CLASS_ARM9TDMI:
>  #endif
> diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
> index f549e61..4c2c6d8 100644
> --- sys/arch/arm/arm/cpufunc.c
> +++ sys/arch/arm/arm/cpufunc.c
> @@ -97,63 +97,6 @@ intarm_dcache_align_mask;
>  /* 1 == use cpu_sleep(), 0 == don't */
>  int cpu_do_powersave;
>  
> -#ifdef CPU_ARM8
> -struct cpu_functions arm8_cpufuncs = {
> - /* CPU functions */
> -
> - cpufunc_id, /* id   */
> - cpufunc_nullop, /* cpwait   */
> -
> - /* MMU functions */
> -
> - cpufunc_control,/* control  */
> - cpufunc_domains,/* domain   */
> - arm8_setttb,/* setttb   */
> - cpufunc_dfsr,   /* dfsr */
> - 

Fix mount point in FAQ section 14.10.3

[Daniel Bolgheroni]

The newly created partition is in sd1, not sd0.

Index: faq14.html
===
RCS file: /cvs/www/faq/faq14.html,v
retrieving revision 1.300
diff -u -p -r1.300 faq14.html
--- faq14.html  8 Mar 2016 01:14:03 -   1.300
+++ faq14.html  9 Mar 2016 01:32:19 -
@@ -924,7 +924,7 @@ softraid0: CRYPTO volume attached as sd1
 # disklabel -E sd1 (create an "i" partition, see above for more info)
 # newfs sd1i
 # mkdir -p /mnt/secretstuff
-# mount /dev/sd0i /mnt/secretstuff
+# mount /dev/sd1i /mnt/secretstuff
 # mv planstotakeovertheworld.txt /mnt/secretstuff/
 # umount /mnt/secretstuff
 # bioctl -d sd1

-- 
db

[patch] make npppd do as the man page says

[Joe Holden]

Below is a patch that corrects pptp to set the pptp hostname as the 
system hostname, as per the man page and l2tp:


diff --git a/usr.sbin/npppd/pptp/pptp_ctrl.c 
b/usr.sbin/npppd/pptp/pptp_ctrl.c

index 1dfdc03..722b2a0 100644
--- a/usr.sbin/npppd/pptp/pptp_ctrl.c
+++ b/usr.sbin/npppd/pptp/pptp_ctrl.c
@@ -721,6 +721,7 @@ pptp_ctrl_send_SCCRP(pptp_ctrl *_this, int result, 
int error)

struct pptp_scc *scc;
char logbuf[512];
const char *val;
+   char hbuf[NI_MAXHOST + NI_MAXSERV + 16];

scc = bytebuffer_pointer(_this->send_buf);
lpkt = bytebuffer_remaining(_this->send_buf);
@@ -749,8 +750,10 @@ pptp_ctrl_send_SCCRP(pptp_ctrl *_this, int result, 
int error)

 * 63 character */
/* host name */

-   if ((val = PPTP_CTRL_CONF(_this)->hostname) == NULL)
-   val = "";
+   if ((val = PPTP_CTRL_CONF(_this)->hostname) == NULL) {
+   gethostname(hbuf, sizeof(hbuf));
+   val = hbuf;
+   }
strlcpy(scc->host_name, val, sizeof(scc->host_name));

/* vender name */

Re: arm: dmamap_destroy: remove explicit unload of map

[Daniel Bolgheroni]

On Sun, Mar 06, 2016 at 12:53:24PM +0100, Tobias Ulmer wrote:
> map is passed straight into free where it gets overwritten with junk.
> No other arch makes map invalid before free, and my N2100 didn't
> suddenly misbehave either.
> 
> ok?

Have been building -current with this diff applied too and no problems so
far.

-- 
db

Re: [patch] ps: atol(3) -> strtonum(3)

[fritjof]

On Tue, Mar 08, 2016 at 01:31:47PM -0700, Todd C. Miller wrote:
> On Tue, 08 Mar 2016 09:32:25 -0700, Theo de Raadt wrote:
> 
> > atol maps to strtol.  Which can accept hex or octal.
> 
> atol() maps to strtol(str, (char **)NULL, 10) so this is a good
> place to use strtonum().  The max value should probably be PID_MAX
> rather than INT_MAX but we only expose that #ifdef _KERNEL.
>

This is what I figured out as well.

>  - todd
> 
X

--F.

Re: Asus-K75D Notebook: acpi0/acpitz0 causing crashes in OpenBSD 5/6/5.7/5.8/5.9 ?

[Stuart Henderson]

On 2016/03/08 13:42, Rick Gregory wrote:
> Hi,
> I have a an Asus K75DE Notebook
>  ( AMD A10-4600M APU with Radeon(tm) HD Graphics 7600 Series )
> Right now I'm running OBSD 5.5, with Gnome3 Desktop, radeon-firmware seems
> to work fine.

Please generate a mail with sendbug run as root. (Probably best to
run 'sendbug -P > /tmp/somefile', fill it out and send it via a normal
mail program so the return address is correct). This will include
acpidump/pcidump output that may help track this down.

Re: NULL checks of static arrays

[Michael McConville]

Martin Pieuchot wrote:
> On 06/03/16(Sun) 19:20, Michael McConville wrote:
> > We check static arrays against NULL pretty often in the kernel. I
> > suspect most of these are due to recent kernel API changes. Should they
> > be removed, or do people want to keep them around in case the APIs
> > change again? Clang 3.7 warns about them by default, so they're easy to
> > find.
> 
> I think you should post diffs so we can decide on a case-by-case basis.
> 
> But if they are leftovers from cleanups, then we should clean them.

Here are a few examples I have sitting in my tree:


Index: sys/dev/ic/ti.c
===
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.22
diff -u -p -r1.22 ti.c
--- sys/dev/ic/ti.c 25 Nov 2015 03:09:58 -  1.22
+++ sys/dev/ic/ti.c 8 Mar 2016 22:02:50 -
@@ -484,9 +484,6 @@ ti_handle_events(struct ti_softc *sc)
struct ti_event_desc*e;
struct ifnet*ifp = >arpcom.ac_if;
 
-   if (sc->ti_rdata->ti_event_ring == NULL)
-   return;
-
while (sc->ti_ev_saved_considx != sc->ti_ev_prodidx.ti_idx) {
e = >ti_rdata->ti_event_ring[sc->ti_ev_saved_considx];
switch (TI_EVENT_EVENT(e)) {
@@ -846,9 +843,6 @@ ti_free_tx_ring(struct ti_softc *sc)
 {
int i;
struct ti_txmap_entry *entry;
-
-   if (sc->ti_rdata->ti_tx_ring == NULL)
-   return;
 
for (i = 0; i < TI_TX_RING_CNT; i++) {
if (sc->ti_cdata.ti_tx_chain[i] != NULL) {
Index: sys/dev/usb/uoakrh.c
===
RCS file: /cvs/src/sys/dev/usb/uoakrh.c,v
retrieving revision 1.13
diff -u -p -r1.13 uoakrh.c
--- sys/dev/usb/uoakrh.c9 Jan 2016 04:14:42 -   1.13
+++ sys/dev/usb/uoakrh.c8 Mar 2016 22:02:50 -
@@ -215,11 +215,6 @@ uoakrh_detach(struct device *self, int f
wakeup(>sc_sensortask);
sensordev_deinstall(>sc_sensordev);
 
-   if (>sc_sensordev != NULL) {
-   sensor_detach(>sc_sensordev, >sc_sensor.temp);
-   sensor_detach(>sc_sensordev, >sc_sensor.humi);
-   }
-
if (sc->sc_sensortask != NULL)
sensor_task_unregister(sc->sc_sensortask);
 

arm: purge arm8 - and maybe more?

[Patrick Wildt]

Hi,

I'd like to get some opinions on this.  ARM8 has probably never ever
been used with OpenBSD, and I doubt it will ever be.  I think it also
makes sense to remove more, like ARM9, ARM9E, ARM10, ARM11.  All the
cruft that is not used, apart from armish, armv7 and zaurus.

In the end it will probably only make sense to support >=ARMv6, which
does not include armish and zaurus.  Not sure how long those will still
be around though.

This diff removes ARM8 first, I can follow up with more diffs quickly.

Thoughts?

Patrick

diff --git sys/arch/arm/arm/cpu.c sys/arch/arm/arm/cpu.c
index bc96e79..12709b1 100644
--- sys/arch/arm/arm/cpu.c
+++ sys/arch/arm/arm/cpu.c
@@ -80,36 +80,10 @@ cpu_attach(struct device *dv)
curcpu()->ci_arm_cpuid & CPU_ID_REVISION_MASK;
 
identify_arm_cpu(dv, curcpu());
-
-#ifdef CPU_ARM8
-   if ((curcpu()->ci_arm_cpuid & CPU_ID_CPU_MASK) == CPU_ID_ARM810) {
-   int clock = arm8_clock_config(0, 0);
-   char *fclk;
-   aprint_normal("%s: ARM810 cp15=%02x", dv->dv_xname, clock);
-   aprint_normal(" clock:%s", (clock & 1) ? " dynamic" : "");
-   aprint_normal("%s", (clock & 2) ? " sync" : "");
-   switch ((clock >> 2) & 3) {
-   case 0:
-   fclk = "bus clock";
-   break;
-   case 1:
-   fclk = "ref clock";
-   break;
-   case 3:
-   fclk = "pll";
-   break;
-   default:
-   fclk = "illegal";
-   break;
-   }
-   aprint_normal(" fclk source=%s\n", fclk);
-   }
-#endif
 }
 
 enum cpu_class {
CPU_CLASS_NONE,
-   CPU_CLASS_ARM8,
CPU_CLASS_ARM9TDMI,
CPU_CLASS_ARM9ES,
CPU_CLASS_ARM9EJS,
@@ -219,9 +193,6 @@ struct cpuidtab {
 };
 
 const struct cpuidtab cpuids[] = {
-   { CPU_ID_ARM810,CPU_CLASS_ARM8, "ARM810",
- generic_steppings },
-
{ CPU_ID_ARM920T,   CPU_CLASS_ARM9TDMI, "ARM920T",
  generic_steppings },
{ CPU_ID_ARM922T,   CPU_CLASS_ARM9TDMI, "ARM922T",
@@ -358,7 +329,6 @@ struct cpu_classtab {
 
 const struct cpu_classtab cpu_classes[] = {
{ "unknown",NULL }, /* CPU_CLASS_NONE */
-   { "ARM8",   "CPU_ARM8" },   /* CPU_CLASS_ARM8 */
{ "ARM9TDMI",   NULL }, /* CPU_CLASS_ARM9TDMI */
{ "ARM9E-S","CPU_ARM9E" },  /* CPU_CLASS_ARM9ES */
{ "ARM9EJ-S",   "CPU_ARM9E" },  /* CPU_CLASS_ARM9EJS */
@@ -429,12 +399,6 @@ identify_arm_cpu(struct device *dv, struct cpu_info *ci)
printf("%s:", dv->dv_xname);
 
switch (cpu_class) {
-   case CPU_CLASS_ARM8:
-   if ((ci->ci_ctrl & CPU_CONTROL_IDC_ENABLE) == 0)
-   printf(" IDC disabled");
-   else
-   printf(" IDC enabled");
-   break;
case CPU_CLASS_ARM9TDMI:
case CPU_CLASS_ARM9ES:
case CPU_CLASS_ARM9EJS:
@@ -490,9 +454,6 @@ identify_arm_cpu(struct device *dv, struct cpu_info *ci)
  skip_pcache:
 
switch (cpu_class) {
-#ifdef CPU_ARM8
-   case CPU_CLASS_ARM8:
-#endif
 #ifdef CPU_ARM9
case CPU_CLASS_ARM9TDMI:
 #endif
diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
index f549e61..4c2c6d8 100644
--- sys/arch/arm/arm/cpufunc.c
+++ sys/arch/arm/arm/cpufunc.c
@@ -97,63 +97,6 @@ int  arm_dcache_align_mask;
 /* 1 == use cpu_sleep(), 0 == don't */
 int cpu_do_powersave;
 
-#ifdef CPU_ARM8
-struct cpu_functions arm8_cpufuncs = {
-   /* CPU functions */
-
-   cpufunc_id, /* id   */
-   cpufunc_nullop, /* cpwait   */
-
-   /* MMU functions */
-
-   cpufunc_control,/* control  */
-   cpufunc_domains,/* domain   */
-   arm8_setttb,/* setttb   */
-   cpufunc_dfsr,   /* dfsr */
-   cpufunc_dfar,   /* dfar */
-   cpufunc_ifsr,   /* ifsr */
-   cpufunc_ifar,   /* ifar */
-
-   /* TLB functions */
-
-   arm8_tlb_flushID,   /* tlb_flushID  */
-   arm8_tlb_flushID_SE,/* tlb_flushID_SE   */
-   arm8_tlb_flushID,   /* tlb_flushI   */
-   arm8_tlb_flushID_SE,/* tlb_flushI_SE*/
-   arm8_tlb_flushID,   /* tlb_flushD   */
-   arm8_tlb_flushID_SE,/* tlb_flushD_SE*/
-
-   /* Cache operations */
-
-   cpufunc_nullop, /* icache_sync_all  */
-   (void *)cpufunc_nullop, /* icache_sync_range*/
-
-   

Re: update comment about p_usrpri

[Martin Pieuchot]

On 08/03/16(Tue) 10:01, Michal Mazurek wrote:
> p_cpu exists, but p_usrpri isn't based on it.

Michal I lost track of all your comment fixes.  One of the accepted
rules when we read code is that comments are always lying.  So I doubt
anyone will object fixing them.

Could you send a single diff with all your non-committed fixes?

Asus-K75D Notebook: acpi0/acpitz0 causing crashes in OpenBSD 5/6/5.7/5.8/5.9 ?

[Rick Gregory]

Hi,
I have a an Asus K75DE Notebook
 ( AMD A10-4600M APU with Radeon(tm) HD Graphics 7600 Series )
Right now I'm running OBSD 5.5, with Gnome3 Desktop, radeon-firmware seems
to work fine.
"$ glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD ARUBA"
"$ uname : OpenBSD 5.5 GENERIC.MP#315 amd64", and I'll explain why I'm
running 5.5 a bit further.

some dmesg output, from OBSD 5.5:

"acpitz0 at acpi0acpi0: WARNING EC not initialized
acpi0: WARNING EC not initialized
acpi0: WARNING EC not initialized
acpitz0: THRM: failed to read _TMP"

"Atheros AR9485" rev 0x01 at pci2 dev 0 function 0 not configured"
-
 The above "AR9485" wireless has never worked in any OBSD, including the
latest current-5.9-snapshot, so I use a wireless dongle.

With latest-current-5.9 snapshot, as of yesterday, or
OpenBSD-Release-5.8/5.7/5.6, they all boot fine, but after I install them,
and try to boot normally, I get the above "acpi" errors and just as I get to
the "Login:" prompt on the console, it spews:
"acpitz0: exceeding temperature of 0 Degrees C,... shutting down
...syncing disks"
It shuts itself down immediately, and therefore I cannot login to see what's up.
 I then tried
boot> boot -c, followed by a "disable acpi", and it comes up, but when I
"fw_update -v" to install the latest radeon-firmware and reboot, it repeats
the shutdown before the login prompt again.
 I seems "acpi" is tied to everything, I cannot "startx" into any window
manager without it, and if I do it crashes again. ?

 ( Note: I tested this notebook with Linux, and Winbloze, and everything works.)
 I also read on a post around here, that disabling USB3 in BIOS had fixed
someones issue with "acpi" errors, but I cannot do that in my BIOS.

 I prefer not to use OpenBSD 5.5, even though it does seemingly work,
because my notebook gets very warm. I hear the fans turning but it still
gets overly hot ?

 I can boot up from latest "snapshot" and post my "dmesg" output, and
anything else if you think it may help to drill down and possibly fix these
persistent issues, 
 although, I fear this Asus K75DE Notebook is not exactly a  "favourite"
amongst the OpenBSD dev's.
 ;)

Re: [patch] ps: atol(3) -> strtonum(3)

[Todd C. Miller]

On Tue, 08 Mar 2016 09:32:25 -0700, Theo de Raadt wrote:

> atol maps to strtol.  Which can accept hex or octal.

atol() maps to strtol(str, (char **)NULL, 10) so this is a good
place to use strtonum().  The max value should probably be PID_MAX
rather than INT_MAX but we only expose that #ifdef _KERNEL.

 - todd

Re: [patch] ps: atol(3) -> strtonum(3)

[Theo de Raadt]

atol maps to strtol.  Which can accept hex or octal.

strtonum cannot do that.

So you have missed a step here -- a justification based upon
verification that loss of support for octal/hex is a good step
forward.  Basically, some archeology.  You need to go pull on a string
for a while, then report back on positive finds, conversations about
it, historical use of octal/hex, etc.

> Index: ps.c
> ===
> RCS file: /cvs/src/bin/ps/ps.c,v
> retrieving revision 1.63
> diff -u -r1.63 ps.c
> --- ps.c  16 Jan 2015 06:39:32 -  1.63
> +++ ps.c  8 Mar 2016 14:15:34 -
> @@ -99,6 +99,7 @@
>   int all, ch, flag, i, fmt, lineno, nentries;
>   int prtheader, showthreads, wflag, kflag, what, Uflag, xflg;
>   char *nlistf, *memf, *swapf, *cols, errbuf[_POSIX2_LINE_MAX];
> + const char *errstr;
>  
>   if ((cols = getenv("COLUMNS")) != NULL && *cols != '\0') {
>   const char *errstr;
> @@ -189,7 +190,9 @@
>   fmt = 1;
>   break;
>   case 'p':
> - pid = atol(optarg);
> + pid = strtonum(optarg, 1, INT_MAX, );
> + if (errstr != NULL)
> + errx(1, "%s is an invalid pid", optarg);
>   xflg = 1;
>   break;
>   case 'r':
> 

[patch] ps: atol(3) -> strtonum(3)

[fritjof]

--F.


Index: ps.c
===
RCS file: /cvs/src/bin/ps/ps.c,v
retrieving revision 1.63
diff -u -r1.63 ps.c
--- ps.c16 Jan 2015 06:39:32 -  1.63
+++ ps.c8 Mar 2016 14:15:34 -
@@ -99,6 +99,7 @@
int all, ch, flag, i, fmt, lineno, nentries;
int prtheader, showthreads, wflag, kflag, what, Uflag, xflg;
char *nlistf, *memf, *swapf, *cols, errbuf[_POSIX2_LINE_MAX];
+   const char *errstr;
 
if ((cols = getenv("COLUMNS")) != NULL && *cols != '\0') {
const char *errstr;
@@ -189,7 +190,9 @@
fmt = 1;
break;
case 'p':
-   pid = atol(optarg);
+   pid = strtonum(optarg, 1, INT_MAX, );
+   if (errstr != NULL)
+   errx(1, "%s is an invalid pid", optarg);
xflg = 1;
break;
case 'r':

Re: mpw(4) vlan handling

[David Gwynne]

im going to commit this tomorrow unless anyone objects. i dont want
to hold up vlan too much.

On Wed, Mar 02, 2016 at 11:48:49AM +1000, David Gwynne wrote:
> ive got a large reworking of vlan(4) to make vlan tx mpsafe, which
> affected mpw(4).
> 
> the biggest effect was that it was no longer safe to traverse the
> interface parent hierarchy looking for vlan interfaces. however,
> from what i could tell from the rfc, such traversal is unecessary.
> 
> this refactors the code so it only reinject vlan headers in tagged
> mode for vlan interfaces in the same bridge as it. in raw mode it
> just sends the packet as is. this is based on my interpretation of
> 4.4.1 in rfc4448.
> 
> this also has the benefit that you can assign local addresses on
> mpw interfaces in raw mode and talk over them without making the
> machine panic. it should also be possible to assign addresses on
> tagged interfaces too.
> 
> to be clear, not traversing the vlan interface parents is necessary
> for making vlan itself mpsafe. i am confident we're still within
> spec without that functionality, and actually get simplifications
> and semantic improvements out of it this way.
> 
> this diff relies on the vlan_input() code i sent to tech@
> 
> ok?
> 
> Index: if_mpw.c
> ===
> RCS file: /cvs/src/sys/net/if_mpw.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 if_mpw.c
> --- if_mpw.c  5 Dec 2015 10:07:55 -   1.12
> +++ if_mpw.c  2 Mar 2016 01:36:49 -
> @@ -351,164 +351,51 @@ extern void vlan_start(struct ifnet *ifp
>  struct mbuf *
>  mpw_vlan_handle(struct mbuf *m, struct mpw_softc *sc)
>  {
> - int needsdummy = 0;
> - int fakeifv = 0;
> - struct ifvlan *ifv = NULL;
> - struct ether_vlan_header *evh;
> - struct ifnet *ifp, *ifp0;
> - int nvlan, moff;
> - struct ether_header eh;
> - struct ifvlan fifv;
> - struct vlan_shim {
> - uint16_tvs_tpid;
> - uint16_tvs_tci;
> - } vs;
> -
> - ifp = ifp0 = if_get(m->m_pkthdr.ph_ifidx);
> - KASSERT(ifp != NULL);
> - if (ifp->if_start == vlan_start)
> - ifv = ifp->if_softc;
> -
> - /* If we were relying on VLAN HW support, fake an ifv */
> - if (ifv == NULL && (m->m_flags & M_VLANTAG) == M_VLANTAG) {
> - memset(, 0, sizeof(fifv));
> - fifv.ifv_tag = EVL_VLANOFTAG(m->m_pkthdr.ether_vtag);
> - fifv.ifv_prio = EVL_PRIOFTAG(m->m_pkthdr.ether_vtag);
> - ifv = 
> - fakeifv = 1;
> - }
> -
> - /*
> -  * Always remove VLAN flag as we are inserting them here. Also we
> -  * might get a tagged packet with no VLAN interface, in this case
> -  * we can't do anything.
> -  */
> - m->m_flags &= ~M_VLANTAG;
> -
> - /*
> -  * Do VLAN managing.
> -  *
> -  * Case ethernet (raw):
> -  *  No VLAN: just pass it.
> -  *  One or more VLANs: insert VLAN tag back.
> -  *
> -  * NOTE: In case of raw access mode, the if_vlan will do the job
> -  * of dropping non tagged packets for us.
> -  */
> - if (sc->sc_type == IMR_TYPE_ETHERNET && ifv == NULL) {
> - if_put(ifp0);
> - return (m);
> - }
> -
> - /*
> -  * Case ethernet-tagged:
> -  *  0 VLAN: Drop packet
> -  *  1 VLAN: Tag packet with dummy VLAN
> -  *  >1 VLAN: Nothing
> -  */
> - if (sc->sc_type == IMR_TYPE_ETHERNET_TAGGED && ifv == NULL) {
> - m_freem(m);
> - if_put(ifp0);
> - return (NULL);
> - }
> -
> - /* Copy and remove ethernet header */
> - m_copydata(m, 0, sizeof(eh), (caddr_t) );
> - if (ntohs(eh.ether_type) == ETHERTYPE_VLAN ||
> - ntohs(eh.ether_type) == ETHERTYPE_QINQ)
> - m_adj(m, sizeof(*evh));
> - else
> - m_adj(m, sizeof(eh));
> -
> - /* Count VLAN stack size */
> - nvlan = 0;
> - while ((ifp = ifv->ifv_p) != NULL && ifp->if_start == vlan_start) {
> - ifv = ifp->if_softc;
> - nvlan++;
> - }
> - moff = sizeof(*evh) + (nvlan * EVL_ENCAPLEN);
> -
> - /* The mode ethernet tagged always need at least 2 VLANs */
> - if (sc->sc_type == IMR_TYPE_ETHERNET_TAGGED && nvlan == 0) {
> - needsdummy = 1;
> - moff += EVL_ENCAPLEN;
> - }
> -
> - /* Add VLAN to the beginning of the packet */
> - M_PREPEND(m, moff, M_NOWAIT);
> - if (m == NULL) {
> - if_put(ifp0);
> - return (NULL);
> - }
> -
> - /* Copy original ethernet type */
> - moff -= sizeof(eh.ether_type);
> - m_copyback(m, moff, sizeof(eh.ether_type), _type, M_NOWAIT);
> -
> - /* Fill inner VLAN values */
> - ifv = ifp0->if_softc;
> - while (nvlan-- > 0) {
> - vs.vs_tci = htons((ifv->ifv_prio << EVL_PRIO_BITS) +
> - ifv->ifv_tag);
> - vs.vs_tpid = htons(ifv->ifv_type);
> -
> -  

Re: improve xterm(1) resilience against control code attacks

[lists]

> Christian Weisgerber wrote on Mon, Mar 07, 2016 at 03:51:41PM +:
> > On 2016-03-07, Ingo Schwarze  wrote:  
> 
> >> Consequently, in the interest of safe and sane defaults, i propose
> >> switching our xterm(1) to enable UTF-8 mode by default.  
> 
> > Seconded.

Please.
 
> >> The best place to switch is in the setup function VTInitialize_locale()
> >> that decides whether to enable UTF-8 mode and which supporting flags
> >> to set, by pretending to it that CODESET is always UTF-8, but without
> >> interfering with the actual value of the CODESET and without changing
> >> the utility function xtermEnvUTF8().  
> 
> > Hmm, maybe you are overthinking this.
> > Other defaults that we set differently from upstream are simply
> > resource changes to XTerm.ad (/usr/X11R6/share/X11/app-defaults/XTerm).  

Tue, 8 Mar 2016 00:14:45 +0100 Ingo Schwarze 
> Heh.  I considered simply changing the resource defaults, but came
> to the wrong conclusion that there wouldn't be a way to achieve the
> desired effect.  Thanks for bringing it up again, that made me
> re-check, and it turns out there *is* a way that is quite
> straightforward, minimally intrusive, very robust, and doesn't get
> in the way of explicit user configuration: See the patch below.
> If this gets OKs, let's forget my previous, more intrusive patch.

Maybe still not forget it for future reference though.

> With that change, users can obviously still set *locale to other
> values (for example, "true" or "false" come to mind), and the command
> line options changing *locale (-lc +lc -en) still work.  Looking
> at the code, explicitly setting *utf8 to false (or equivalently,
> +u8 on the command line) also overrides this.
> 
> Spending a day reading xterm source code wasn't wasted, though -
> by reading the documentation only, i wouldn't have understood
> that this way works as intended and is safe.

If it took you that long, no wonder the barrier is too high for entry
in this program.  Not implying anything though, please leave it be.

> >>   printf "\303\237\n"   # thanks to sobrado@ for the striking example
> >> Now your local terminal hangs until you force a reset using the
> >> menus of the xterm program.  
> 
> > \237 is 0x9F, equivalent to ESC _, which is APC (Application Program
> > Command).  That appears in a table, but is not explained in the
> > VT220 manual.  The VT420 manual says: "The VT420 ignores all following
> > characters until it receives a SUB, ST, or any other C1 control
> > character."  
> 
> Yes.  I spent so much time reading terminal control code documentation
> lately that i probably assumed this to be widely known.  ;-)
> You are right, explaining it is helpful.

More thinking on terminal resilience and utf8, thanks for making huge
progress so far system wide.

> Index: XTerm.ad
> ===
> RCS file: /cvs/xenocara/app/xterm/XTerm.ad,v
> retrieving revision 1.15
> diff -u -p -r1.15 XTerm.ad
> --- XTerm.ad  26 Aug 2013 20:06:10 -  1.15
> +++ XTerm.ad  7 Mar 2016 22:54:44 -
> @@ -259,6 +259,11 @@
>  
>  ! OpenBSD local modifications
>  
> +! Enable UTF-8 mode since OpenBSD does not support any other multibyte
> +! locales.  Even for people using the C/POSIX locale for everything,
> +! that's safer and more usable than the upstream default of "medium".
> +*locale: UTF-8
> +
>  ! ScrollBar by default
>  *scrollBar: true

Not mentioning the unrelated login resource class set to true in
another patch for application defaults instead of user resources.

Re: Grammatical changes to httpd.conf(5)

[Sevan Janiyan]

On 08/03/2016 07:04, Jason McIntyre wrote:
> i think it's better to submit changes where there is a clear
> improvement, or where we can definitely say what's there now is
> incorrect.

Ok, no worries.


Sevan

update comment about p_usrpri

[Michal Mazurek]

p_cpu exists, but p_usrpri isn't based on it.

Index: sys/sys/proc.h
===
RCS file: /cvs/src/sys/sys/proc.h,v
retrieving revision 1.216
diff -u -p -r1.216 proc.h
--- sys/sys/proc.h  6 Mar 2016 05:20:26 -   1.216
+++ sys/sys/proc.h  8 Mar 2016 08:52:58 -
@@ -323,7 +323,7 @@ struct proc {
sigset_t p_sigmask; /* Current signal mask. */
 
u_char  p_priority; /* Process priority. */
-   u_char  p_usrpri;   /* User-priority based on p_cpu and ps_nice. */
+   u_char  p_usrpri;   /* User-priority based on p_estcpu and ps_nice. 
*/
charp_comm[MAXCOMLEN+1];
 
int p_pledge_syscall;   /* Cache of current syscall */
Index: sys/sys/sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.158
diff -u -p -r1.158 sysctl.h
--- sys/sys/sysctl.h29 Feb 2016 19:44:07 -  1.158
+++ sys/sys/sysctl.h8 Mar 2016 08:52:58 -
@@ -377,7 +377,7 @@ struct kinfo_proc {
 
int8_t  p_stat; /* CHAR: S* process status (from LWP). 
*/
u_int8_t p_priority;/* U_CHAR: Process priority. */
-   u_int8_t p_usrpri;  /* U_CHAR: User-priority based on p_cpu 
and ps_nice. */
+   u_int8_t p_usrpri;  /* U_CHAR: User-priority based on 
p_estcpu and ps_nice. */
u_int8_t p_nice;/* U_CHAR: Process "nice" value. */
 
u_int16_t p_xstat;  /* U_SHORT: Exit status for wait; also 
stop signal. */

-- 
Michal Mazurek

Re: improve xterm(1) resilience against control code attacks

[Matthieu Herrb]

On Tue, Mar 08, 2016 at 12:14:45AM +0100, Ingo Schwarze wrote:
> Hi Christian,
> 
> Christian Weisgerber wrote on Mon, Mar 07, 2016 at 03:51:41PM +:
> > On 2016-03-07, Ingo Schwarze  wrote:
> 
> >> Consequently, in the interest of safe and sane defaults, i propose
> >> switching our xterm(1) to enable UTF-8 mode by default.
> 
> > Seconded.
>  
> >> The best place to switch is in the setup function VTInitialize_locale()
> >> that decides whether to enable UTF-8 mode and which supporting flags
> >> to set, by pretending to it that CODESET is always UTF-8, but without
> >> interfering with the actual value of the CODESET and without changing
> >> the utility function xtermEnvUTF8().
> 
> > Hmm, maybe you are overthinking this.
> > Other defaults that we set differently from upstream are simply
> > resource changes to XTerm.ad (/usr/X11R6/share/X11/app-defaults/XTerm).
> 
> Heh.  I considered simply changing the resource defaults, but came
> to the wrong conclusion that there wouldn't be a way to achieve the
> desired effect.  Thanks for bringing it up again, that made me
> re-check, and it turns out there *is* a way that is quite
> straightforward, minimally intrusive, very robust, and doesn't get
> in the way of explicit user configuration: See the patch below.
> If this gets OKs, let's forget my previous, more intrusive patch.
> 
> With that change, users can obviously still set *locale to other
> values (for example, "true" or "false" come to mind), and the command
> line options changing *locale (-lc +lc -en) still work.  Looking
> at the code, explicitly setting *utf8 to false (or equivalently,
> +u8 on the command line) also overrides this.
> 
> Spending a day reading xterm source code wasn't wasted, though -
> by reading the documentation only, i wouldn't have understood
> that this way works as intended and is safe.
> 
> OK?
>   Ingo
> 

Ok. 

Thanks for the extra explanations. 

> 
> > 
> > PS:
>  
> >>   printf "\303\237\n"   # thanks to sobrado@ for the striking example
> >> Now your local terminal hangs until you force a reset using the
> >> menus of the xterm program.
> 
> > \237 is 0x9F, equivalent to ESC _, which is APC (Application Program
> > Command).  That appears in a table, but is not explained in the
> > VT220 manual.  The VT420 manual says: "The VT420 ignores all following
> > characters until it receives a SUB, ST, or any other C1 control
> > character."
> 
> Yes.  I spent so much time reading terminal control code documentation
> lately that i probably assumed this to be widely known.  ;-)
> You are right, explaining it is helpful.
> 
> 
> Index: XTerm.ad
> ===
> RCS file: /cvs/xenocara/app/xterm/XTerm.ad,v
> retrieving revision 1.15
> diff -u -p -r1.15 XTerm.ad
> --- XTerm.ad  26 Aug 2013 20:06:10 -  1.15
> +++ XTerm.ad  7 Mar 2016 22:54:44 -
> @@ -259,6 +259,11 @@
>  
>  ! OpenBSD local modifications
>  
> +! Enable UTF-8 mode since OpenBSD does not support any other multibyte
> +! locales.  Even for people using the C/POSIX locale for everything,
> +! that's safer and more usable than the upstream default of "medium".
> +*locale: UTF-8
> +
>  ! ScrollBar by default
>  *scrollBar: true
>  

-- 
Matthieu Herrb


pgp90Bs5BZ5DM.pgp
Description: PGP signature