Re: Can not allocate memory for KERN_MSGBUF

[Andreas Kusalananda Kähäri]

On Fri, Jun 24, 2016 at 01:19:32PM +0200, Alexander Bluhm wrote:
> On Fri, Jun 24, 2016 at 10:30:04AM +0200, Andreas Kusalananda K?h?ri wrote:
> > I'm following -current on amd64, running in VirtualBox.  I recompiled
> > the kernel today with fresh sources, like I do a few times a week on
> > slow days.
> 
> Have you also installed /usr/include/sys/msgbuf.h from
> /usr/src/sys/sys/msgbuf.h and recomiled /usr/src/sbin/dmesg ?
> A make build should do that.
> 
> bluhm
> 

I believe I have fallen into the trap of not recompiling the userland
binaries before reacting te seeing the dmesg command misbehave.

I was doing a regular update of the system so I recompiled the kernel
and rebooted.  I have a piece of shell code in my login scripts that
compares the dmsg output from the current boot with that of the previous
boot, and when I saw that there was no output from the current boot I
reacted before thinking.


I am sincerely sorry for the noise.

Regards,


signature.asc
Description: PGP signature

Re: Can not allocate memory for KERN_MSGBUF

[Alexander Bluhm]

On Fri, Jun 24, 2016 at 10:30:04AM +0200, Andreas Kusalananda K?h?ri wrote:
> I'm following -current on amd64, running in VirtualBox.  I recompiled
> the kernel today with fresh sources, like I do a few times a week on
> slow days.

Have you also installed /usr/include/sys/msgbuf.h from
/usr/src/sys/sys/msgbuf.h and recomiled /usr/src/sbin/dmesg ?
A make build should do that.

bluhm

Medion Mobile S4222 works with umb(4)

[Ingo Feinerer]

Hi,

just a short report that the "Medion Mobile S4222" UMTS stick (attached via
USB) works fine with the new umb(4):

umsm0 at uhub0 port 2 configuration 1 interface 0 "MediaTek Inc Product" rev 
2.00/3.00 addr 10
umsm0 detached
umb1 at uhub0 port 2 configuration 1 interface 0 "MediaTek Inc Product" rev 
2.00/3.00 addr 10
umsm0 at uhub0 port 2 configuration 1 interface 2 "MediaTek Inc Product" rev 
2.00/3.00 addr 10
ucom3 at umsm0
umsm1 at uhub0 port 2 configuration 1 interface 3 "MediaTek Inc Product" rev 
2.00/3.00 addr 10
ucom4 at umsm1
umsm2 at uhub0 port 2 configuration 1 interface 4 "MediaTek Inc Product" rev 
2.00/3.00 addr 10
ucom5 at umsm2
umsm3 at uhub0 port 2 configuration 1 interface 5 "MediaTek Inc Product" rev 
2.00/3.00 addr 10
ucom6 at umsm3

Is it worth documenting this (in analogy to umsm(4))?

(Btw. mdoc(7) states for "Tn": "do not use this in new manuals". However, for
consistency with the existing entries I kept it.)

Best regards,
Ingo

Index: umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.2
diff -u -p -r1.2 umb.4
--- umb.4   20 Jun 2016 09:03:08 -  1.2
+++ umb.4   24 Jun 2016 12:42:30 -
@@ -44,6 +44,7 @@ PIN again even if the system was reboote
 The following devices should work:
 .Pp
 .Bl -tag -width Ds -offset indent -compact
+.It Tn Medion Mobile S4222 (MediaTek OEM)
 .It Tn Sierra Wireless EM8805
 .It Tn Sierra Wireless MC8305
 .El

Re: less progname in r

[Mark Kettenis]

> From: "Ted Unangst" 
> Date: Thu, 23 Jun 2016 21:57:00 -0400
> 
> These programs don't do anything interesting based on progname,
> except to echo is back to the user. If the user creates a link, is
> it somehow more correct to print that name? I'd argue the original
> name is better (especially in usage) because then you have a hint
> what man page to read.

Using __progname in this context has been the standard on *BSD for a
long time.  This really feels like unnecessary churn to me.

