Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

[Alexandre Ratchov]

On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote:
> > > ok for removing xfree from aucat?
> > > 
> > 
> > yes, ok ratchov; if later this causes me merges i'll find another
> > solution.  Feel free to do the same in usr.bin/sndiod, as it's
> > almost the same.
> > 
> 
> Same thing for sndiod...
> 

ok to replace xfree->free.  But I'd like to keep this constructs:

if (ptr != NULL)
free(ptr);

the reason is that sometimes i add printf()s or additional code
when needed, so i don't want to loose the condition.

pledge telnet

[Theo de Raadt]

I really want to delete telnet entirely, but there are still occasions
when someone might want to use it on an intranet.  Other telnet tools
are probably worse shape.

This adds two pledge calls.

The subshell and skey support are removed (you can use ^Z), and you
cannot start a new telnet session.  Only the first session.  (That is
not handled nicely yet... I'm looking into it).

Index: Makefile
===
RCS file: /cvs/src/usr.bin/telnet/Makefile,v
retrieving revision 1.33
diff -u -p -u -r1.33 Makefile
--- Makefile20 Jul 2014 05:29:39 -  1.33
+++ Makefile13 Nov 2015 08:16:12 -
@@ -32,7 +32,7 @@
 
 PROG=  telnet
 
-CFLAGS+=-DKLUDGELINEMODE -DSKEY
+CFLAGS+=-DKLUDGELINEMODE
 CFLAGS+= -Wall
 LDADD+=-lcurses
 DPADD= ${LIBCURSES}
Index: commands.c
===
RCS file: /cvs/src/usr.bin/telnet/commands.c,v
retrieving revision 1.74
diff -u -p -u -r1.74 commands.c
--- commands.c  26 Oct 2015 00:33:03 -  1.74
+++ commands.c  13 Nov 2015 08:27:43 -
@@ -49,11 +49,6 @@
 #include 
 #include 
 
-#ifdef SKEY
-#include 
-#define PATH_SKEY  "/usr/bin/skey"
-#endif
-
 char   *hostname;
 
 typedef struct {
@@ -64,37 +59,9 @@ typedef struct {
 } Command;
 
 static char line[256];
-static char saveline[256];
 static int margc;
 static char *margv[20];
 
-#ifdef SKEY
-int
-skey_calc(int argc, char **argv)
-{
-   int status;
-
-   if(argc != 3) {
-   printf("usage: %s sequence challenge\n", argv[0]);
-   return 0;
-   }
-
-   switch(fork()) {
-   case 0:
-   execv(PATH_SKEY, argv);
-   exit (1);
-   case -1:
-   err(1, "fork");
-   break;
-   default:
-   (void) wait();
-   if (WIFEXITED(status))
-   return (WEXITSTATUS(status));
-   return (0);
-   }
-}
-#endif
-
 static void
 makeargv(void)
 {
@@ -103,12 +70,6 @@ makeargv(void)
 
 margc = 0;
 cp = line;
-if (*cp == '!') {  /* Special case shell escape */
-   strlcpy(saveline, line, sizeof(saveline)); /* save for shell command */
-   *argp++ = "!";  /* No room in string to get this */
-   margc++;
-   cp++;
-}
 while ((c = *cp)) {
int inquote = 0;
while (isspace((unsigned char)c))
@@ -779,7 +740,6 @@ static struct setlist Setlist[] = {
 #endif
 { "escape","character to escape back to telnet command mode", 0, 
 },
 { "rlogin", "rlogin escape character", 0,  },
-{ "tracefile", "file to write trace information to", SetNetTrace, (cc_t 
*)NetTraceFile},
 { " ", "" },
 { " ", "The following need 'localchars' to be toggled true", 0, 0 },
 { "flushoutput", "character to cause an Abort Output", 0,  },
@@ -1243,52 +1203,6 @@ telnetsuspend(int unused1, char *unused2
 return 1;
 }
 
-int
-shell(int argc, char *argv[])
-{
-long oldrows, oldcols, newrows, newcols, err;
-
-setcommandmode();
-
-err = (TerminalWindowSize(, ) == 0) ? 1 : 0;
-switch(vfork()) {
-case -1:
-   perror("Fork failed\r\n");
-   break;
-
-case 0:
-   {
-   /*
-* Fire up the shell in the child.
-*/
-   char *shellp, *shellname;
-
-   shellp = getenv("SHELL");
-   if (shellp == NULL)
-   shellp = "/bin/sh";
-   if ((shellname = strrchr(shellp, '/')) == 0)
-   shellname = shellp;
-   else
-   shellname++;
-   if (argc > 1)
-   execl(shellp, shellname, "-c", [1], (char *)NULL);
-   else
-   execl(shellp, shellname, (char *)NULL);
-   perror("Execl");
-   _exit(1);
-   }
-default:
-   (void)wait((int *)0);   /* Wait for the shell to complete */
-
-   if (TerminalWindowSize(, ) && connected &&
-   (err || ((oldrows != newrows) || (oldcols != newcols {
-   sendnaws();
-   }
-   break;
-}
-return 1;
-}
-
 static void
 close_connection(void)
 {
@@ -2012,6 +1926,7 @@ tn(int argc, char *argv[])
connected++;
break;
 }
+
 freeaddrinfo(res0);
 if (net < 0) {
return 0;
@@ -2029,6 +1944,7 @@ tn(int argc, char *argv[])
user = NULL;
}
 }
+
 if (user) {
env_define("USER", user);
env_export("USER");
@@ -2056,10 +1972,6 @@ static char
slchelp[] = "change state of special charaters ('slc ?' for more)",
displayhelp[] = "display operating parameters",
zhelp[] =   "suspend telnet",
-#ifdef SKEY
-   skeyhelp[] ="compute response to s/key challenge",
-#endif
-   shellhelp[] =   "invoke a subshell",
envhelp[] = "change environment variables ('environ ?' for more)",
modestring[] = "try to enter line or 

MALLOC_STATS and pledge

[David CARLIER]

Hi all,

I ve tried to discuss this point with Otto Moerbeek but he might be
very busy so I throw the topic here if you do not mind ...

I have the habit to enable MALLOC_STATS but with the recent pledge
feature, it s now difficult to debug some pledged applications with
MALLOC_OPTIONS=D as, for malloc_dump, wpath and rpath are needed ...
and it is fore sure not wishable to enable those in those userland
apps.

Is there a way, somehow, to succeed ? For the moment I ve slighty
modified malloc_dump to only write on stderr and then I redirect the
output myself.

Thanks in advance.

Kind regards.

Re: initial 802.11n implementation

[Stefan Sperling]

On Thu, Nov 12, 2015 at 08:22:07PM +0100, Stefan Sperling wrote:
> This diff adds an initial implementation of 802.11n.

While testing this diff, please pay attention to stuttering
behaviour in audio before and after applying this diff.
If you're hearing audio stutter as a side effect of this diff,
please let me know.

Re: initial 802.11n implementation

[Martin Pieuchot]

On 12/11/15(Thu) 20:22, Stefan Sperling wrote:
> This diff adds an initial implementation of 802.11n.
> 
> [...]

Looks good.  I think you should already put in the chunks below.
Especially the one needed for ifconfig(8).

I think I found a typo...

> Index: net/if_media.h
> ===
> RCS file: /cvs/src/sys/net/if_media.h,v
> retrieving revision 1.34
> diff -u -p -r1.34 if_media.h
> --- net/if_media.h11 Sep 2015 13:02:28 -  1.34
> +++ net/if_media.h12 Nov 2015 15:33:07 -

ok mpi@

> Index: net80211/ieee80211.h
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211.h,v
> retrieving revision 1.53
> diff -u -p -r1.53 ieee80211.h
> --- net80211/ieee80211.h  10 Oct 2015 07:51:47 -  1.53
> +++ net80211/ieee80211.h  12 Nov 2015 15:33:07 -

ok mpi@

> Index: net80211/ieee80211_amrr.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_amrr.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 ieee80211_amrr.c
> --- net80211/ieee80211_amrr.c 23 Dec 2014 03:24:08 -  1.8
> +++ net80211/ieee80211_amrr.c 12 Nov 2015 15:33:07 -

This is ok and could go with the "struct ieee80211_node" growth.

I like how you explain your design choice for adding MCS support
and it would be nice to have that in the commit message.

>  void
>  ieee80211_amrr_node_init(const struct ieee80211_amrr *amrr,
> Index: net80211/ieee80211_crypto_ccmp.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_crypto_ccmp.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 ieee80211_crypto_ccmp.c
> --- net80211/ieee80211_crypto_ccmp.c  15 Jul 2015 22:16:42 -  1.16
> +++ net80211/ieee80211_crypto_ccmp.c  12 Nov 2015 15:33:07 -
> @@ -88,17 +88,18 @@ ieee80211_ccmp_phase1(rijndael_ctx *ctx,
>   /* construct AAD (additional authenticated data) */
>   aad = [2]; /* skip l(a), will be filled later */
>   *aad = wh->i_fc[0];
> - /* 11w: conditionnally mask subtype field */
> + /* 11w: conditionally mask subtype field */
>   if ((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) ==
>   IEEE80211_FC0_TYPE_DATA)
> - *aad &= ~IEEE80211_FC0_SUBTYPE_MASK;
> + *aad &= ~IEEE80211_FC0_SUBTYPE_MASK |
> +IEEE80211_FC0_SUBTYPE_QOS;

I believe this can go already with an explanation of the fix, right?

>   aad++;
>   /* protected bit is already set in wh */
>   *aad = wh->i_fc[1];
>   *aad &= ~(IEEE80211_FC1_RETRY | IEEE80211_FC1_PWR_MGT |
>   IEEE80211_FC1_MORE_DATA);
> - /* 11n: conditionnally mask order bit */
> - if (ieee80211_has_htc(wh))
> + /* 11n: conditionally mask order bit */
> + if (ieee80211_has_qos(wh))
>   *aad &= ~IEEE80211_FC1_ORDER;
>   aad++;
>   IEEE80211_ADDR_COPY(aad, wh->i_addr1); aad += IEEE80211_ADDR_LEN;
> @@ -112,6 +113,10 @@ ieee80211_ccmp_phase1(rijndael_ctx *ctx,
>   aad += IEEE80211_ADDR_LEN;
>   }
>   if (ieee80211_has_qos(wh)) {
> + /* 
> +  * XXX 802.11-2012 11.4.3.3.3 g says the A-MSDU present bit
> +  * should be set here if both STAs are SPP A-MSDU capable.
> +  */

It's not clear to me why you left an XXX if you use "should".

>   *aad++ = tid = ieee80211_get_qos(wh) & IEEE80211_QOS_TID;
>   *aad++ = 0;
>   }
> Index: net80211/ieee80211_ioctl.h
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.h,v
> retrieving revision 1.21
> diff -u -p -r1.21 ieee80211_ioctl.h
> --- net80211/ieee80211_ioctl.h9 Jan 2015 20:34:21 -   1.21
> +++ net80211/ieee80211_ioctl.h12 Nov 2015 15:33:07 -

ok mpi@

> Index: net80211/ieee80211_node.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 ieee80211_node.c
> --- net80211/ieee80211_node.c 4 Nov 2015 12:12:00 -   1.89
> +++ net80211/ieee80211_node.c 12 Nov 2015 15:33:07 -

That could also go with the structure growth.

> Index: net80211/ieee80211_node.h
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_node.h,v
> retrieving revision 1.47
> diff -u -p -r1.47 ieee80211_node.h
> --- net80211/ieee80211_node.h 4 Nov 2015 12:12:00 -   1.47
> +++ net80211/ieee80211_node.h 12 Nov 2015 15:33:07 -
> @@ -112,8 +112,8 @@ struct ieee80211_tx_ba {
>   struct ieee80211_node   *ba_ni; /* backpointer for callbacks */
>   struct timeout  ba_to;
>   int ba_timeout_val;
> -#define IEEE80211_BA_MIN_TIMEOUT (10 * 1000) /* 10msec */
> -#define IEEE80211_BA_MAX_TIMEOUT  

Re: Driver for Attansic Technology E2200.

[Guillermo Bernaldo de Quiros Maraver]

Hi Martin, good afternoon.

First of all, I want to thank your reply with the comments about the device
driver. I answer you email next to you comments.

2015-11-09 11:30 GMT+01:00 Martin Pieuchot :

> Hello Guillermo,
>
> On 08/11/15(Sun) 17:06, Guillermo Bernaldo de Quiros Maraver wrote:
> > Hi, good afternoon.
> >
> > I don't know if this is the correct list to post the next email so, I'm
> > sorry if this isn't the correct place.
> >
> > My laptop computer wich is an MSI GE70 2QE has a network interface which
> > currently it seems to be not supported by -current so I tried to port the
> > device driver to OpenBSD based on the driver from FreeBSD which is
> similar
> > and now the network interface is working correctly. Next I paste some
> > information about the hardware and the device driver:
> >
> > 1º Dmesg:
> > alc0 at pci4 dev 0 function 0 "Attansic Technology E2200" rev 0x13: msi,
> > address d8:cb:8a:84:db:cc
> > atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 9
> >
> > 2º Output of ifconfig alc0
> >  alc0: flags=8843 mtu 1500
> > lladdr d8:cb:8a:84:db:cc
> > priority: 0
> > groups: egress
> > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
> > status: active
> > inet 192.168.1.7 netmask 0xff00 broadcast 192.168.1.255
> > 3º full dmesg in the attachment
> > 4º cvs diff if_alc.c and cvs diff in the attachments.
> >
> > I don't know if you're interested to apply the diff's into base but I
> think
> > that could be a good idea.
>
> Some comments inline.
>
> > alc0: could not disable Rx/Tx MAC(0x40009e00)!
>
> Did you investigate what does that mean?
>
No, I didn't because I hadn't enough time to investigate this problem but
I'll investigate as soon as I have free time.

>
> > Index: if_alc.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_alc.c,v
> > retrieving revision 1.35
> > diff -u -p -r1.35 if_alc.c
> > --- if_alc.c  25 Oct 2015 13:04:28 -  1.35
> > +++ if_alc.c  8 Nov 2015 16:02:09 -
> > @@ -120,7 +120,8 @@ const struct pci_matchid alc_devices[] =
> >   { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L1D },
> >   { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L1D_1 },
> >   { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L2C_1 },
> > - { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L2C_2 }
> > + { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L2C_2 },
> > + { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_E2200 }
> >  };
> >
> >  struct cfattach alc_ca = {
> > @@ -525,6 +526,7 @@ alc_phy_down(struct alc_softc *sc)
> >   switch (sc->sc_product) {
> >   case PCI_PRODUCT_ATTANSIC_L1D:
> >   case PCI_PRODUCT_ATTANSIC_L1D_1:
> > + case PCI_PRODUCT_ATTANSIC_E2200:
> >   /*
> >* GPHY power down caused more problems on AR8151 v2.0.
> >* When driver is reloaded after GPHY power down,
> > @@ -783,10 +785,14 @@ alc_attach(struct device *parent, struct
> >   case PCI_PRODUCT_ATTANSIC_L1D_1:
> >   sc->alc_flags |= ALC_FLAG_APS;
> >   /* FALLTHROUGH */
> > + case PCI_PRODUCT_ATTANSIC_E2200:
> > + sc->alc_flags |= ALC_FLAG_AR816X_FAMILY;
> > + break;
> >   default:
> >   break;
> >   }
> > - sc->alc_flags |= ALC_FLAG_ASPM_MON | ALC_FLAG_JUMBO;
> > + //sc->alc_flags |= ALC_FLAG_ASPM_MON | ALC_FLAG_JUMBO;
> > + sc->alc_flags |= ALC_FLAG_JUMBO;
>
> Why did you change this flag?  This cannot be committed as-is if this is
> really needed then you could add a conditional statement based on the
> product ID.
>
Sorry I changed this flag because in the FreeBSD device driver this flag
doesn't seems to exist. I'll fix this maybe tomorrow morning.

>
>
> > @@ -797,6 +803,7 @@ alc_attach(struct device *parent, struct
> >   case PCI_PRODUCT_ATTANSIC_L1D_1:
> >   case PCI_PRODUCT_ATTANSIC_L2C_1:
> >   case PCI_PRODUCT_ATTANSIC_L2C_2:
> > + case PCI_PRODUCT_ATTANSIC_E2200:
> >   sc->alc_max_framelen = 6 * 1024;
> >   break;
> >   }
> > @@ -2035,7 +2042,9 @@ alc_reset(struct alc_softc *sc)
> >   printf("%s: master reset timeout!\n", sc->sc_dev.dv_xname);
> >
> >   for (i = ALC_RESET_TIMEOUT; i > 0; i--) {
> > - if ((reg = CSR_READ_4(sc, ALC_IDLE_STATUS)) == 0)
> > + reg = CSR_READ_4(sc,ALC_IDLE_STATUS);
> > + if ((reg & (IDLE_STATUS_RXMAC | IDLE_STATUS_TXMAC |
> > + IDLE_STATUS_RXQ | IDLE_STATUS_TXQ)) == 0)
>
> Isn't this related to the message in your dmesg?
>
Maybe, I just tried to write the same code as the FreeBSD device driver
source code. But in fact, if you omit this code, the network doesn't works.

>
> >   break;
> >   DELAY(10);
> >   }
> > @@ -2485,6 +2494,7 @@ alc_stop_queue(struct alc_softc *sc)
> >   reg &= ~TXQ_CFG_ENB;
> >   

Re: httpd URL rewrite support patch

[Stanislaw Adaszewski]

Excuse me, the indentation was removed because message wasn't plain text.

Patch: http://pastebin.com/XnZLEPEk

httpd.conf: http://pastebin.com/gGp3NqCD

rewr.php: http://pastebin.com/prA1NJXC

Re: telnet: Delete tracefile command.

[Ingo Schwarze]

Hi Theo,

> CVSROOT:  /cvs
> Module name:  src
> Changes by:   dera...@cvs.openbsd.org 2015/11/13 09:53:46
> 
> Modified files:
>   usr.bin/telnet : commands.c telnet.1 
> 
> Log message:
> Delete tracefile command.  Tracefiles can now only be specified at
> program startup.  Who uses that?  Noone...
> ok millert

Heh, you will probably be able to use that to get rid of "wpath"
near the end of main()!

I saw no "wpath" operation except the fopen() in SetNetTrace(),
and once you get rid of the nasty call path

  close_connection() -> tninit() -> init_network() -> SetNetTrace()

then SetNetTrace() will only be called from the tninit() at the
top of main() and from the getopt() loop in main().

Yours,
  Ingo

Re: pledge telnet

[Theo de Raadt]

> > I really want to delete telnet entirely,
> 
> I often use it for testing unencrypted SMTP and HTTP across the
> Internet.  Which tool would you recommend for that purpose?

nc(1).

> You might wish to cross-check these three points though:
> 
>  * Does "inet" actually allow the following setsockopt()
>arguments: SO_DEBUG, SO_RTABLE, IP_TOS, IPV6_TCLASS?
>I know nothing about socket options.

I think all of those should be deleted, except perhaps SO_RTABLE,
which should be done line in nc(1).

>  * Does ioctl(TIOCGWINSZ) in TerminalWindowSize(), sys_bsd.c
>require "ioctl"?  The pledge(2) manual seems to say so.

"tty"

>  * Do getpwnam() and getpwuid() in tn(), commands.c
>require "getpw"?  The pledge(2) manual seems to say so,
>or is "rpath" sufficient here and YP irrelevant?

Adding "getpw" at the initial pledge; the later one is main
loop and never needs it again.

Few other changes coming on top of that.

Re: pledge telnet

[Ingo Schwarze]

Hi Theo,

Theo de Raadt wrote on Fri, Nov 13, 2015 at 01:36:23AM -0700:

> I really want to delete telnet entirely,

I often use it for testing unencrypted SMTP and HTTP across the
Internet.  Which tool would you recommend for that purpose?

> but there are still occasions when someone might want to use it
> on an intranet.  Other telnet tools are probably worse shape.
> 
> This adds two pledge calls.

I made the mistake of looking through the code.
That thing is big!

It is easy to miss stuff in a large program, but from what i saw,
your pledge looks good to me.

You might wish to cross-check these three points though:

 * Does "inet" actually allow the following setsockopt()
   arguments: SO_DEBUG, SO_RTABLE, IP_TOS, IPV6_TCLASS?
   I know nothing about socket options.
 * Does ioctl(TIOCGWINSZ) in TerminalWindowSize(), sys_bsd.c
   require "ioctl"?  The pledge(2) manual seems to say so.
 * Do getpwnam() and getpwuid() in tn(), commands.c
   require "getpw"?  The pledge(2) manual seems to say so,
   or is "rpath" sufficient here and YP irrelevant?

> The subshell and skey support are removed (you can use ^Z),
> and you cannot start a new telnet session.
> Only the first session.

No objection, but my OK probably doesn't mean much for that.

Yours,
  Ingo


> (That is not handled nicely yet... I'm looking into it).
[...]

Re: pledge telnet

[Stuart Henderson]

On 2015/11/13 09:59, Theo de Raadt wrote:
> > > I really want to delete telnet entirely,
> > 
> > I often use it for testing unencrypted SMTP and HTTP across the
> > Internet.  Which tool would you recommend for that purpose?
> 
> nc(1).

I use telnet fairly often for connecting to things like crappy switches,
crappy routers, APs of varying crappiness, etc. nc -t isn't close to being
good enough for this, also with nc it's difficult to send things like ^C
(even worse, if you use it much you forget about this and end up killing
your connection). I wouldn't mind having it removed from base, but would
need to go in ports unless nc gets a lot of polishing.

> > You might wish to cross-check these three points though:
> > 
> >  * Does "inet" actually allow the following setsockopt()
> >arguments: SO_DEBUG, SO_RTABLE, IP_TOS, IPV6_TCLASS?
> >I know nothing about socket options.
> 
> I think all of those should be deleted, except perhaps SO_RTABLE,
> which should be done line in nc(1).

TOS/TCLASS are somewhat important, nc and ssh in client mode also
use them. IP_TOS is permitted by "inet". IPV6_TCLASS was missed but
should be added, it's the IPv6 equivalent to IP_TOS.

Index: kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.106
diff -u -p -r1.106 kern_pledge.c
--- kern_pledge.c   10 Nov 2015 04:30:59 -  1.106
+++ kern_pledge.c   13 Nov 2015 17:11:20 -
@@ -1275,6 +1275,7 @@ pledge_sockopt(struct proc *p, int set, 
break;
case IPPROTO_IPV6:
switch (optname) {
+   case IPV6_TCLASS:
case IPV6_UNICAST_HOPS:
case IPV6_RECVHOPLIMIT:
case IPV6_PORTRANGE:

httpd URL rewrite support patch

[Stanislaw Adaszewski]

Hello everyone,

I'm new to OpenBSD and the tech@ list.

I need to run a WordPress-like URL rewriting scheme for my blog. Basically
URLs of the form /long-fancy-blog-post-title/ to be translated to
/index.php?q=long-fancy-blog-post-title.

I couldn't find this function in OpenBSD's new httpd which otherwise seems
like a great piece of s/w.

I spotted however the "block return code return_uri" directive  which
corresponds almost perfectly to my needs. I concluded that extending it to
support code 200 which would signify an internal HTTP redirection is
logical, as the original request is still _blocked_.

The patch attached contains the necessary changes, whereas the httpd.conf
and rewr.php illustrate how the functionality is used.

Could I please ask the person responsible for httpd to integrate my patch
or something with equivalent functionality?

Thank you for your time.

Best regards,

Stanislaw Adaszewski

? httpd
? httpd_url_rewrite.patch
? parse.c
? y.tab.h
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.73
diff -u -p -u -r1.73 parse.y
--- parse.y 19 Jul 2015 05:17:27 - 1.73
+++ parse.y 13 Nov 2015 08:29:10 -
@@ -907,7 +907,7 @@ filter : block RETURN NUMBER optstring

  if ($4 != NULL) {
  /* Only for 3xx redirection headers */
- if ($3 < 300 || $3 > 399) {
+ if ($3 != 200 && ($3 < 300 || $3 > 399)) {
  yyerror("invalid return code for "
 "location URI");
  free($4);
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.96
diff -u -p -u -r1.96 server_http.c
--- server_http.c 31 Jul 2015 00:10:51 - 1.96
+++ server_http.c 13 Nov 2015 08:29:10 -
@@ -1054,6 +1054,7 @@ server_response(struct httpd *httpd, str
  int portval = -1, ret;
  char *hostval;
  const char *errstr = NULL;
+ char buf[IBUF_READ_SIZE];

  /* Canonicalize the request path */
  if (desc->http_path == NULL ||
@@ -1154,11 +1155,44 @@ server_response(struct httpd *httpd, str
  resp->http_method = desc->http_method;
  if ((resp->http_version = strdup(desc->http_version)) == NULL)
  goto fail;
+
+#ifdef DEBUG
+ DPRINTF("%s: http_path: %s, http_path_alias: %s\n", __func__,
desc->http_path, desc->http_path_alias);
+#endif

  /* Now search for the location */
  srv_conf = server_getlocation(clt, desc->http_path);

- if (srv_conf->flags & SRVFLAG_BLOCK) {
+
+ if ((srv_conf->flags & SRVFLAG_BLOCK) && srv_conf->return_code == 200) {
+#ifdef DEBUG
+ DPRINTF("%s: Rewrite from: %s to %s\n", __func__, desc->http_path,
srv_conf->return_uri);
+#endif
+ if (desc->http_path != NULL) {
+ free(desc->http_path);
+ desc->http_path = NULL;
+ }
+ if (server_expand_http(clt, srv_conf->return_uri, buf, sizeof(buf)) ==
NULL) {
+ server_abort_http(clt, 500, strerror(errno));
+ return (-1);
+ }
+ desc->http_path = strdup(buf);
+ if (desc->http_path == NULL) {
+ server_abort_http(clt, 500, strerror(errno));
+ }
+ desc->http_query = strchr(desc->http_path, '?');
+ if (desc->http_query != NULL) {
+ *desc->http_query++ = '\0';
+ desc->http_query = strdup(desc->http_query);
+ if (desc->http_query == NULL) {
+ server_abort_http(clt, 500, strerror(errno));
+ }
+ }
+ srv_conf = server_getlocation(clt, desc->http_path); // again
+ }
+
+
+ if ((srv_conf->flags & SRVFLAG_BLOCK) && srv_conf->return_code != 200) {
  server_abort_http(clt, srv_conf->return_code,
 srv_conf->return_uri);
  return (-1);


server "default" {
listen on * port 80
root "/htdocs/sadaszew/algoholic"

location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}

location match "^/([%l%u%d%-]+)/$" {
block return 200 "/rewr.php?q=%1"
}
}

Re: em(4) watchdog timeouts

[Sonic]

On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best  wrote:
> I've done some further testing and I think I've narrowed it down to the
> "Unlocking em(4) a bit further"-patch [0].

That was the start of it for me.

When I could revert to rev 1.305 for if_em.c and rev 1.57 for if_em.h
all was fine. But the kernel no longer builds with if_em.c rev 1.305
due to:
cc1: warnings being treated as errors
../../../../dev/pci/if_em.c: In function 'em_ioctl':
../../../../dev/pci/if_em.c:674: warning: implicit declaration of function
'arp_ifinit'
*** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:937
'if_em.o')

I'm wondering if the patch that moved if_em.c from rev 1.308 to rev
1.309 could be applied to rev 1.305 and if that would the kernel to
build and work?

These timeouts are killing me.
Nov 13 08:21:11 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:47:36 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:47:36 stargate unbound: [22477:0] notice: sendto failed: No
buffer space available
Nov 13 09:47:36 stargate unbound: [22477:0] notice: remote address is
172.27.12.66 port 34281
Nov 13 09:47:36 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 34281
Nov 13 09:47:37 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:49:42 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:51:55 stargate unbound: [22477:0] notice: sendto failed: No
buffer space available
Nov 13 09:51:55 stargate unbound: [22477:0] notice: remote address is
172.27.12.66 port 57280
Nov 13 09:52:00 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:53:18 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:54:32 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:54:32 stargate unbound: [22477:0] notice: sendto failed: No
buffer space available
Nov 13 09:54:32 stargate unbound: [22477:0] notice: remote address is
172.27.12.66 port 57438
Nov 13 09:54:32 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 57438
Nov 13 09:54:35 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:55:54 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:58:08 stargate last message repeated 2 times
Nov 13 09:58:53 stargate /bsd: em1: watchdog timeout -- resetting
Nov 13 09:59:05 stargate ftp-proxy[18455]: #1 client command too long
or not clean
Nov 13 09:59:09 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:59:09 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 22970
Nov 13 09:59:09 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:59:09 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 60307
Nov 13 09:59:11 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:59:11 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 41198
Nov 13 09:59:11 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 10:01:15 stargate /bsd: em0: watchdog timeout -- resetting

Chris

Re: pledge("stdio") for arch(1)/machine(1)

[Theo de Raadt]

> This straightforward pledge("stdio") is one of the last uncommitted ones
> from Theo's big 'tame in userland' diff and seems to have been
> overlooked so far.

I think arch.c gains no value from being pledged.  It adds a system
call to a program which makes no user-input decisions.

Re: pledge telnet

[Todd C. Miller]

On Fri, 13 Nov 2015 17:52:21 +0100, Ingo Schwarze wrote:

> I often use it for testing unencrypted SMTP and HTTP across the
> Internet.  Which tool would you recommend for that purpose?

nc

 - todd

Re: pledge("stdio") for arch(1)/machine(1)

[Ingo Schwarze]

Hi,

Theo de Raadt wrote on Fri, Nov 13, 2015 at 08:21:41AM -0700:
> Theo Buehler wrote:

>> This straightforward pledge("stdio") is one of the last uncommitted ones
>> from Theo's big 'tame in userland' diff and seems to have been
>> overlooked so far.

> I think arch.c gains no value from being pledged.  It adds a system
> call to a program which makes no user-input decisions.

Except for setlocale(LC_ALL, "");
but why the hell does it call that?

Tholo@ added that shortly after Caesar was murdered, but the commit
message doesn't explain why.

OK?
  Ingo


Index: arch.c
===
RCS file: /cvs/src/usr.bin/arch/arch.c,v
retrieving revision 1.16
diff -u -p -r1.16 arch.c
--- arch.c  25 Sep 2015 16:19:26 -  1.16
+++ arch.c  13 Nov 2015 18:38:08 -
@@ -25,7 +25,6 @@
 
 #include  /* MACHINE MACHINE_ARCH */
 
-#include 
 #include 
 #include 
 #include 
@@ -41,8 +40,6 @@ main(int argc, char *argv[])
extern char *__progname;
int short_form = 0, c;
char *arch, *opts;
-
-   setlocale(LC_ALL, "");
 
machine = strcmp(__progname, "machine") == 0;
if (machine) {

pledge route(8) with '-n' flag

[Ricardo Mestre]

Hello,

If '-n' argument is used on route(8) then nflag will be active and dns 
transactions won't be needed, am I correct?

Index: route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.179
diff -u -p -u -r1.179 route.c
--- route.c 25 Oct 2015 09:37:08 -  1.179
+++ route.c 13 Nov 2015 15:37:37 -
@@ -227,7 +227,7 @@ main(int argc, char **argv)
}

if (nflag) {
-   if (pledge("stdio rpath dns", NULL) == -1)
+   if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
} else {
if (pledge("stdio rpath dns", NULL) == -1)
@@ -330,7 +330,7 @@ flushroutes(int argc, char **argv)
}
 
if (nflag) {
-   if (pledge("stdio rpath dns", NULL) == -1)
+   if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
} else {
if (pledge("stdio rpath dns", NULL) == -1)
Index: show.c
===
RCS file: /cvs/src/sbin/route/show.c,v
retrieving revision 1.102
diff -u -p -u -r1.102 show.c
--- show.c  23 Oct 2015 15:03:25 -  1.102
+++ show.c  13 Nov 2015 15:37:37 -
@@ -146,7 +146,7 @@ p_rttables(int af, u_int tableid, int ha
}
 
if (nflag) {
-   if (pledge("stdio rpath dns", NULL) == -1)
+   if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
} else {
if (pledge("stdio rpath dns", NULL) == -1)

Best regards,
Ricardo Mestre

Re: pledge telnet

[Theo de Raadt]

> > > > I really want to delete telnet entirely,
> > > 
> > > I often use it for testing unencrypted SMTP and HTTP across the
> > > Internet.  Which tool would you recommend for that purpose?
> > 
> > nc(1).
> 
> I use telnet fairly often for connecting to things like crappy switches,
> crappy routers, APs of varying crappiness, etc. nc -t isn't close to being
> good enough for this, also with nc it's difficult to send things like ^C
> (even worse, if you use it much you forget about this and end up killing
> your connection). I wouldn't mind having it removed from base, but would
> need to go in ports unless nc gets a lot of polishing.

This conversation is going far too meta.

I am not deleting telnet.  That is why I am going through the effort
of shrinking it, and then pledging it.

pledge is even more relevant when dealing with bowls of unmaintained
spaghetti.

> > > You might wish to cross-check these three points though:
> > > 
> > >  * Does "inet" actually allow the following setsockopt()
> > >arguments: SO_DEBUG, SO_RTABLE, IP_TOS, IPV6_TCLASS?
> > >I know nothing about socket options.
> > 
> > I think all of those should be deleted, except perhaps SO_RTABLE,
> > which should be done line in nc(1).
> 
> TOS/TCLASS are somewhat important, nc and ssh in client mode also
> use them. IP_TOS is permitted by "inet". IPV6_TCLASS was missed but
> should be added, it's the IPv6 equivalent to IP_TOS.
> 
> Index: kern_pledge.c
> ===
> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
> retrieving revision 1.106
> diff -u -p -r1.106 kern_pledge.c
> --- kern_pledge.c 10 Nov 2015 04:30:59 -  1.106
> +++ kern_pledge.c 13 Nov 2015 17:11:20 -
> @@ -1275,6 +1275,7 @@ pledge_sockopt(struct proc *p, int set, 
>   break;
>   case IPPROTO_IPV6:
>   switch (optname) {
> + case IPV6_TCLASS:
>   case IPV6_UNICAST_HOPS:
>   case IPV6_RECVHOPLIMIT:
>   case IPV6_PORTRANGE:

Yes, I decided they should stay.  Commited the same diff 1 minute ago
already.

Re: pledge telnet

[Alexey Suslikov]

On Fri, Nov 13, 2015 at 8:40 PM, Theo de Raadt  wrote:
>> > On 2015/11/13 09:59, Theo de Raadt wrote:
>> > > > > I really want to delete telnet entirely,
>> > > >
>> > > > I often use it for testing unencrypted SMTP and HTTP across the
>> > > > Internet.  Which tool would you recommend for that purpose?
>> > >
>> > > nc(1).
>> > I use telnet fairly often for connecting to things like crappy switches,
>> > crappy routers, APs of varying crappiness, etc. nc -t isn't close to being
>> > good enough for this, also with nc it's difficult to send things like ^C
>> > (even worse, if you use it much you forget about this and end up killing
>> > your connection). I wouldn't mind having it removed from base, but would
>> > need to go in ports unless nc gets a lot of polishing.
>>
>> I always thought of telnet as a kind of discipline over the wire. There are
>> even extensions (like RFC 2217) well-fitting discipline model.
>
> Like a horse buggy in the inside lane of a 4-lane highway, there are going
> to fatalities.
>
> "discipline" applies to the user of this code -- it means "avoid any and all
> unnecessary use".
>
>> >From other hand, nc(1) is a "raw" tool with decent client-server model.
>>
>> Is there any possibility to run nc(1) as a privsep server, and a telnet(1) as
>> a client, talking to nc(1) server via IMSG (instead of doing network stuff
>> directly)?
>
> What's the goal.  To continue the lifetime of telne?  To make the nc code
> more complicated and fragile?  Those are the only outcomes I see.

It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO.

The goal is to delete classic telnet entirely and make it an
(optional) discipline
frontend for nc(1). In "telnet mode" nc(1) will only attach discipline
and let user
use flow control features (like ^C).

It is not about extending a lifetime of telnet, it is about making telnet truly
optional by making it a discipline (or flow control protocol), not a separate
tool.

Re: pledge route(8) with '-n' flag

[Sebastian Benoit]

Ricardo Mestre(ser...@helheim.mooo.com) on 2015.11.13 18:00:11 +:
> Hello,
> 
> If '-n' argument is used on route(8) then nflag will be active and dns
> transactions won't be needed, am I correct?

please find out yourself.

at least the pledge call in monitor will fail with -n and your diff,
so some more work is required.

> Index: route.c
> ===
> RCS file: /cvs/src/sbin/route/route.c,v
> retrieving revision 1.179
> diff -u -p -u -r1.179 route.c
> --- route.c   25 Oct 2015 09:37:08 -  1.179
> +++ route.c   13 Nov 2015 15:37:37 -
> @@ -227,7 +227,7 @@ main(int argc, char **argv)
>   }
>   
>   if (nflag) {
> - if (pledge("stdio rpath dns", NULL) == -1)
> + if (pledge("stdio rpath", NULL) == -1)
>   err(1, "pledge");
>   } else {
>   if (pledge("stdio rpath dns", NULL) == -1)
> @@ -330,7 +330,7 @@ flushroutes(int argc, char **argv)
>   }
>  
>   if (nflag) {
> - if (pledge("stdio rpath dns", NULL) == -1)
> + if (pledge("stdio rpath", NULL) == -1)
>   err(1, "pledge");
>   } else {
>   if (pledge("stdio rpath dns", NULL) == -1)
> Index: show.c
> ===
> RCS file: /cvs/src/sbin/route/show.c,v
> retrieving revision 1.102
> diff -u -p -u -r1.102 show.c
> --- show.c23 Oct 2015 15:03:25 -  1.102
> +++ show.c13 Nov 2015 15:37:37 -
> @@ -146,7 +146,7 @@ p_rttables(int af, u_int tableid, int ha
>   }
>  
>   if (nflag) {
> - if (pledge("stdio rpath dns", NULL) == -1)
> + if (pledge("stdio rpath", NULL) == -1)
>   err(1, "pledge");
>   } else {
>   if (pledge("stdio rpath dns", NULL) == -1)
> 
> Best regards,
> Ricardo Mestre
> 

-- 

Re: pledge telnet

[Alexey Suslikov]

On Fri, Nov 13, 2015 at 9:00 PM, Theo de Raadt  wrote:
>> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO.
>
> No, it is similar to  over the INTERNET, because the INTERNET
> is nothing at all like a serial line, the later generally being nicely
> contained to a single room.
>
>> The goal is to delete classic telnet entirely and make it an
>> (optional) discipline frontend for nc(1). In "telnet mode" nc(1)
>> will only attach discipline and let user  use flow control features (like 
>> ^C).
>
> You have a diff?
>
>> It is not about extending a lifetime of telnet, it is about making telnet 
>> truly
>> optional by making it a discipline (or flow control protocol), not a separate
>> tool.
>
> If you can do it without adding *any complexity* to nc, fine.
>
> Except I know you can't do that, it will add substantial complexity.
> So this seems like a pointless discussion.  nc is already more than
> complex enough.  Probably best to focus on making it more secure,
> before making it support the stone age.

Can telnet be extended to coexist with nc -F? Manual only mentions ssh.

Re: pledge telnet

[Alexey Suslikov]

Stuart Henderson wrote:

> On 2015/11/13 09:59, Theo de Raadt wrote:
> > > > I really want to delete telnet entirely,
> > >
> > > I often use it for testing unencrypted SMTP and HTTP across the
> > > Internet.  Which tool would you recommend for that purpose?
> >
> > nc(1).
> I use telnet fairly often for connecting to things like crappy switches,
> crappy routers, APs of varying crappiness, etc. nc -t isn't close to being
> good enough for this, also with nc it's difficult to send things like ^C
> (even worse, if you use it much you forget about this and end up killing
> your connection). I wouldn't mind having it removed from base, but would
> need to go in ports unless nc gets a lot of polishing.

I always thought of telnet as a kind of discipline over the wire. There are
even extensions (like RFC 2217) well-fitting discipline model.

>From other hand, nc(1) is a "raw" tool with decent client-server model.

Is there any possibility to run nc(1) as a privsep server, and a telnet(1) as
a client, talking to nc(1) server via IMSG (instead of doing network stuff
directly)?

Re: pledge telnet

[Theo de Raadt]

> > On 2015/11/13 09:59, Theo de Raadt wrote:
> > > > > I really want to delete telnet entirely,
> > > >
> > > > I often use it for testing unencrypted SMTP and HTTP across the
> > > > Internet.  Which tool would you recommend for that purpose?
> > >
> > > nc(1).
> > I use telnet fairly often for connecting to things like crappy switches,
> > crappy routers, APs of varying crappiness, etc. nc -t isn't close to being
> > good enough for this, also with nc it's difficult to send things like ^C
> > (even worse, if you use it much you forget about this and end up killing
> > your connection). I wouldn't mind having it removed from base, but would
> > need to go in ports unless nc gets a lot of polishing.
> 
> I always thought of telnet as a kind of discipline over the wire. There are
> even extensions (like RFC 2217) well-fitting discipline model.

Like a horse buggy in the inside lane of a 4-lane highway, there are going
to fatalities.

"discipline" applies to the user of this code -- it means "avoid any and all
unnecessary use".

> >From other hand, nc(1) is a "raw" tool with decent client-server model.
> 
> Is there any possibility to run nc(1) as a privsep server, and a telnet(1) as
> a client, talking to nc(1) server via IMSG (instead of doing network stuff
> directly)?

What's the goal.  To continue the lifetime of telne?  To make the nc code
more complicated and fragile?  Those are the only outcomes I see.

Re: MALLOC_STATS and pledge

[Ted Unangst]

David CARLIER wrote:
> Hi all,
> 
> I ve tried to discuss this point with Otto Moerbeek but he might be
> very busy so I throw the topic here if you do not mind ...
> 
> I have the habit to enable MALLOC_STATS but with the recent pledge
> feature, it s now difficult to debug some pledged applications with
> MALLOC_OPTIONS=D as, for malloc_dump, wpath and rpath are needed ...
> and it is fore sure not wishable to enable those in those userland
> apps.
> 
> Is there a way, somehow, to succeed ? For the moment I ve slighty
> modified malloc_dump to only write on stderr and then I redirect the
> output myself.

I would say the simplest is to disable the pledge() call in the program while
debugging.

Re: pledge("stdio") for arch(1)/machine(1)

[Ted Unangst]

Ingo Schwarze wrote:
> Hi,
> 
> Theo de Raadt wrote on Fri, Nov 13, 2015 at 08:21:41AM -0700:
> > Theo Buehler wrote:
> 
> >> This straightforward pledge("stdio") is one of the last uncommitted ones
> >> from Theo's big 'tame in userland' diff and seems to have been
> >> overlooked so far.
> 
> > I think arch.c gains no value from being pledged.  It adds a system
> > call to a program which makes no user-input decisions.
> 
> Except for setlocale(LC_ALL, "");
> but why the hell does it call that?
> 
> Tholo@ added that shortly after Caesar was murdered, but the commit
> message doesn't explain why.

maybe "machine" is spelled differently in your language? ha! setlocale()
everywhere seems to have been the style in a certain era, in preparation for a
glorious future where it would do something.

Re: pledge telnet

[Theo de Raadt]

> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO.

No, it is similar to  over the INTERNET, because the INTERNET
is nothing at all like a serial line, the later generally being nicely
contained to a single room.

> The goal is to delete classic telnet entirely and make it an
> (optional) discipline frontend for nc(1). In "telnet mode" nc(1)
> will only attach discipline and let user  use flow control features (like ^C).

You have a diff?

> It is not about extending a lifetime of telnet, it is about making telnet 
> truly
> optional by making it a discipline (or flow control protocol), not a separate
> tool.

If you can do it without adding *any complexity* to nc, fine.

Except I know you can't do that, it will add substantial complexity.
So this seems like a pointless discussion.  nc is already more than
complex enough.  Probably best to focus on making it more secure,
before making it support the stone age.

Re: pledge telnet

[Theo de Raadt]

> Can telnet be extended to coexist with nc -F? Manual only mentions ssh.

Please don't email while driving your horse buggy.

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

[Michael McConville]

Alexandre Ratchov wrote:
> On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote:
> > > > ok for removing xfree from aucat?
> > > 
> > > yes, ok ratchov; if later this causes me merges i'll find another
> > > solution.  Feel free to do the same in usr.bin/sndiod, as it's
> > > almost the same.
> > 
> > Same thing for sndiod...
> 
> ok to replace xfree->free.  But I'd like to keep this constructs:
> 
>   if (ptr != NULL)
>   free(ptr);
> 
> the reason is that sometimes i add printf()s or additional code when
> needed, so i don't want to loose the condition.

Its long been protocol to remove this wherever we find it. POSIX
specifies that free() is NULL-safe, and removing the conditions can
greatly improve readability. IMO, this is another instance where a macro
and (Coccinelle|cscope|sed|awk) is your best bet.

Re: sdhc(4) on APU2

[Mark Kettenis]

> Date: Tue, 10 Nov 2015 20:28:24 +
> From: Miod Vallat 
> 
> > The SDHC on this machine comes with a 64-bit BAR, so we need to fix
> > that XXX.  I did change the error handling a bit such that we give up
> > after the first unmappable BAR.  It seems multi-slot controllers are
> > rare and it is questionable whether higher numbered slots work if we
> > can't properly configure a lower numbered slot.
> > 
> > ok?
> 
> I agree with the intent, but your diff will cause the loop to exit for
> any mapping error or if an I/O BAR is found - could the latter occur on
> some systems?

The Simplified SD Host Controller Specification specifies that the
BARs are "mapped to memory space".  So if an I/O BAR is found, the
device does not conform to the specification.  But it also indicates
that bit 07-01 should be hardwired to 0.  So it doesn't allow 64-bit
memory BARs either.  But perhaps there is an update of the SD Host
Controller Specification that does allow this.  The AMD controller
claims to conform to the standard since its interface code is set to
01.

There is no reason why an I/O BAR couln't work with our driver since
bus_space(9) nicely abstracts away the differences.  But I don't
really expect to see devices that have one.

> I'd rather see something like this:
> 
>   for (... ; ...; reg += span) {
>   if (pci_mapreg_probe() fails)
>   break;  /* because there is nothing better we can do */
> 
>   if (type == PCI_MAPREG_TYPE_IO)
>   span = 4;
>   else
>   span = type & PCI_MAPREG_MEM_TYPE_64BIT ? 8 : 4;
> 
>   ...
>   }

Re: give cron a sensible default max load_avg for batch jobs

[Benny Lofgren]

On 2015-11-14 04:28, Todd C. Miller wrote:
> On Fri, 13 Nov 2015 16:45:44 -0700, Theo de Raadt wrote:
> 
>>> This patch changes the default setting to 1.5 *
>>> (number_of_cpus_in_system) instead, which I find better matches modern
>>> behaviour.
>>
>> A larger number is sensible in this position.
>>
>> I would propose 8.  I don't agree with a calculation like that; the
>> amount of work a system can do should not be calculated like that.
> 
> I think 8 is way to high.  Isn't the point of batch to run things
> when the machine is mostly idle?

The problem is (and we've had this discussion several times before at
least in misc@), that the system load doesn't really tell us that.

It *may* be the case that the system is under lots of work, but it may
also be the case that there are many processes just blocking waiting for
some resource and that the system is essentially idling.

My particular problem, and the reason I suggested this patch in the
first place, is that I often see loads of 20-30-50 or even way more,
without there even being a problem. The machine is very responsive, and
everything works great - there are just a lot of processes running or
waiting for an opportunity to run.


Since the system load essentially is a decaying average of the number of
runnable or running processes, it is not in any way connected to actual
processor workload as in instructions executed, just to the fact that
there is much *potentially* going on in the system.

For example, I run a couple of Hadoop clusters (not on OpenBSD
unfortunately), and with cluster nodes containing dual 6-core
hyper-threading Xeon processors, there is 24 "cores" that can be tasked
with calculations, and if they are all doing something the system load
will be at least 24 - but there would be no problem whatsoever to do
more things on the server, especially since the map/reduce tasks are
running with lowered priority. Each core's individual load would be about 1.

That's also why I suggested to base the default on a value relative to
the number of cores - it made sense from my practical point of view. But
I understand where Theo's coming from on this.



Regards,

/Benny


-- 
internetlabbet.se / work:   +46 8 551 124 80  / "Words must
Benny Lofgren/  mobile: +46 70 718 11 90 /   be weighed,
/   fax:+46 8 551 124 89/not counted."
   /email:  benny -at- internetlabbet.se

give cron a sensible default max load_avg for batch jobs

[Benny Lofgren]

Hi tech@,

Inspired by the flurry of changes to cron(8) the last couple of days, I
finally went to fix an issue that has bitten me numerous times over the
years, since I'm a heavy user of batch(1) and at(1):

When running a batch/at job, cron looks at the system's current load
average to determine if it can run the job now or needs to wait until
the system is more lightly loaded.

The default load_avg is set to 1.5, which is often way too low in a
modern system with perhaps thousands of processes running or waiting to
run on dozens of cpu cores. I often forget to change the default on new
machines (hence the frequency of me messing this up).


This patch changes the default setting to 1.5 *
(number_of_cpus_in_system) instead, which I find better matches modern
behaviour.

I took inspiration from FreeBSD's atrun(8) that does the same. We
(thankfully) don't have a separate atrun, it is rather integrated in the
cron daemon.

I also added a -L switch that works like cron -l in that it adjusts the
load average used, but uses the same scaling as I do when calculating
the default, so that for example "cron -L 2.5" on a 12-core machine
gives a max load_avg of 30, while "cron -l 2.5" still gets the same 2.5
as it always has.


The easiest solution to this is perhaps to simply set the default to
0.0, disabling the resource check altogether. But I rather like that it
is there and works, as a safeguard - it just needs a default that is
better adapted to modern computing, and I feel that this approach would
add minimal complexity while still retaining a useful default in most
situations.


Thoughts?


Regards,

/Benny



Index: cron.8
===
RCS file: /cvs/src/usr.sbin/cron/cron.8,v
retrieving revision 1.32
diff -u -p -u -r1.32 cron.8
--- cron.8  23 Jan 2015 01:01:06 -  1.32
+++ cron.8  13 Nov 2015 22:47:27 -
@@ -29,6 +29,7 @@
 .Nm cron
 .Op Fl n
 .Op Fl l Ar load_avg
+.Op Fl L Ar scaled_load_avg
 .Sh DESCRIPTION
 The
 .Nm
@@ -116,10 +117,14 @@ If the current load average is greater t
 .Ar load_avg ,
 .Xr batch 1
 jobs will not be run.
-The default value is 1.5.
+The default value is 1.5 * number of cpus present in the system.
 To allow
 .Xr batch 1
 jobs to run regardless of the load, a value of 0.0 may be used.
+.It Fl L Ar scaled_load_avg
+Similar to -l, but
+.Ar scaled_load_avg
+is multiplied by the number of cpus before being set.
 .It Fl n
 By default,
 .Nm
Index: cron.c
===
RCS file: /cvs/src/usr.sbin/cron/cron.c,v
retrieving revision 1.66
diff -u -p -u -r1.66 cron.c
--- cron.c  9 Nov 2015 16:37:07 -   1.66
+++ cron.c  13 Nov 2015 22:47:27 -
@@ -17,9 +17,10 @@
  * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */

-#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -53,7 +54,8 @@ staticvoidusage(void),
sigchld_reaper(void),
parse_args(int c, char *v[]);

-static int open_socket(void);
+static int open_socket(void),
+   getncpu(void);

 static volatile sig_atomic_t   got_sighup, got_sigchld;
 static time_t  timeRunning, virtualTime, clockTime;
@@ -61,24 +63,50 @@ static  int cronSock;
 static longGMToff;
 static cron_db *database;
 static at_db   *at_database;
-static double  batch_maxload = BATCH_MAXLOAD;
+static double  batch_maxload;
 static int NoFork;
 static time_t  StartTime;
+static int ncpus;

 static void
 usage(void)
 {

-   fprintf(stderr, "usage: %s [-n] [-l load_avg]\n", __progname);
+   fprintf(stderr,
+   "usage: %s [-n] [-l load_avg] [-L scaled_load_avg]\n",
+   __progname);
exit(EXIT_FAILURE);
 }

+
+static int
+getncpu(void)  /* From top(1), machine.c */
+{
+int mib[] = { CTL_HW, HW_NCPU };
+int ncpu;
+size_t size = sizeof(ncpu);
+
+if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
+, , NULL, 0) == -1)
+return -1;
+
+return ncpu;
+}
+
+
 int
 main(int argc, char *argv[])
 {
struct sigaction sact;
sigset_t blocked, omask;

+   ncpus = getncpu(); /* Get this early, before pledge() */
+   if (ncpus == -1)
+   ncpus = 1; /* Silently assume SP if sysctl() call fails */
+
+   /* Scale default value by number of cpus present */
+   batch_maxload = BATCH_MAXLOAD * ncpus;
+
setlocale(LC_ALL, "");

setvbuf(stdout, NULL, _IOLBF, 0);
@@ -509,6 +537,16 @@ parse_args(int argc, char *argv[])
case 'l':
errno = 0;
batch_maxload = strtod(optarg, );
+   if (*ep != '\0' || ep == optarg || errno == ERANGE ||
+

Re: give cron a sensible default max load_avg for batch jobs

[Theo de Raadt]

> This patch changes the default setting to 1.5 *
> (number_of_cpus_in_system) instead, which I find better matches modern
> behaviour.

A larger number is sensible in this position.

I would propose 8.  I don't agree with a calculation like that; the
amount of work a system can do should not be calculated like that.

Re: give cron a sensible default max load_avg for batch jobs

[Todd C. Miller]

On Fri, 13 Nov 2015 16:45:44 -0700, Theo de Raadt wrote:

> > This patch changes the default setting to 1.5 *
> > (number_of_cpus_in_system) instead, which I find better matches modern
> > behaviour.
> 
> A larger number is sensible in this position.
> 
> I would propose 8.  I don't agree with a calculation like that; the
> amount of work a system can do should not be calculated like that.

I think 8 is way to high.  Isn't the point of batch to run things
when the machine is mostly idle?

 - todd

Re: give cron a sensible default max load_avg for batch jobs

[Benny Lofgren]

On 2015-11-14 00:45, Theo de Raadt wrote:
>> This patch changes the default setting to 1.5 *
>> (number_of_cpus_in_system) instead, which I find better matches modern
>> behaviour.
> 
> A larger number is sensible in this position.
> 
> I would propose 8.  I don't agree with a calculation like that; the
> amount of work a system can do should not be calculated like that.


Fair enough! I agree that 8 will probably fit most cases. It makes for a
simpler patch, too. :-)

(I retained the decimal point in 8.0 in the man page, as an indicator
that it is not an integer value.)


Regards,

/Benny





Index: config.h
===
RCS file: /cvs/src/usr.sbin/cron/config.h,v
retrieving revision 1.23
diff -u -p -u -r1.23 config.h
--- config.h23 Oct 2015 18:42:55 -  1.23
+++ config.h14 Nov 2015 00:32:21 -
@@ -40,7 +40,7 @@
 #define MAILARG _PATH_SENDMAIL /*-*/

/* maximum load at which batch jobs will still run */
-#define BATCH_MAXLOAD  1.5 /*-*/
+#define BATCH_MAXLOAD  8.0 /*-*/

/* Define this to run crontab setgid instead of
 * setuid root.  Group access will be used to read
Index: cron.8
===
RCS file: /cvs/src/usr.sbin/cron/cron.8,v
retrieving revision 1.34
diff -u -p -u -r1.34 cron.8
--- cron.8  12 Nov 2015 21:14:01 -  1.34
+++ cron.8  14 Nov 2015 00:32:21 -
@@ -116,7 +116,7 @@ If the current load average is greater t
 .Ar load_avg ,
 .Xr batch 1
 jobs will not be run.
-The default value is 1.5.
+The default value is 8.0.
 To allow
 .Xr batch 1
 jobs to run regardless of the load, a value of 0.0 may be used.

Re: [patch] was: Re: login(3) routines data integrity patch

[Chris Turner]

On 11/12/15 14:10, Ted Unangst wrote:

Chris Turner wrote:

>>>

The attached patch calls fsync(2) on related FD's in the login(3)
routines, which corrected the problem on my test machine,
and imho might be a good idea in general.


AFAIK it should not be necessary to call fsync() before close(). Closing a
file should flush all its data. The patch either does nothing, or masks a much
more serious somewhere else. (The latter is a distinct possibility, but we
can't go adding fsync to hundreds of file operations throughout the tree.)


Will defer -

To be clear however, in this case I'm strictly referring to the (brief)
time window between data being flushed from the process and that data then
being sync'ed to disk by the system -

E.g., as related to fsync(2):

"
 fsync() and fdatasync() should be used by programs that require a file to
 be in a known state, for example, in building a simple transaction
 facility.
"

obviously there's still the case of physical disk caches, etc.

I realize fsync is not done everywhere on file close, and likely rightfully
so in many/most cases - my thinking was that here specifically might be a
good place given the type of (sensitive, non-reproducable) data being stored.

Again, deferring, but, thought i'd clarify a bit more of my thinking
in case it might be beneficial to the discussion.

Cheers,

- Chris

Re: MALLOC_STATS and pledge

[Otto Moerbeek]

On Fri, Nov 13, 2015 at 09:11:46AM +, David CARLIER wrote:

> Hi all,
> 
> I ve tried to discuss this point with Otto Moerbeek but he might be
> very busy so I throw the topic here if you do not mind ...
> 
> I have the habit to enable MALLOC_STATS but with the recent pledge
> feature, it s now difficult to debug some pledged applications with
> MALLOC_OPTIONS=D as, for malloc_dump, wpath and rpath are needed ...
> and it is fore sure not wishable to enable those in those userland
> apps.
> 
> Is there a way, somehow, to succeed ? For the moment I ve slighty
> modified malloc_dump to only write on stderr and then I redirect the
> output myself.
> 
> Thanks in advance.
> 
> Kind regards.

you're too fast...

I do not like writing to stderr. The idea is that malloc writes the
info only if a writable malloc.out file already exists in the cwd. 

An idea would be to open the fd at init time, which should be early
enough for most cases (i.e. before the first pledge(2) call).  Big
drawback is the open fd all the time until program exits. 

Another way would be to special case malloc.out in in the kernel. Not
too nice either.


-Otto

Re: MALLOC_STATS and pledge

[Theo de Raadt]

> I ve tried to discuss this point with Otto Moerbeek but he might be
> very busy so I throw the topic here if you do not mind ...
> 
> I have the habit to enable MALLOC_STATS but with the recent pledge
> feature, it s now difficult to debug some pledged applications with
> MALLOC_OPTIONS=D as, for malloc_dump, wpath and rpath are needed ...
> and it is fore sure not wishable to enable those in those userland
> apps.
> 
> Is there a way, somehow, to succeed ? For the moment I ve slighty
> modified malloc_dump to only write on stderr and then I redirect the
> output myself.

Yes, opening a file late under program control becomes undesireable.
I suspect utrace(2) becomes a good idea, then the data can show up in
ktrace.  'ktrace -t u' can be used to request just that information...

Re: MALLOC_STATS and pledge

[Theo de Raadt]

> An idea would be to open the fd at init time, which should be early
> enough for most cases (i.e. before the first pledge(2) call).  Big
> drawback is the open fd all the time until program exits. 

Keeping a fd open through libc runtime is not going to fly.  It isn't
just the fragility of it.  The risks of misuse are too high.

pledge("stdio") for arch(1)/machine(1)

[Theo Buehler]

This straightforward pledge("stdio") is one of the last uncommitted ones
from Theo's big 'tame in userland' diff and seems to have been
overlooked so far.

Index: usr.bin/arch/arch.c
===
RCS file: /cvs/src/usr.bin/arch/arch.c,v
retrieving revision 1.16
diff -u -p -r1.16 arch.c
--- usr.bin/arch/arch.c 25 Sep 2015 16:19:26 -  1.16
+++ usr.bin/arch/arch.c 13 Nov 2015 13:32:35 -
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void __dead usage(void);
 
@@ -43,6 +44,9 @@ main(int argc, char *argv[])
char *arch, *opts;
 
setlocale(LC_ALL, "");
+
+   if (pledge("stdio", NULL) == -1)
+   err(1, "pledge");
 
machine = strcmp(__progname, "machine") == 0;
if (machine) {

Tighter pledge(2) for nm(1)/size(1)

[Theo Buehler]

nm(1) was tamed shortly before the "exec" promise was introduced.  The
"proc exec" is necessary to cover `nm -C' which fork-exec's c++filt(1).
Right after potential fork-exec, the original pledge "stdio rpath" is
given (one could make that last pledge call in the file conditional on
`issize' so that size only pledges once, but that complication doesn't
seem to be worth it).

Index: usr.bin/nm/nm.c
===
RCS file: /cvs/src/usr.bin/nm/nm.c,v
retrieving revision 1.49
diff -u -p -r1.49 nm.c
--- usr.bin/nm/nm.c 9 Oct 2015 01:37:08 -   1.49
+++ usr.bin/nm/nm.c 13 Nov 2015 13:38:20 -
@@ -135,10 +135,16 @@ main(int argc, char *argv[])
const struct option *lopts;
int ch, eval;
 
+   if (pledge("stdio rpath proc exec", NULL) == -1)
+   err(1, "pledge");
+
optstr = OPTSTRING_NM;
lopts = longopts_nm;
if (!strcmp(__progname, "size")) {
-   issize++;
+   if (pledge("stdio rpath", NULL) == -1)
+   err(1, "pledge");
+
+   issize = 1;
optstr = "tw";
lopts = NULL;
}