> Index: radioctl/radioctl.c
> ===
> RCS file: /cvs/src/usr.bin/radioctl/radioctl.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 radioctl.c
> --- radioctl/radioctl.c   21 Dec 2013 06:54:53 -  1.19
> +++ radioctl/radioctl.c   24 Jun 2016 01:47:26 -
> @@ -94,7 +94,6 @@ struct chansets {
>  { 0, NULL }
>  };
>  
> -extern char *__progname;
>  const char *onchar = "on";
>  #define ONCHAR_LEN   2
>  const char *offchar = "off";
> @@ -218,10 +217,9 @@ void
>  usage(void)
>  {
>   fprintf(stderr,
> - "usage: %s [-anv] [-f file]\n"
> - "   %s [-nv] [-f file] name\n"
> - "   %s [-n] [-f file] name=value\n",
> - __progname, __progname, __progname);
> + "usage: radioctl [-anv] [-f file]\n"
> + "   radioctl [-nv] [-f file] name\n"
> + "   radioctl [-n] [-f file] name=value\n");
>   exit(1);
>  }
>  
> Index: rdist/common.c
> ===
> RCS file: /cvs/src/usr.bin/rdist/common.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 common.c
> --- rdist/common.c22 Dec 2015 08:48:39 -  1.37
> +++ rdist/common.c24 Jun 2016 01:48:13 -
> @@ -62,7 +62,6 @@ int isserver = FALSE;   /* We're the ser
>  int  amchild = 0;/* This PID is a child */
>  int  do_fork = 1;/* Fork child process */
>  char*currenthost = NULL; /* Current client hostname */
> -char*progname = NULL;/* Name of this program */
>  int  rem_r = -1; /* Client file descriptor */
>  int  rem_w = -1; /* Client file descriptor */
>  struct passwd   *pw = NULL;  /* Local user's pwd 
> entry */
> Index: rdist/defs.h
> ===
> RCS file: /cvs/src/usr.bin/rdist/defs.h,v
> retrieving revision 1.36
> diff -u -p -r1.36 defs.h
> --- rdist/defs.h  21 Jan 2015 03:05:03 -  1.36
> +++ rdist/defs.h  24 Jun 2016 01:48:18 -
> @@ -156,7 +156,6 @@
>  
>  
>  extern char *currenthost;/* Name of current host */
> -extern char *progname;   /* Name of this program */
>  extern char *locuser;/* Local User's name */
>  extern int   debug;  /* Debugging flag */
>  extern int   isserver;   /* Acting as remote server */
> Index: rdist/message.c
> ===
> RCS file: /cvs/src/usr.bin/rdist/message.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 message.c
> --- rdist/message.c   30 Mar 2016 20:51:59 -  1.28
> +++ rdist/message.c   24 Jun 2016 01:48:30 -
> @@ -251,7 +251,7 @@ setmsgtypes(struct msgfacility *msgfac, 
>   break;
>  
>   case MF_SYSLOG:
> - openlog(progname, LOG_PID, LOG_DAEMON);
> + openlog("rdist", LOG_PID, LOG_DAEMON);
>   break;
>   }
>  
> Index: rdist/rdist.c
> ===
> RCS file: /cvs/src/usr.bin/rdist/rdist.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 rdist.c
> --- rdist/rdist.c 8 Feb 2015 23:40:34 -   1.30
> +++ rdist/rdist.c 24 Jun 2016 01:48:55 -
> @@ -87,7 +87,6 @@ addhostlist(char *name, struct namelist 
>  int
>  main(int argc, char **argv, char **envp)
>  {
> - extern char *__progname;
>   struct namelist *hostlist = NULL;
>   char *distfile = NULL;
>   char *cp;
> @@ -95,8 +94,6 @@ main(int argc, char **argv, char **envp)
>   int c;
>   const char *errstr;
>  
> - progname = __progname;
> -
>   if ((cp = msgparseopts(localmsglist, TRUE)) != NULL) {
>   error("Bad builtin log option (%s): %s.", 
> localmsglist, cp);
> @@ -334,16 +331,15 @@ opendist(char *distfile)
>  static void
>  usage(void)
>  {
> - extern char *__progname;
>  
>   (void) fprintf(stderr,
> - "usage: %s [-DFnV] [-A num] [-a num] "
> + "usage: rdist [-DFnV] [-A num] [-a num] "
>   "[-c mini_distfile]\n"
>   "\t[-d var=value] [-f distfile] [-L remote_logopts] "
>   "[-l local_logopts]\n"
>   "\t[-M maxproc] [-m host] [-o distopts] [-P rsh-path] "
>  

opencvs - check len in rcsnum_setsize()

[Joris Vink]

Hi,

Since RCSNUM's rn_id array is limited to RCSNUM_MAXLEN it is very
sensible to make sure rcsnum_setsize() protects against this.

Index: rcsnum.c
===
RCS file: /cvs/src/usr.bin/cvs/rcsnum.c,v
retrieving revision 1.57
diff -u -p -r1.57 rcsnum.c
--- rcsnum.c5 Nov 2015 09:48:21 -   1.57
+++ rcsnum.c24 Jun 2016 09:27:07 -
@@ -427,6 +427,9 @@ rcsnum_branch_root(RCSNUM *brev)
 static void
 rcsnum_setsize(RCSNUM *num, u_int len)
 {
+   if (len > RCSNUM_MAXLEN)
+   fatal("rcsnum_setsize: len %u too long", len);
+
num->rn_len = len;
 }

Can not allocate memory for KERN_MSGBUF

[Andreas Kusalananda Kähäri]

On Thu, Jun 23, 2016 at 07:15:21AM -0600, Alexander Bluhm wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   bl...@cvs.openbsd.org   2016/06/23 07:15:21
> 
> Modified files:
>   sys/kern   : subr_log.c 
>   sys/sys: msgbuf.h 
> 
> Log message:
> It is annoying that the dmesg buffer can overflow and loose messages
> undetected during debugging.  To make clear what happens, count the
> dropped bytes and write message buffer full to syslogd.  This also
> helps to have a reliable log system.
> OK deraadt@ millert@ tedu@
> 

Hi,

I'm following -current on amd64, running in VirtualBox.  I recompiled
the kernel today with fresh sources, like I do a few times a week on
slow days.

After reboot:

$ dmesg
dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory

I have no /etc/sysctl.conf and I don't set those variables by
hand.

The issue *seems* to have been introduced with the commit above
as backing it out fixes it.

dmesg output without the commit (or any later commit):

OpenBSD 6.0-beta (GENERIC.MP) #26: Fri Jun 24 10:16:28 CEST 2016
kk@uerfale:/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278124544 (4079MB)
avail mem = 4143943680 (3951MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3193.07 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.77 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: GFX0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 128-sector PIO, LBA, 51200MB, 104857600 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82543GC" rev 0x02: apic 2 int 19, address 
08:00:27:b1:89:72
"InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not 
configured
piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: SMBus disabled
em1 at pci0 dev 8 function 0 "Intel 82543GC" rev 0x02: apic 2 int 16, address 
08:00:27:ff:fb:ca
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (22d20e8d1f94fa20.a) swap on wd0b dump on wd0b


signature.asc
Description: PGP signature

Re: new feature in pkg_add(1)

[Marc Espie]

On Thu, Jun 23, 2016 at 06:44:19AM +0200, Patrik Lundin wrote:
> On Wed, Jun 22, 2016 at 02:19:26PM +0200, Marc Espie wrote:
> > On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote:
> > > The reason for doing this is that it is much faster than just blindly
> > > trying to install a package, and does not hammer mirrors needlessly.
> > > 
> > > Are there any plans to teach pkg_info -e about "%"? Is it even possible?
> > 
> > Okay, just committed the exit code fix.
> > 
> > pkg_info -Iq inst:python%3.5
> > will perform just as you would expect.
> 
> Awesome :).
> 
> I will play around with this and see what I can come up with, thanks!

Actually, I think there's something deeply wrong with this process.
This is not Unix.

The philosophy has always been: you want something, you try to do it.
You do not check whether it's already there, and then do it if it's
not.  So the bigger problem is that there's no quick mode for pkg_add
that checks very quickly on the installed system, stops if it's already
there, and otherwise goes installing.

Right now, you're doing the same check twice, which is not so cool.

So I'll see if I can speed up pkg_add  at some point for the cases things
are already there.

[PATCH] small improvements to ftp(1)

[vladsotirov]

Hi,

The patch below implements the following changes to ftp(1), beginning
with the least disruptive and ending with the most disruptive.

1) Change ftp->newer's behavior to match ftp->reget's behavior when
stat(2) on the local file fails: do the file transfer from offset 0
instead of from whatever offset is stored in the global variable
restart_point. 

2) Document ftp->newer's behavior of declining to do the transfer if the
modification time of the remote file cannot be determined.
Make ftp->newer emit an alert when this happens instead of being silent.
Document that ftp -C transfers files using the logic of ftp->reget
(unless I've misread the code, that's literally what happens in fetch.c)

3) Make the options -c and -n of ftp>mget for using reget or newer
exclusive instead of allowing ftp>mget -ncncncncccnc with the last
option winning.

4) Improve ftp>reget's behavior so that a local file is considered to
be a partially complete transfer only if its modification time is
determined to be more recent than the modification time of the remote
file. If so, the transfer is continued from the interruption point,
otherwise, the transfer is restarted from the beginning, overwriting
the local file.

5) Change ftp->reget's behavior to match ftp->newer's behaviour when the
modification time of the remote file cannot be determined: decline the
transfer (and alert!) instead of doing the transer anyway.

The actual diff implements these as follows.
1-5) a rewrite of the restartit conditional in getit() in small.c
3) Simple change to mget() in small.c
2-5) appropriate changes to ftp.1

Additionally, I enacted a few style improvements before the restartit
block in getit() in small.c: I removed some unnecessary braces,
eliminated a '!' from a boolean test, and changed a silly increment
of the 0-initialized variable loc to an explict assignment of 1.

--Vladimir Sotirov

Index: ftp.1
===
RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
retrieving revision 1.101
diff -u -p -r1.101 ftp.1
--- ftp.1   5 Nov 2015 16:25:57 -   1.101
+++ ftp.1   24 Jun 2016 09:26:03 -
@@ -123,7 +123,9 @@ to bypass the normal login procedure and
 Continue a previously interrupted file transfer.
 .Nm
 will continue transferring from an offset equal to the length of
-.Ar file .
+.Ar file 
+using the logic of 
+.Ic reget .
 .Pp
 Resuming HTTP(S) transfers are only supported
 if the remote server supports the
@@ -628,7 +630,8 @@ on the remote machine.
 A synonym for
 .Ic mls .
 .It Xo Ic mget
-.Op Fl cnr
+.Op Fl r
+.Op Fl c | n
 .Op Fl d Ar depth
 .Ar remote-files
 .Xc
@@ -746,8 +749,9 @@ directories.
 A synonym for
 .Ic mput .
 .It Ic newer Ar remote-file Op Ar local-file
-Get the file only if the modification time of the remote file is more
-recent than the file on the current system.
+Get the file only if the modification time of the remote file can be 
+determined and is more
+recent than the modification time of the file on the current system.
 If the file does not
 exist on the current system, the remote file is considered
 .Ic newer .
@@ -1073,10 +1077,12 @@ The arguments specified are sent, verbat
 A synonym for
 .Ic get .
 .It Ic reget Ar remote-file Op Ar local-file
-Reget acts like get, except that if
+Reget acts like get, except that it transfers the
+.Ar remote-file
+only if its modification time can be determined, in which case if
 .Ar local-file
 exists and is
-smaller than
+smaller and more recent than 
 .Ar remote-file ,
 .Ar local-file
 is presumed to be
Index: small.c
===
RCS file: /cvs/src/usr.bin/ftp/small.c,v
retrieving revision 1.6
diff -u -p -r1.6 small.c
--- small.c 25 May 2016 15:36:01 -  1.6
+++ small.c 24 Jun 2016 09:26:03 -
@@ -215,7 +215,7 @@ getit(int argc, char *argv[], int restar
if (argc == 2) {
argc++;
argv[2] = argv[1];
-   loc++;
+   loc = 1;
}
 #ifndef SMALL
if (argc < 2 && !another(, , "remote-file"))
@@ -238,16 +238,14 @@ usage:
if (loc && mcase) {
char *tp = argv[1], *tp2, tmpbuf[PATH_MAX];
 
-   while (*tp && !islower((unsigned char)*tp)) {
+   while (*tp && !islower((unsigned char)*tp))
tp++;
-   }
-   if (!*tp) {
+   if (*tp == '\0') {
tp = argv[2];
tp2 = tmpbuf;
while ((*tp2 = *tp) != '\0') {
-   if (isupper((unsigned char)*tp2)) {
+   if (isupper((unsigned char)*tp2))
*tp2 = tolower((unsigned char)*tp2);
-   }
tp++;
tp2++;
}
@@ -262,26 +260,29 @@ usage:
if (restartit) {
   

Re: Can not allocate memory for KERN_MSGBUF

[Mark Kettenis]

This happens if kernel and the dmesg(8) userland program are out of
sync.  And yes, that can even happen for snapshots.  Next snapshot
should be ok again.

[patch] opencvs rcsnum_free()

[Michael W. Bombardieri]

Hi,

If people are interested in opencvs diffs again, sharing a rcsnum_free()->free()
clean-up item. Note that rcs(1) also has a version of rcsnum_free() which does 
more
than simply call free().

- Michael


Index: add.c
===
RCS file: /cvs/src/usr.bin/cvs/add.c,v
retrieving revision 1.112
diff -u -p -u -r1.112 add.c
--- add.c   5 Nov 2015 09:48:21 -   1.112
+++ add.c   24 Jun 2016 06:10:45 -
@@ -485,8 +485,7 @@ add_file(struct cvs_file *cf)
break;
}
 
-   if (head != NULL)
-   rcsnum_free(head);
+   free(head);
 
if (stop == 1)
return;
Index: admin.c
===
RCS file: /cvs/src/usr.bin/cvs/admin.c,v
retrieving revision 1.66
diff -u -p -u -r1.66 admin.c
--- admin.c 5 Nov 2015 09:48:21 -   1.66
+++ admin.c 24 Jun 2016 06:10:45 -
@@ -334,11 +334,11 @@ cvs_admin_local(struct cvs_file *cf)
if (rcs_rev_setlog(cf->file_rcs, rev, logmsg) < 0) {
cvs_log(LP_ERR, "failed to set logmsg for `%s' to `%s'",
logstr, logmsg);
-   rcsnum_free(rev);
+   free(rev);
return;
}
 
-   rcsnum_free(rev);
+   free(rev);
}
 
if (orange != NULL) {
@@ -380,7 +380,7 @@ cvs_admin_local(struct cvs_file *cf)
 
(void)rcs_state_set(cf->file_rcs, rev, state);
 
-   rcsnum_free(rev);
+   free(rev);
}
 
if (lkmode != RCS_LOCK_INVAL)
Index: annotate.c
===
RCS file: /cvs/src/usr.bin/cvs/annotate.c,v
retrieving revision 1.65
diff -u -p -u -r1.65 annotate.c
--- annotate.c  5 Nov 2015 09:48:21 -   1.65
+++ annotate.c  24 Jun 2016 06:10:45 -
@@ -178,7 +178,7 @@ cvs_annotate_local(struct cvs_file *cf)
rev = rcsnum_parse(cvs_specified_tag);
if (rev == NULL)
fatal("no such tag %s", cvs_specified_tag);
-rcsnum_free(rev);
+free(rev);
rev = rcsnum_alloc();
rcsnum_cpy(cf->file_rcs->rf_head, rev, 0);
}
@@ -205,9 +205,9 @@ cvs_annotate_local(struct cvs_file *cf)
 */
if (bnum != rev) {
rcs_annotate_getlines(cf->file_rcs, rev, );
-   rcsnum_free(bnum);
+   free(bnum);
}
-   rcsnum_free(rev);
+   free(rev);
} else {
rcs_rev_getlines(cf->file_rcs, (cvs_specified_date != -1 ||
cvs_directory_date != -1) ? cf->file_rcsrev :
Index: commit.c
===
RCS file: /cvs/src/usr.bin/cvs/commit.c,v
retrieving revision 1.154
diff -u -p -u -r1.154 commit.c
--- commit.c5 Nov 2015 09:48:21 -   1.154
+++ commit.c24 Jun 2016 06:10:45 -
@@ -365,7 +365,7 @@ cvs_commit_check_files(struct cvs_file *
if (brev != NULL) {
if (RCSNUM_ISBRANCH(brev))
goto next;
-   rcsnum_free(brev);
+   free(brev);
}
 
brev = rcs_translate_tag(tag, cf->file_rcs);
@@ -382,7 +382,7 @@ cvs_commit_check_files(struct cvs_file *
"a branch for file %s", tag,
cf->file_path);
conflicts_found++;
-   rcsnum_free(brev);
+   free(brev);
return;
}
 
@@ -391,8 +391,8 @@ cvs_commit_check_files(struct cvs_file *
"a branch for file %s", tag,
cf->file_path);
conflicts_found++;
-   rcsnum_free(branch);
-   rcsnum_free(brev);
+   free(branch);
+   free(brev);
return;
}
 
@@ -401,18 +401,16 @@ cvs_commit_check_files(struct cvs_file *
"a branch for file %s", tag,
cf->file_path);
conflicts_found++;
-   rcsnum_free(branch);
-   rcsnum_free(brev);
+   free(branch);
+   free(brev);
return;
}
   

Re: less progname in r

[Ted Unangst]

Theo de Raadt wrote:
> 
> I actually dislike how these programs behave when linked to.  It is
> rare.  But it feels misleading somehow.

Yes, I mentioned this in passing. It's somewhat contrived, but here's an
example.

$ cp /bin/ls ~/bin/ld
$ ld -X
ld: unknown option -- X
usage: ld [-1AaCcdFfgHhikLlmnopqRrSsTtux] [file ...]

Now I read 'man ld' and woah...

On the one hand, obviously stupid idea to copy one command and give it another
name, but the way we accomodate this misuse makes the problem worse. Sometimes
these things happen by accident. If "ld" told me its name was "ls" that would
give me a hint about how to correct the problem and I'd remember that time I
fat fingered s/d.

Re: less progname in r

[Ted Unangst]

Mark Kettenis wrote:
> > From: "Ted Unangst" 
> > Date: Thu, 23 Jun 2016 21:57:00 -0400
> > 
> > These programs don't do anything interesting based on progname,
> > except to echo is back to the user. If the user creates a link, is
> > it somehow more correct to print that name? I'd argue the original
> > name is better (especially in usage) because then you have a hint
> > what man page to read.
> 
> Using __progname in this context has been the standard on *BSD for a
> long time.  This really feels like unnecessary churn to me.

Yes, although I think it's kind of mindless copying. This code doesn't benefit
from progname. (Code that inspects argv[0] does benefit.)

I doubt porting these programs is a high priority for anyone, but nevertheless
I prefer standard code over nonstandard code.

That said, it is kind of noise.

Re: less progname in r

[Theo de Raadt]

> > Yes, although I think it's kind of mindless copying. This code doesn't
> > benefit from progname. (Code that inspects argv[0] does benefit.)
> > 
> > I doubt porting these programs is a high priority for anyone, but
> > nevertheles I prefer standard code over nonstandard code.
> > 
> > That said, it is kind of noise.
> 
> And you just know that if this is committed there will be a diff
> from someone else in a year or so to use getprogname() instead of
> hard-coding the value.

I actually dislike how these programs behave when linked to.  It is
rare.  But it feels misleading somehow.

Re: less progname in r

[Todd C. Miller]

On Fri, 24 Jun 2016 16:52:24 -0400, "Ted Unangst" wrote:

> Yes, although I think it's kind of mindless copying. This code doesn't
> benefit from progname. (Code that inspects argv[0] does benefit.)
> 
> I doubt porting these programs is a high priority for anyone, but
> nevertheles I prefer standard code over nonstandard code.
> 
> That said, it is kind of noise.

And you just know that if this is committed there will be a diff
from someone else in a year or so to use getprogname() instead of
hard-coding the value.

 - todd

path mtu discovery dynamic route

[Alexander Bluhm]

Hi,

Path MTU discovery in IPv6 is slightly broken.  I takes two
ICMP6_PACKET_TOO_BIG packets to create and change the dynamic route.

When the first ICMP6 packet arrives, a dynamic route gets created
in icmp6_mtudisc_clone() and icmp6_mtudisc_update() sets its MTU
value.  During notify tcp_mtudisc() removes the old route from the
inp and allocates the dynamic route.  As the gateway route is not
set, the MTU is reset to 0 in _rtalloc().

The second packet will not allocate a dynamic route as it already
exists.  Just the MTU is updated.  Then tcp_mtudisc() does not
change the route at the inp as it already the correct one.  So now
PMTU discovery is successful.

This behavior was introduced in net/route.c rev 1.269 when the
gateway route allocation was moved from rt_setgateway() to _rtalloc().
So now rtrequest() can return a route without a valid gateway route.
To fix this, I call rt_setgwroute() from _rtalloc() and rt_setgateway().
As a result icmp6_mtudisc_clone() will create a route with a gateway
route and tcp_mtudisc() will not reset the MTU to 0 during rtalloc().

ok?

bluhm

Index: net/if_spppsubr.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_spppsubr.c,v
retrieving revision 1.154
diff -u -p -r1.154 if_spppsubr.c
--- net/if_spppsubr.c   14 Jun 2016 20:44:43 -  1.154
+++ net/if_spppsubr.c   24 Jun 2016 22:32:28 -
@@ -4161,7 +4161,7 @@ sppp_update_gw_walker(struct rtentry *rt
rt->rt_gateway->sa_family ||
!ISSET(rt->rt_flags, RTF_GATEWAY))
return (0); /* do not modify non-gateway routes */
-   rt_setgate(rt, rt->rt_ifa->ifa_dstaddr);
+   rt_setgate(rt, rt->rt_ifa->ifa_dstaddr, ifp->if_rdomain);
}
return (0);
 }
Index: net/route.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/route.c,v
retrieving revision 1.309
diff -u -p -r1.309 route.c
--- net/route.c 14 Jun 2016 09:48:52 -  1.309
+++ net/route.c 24 Jun 2016 22:37:45 -
@@ -154,6 +154,7 @@ struct pool rttimer_pool;   /* pool for r
 
 void   rt_timer_init(void);
 intrt_setaddr(struct rtentry *, struct sockaddr *);
+void   rt_setgwroute(struct rtentry *, u_int);
 intrtflushclone1(struct rtentry *, void *, u_int);
 void   rtflushclone(unsigned int, struct rtentry *);
 intrt_if_remove_rtdelete(struct rtentry *, void *, u_int);
@@ -369,7 +370,7 @@ rtalloc(struct sockaddr *dst, int flags,
 struct rtentry *
 _rtalloc(struct sockaddr *dst, uint32_t *src, int flags, unsigned int rtableid)
 {
-   struct rtentry *rt, *nhrt;
+   struct rtentry *rt;
 
rt = rt_match(dst, src, flags, rtableid);
 
@@ -381,6 +382,16 @@ _rtalloc(struct sockaddr *dst, uint32_t 
if (rtisvalid(rt->rt_gwroute))
return (rt);
 
+   rt_setgwroute(rt, rtableid);
+
+   return (rt);
+}
+
+void
+rt_setgwroute(struct rtentry *rt, u_int rtableid)
+{
+   struct rtentry *nhrt;
+
rtfree(rt->rt_gwroute);
rt->rt_gwroute = NULL;
 
@@ -392,10 +403,9 @@ _rtalloc(struct sockaddr *dst, uint32_t 
 * this behavior.  But it is safe since rt_checkgate() wont
 * allow us to us this route later on.
 */
-   nhrt = rt_match(rt->rt_gateway, NULL, flags | RT_RESOLVE,
-   rtable_l2(rtableid));
+   nhrt = rt_match(rt->rt_gateway, NULL, RT_RESOLVE, rtable_l2(rtableid));
if (nhrt == NULL)
-   return (rt);
+   return;
 
/*
 * Next hop must be reachable, this also prevents rtentry
@@ -403,13 +413,13 @@ _rtalloc(struct sockaddr *dst, uint32_t 
 */
if (ISSET(nhrt->rt_flags, RTF_CLONING|RTF_GATEWAY)) {
rtfree(nhrt);
-   return (rt);
+   return;
}
 
/* Next hop entry must be UP and on the same interface. */
if (!ISSET(nhrt->rt_flags, RTF_UP) || nhrt->rt_ifidx != rt->rt_ifidx) {
rtfree(nhrt);
-   return (rt);
+   return;
}
 
/*
@@ -424,8 +434,6 @@ _rtalloc(struct sockaddr *dst, uint32_t 
 * do the magic for us.
 */
rt->rt_gwroute = nhrt;
-
-   return (rt);
 }
 
 void
@@ -595,7 +603,7 @@ create:
flags |= RTF_MODIFIED;
prio = rt->rt_priority;
stat = _newgateway;
-   rt_setgate(rt, gateway);
+   rt_setgate(rt, gateway, rdomain);
}
} else
error = EHOSTUNREACH;
@@ -1089,7 +1097,8 @@ rtrequest(int req, struct rt_addrinfo *i
 * it to (re)order routes.
 */
if ((error = rt_setaddr(rt, ifa->ifa_addr)) ||
-   (error = rt_setgate(rt, info->rti_info[RTAX_GATEWAY]))) {
+   (error = rt_setgate(rt,