const in crypto code
Hi, Add "const" to weak_keys array which is read only (read via bcmp()). >From what I see all other arrays in src/sys/crypto are already "static const". - Michael Index: set_key.c === RCS file: /cvs/src/sys/crypto/set_key.c,v retrieving revision 1.4 diff -u -p -u -r1.4 set_key.c --- set_key.c 10 Dec 2015 21:00:51 - 1.4 +++ set_key.c 4 Jan 2017 06:34:27 - @@ -84,7 +84,7 @@ check_parity(des_cblock (*key)) * (and actual cblock values). */ #define NUM_WEAK_KEY 16 -static des_cblock weak_keys[NUM_WEAK_KEY]={ +static const des_cblock weak_keys[NUM_WEAK_KEY]={ /* weak keys */ {0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}, {0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE},
Re: [patch] turn igmpstat into a set of percpu counters
> On 22 Dec 2016, at 20:51, Dimitris Papastamoswrote: > > On Sun, Dec 11, 2016 at 07:24:40PM +, Dimitris Papastamos wrote: >> Hi, >> >> I converted the igmp stats to use percpu counters. This work is >> basically the same as what dlg@ did for other parts of the stack. >> I looked at the diff and adjusted it for igmp. > > ping it's in now. sorry about the delay, i wanted to be around after committing to handle any (unlikely) fallout. cheers, dlg
Re: qsort.c: remove useless variable
On Tue, Jan 03, 2017 at 04:40:47PM -0700, Todd C. Miller wrote: > On Tue, 03 Jan 2017 21:51:12 +0100, Alexander Bluhm wrote: > > > I think it would be nicer to keep the char * a variable and remove > > the (char *) casts instead. > > How about this? The qsort.o does not change. OK bluhm@ > > - todd > > Index: lib/libc/stdlib/qsort.c > === > RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v > retrieving revision 1.13 > diff -u -p -u -r1.13 qsort.c > --- lib/libc/stdlib/qsort.c 13 Sep 2015 08:31:47 - 1.13 > +++ lib/libc/stdlib/qsort.c 3 Jan 2017 23:39:24 - > @@ -90,16 +90,16 @@ qsort(void *aa, size_t n, size_t es, int > > loop:SWAPINIT(a, es); > if (n < 7) { > - for (pm = (char *)a + es; pm < (char *) a + n * es; pm += es) > - for (pl = pm; pl > (char *) a && cmp(pl - es, pl) > 0; > + for (pm = a + es; pm < a + n * es; pm += es) > + for (pl = pm; pl > a && cmp(pl - es, pl) > 0; >pl -= es) > swap(pl, pl - es); > return; > } > - pm = (char *)a + (n / 2) * es; > + pm = a + (n / 2) * es; > if (n > 7) { > - pl = (char *)a; > - pn = (char *)a + (n - 1) * es; > + pl = a; > + pn = a + (n - 1) * es; > if (n > 40) { > d = (n / 8) * es; > pl = med3(pl, pl + d, pl + 2 * d, cmp); > @@ -109,9 +109,9 @@ loop: SWAPINIT(a, es); > pm = med3(pl, pm, pn, cmp); > } > swap(a, pm); > - pa = pb = (char *)a + es; > + pa = pb = a + es; > > - pc = pd = (char *)a + (n - 1) * es; > + pc = pd = a + (n - 1) * es; > for (;;) { > while (pb <= pc && (cmp_result = cmp(pb, a)) <= 0) { > if (cmp_result == 0) { > @@ -134,8 +134,8 @@ loop: SWAPINIT(a, es); > pc -= es; > } > > - pn = (char *)a + n * es; > - r = min(pa - (char *)a, pb - pa); > + pn = a + n * es; > + r = min(pa - a, pb - pa); > vecswap(a, pb - r, r); > r = min(pd - pc, pn - pd - es); > vecswap(pb, pn - r, r);
Re: qsort.c: remove useless variable
On Tue, 03 Jan 2017 21:51:12 +0100, Alexander Bluhm wrote: > I think it would be nicer to keep the char * a variable and remove > the (char *) casts instead. How about this? - todd Index: lib/libc/stdlib/qsort.c === RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v retrieving revision 1.13 diff -u -p -u -r1.13 qsort.c --- lib/libc/stdlib/qsort.c 13 Sep 2015 08:31:47 - 1.13 +++ lib/libc/stdlib/qsort.c 3 Jan 2017 23:39:24 - @@ -90,16 +90,16 @@ qsort(void *aa, size_t n, size_t es, int loop: SWAPINIT(a, es); if (n < 7) { - for (pm = (char *)a + es; pm < (char *) a + n * es; pm += es) - for (pl = pm; pl > (char *) a && cmp(pl - es, pl) > 0; + for (pm = a + es; pm < a + n * es; pm += es) + for (pl = pm; pl > a && cmp(pl - es, pl) > 0; pl -= es) swap(pl, pl - es); return; } - pm = (char *)a + (n / 2) * es; + pm = a + (n / 2) * es; if (n > 7) { - pl = (char *)a; - pn = (char *)a + (n - 1) * es; + pl = a; + pn = a + (n - 1) * es; if (n > 40) { d = (n / 8) * es; pl = med3(pl, pl + d, pl + 2 * d, cmp); @@ -109,9 +109,9 @@ loop: SWAPINIT(a, es); pm = med3(pl, pm, pn, cmp); } swap(a, pm); - pa = pb = (char *)a + es; + pa = pb = a + es; - pc = pd = (char *)a + (n - 1) * es; + pc = pd = a + (n - 1) * es; for (;;) { while (pb <= pc && (cmp_result = cmp(pb, a)) <= 0) { if (cmp_result == 0) { @@ -134,8 +134,8 @@ loop: SWAPINIT(a, es); pc -= es; } - pn = (char *)a + n * es; - r = min(pa - (char *)a, pb - pa); + pn = a + n * es; + r = min(pa - a, pb - pa); vecswap(a, pb - r, r); r = min(pd - pc, pn - pd - es); vecswap(pb, pn - r, r);
Re: find(1): pledge mayexecve codepath
Theo Buehler wrote: > tedu's -delete diff reminded me of a patch I've had in one of my trees > for quite a while: find(1) was tamed a few days before execve(2) was > added to kern_tame.c and I think it was simply forgotten that everything > was already prepared for this. Now it's slightly more complicated than > before because of the -delete option. Yeah. I had to fiddle because I was adding something. I wasn't sure if it would be better to add a switch? Pick a string and then call pledge(perms). We don't typically do that, but is there a tipping point where the if/err dance gets too repititive? > > Index: find.c > === > RCS file: /cvs/src/usr.bin/find/find.c,v > retrieving revision 1.21 > diff -u -p -r1.21 find.c > --- find.c3 Jan 2017 21:31:16 - 1.21 > +++ find.c3 Jan 2017 21:44:50 - > @@ -162,6 +162,15 @@ find_execute(PLAN *plan, /* search plan > if (pledge("stdio rpath getpw", NULL) == -1) > err(1, "pledge"); > } > + } else { > + if (isdelete) { > + if (pledge("stdio rpath cpath getpw proc exec", NULL) > + == -1) > + err(1, "pledge"); > + } else { > + if (pledge("stdio rpath getpw proc exec", NULL) == -1) > + err(1, "pledge"); > + } > } > > rval = 0; >
Re: find(1): pledge mayexecve codepath
On Tue, 03 Jan 2017 23:52:46 +0100, Theo Buehler wrote: > tedu's -delete diff reminded me of a patch I've had in one of my trees > for quite a while: find(1) was tamed a few days before execve(2) was > added to kern_tame.c and I think it was simply forgotten that everything > was already prepared for this. Now it's slightly more complicated than > before because of the -delete option. OK millert@ - todd
find(1): pledge mayexecve codepath
tedu's -delete diff reminded me of a patch I've had in one of my trees for quite a while: find(1) was tamed a few days before execve(2) was added to kern_tame.c and I think it was simply forgotten that everything was already prepared for this. Now it's slightly more complicated than before because of the -delete option. Index: find.c === RCS file: /cvs/src/usr.bin/find/find.c,v retrieving revision 1.21 diff -u -p -r1.21 find.c --- find.c 3 Jan 2017 21:31:16 - 1.21 +++ find.c 3 Jan 2017 21:44:50 - @@ -162,6 +162,15 @@ find_execute(PLAN *plan, /* search plan if (pledge("stdio rpath getpw", NULL) == -1) err(1, "pledge"); } + } else { + if (isdelete) { + if (pledge("stdio rpath cpath getpw proc exec", NULL) + == -1) + err(1, "pledge"); + } else { + if (pledge("stdio rpath getpw proc exec", NULL) == -1) + err(1, "pledge"); + } } rval = 0;
Re: find -delete
Mark Kettenis wrote: > I really think we should not encourage unportable code like that by > giving an example in our manual page. That's fair. > I'm even tempted to say that you should leave the "-exec rm {} \;" > example alone. The + here only works because rm(1) accepts multiple > file arguments. This whole adventure started because I was trying to delete 10 old emails. The default recipe, which execs one rm per file, was taking forever. It would probably still be running. If I'm reading the find man page because I'm trying to delete so many files I would overflow argv with shell wildcards, I definitely want the turbo recipe. > And I don't understand the sentence about recursively removing > non-empty directories; rm(1) doesn't remove directories unless you use the > -r option! If some of the files you want to delete are directories, the obvious solution when using xargs or -exec is to add -r to rm. But then this will change behavior. I think it's possible to cook up a find invocation that uses -type d -exec rmdir {} \; -o \! -type d -exec rm {} \; but as you see, it gets unwieldy fast. I thought this would be worth highlighting.
Re: find -delete
>> From: "Ted Unangst">> Date: Tue, 03 Jan 2017 16:39:48 -0500 >> >> I copied this straight from freebsd. Not fixed, but feel free to correct as >> desired. >> >> This adds a third example showing -delete, mentioning that it's not standard, >> but also hinting that it may work better than "rm -r" when you want to delete >> directories. > >I really think we should not encourage unportable code like that by >giving an example in our manual page. Well lets be honest, we are accepting this feature last; it was only missing in openbsd and whocaris
Re: find -delete
> From: "Ted Unangst"> Date: Tue, 03 Jan 2017 16:39:48 -0500 > > I copied this straight from freebsd. Not fixed, but feel free to correct as > desired. > > This adds a third example showing -delete, mentioning that it's not standard, > but also hinting that it may work better than "rm -r" when you want to delete > directories. I really think we should not encourage unportable code like that by giving an example in our manual page. I'm even tempted to say that you should leave the "-exec rm {} \;" example alone. The + here only works because rm(1) accepts multiple file arguments. And I don't understand the sentence about recursively removing non-empty directories; rm(1) doesn't remove directories unless you use the -r option! > Index: find.1 > === > RCS file: /cvs/src/usr.bin/find/find.1,v > retrieving revision 1.92 > diff -u -p -r1.92 find.1 > --- find.13 Jan 2017 21:31:16 - 1.92 > +++ find.13 Jan 2017 21:36:30 - > @@ -575,9 +575,15 @@ ending in a dot and single digit, but sk > Find and remove all *.jpg and *.gif files under the current working > directory: > .Pp > -.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} \e;" > +.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} +" > or > .Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -print0 | xargs -0r rm" > +or > +.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -delete" > +.Pp > +Note that this third version is not guaranteed to be portable. > +However, if it is desired to delete directories as well, it may be safer > +because it will not accidentally recursively remove non-emtpy directories. > .Sh SEE ALSO > .Xr chflags 1 , > .Xr chmod 1 , > >
Re: find -delete
Jason McIntyre wrote: > no opinion on the addition, but if there is a better way to write the > examples that are there, i think you should take the time to do so. i'd > also slightly prefer we show the more traditional way to do it, though i > appreciate that might not make a ton of sense for find(1). Patch below. > i'd use Sq rather than Dq for single letters if you really need it > quoted. and check, but i think you need \& after the dot, not before, or > you'll get a double space injected. I copied this straight from freebsd. Not fixed, but feel free to correct as desired. This adds a third example showing -delete, mentioning that it's not standard, but also hinting that it may work better than "rm -r" when you want to delete directories. Index: find.1 === RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.92 diff -u -p -r1.92 find.1 --- find.1 3 Jan 2017 21:31:16 - 1.92 +++ find.1 3 Jan 2017 21:36:30 - @@ -575,9 +575,15 @@ ending in a dot and single digit, but sk Find and remove all *.jpg and *.gif files under the current working directory: .Pp -.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} \e;" +.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} +" or .Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -print0 | xargs -0r rm" +or +.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -delete" +.Pp +Note that this third version is not guaranteed to be portable. +However, if it is desired to delete directories as well, it may be safer +because it will not accidentally recursively remove non-emtpy directories. .Sh SEE ALSO .Xr chflags 1 , .Xr chmod 1 ,
Re: Recursive NET_LOCK()
> Date: Tue, 3 Jan 2017 17:13:27 +0100 > From: Martin Pieuchot> > It seems that most of the problems exposed by the introduction of the > NET_LOCK() are related to the non-recursive nature of the rwlock. Some > known issues involve pflow(4), cloning interfaces an NFS. > > Diff below makes use of a recursive-rwlock instead. I just finished a > build on NFS with it, so I'd like to know if it works for your use case. > > Please test and report back. This does not fix the chrome hang that I was seeing. > Index: kern/kern_rwlock.c > === > RCS file: /cvs/src/sys/kern/kern_rwlock.c,v > retrieving revision 1.27 > diff -u -p -r1.27 kern_rwlock.c > --- kern/kern_rwlock.c14 Mar 2015 07:33:42 - 1.27 > +++ kern/kern_rwlock.c3 Jan 2017 14:23:56 - > @@ -346,3 +346,23 @@ rrw_status(struct rrwlock *rrwl) > { > return (rw_status(>rrwl_lock)); > } > + > +int > +rrw_release_all(struct rrwlock *rrwl) > +{ > + int rv; > + > + rv = rrwl->rrwl_wcnt; > + KASSERT(rv >= 1); > + rrwl->rrwl_wcnt = 1; > + rrw_exit(rrwl); > + > + return (rv); > +} > + > +void > +rrw_acquire_count(struct rrwlock *rrwl, int count, int flags) > +{ > + while (count--) > + rrw_enter(rrwl, flags); > +} > Index: kern/kern_synch.c > === > RCS file: /cvs/src/sys/kern/kern_synch.c,v > retrieving revision 1.135 > diff -u -p -r1.135 kern_synch.c > --- kern/kern_synch.c 13 Sep 2016 08:32:44 - 1.135 > +++ kern/kern_synch.c 3 Jan 2017 14:07:23 - > @@ -231,27 +231,28 @@ msleep(const volatile void *ident, struc > * entered the sleep queue we drop the it. After sleeping we re-lock. > */ > int > -rwsleep(const volatile void *ident, struct rwlock *wl, int priority, > +rrwsleep(const volatile void *ident, struct rrwlock *rrwl, int priority, > const char *wmesg, int timo) > { > struct sleep_state sls; > int error, error1; > + int count; > > KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0); > - rw_assert_wrlock(wl); > + KASSERT(rrw_status(rrwl) == RW_WRITE); > > sleep_setup(, ident, priority, wmesg); > sleep_setup_timeout(, timo); > sleep_setup_signal(, priority); > > - rw_exit_write(wl); > + count = rrw_release_all(rrwl); > > sleep_finish(, 1); > error1 = sleep_finish_timeout(); > error = sleep_finish_signal(); > > if ((priority & PNORELOCK) == 0) > - rw_enter_write(wl); > + rrw_acquire_count(rrwl, count, RW_WRITE); > > /* Signal errors are higher priority than timeouts. */ > if (error == 0 && error1 != 0) > Index: kern/uipc_socket.c > === > RCS file: /cvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.171 > diff -u -p -r1.171 uipc_socket.c > --- kern/uipc_socket.c29 Dec 2016 12:12:43 - 1.171 > +++ kern/uipc_socket.c3 Jan 2017 14:04:42 - > @@ -256,7 +256,7 @@ soclose(struct socket *so) > (so->so_state & SS_NBIO)) > goto drop; > while (so->so_state & SS_ISCONNECTED) { > - error = tsleep(>so_timeo, > + error = rrwsleep(>so_timeo, , > PSOCK | PCATCH, "netcls", > so->so_linger * hz); > if (error) > @@ -1039,7 +1039,7 @@ sorflush(struct socket *so) > struct sockbuf asb; > > sb->sb_flags |= SB_NOINTR; > - (void) sblock(sb, M_WAITOK, NULL); > + (void) sblock(sb, M_WAITOK, ); > socantrcvmore(so); > sbunlock(sb); > asb = *sb; > Index: kern/uipc_socket2.c > === > RCS file: /cvs/src/sys/kern/uipc_socket2.c,v > retrieving revision 1.70 > diff -u -p -r1.70 uipc_socket2.c > --- kern/uipc_socket2.c 29 Dec 2016 12:12:43 - 1.70 > +++ kern/uipc_socket2.c 3 Jan 2017 14:06:54 - > @@ -53,7 +53,7 @@ u_long sb_max = SB_MAX;/* patchable */ > extern struct pool mclpools[]; > extern struct pool mbpool; > > -int sbsleep(struct sockbuf *, struct rwlock *); > +int sbsleep(struct sockbuf *, struct rrwlock *); > > /* > * Procedures to manipulate state flags of socket > @@ -276,18 +276,18 @@ sbwait(struct sockbuf *sb) > NET_ASSERT_LOCKED(); > > sb->sb_flagsintr |= SB_WAIT; > - return (tsleep(>sb_cc, > + return (rrwsleep(>sb_cc, , > (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH, "netio", > sb->sb_timeo)); > } > > int > -sbsleep(struct sockbuf *sb, struct rwlock *lock) > +sbsleep(struct sockbuf *sb, struct rrwlock *rrwl) > { > int error, prio = (sb->sb_flags & SB_NOINTR) ? PSOCK :
ld.so diff that needs testing on landisk
The diff below (partly by guenther@) removes ld.so's dependency on the __got_{start,end} symbols by looking at PT_GNU_RELRO instead. On some platforms (hppa and perhaps a few others) this leads to even less writable pages. However, we're not sure if this will work correctly on landisk. So if somebody with a fairly up-to-date landisk could give this a spin for us, it would be highly appreciated. Index: libexec/ld.so/boot.c === RCS file: /cvs/src/libexec/ld.so/boot.c,v retrieving revision 1.14 diff -u -p -r1.14 boot.c --- libexec/ld.so/boot.c13 Aug 2016 20:57:04 - 1.14 +++ libexec/ld.so/boot.c2 Jan 2017 15:55:52 - @@ -87,6 +87,8 @@ _dl_boot_bind(const long sp, long *dl_da longloff; Elf_Addri; RELOC_TYPE *rp; + Elf_Ehdr*ehdp; + Elf_Phdr*phdp; /* * Scan argument and environment vectors. Find dynamic @@ -189,4 +191,30 @@ _dl_boot_bind(const long sp, long *dl_da * we have been fully relocated here, so most things no longer * need the loff adjustment */ + + /* +* No further changes to the PLT and/or GOT are needed so make +* them read-only. +*/ + + /* do any RWX -> RX fixups for executable PLTs and apply GNU_RELRO */ + ehdp = (Elf_Ehdr *)loff; + phdp = (Elf_Phdr *)(loff + ehdp->e_phoff); + for (i = 0; i < dl_data[AUX_phnum]; i++, phdp++) { + switch (phdp->p_type) { +#if defined(__alpha__) || defined(__hppa__) || defined(__powerpc__) || \ +defined(__sparc64__) + case PT_LOAD: + if ((phdp->p_flags & (PF_X | PF_W)) != (PF_X | PF_W)) + break; + _dl_mprotect((void *)(phdp->p_vaddr + loff), + phdp->p_memsz, PROT_READ); + break; +#endif + case PT_GNU_RELRO: + _dl_mprotect((void *)(phdp->p_vaddr + loff), + phdp->p_memsz, PROT_READ); + break; + } + } } Index: libexec/ld.so/loader.c === RCS file: /cvs/src/libexec/ld.so/loader.c,v retrieving revision 1.167 diff -u -p -r1.167 loader.c --- libexec/ld.so/loader.c 28 Aug 2016 04:33:17 - 1.167 +++ libexec/ld.so/loader.c 2 Jan 2017 15:55:52 - @@ -413,25 +413,6 @@ _dl_boot(const char **argv, char **envp, #define ROUND_PG(x) (((x) + align) & ~(align)) #define TRUNC_PG(x) ((x) & ~(align)) - /* -* now that GOT and PLT have been relocated, and we know -* page size, protect them from modification -*/ -#ifndef RTLD_NO_WXORX - { - extern char *__got_start; - extern char *__got_end; - - if (&__got_start != &__got_end) { - _dl_mprotect((void *)ELF_TRUNC((long)&__got_start, - _dl_pagesz), - ELF_ROUND((long)&__got_end,_dl_pagesz) - - ELF_TRUNC((long)&__got_start, _dl_pagesz), - GOT_PERMS); - } - } -#endif - _dl_setup_env(argv[0], envp); DL_DEB(("rtld loading: '%s'\n", __progname)); Index: libexec/ld.so/alpha/archdep.h === RCS file: /cvs/src/libexec/ld.so/alpha/archdep.h,v retrieving revision 1.17 diff -u -p -r1.17 archdep.h --- libexec/ld.so/alpha/archdep.h 6 Dec 2015 23:36:12 - 1.17 +++ libexec/ld.so/alpha/archdep.h 2 Jan 2017 15:55:52 - @@ -65,6 +65,4 @@ RELOC_DYN(Elf64_Rela *r, const Elf64_Sym #define RELOC_GOT(obj, offs) -#define GOT_PERMS PROT_READ - #endif /* _ALPHA_ARCHDEP_H_ */ Index: libexec/ld.so/amd64/archdep.h === RCS file: /cvs/src/libexec/ld.so/amd64/archdep.h,v retrieving revision 1.8 diff -u -p -r1.8 archdep.h --- libexec/ld.so/amd64/archdep.h 18 May 2016 20:40:20 - 1.8 +++ libexec/ld.so/amd64/archdep.h 2 Jan 2017 15:55:52 - @@ -68,6 +68,4 @@ RELOC_DYN(Elf64_Rela *r, const Elf64_Sym #define RELOC_GOT(obj, offs) -#define GOT_PERMS PROT_READ - #endif /* _X86_64_ARCHDEP_H_ */ Index: libexec/ld.so/arm/archdep.h === RCS file: /cvs/src/libexec/ld.so/arm/archdep.h,v retrieving revision 1.8 diff -u -p -r1.8 archdep.h --- libexec/ld.so/arm/archdep.h 8 Sep 2016 18:56:58 - 1.8 +++ libexec/ld.so/arm/archdep.h 2 Jan 2017 15:55:52 - @@ -73,6 +73,4 @@ RELOC_DYN(Elf_Rel *r, const Elf_Sym *s, #define RELOC_GOT(obj, offs) -#define GOT_PERMS (PROT_READ|PROT_EXEC) - #endif /* _ARM_ARCHDEP_H_ */ Index: libexec/ld.so/hppa/archdep.h
Re: qsort.c: remove useless variable
On Tue, Jan 03, 2017 at 12:57:59PM -0700, Todd C. Miller wrote: > When qsort.c was de-registered, the register version of 'aa' was > not removed. Since qsort() already contains casts of a to char * > there's no need for a separate variable here. I think it would be nicer to keep the char * a variable and remove the (char *) casts instead. bluhm > > - todd > > Index: lib/libc/stdlib/qsort.c > === > RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v > retrieving revision 1.13 > diff -u -p -u -r1.13 qsort.c > --- lib/libc/stdlib/qsort.c 13 Sep 2015 08:31:47 - 1.13 > +++ lib/libc/stdlib/qsort.c 3 Jan 2017 14:29:03 - > @@ -81,12 +81,11 @@ med3(char *a, char *b, char *c, int (*cm > } > > void > -qsort(void *aa, size_t n, size_t es, int (*cmp)(const void *, const void *)) > +qsort(void *a, size_t n, size_t es, int (*cmp)(const void *, const void *)) > { > char *pa, *pb, *pc, *pd, *pl, *pm, *pn; > int cmp_result, swaptype; > size_t d, r; > - char *a = aa; > > loop:SWAPINIT(a, es); > if (n < 7) {
Re: vndcompress et al import?
Timo Buhrmester wrote: > > delete [vnd] entirely > Out of curiosity (I'm mostly a NetBSD user), without vnd what would be > the OpenBSD-way of providing a disk-ish interface to a file? Well, the biggest use of vnd in base was just replaced with the makefs. (from netbsd, actually.) vnd isn't going to be deleted, but it's pretty easy to make a vscsi provider that talks to a file. If i had a pressing need to mount compressed disk images, I'd start there. (I had some code for this, but it's in another castle. It's pretty short, only like 20 lines anyway.)
Re: compiler-rt: upgrade to 3.9.1 / fix gcc personality compile error
> Date: Tue, 3 Jan 2017 17:49:19 +0100 > From: Patrick Wildt> > Hi, > > the GCC personality C file does not compile with clang 3.8 on ARM. They > have fixed the issue in compiler-rt and released 3.9.1. Apparently that > is the only thing they changed in the builtins. Thus this diff is in > essence an update to the compiler-rt release 3.9.1. > > ok? Don't fully understand the issue, but it's probably best to go with the flow. ok kettenis@ > diff --git a/lib/libcompiler_rt/gcc_personality_v0.c > b/lib/libcompiler_rt/gcc_personality_v0.c > index 29e5be30712..0bc76562456 100644 > --- a/lib/libcompiler_rt/gcc_personality_v0.c > +++ b/lib/libcompiler_rt/gcc_personality_v0.c > @@ -12,6 +12,17 @@ > #include "int_lib.h" > > #include > +#if defined(__arm__) && !defined(__ARM_DWARF_EH__) && > !defined(__USING_SJLJ_EXCEPTIONS__) > +/* > + * When building with older compilers (e.g. clang <3.9), it is possible that > we > + * have a version of unwind.h which does not provide the EHABI declarations > + * which are quired for the C personality to conform to the specification. > In > + * order to provide forward compatibility for such compilers, we re-declare > the > + * necessary interfaces in the helper to permit a standalone compilation of > the > + * builtins (which contains the C unwinding personality for historical > reasons). > + */ > +#include "unwind-ehabi-helpers.h" > +#endif > > /* > * Pointer encodings documented at: > diff --git a/lib/libcompiler_rt/unwind-ehabi-helpers.h > b/lib/libcompiler_rt/unwind-ehabi-helpers.h > new file mode 100644 > index 000..ccb0765975a > --- /dev/null > +++ b/lib/libcompiler_rt/unwind-ehabi-helpers.h > @@ -0,0 +1,55 @@ > +/* ===-- arm-ehabi-helpers.h - Supplementary ARM EHABI declarations > === > + * > + * The LLVM Compiler Infrastructure > + * > + * This file is dual licensed under the MIT and the University of Illinois > Open > + * Source Licenses. See LICENSE.TXT for details. > + * > + * > ====== */ > + > +#ifndef UNWIND_EHABI_HELPERS_H > +#define UNWIND_EHABI_HELPERS_H > + > +#include > +/* NOTE: see reasoning for this inclusion below */ > +#include > + > +#if !defined(__ARM_EABI_UNWINDER__) > + > +/* > + * NOTE: _URC_OK, _URC_FAILURE must be present as preprocessor tokens. This > + * allows for a substitution of a constant which can be cast into the > + * appropriate enumerated type. This header is expected to always be > included > + * AFTER unwind.h (which is why it is forcefully included above). This > ensures > + * that we do not overwrite the token for the enumeration. Subsequent uses > of > + * the token would be clean to rewrite with constant values. > + * > + * The typedef redeclaration should be safe. Due to the protection granted > to > + * us by the `__ARM_EABI_UNWINDER__` above, we are guaranteed that we are in > a > + * header not vended by gcc. The HP unwinder (being an itanium unwinder) > does > + * not support EHABI, and the GNU unwinder, derived from the HP unwinder, > also > + * does not support EHABI as of the introduction of this header. As such, we > + * are fairly certain that we are in the LLVM case. Here, _Unwind_State is a > + * typedef, and so we can get away with a redeclaration. > + * > + * Guarded redefinitions of the needed unwind state prevent the redefinition > of > + * those states. > + */ > + > +#define _URC_OK 0 > +#define _URC_FAILURE 9 > + > +typedef uint32_t _Unwind_State; > + > +#if !defined(_US_UNWIND_FRAME_STARTING) > +#define _US_UNWIND_FRAME_STARTING ((_Unwind_State)1) > +#endif > + > +#if !defined(_US_ACTION_MASK) > +#define _US_ACTION_MASK ((_Unwind_State)3) > +#endif > + > +#endif > + > +#endif > + > >
Re: vndcompress et al import?
> delete [vnd] entirely Out of curiosity (I'm mostly a NetBSD user), without vnd what would be the OpenBSD-way of providing a disk-ish interface to a file?
qsort.c: remove useless variable
When qsort.c was de-registered, the register version of 'aa' was not removed. Since qsort() already contains casts of a to char * there's no need for a separate variable here. - todd Index: lib/libc/stdlib/qsort.c === RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v retrieving revision 1.13 diff -u -p -u -r1.13 qsort.c --- lib/libc/stdlib/qsort.c 13 Sep 2015 08:31:47 - 1.13 +++ lib/libc/stdlib/qsort.c 3 Jan 2017 14:29:03 - @@ -81,12 +81,11 @@ med3(char *a, char *b, char *c, int (*cm } void -qsort(void *aa, size_t n, size_t es, int (*cmp)(const void *, const void *)) +qsort(void *a, size_t n, size_t es, int (*cmp)(const void *, const void *)) { char *pa, *pb, *pc, *pd, *pl, *pm, *pn; int cmp_result, swaptype; size_t d, r; - char *a = aa; loop: SWAPINIT(a, es); if (n < 7) {
Re: vndcompress et al import?
> Franco Fichtner wrote: > > Hi, > > > > Is anyone aware or interested in porting vndcompress et al > > from NetBSD to OpenBSD? > > > > Is there any technical reason against inclusion? > > well, vnd is kind of on life support. my efforts to delete it entirely have > mostly stalled, but new features are probably best added to some other > component. It's not going to happen. It would be a pointless exercise, I don't see any point in supporting this.
Re: vndcompress et al import?
Franco Fichtner wrote: > Hi, > > Is anyone aware or interested in porting vndcompress et al > from NetBSD to OpenBSD? > > Is there any technical reason against inclusion? well, vnd is kind of on life support. my efforts to delete it entirely have mostly stalled, but new features are probably best added to some other component.
Re: Recursive NET_LOCK()
On 03/01/17(Tue) 14:08, Ted Unangst wrote: > Martin Pieuchot wrote: > > It seems that most of the problems exposed by the introduction of the > > NET_LOCK() are related to the non-recursive nature of the rwlock. Some > > known issues involve pflow(4), cloning interfaces an NFS. > > > > Diff below makes use of a recursive-rwlock instead. I just finished a > > build on NFS with it, so I'd like to know if it works for your use case. > > I don't want to interfere with progress, so if you think this is best, carry > on. > > But I'll note that using recursive locks leads to sloppy locking discipline, > which is exactly how we find ourselves in this mess today. Need the lock? Not > sure? Grab it anyway. > > The rrwlock was added for the particular use case of vfs locking, which is > already a recursive cluster fuck, but wasn't supposed to be used for new code. > Of course, the network stack also qualifies as legacy code, so can't object > much to using it there either. > > I imagine you've already thought of this. :) I did :) To be honest I'm not sure if we should take this direction. For the moment I'm trying to learn as much as possible about the problems we're facing. If it appears to be just sloppy recursive code then we can decide what to do with it and when. I am also looking for more feedbacks and/or inputs so I appreciate your email on the matter.
Re: libcrypto: fix assembly for clang
Patrick Wildt wrote: > > Maybe they want to support older binutils that do not support the unified > syntax? > What's our policy there? OpenBSD is just about the oldest binutils around. I wouldn't worry about anything older than what we have in base.
Re: ed(1) doesn't support adress ranges which begin with comma or semicolon
Theo Buehler wrote: > On Sat, Dec 24, 2016 at 10:45:16PM +0100, Theo Buehler wrote: > > On Sat, Dec 24, 2016 at 05:44:07PM +0100, Jérôme FRGACIC wrote: > > > Hi @tech, > > > > > > I remark that ed(1) do not support adress ranges which begin with > > > comma or semicolon, for example ",10p" which is equivalent to "1,10p" or > > > "; +10p" which is equivalent to ".;+10p". These adress ranges are > > > specified by Open Group Base Specifications Issue 6 (IEEE Std 1003.1, > > > 2004 Edition) (in fact, there are also adress ranges like "10," which > > > is equivalent to "10,10" but they seem useless to me...). > > > > > > I would suggest this diff to add support for these adress ranges. > > > > ok tb@ > > anyone willing to commit this or give another ok? Looks good to me. ok stefan@ > > > > > Index: main.c > > > === > > > RCS file: /cvs/src/bin/ed/main.c,v > > > retrieving revision 1.58 > > > diff -u -r1.58 main.c > > > --- main.c16 Aug 2016 20:04:46 - 1.58 > > > +++ main.c24 Dec 2016 15:26:41 - > > > @@ -383,7 +383,9 @@ > > > ibufp++; > > > addr_cnt++; > > > second_addr = (c == ';') ? > > > current_addr : 1; > > > - addr = addr_last; > > > + addr = next_addr(); > > > + if (addr < 0) > > > + addr = addr_last; > > > break; > > > } > > > /* FALLTHROUGH */ > > > > > > PS : I haven't subcribe to the tech mailing list, so please add me as > > > recipient if you reply. > > > PPS : Merry Christmas. > > > > > > > > > Kind regards, > > > > > > > > > Jérôme FRGACIC > > > > > >
Re: Recursive NET_LOCK()
Martin Pieuchot wrote: > It seems that most of the problems exposed by the introduction of the > NET_LOCK() are related to the non-recursive nature of the rwlock. Some > known issues involve pflow(4), cloning interfaces an NFS. > > Diff below makes use of a recursive-rwlock instead. I just finished a > build on NFS with it, so I'd like to know if it works for your use case. I don't want to interfere with progress, so if you think this is best, carry on. But I'll note that using recursive locks leads to sloppy locking discipline, which is exactly how we find ourselves in this mess today. Need the lock? Not sure? Grab it anyway. The rrwlock was added for the particular use case of vfs locking, which is already a recursive cluster fuck, but wasn't supposed to be used for new code. Of course, the network stack also qualifies as legacy code, so can't object much to using it there either. I imagine you've already thought of this. :)
libcrypto: fix assembly for clang
Hi, clang complains about the ARM assembly, since it expects the conditional branch instructions to state the condition (in this case pl/ne) after the "b" for branch. We also need to state that we're using the unified syntax, so that binutils 2.17 likes it as well. OpenSSL fixed that issue in another way: .text #if defined(__thumb2__) || defined(__clang__) .syntax unified #endif #if defined(__thumb2__) .thumb #else .code 32 #endif #ifdef __clang__ #define ldrplb ldrbpl #define ldrneb ldrbne #endif Maybe they want to support older binutils that do not support the unified syntax? What's our policy there? Comments? Patrick diff --git a/lib/libcrypto/modes/asm/ghash-armv4.pl b/lib/libcrypto/modes/asm/ghash-armv4.pl index d91586ee292..4f8372d8974 100644 --- a/lib/libcrypto/modes/asm/ghash-armv4.pl +++ b/lib/libcrypto/modes/asm/ghash-armv4.pl @@ -110,6 +110,7 @@ $code=<<___; #include "arm_arch.h" .text +.syntaxunified .code 32 .type rem_4bit,%object @@ -182,7 +183,7 @@ gcm_ghash_4bit: eor $Zlh,$Zlh,$Zhl,lsl#28 ldrh$Tll,[sp,$nlo] @ rem_4bit[rem] eor $Zhl,$Thl,$Zhl,lsr#4 - ldrplb $nlo,[$inp,$cnt] + ldrbpl $nlo,[$inp,$cnt] eor $Zhl,$Zhl,$Zhh,lsl#28 eor $Zhh,$Thh,$Zhh,lsr#4 @@ -192,7 +193,7 @@ gcm_ghash_4bit: add $nhi,$nhi,$nhi ldmia $Thh,{$Tll-$Thh}@ load Htbl[nhi] eor $Zll,$Tll,$Zll,lsr#4 - ldrplb $Tll,[$Xi,$cnt] + ldrbpl $Tll,[$Xi,$cnt] eor $Zll,$Zll,$Zlh,lsl#28 eor $Zlh,$Tlh,$Zlh,lsr#4 ldrh$Tlh,[sp,$nhi] @@ -210,7 +211,7 @@ gcm_ghash_4bit: add $inp,$inp,#16 mov $nhi,$Zll ___ - ("cmp\t$inp,$len","ldrneb\t$nlo,[$inp,#15]"); + ("cmp\t$inp,$len","ldrbne\t$nlo,[$inp,#15]"); $code.=<<___; bne .Louter @@ -268,7 +269,7 @@ gcm_gmult_4bit: eor $Zlh,$Zlh,$Zhl,lsl#28 ldrh$Tll,[$rem_4bit,$nlo] @ rem_4bit[rem] eor $Zhl,$Thl,$Zhl,lsr#4 - ldrplb $nlo,[$Xi,$cnt] + ldrbpl $nlo,[$Xi,$cnt] eor $Zhl,$Zhl,$Zhh,lsl#28 eor $Zhh,$Thh,$Zhh,lsr#4
xargs(1): remove unused variable
The repllen variable is not used anywhere. Index: strnsubst.c === RCS file: /cvs/src/usr.bin/xargs/strnsubst.c,v retrieving revision 1.5 diff -u -r1.5 strnsubst.c --- strnsubst.c 27 Oct 2009 23:59:50 - 1.5 +++ strnsubst.c 3 Jan 2017 10:26:22 - @@ -31,7 +31,7 @@ strnsubst(char **str, const char *match, const char *replstr, size_t maxsize) { char *s1, *s2, *this; - size_t matchlen, repllen, s2len; + size_t matchlen, s2len; int n; if ((s1 = *str) == NULL) @@ -50,7 +50,6 @@ *s2 = '\0'; s2len = 0; matchlen = strlen(match); - repllen = strlen(replstr); for (;;) { if ((this = strstr(s1, match)) == NULL) break;
Re: Recursive NET_LOCK()
On Tue, Jan 03, 2017 at 05:13:27PM +0100, Martin Pieuchot wrote: > It seems that most of the problems exposed by the introduction of the > NET_LOCK() are related to the non-recursive nature of the rwlock. Some > known issues involve pflow(4), cloning interfaces an NFS. > > Diff below makes use of a recursive-rwlock instead. I just finished a > build on NFS with it, so I'd like to know if it works for your use case. > > Please test and report back. I started to use it on my gateway (which use pflow and which paniced previously). For now, there is no problem, whereas previously panic occurred soon after starting. I will keep it running. Thanks. -- Sebastien Marie
compiler-rt: upgrade to 3.9.1 / fix gcc personality compile error
Hi, the GCC personality C file does not compile with clang 3.8 on ARM. They have fixed the issue in compiler-rt and released 3.9.1. Apparently that is the only thing they changed in the builtins. Thus this diff is in essence an update to the compiler-rt release 3.9.1. ok? Patrick diff --git a/lib/libcompiler_rt/gcc_personality_v0.c b/lib/libcompiler_rt/gcc_personality_v0.c index 29e5be30712..0bc76562456 100644 --- a/lib/libcompiler_rt/gcc_personality_v0.c +++ b/lib/libcompiler_rt/gcc_personality_v0.c @@ -12,6 +12,17 @@ #include "int_lib.h" #include +#if defined(__arm__) && !defined(__ARM_DWARF_EH__) && !defined(__USING_SJLJ_EXCEPTIONS__) +/* + * When building with older compilers (e.g. clang <3.9), it is possible that we + * have a version of unwind.h which does not provide the EHABI declarations + * which are quired for the C personality to conform to the specification. In + * order to provide forward compatibility for such compilers, we re-declare the + * necessary interfaces in the helper to permit a standalone compilation of the + * builtins (which contains the C unwinding personality for historical reasons). + */ +#include "unwind-ehabi-helpers.h" +#endif /* * Pointer encodings documented at: diff --git a/lib/libcompiler_rt/unwind-ehabi-helpers.h b/lib/libcompiler_rt/unwind-ehabi-helpers.h new file mode 100644 index 000..ccb0765975a --- /dev/null +++ b/lib/libcompiler_rt/unwind-ehabi-helpers.h @@ -0,0 +1,55 @@ +/* ===-- arm-ehabi-helpers.h - Supplementary ARM EHABI declarations === + * + * The LLVM Compiler Infrastructure + * + * This file is dual licensed under the MIT and the University of Illinois Open + * Source Licenses. See LICENSE.TXT for details. + * + * ====== */ + +#ifndef UNWIND_EHABI_HELPERS_H +#define UNWIND_EHABI_HELPERS_H + +#include +/* NOTE: see reasoning for this inclusion below */ +#include + +#if !defined(__ARM_EABI_UNWINDER__) + +/* + * NOTE: _URC_OK, _URC_FAILURE must be present as preprocessor tokens. This + * allows for a substitution of a constant which can be cast into the + * appropriate enumerated type. This header is expected to always be included + * AFTER unwind.h (which is why it is forcefully included above). This ensures + * that we do not overwrite the token for the enumeration. Subsequent uses of + * the token would be clean to rewrite with constant values. + * + * The typedef redeclaration should be safe. Due to the protection granted to + * us by the `__ARM_EABI_UNWINDER__` above, we are guaranteed that we are in a + * header not vended by gcc. The HP unwinder (being an itanium unwinder) does + * not support EHABI, and the GNU unwinder, derived from the HP unwinder, also + * does not support EHABI as of the introduction of this header. As such, we + * are fairly certain that we are in the LLVM case. Here, _Unwind_State is a + * typedef, and so we can get away with a redeclaration. + * + * Guarded redefinitions of the needed unwind state prevent the redefinition of + * those states. + */ + +#define _URC_OK 0 +#define _URC_FAILURE 9 + +typedef uint32_t _Unwind_State; + +#if !defined(_US_UNWIND_FRAME_STARTING) +#define _US_UNWIND_FRAME_STARTING ((_Unwind_State)1) +#endif + +#if !defined(_US_ACTION_MASK) +#define _US_ACTION_MASK ((_Unwind_State)3) +#endif + +#endif + +#endif +
Re: Unable to boot since latest installer HTTPS changes
Hey, On 01/03/17 17:29, Theo de Raadt wrote: I am on AMD64. I cannot provide a dmesg of that machine because i am unable to boot it at all. Sure you can -- install 6.0 to do show it. stupid me, i did not think about that. Here i attached a fresh dmesg for you. Really sorry about that Greetings Leo OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17139134464 (16345MB) avail mem = 16615231488 (15845MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xead50 (101 entries) bios0: vendor American Megatrends Inc. version "1606" date 04/26/2011 bios0: ASUSTeK Computer INC. P8P67 DELUXE acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG HPET acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) BR20(S3) USBE(S4) P0P3(S4) P0P4(S4) P0P1(S4) P0P2(S4) PEX0(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) BR24(S4) BR31(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3503.22 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 103MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu6: 256KB 64b/line 8-way L2 cache cpu6: smt 1, core 2, package 0 cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu7: 256KB 64b/line 8-way L2 cache cpu7: smt 1, core 3, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0:
Re: Unable to boot since latest installer HTTPS changes
> Hey tech@ > i wanted to upgrade to the latest snapshot (as i always do, every week) > but since you added the HTTPS support to the installer i am unable to > boot my system or the install.fs from a flash drive. > > I get to the MBR and then into the PBR but after probing all discs the > system restarts instantly. No debug prompt or something else. I tryed it > with the latest 3 install.fs or so. But i am unable to boot at all. > > This only happens in MBR mode, i am able to boot in UEFI mode from the > install.fs. > > I also tryed a 4 weeks old install.fs and in there it works fine. So its > not a hardware issue. > > This started to happend around the same time you added HTTPS support to > the installer. > > I am on AMD64. I cannot provide a dmesg of that machine because i am > unable to boot it at all. Sure you can -- install 6.0 to do show it. It is more likely this is related to some small UEFI changes that have occured.
Unable to boot since latest installer HTTPS changes
Hey tech@ i wanted to upgrade to the latest snapshot (as i always do, every week) but since you added the HTTPS support to the installer i am unable to boot my system or the install.fs from a flash drive. I get to the MBR and then into the PBR but after probing all discs the system restarts instantly. No debug prompt or something else. I tryed it with the latest 3 install.fs or so. But i am unable to boot at all. This only happens in MBR mode, i am able to boot in UEFI mode from the install.fs. I also tryed a 4 weeks old install.fs and in there it works fine. So its not a hardware issue. This started to happend around the same time you added HTTPS support to the installer. I am on AMD64. I cannot provide a dmesg of that machine because i am unable to boot it at all. There is someone else on Reddit having the exact same problem. Thanks and greetings Leo
Re: find -delete
OK millert@ for the code. I'll defer to jmc@ on the man page bits. - todd
Recursive NET_LOCK()
It seems that most of the problems exposed by the introduction of the NET_LOCK() are related to the non-recursive nature of the rwlock. Some known issues involve pflow(4), cloning interfaces an NFS. Diff below makes use of a recursive-rwlock instead. I just finished a build on NFS with it, so I'd like to know if it works for your use case. Please test and report back. Index: kern/kern_rwlock.c === RCS file: /cvs/src/sys/kern/kern_rwlock.c,v retrieving revision 1.27 diff -u -p -r1.27 kern_rwlock.c --- kern/kern_rwlock.c 14 Mar 2015 07:33:42 - 1.27 +++ kern/kern_rwlock.c 3 Jan 2017 14:23:56 - @@ -346,3 +346,23 @@ rrw_status(struct rrwlock *rrwl) { return (rw_status(>rrwl_lock)); } + +int +rrw_release_all(struct rrwlock *rrwl) +{ + int rv; + + rv = rrwl->rrwl_wcnt; + KASSERT(rv >= 1); + rrwl->rrwl_wcnt = 1; + rrw_exit(rrwl); + + return (rv); +} + +void +rrw_acquire_count(struct rrwlock *rrwl, int count, int flags) +{ + while (count--) + rrw_enter(rrwl, flags); +} Index: kern/kern_synch.c === RCS file: /cvs/src/sys/kern/kern_synch.c,v retrieving revision 1.135 diff -u -p -r1.135 kern_synch.c --- kern/kern_synch.c 13 Sep 2016 08:32:44 - 1.135 +++ kern/kern_synch.c 3 Jan 2017 14:07:23 - @@ -231,27 +231,28 @@ msleep(const volatile void *ident, struc * entered the sleep queue we drop the it. After sleeping we re-lock. */ int -rwsleep(const volatile void *ident, struct rwlock *wl, int priority, +rrwsleep(const volatile void *ident, struct rrwlock *rrwl, int priority, const char *wmesg, int timo) { struct sleep_state sls; int error, error1; + int count; KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0); - rw_assert_wrlock(wl); + KASSERT(rrw_status(rrwl) == RW_WRITE); sleep_setup(, ident, priority, wmesg); sleep_setup_timeout(, timo); sleep_setup_signal(, priority); - rw_exit_write(wl); + count = rrw_release_all(rrwl); sleep_finish(, 1); error1 = sleep_finish_timeout(); error = sleep_finish_signal(); if ((priority & PNORELOCK) == 0) - rw_enter_write(wl); + rrw_acquire_count(rrwl, count, RW_WRITE); /* Signal errors are higher priority than timeouts. */ if (error == 0 && error1 != 0) Index: kern/uipc_socket.c === RCS file: /cvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.171 diff -u -p -r1.171 uipc_socket.c --- kern/uipc_socket.c 29 Dec 2016 12:12:43 - 1.171 +++ kern/uipc_socket.c 3 Jan 2017 14:04:42 - @@ -256,7 +256,7 @@ soclose(struct socket *so) (so->so_state & SS_NBIO)) goto drop; while (so->so_state & SS_ISCONNECTED) { - error = tsleep(>so_timeo, + error = rrwsleep(>so_timeo, , PSOCK | PCATCH, "netcls", so->so_linger * hz); if (error) @@ -1039,7 +1039,7 @@ sorflush(struct socket *so) struct sockbuf asb; sb->sb_flags |= SB_NOINTR; - (void) sblock(sb, M_WAITOK, NULL); + (void) sblock(sb, M_WAITOK, ); socantrcvmore(so); sbunlock(sb); asb = *sb; Index: kern/uipc_socket2.c === RCS file: /cvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.70 diff -u -p -r1.70 uipc_socket2.c --- kern/uipc_socket2.c 29 Dec 2016 12:12:43 - 1.70 +++ kern/uipc_socket2.c 3 Jan 2017 14:06:54 - @@ -53,7 +53,7 @@ u_longsb_max = SB_MAX;/* patchable */ extern struct pool mclpools[]; extern struct pool mbpool; -int sbsleep(struct sockbuf *, struct rwlock *); +int sbsleep(struct sockbuf *, struct rrwlock *); /* * Procedures to manipulate state flags of socket @@ -276,18 +276,18 @@ sbwait(struct sockbuf *sb) NET_ASSERT_LOCKED(); sb->sb_flagsintr |= SB_WAIT; - return (tsleep(>sb_cc, + return (rrwsleep(>sb_cc, , (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH, "netio", sb->sb_timeo)); } int -sbsleep(struct sockbuf *sb, struct rwlock *lock) +sbsleep(struct sockbuf *sb, struct rrwlock *rrwl) { int error, prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH; - if (lock != NULL) - error = rwsleep(>sb_flags, lock, prio, "netlck", 0); + if (rrwl != NULL) + error = rrwsleep(>sb_flags, rrwl, prio, "netlck", 0); else error = tsleep(>sb_flags, prio, "netlck", 0); @@ -295,7 +295,7 @@ sbsleep(struct sockbuf *sb, struct
Re: [PATCH] iked: Bugfixes for IKE rekeying
Am 09.11.2016 um 20:36 schrieb Vincent Gross: > On Wed, 9 Nov 2016 13:16:46 + > Thomas Klutewrote: > >> Hi tech@, >> >> this patch contains fixes for two bugs that break IKE rekeying >> initiated by iked. Please review, and apply or let me know what has to >> be changed! Both bugs are fixed by initializing the respective >> structures of the new IKE SA (struct iked_sa *nsa in the >> ikev2_ike_sa_rekey function): > > Thanks, we are looking into it. Hi, is there any progress on this? >> For [1]: Copying the address information is required to send any >> request messages over the new IKE SA after rekeying, otherwise errors >> like the following happen because the IP addresses and ports remain >> initialized to zero: >> >> ikev2_msg_send: INFORMATIONAL request from any to any msgid 1, 80 >> bytes ikev2_msg_send: sendtofrom: Invalid argument >> >> For [2]: Setting the DH group based on the currently used one is >> necessary because iked proposes only the currently used transforms >> during IKE rekeying, so trying to use any other group for the DH >> exchange will fail even if it is preferred by local policy (see >> comment in the patch for details). >> >> This patch includes and supersedes the one for only the first bug I >> sent yesterday. >> >> Best regards, >> Thomas >> >> [1] https://marc.info/?l=openbsd-bugs=147739504516767=2 >> [2] https://marc.info/?l=openbsd-bugs=147747405806461=2 >> >> Index: src/sbin/iked/ikev2.c >> === >> RCS file: /cvs/src/sbin/iked/ikev2.c,v >> retrieving revision 1.131 >> diff -u -p -u -r1.131 ikev2.c >> --- src/sbin/iked/ikev2.c2 Jun 2016 07:14:26 - >> 1.131 +++ src/sbin/iked/ikev2.c 9 Nov 2016 13:12:32 - >> @@ -2658,6 +2658,18 @@ ikev2_ike_sa_rekey(struct iked *env, voi >> goto done; >> } >> >> +/* Select the DH group ID based on the currently used >> + * one. Otherwise the call to ikev2_sa_initiator below would >> + * set it to the first DH transform in the policy, while the >> + * SA payload contains only one proposal matching the >> + * currently used transforms. If a different DH transform has >> + * been negotiated this means KE payload and negotiated DH >> + * transform cannot match, causing rekeying to fail. */ >> +if ((nsa->sa_dhgroup = group_get(sa->sa_dhgroup->id)) == >> NULL) { >> +log_debug("%s: failed to initialize DH group", >> __func__); >> +goto done; >> +} >> + >> if (ikev2_sa_initiator(env, nsa, sa, NULL)) { >> log_debug("%s: failed to setup DH", __func__); >> goto done; >> @@ -2665,6 +2677,13 @@ ikev2_ike_sa_rekey(struct iked *env, voi >> sa_state(env, nsa, IKEV2_STATE_AUTH_SUCCESS); >> nonce = nsa->sa_inonce; >> >> +/* Copy local and peer address from the old SA */ >> +if (sa_address(nsa, >sa_peer, >sa_peer.addr) == -1 >> || >> +sa_address(nsa, >sa_local, >sa_local.addr) == >> -1) { >> +log_debug("%s: failed copy address data", __func__); >> +goto done; >> +} >> + >> if ((e = ibuf_static()) == NULL) >> goto done; >> >> >
Re: if attach/detach netlocks
On 3 January 2017 at 12:06, Reyk Floeterwrote: > On Tue, Jan 03, 2017 at 11:42:21AM +0100, Martin Pieuchot wrote: >> On 02/01/17(Mon) 21:51, Mike Belopuhov wrote: >> > I got to test the diff and I had to make another adjustment: >> > vxlan_if_change is setup as a detach hook, however dohooks is >> > called very early in if_detach before we remove IP addresses >> > from the interface. It makes vxlan_config find these IP >> > addresses just fine and re-add its own detach hook again. >> >> Why not fix vxlan_if_change()? >> >> > This >> > repeats ad infinitum hogging the machine. I couldn't think of >> > anything better than deferring an operation via a task. Seems >> > to do the trick. >> >> That's ugly. Why would you re-add anything in a detach hook? This >> is obviously broken. >> > > It is used for the multicast address (only) and it made sense when the > source address wasn't mandatory, eg. 0.0.0.0 -> 239.1.1.100 would find > the next interface that points to the group after detaching the > current one. > > The source is mandatory now, so the diff below should work as well. > > Reyk > Thanks, this looks good, OK mikeb
splsoftnet() in mroute
Diff below gets rid of the various splsoftnet() in multicast forwarding code. I've put asserts to ease review. While here remove #ifdef PIM leftovers. ok? Index: netinet/ip_mroute.c === RCS file: /cvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.101 diff -u -p -r1.101 ip_mroute.c --- netinet/ip_mroute.c 22 Dec 2016 11:04:44 - 1.101 +++ netinet/ip_mroute.c 3 Jan 2017 11:08:50 - @@ -316,20 +316,16 @@ mrt_ioctl(struct socket *so, u_long cmd, int get_sg_cnt(unsigned int rtableid, struct sioc_sg_req *req) { - int s; struct mfc *rt; - s = splsoftnet(); rt = mfc_find(rtableid, >src, >grp); if (rt == NULL) { - splx(s); req->pktcnt = req->bytecnt = req->wrong_if = 0x; return (EADDRNOTAVAIL); } req->pktcnt = rt->mfc_pkt_cnt; req->bytecnt = rt->mfc_byte_cnt; req->wrong_if = rt->mfc_wrong_if; - splx(s); return (0); } @@ -478,11 +474,7 @@ ip_mrouter_init(struct socket *so, struc arc4random_buf([rtableid], sizeof(mfchashkey[rtableid])); memset(nexpire[rtableid], 0, sizeof(nexpire[rtableid])); -#ifdef PIM - pim_assert = 0; -#endif - - timeout_set(_upcalls_ch[rtableid], expire_upcalls, + timeout_set_proc(_upcalls_ch[rtableid], expire_upcalls, >inp_rtableid); timeout_add_msec(_upcalls_ch[rtableid], EXPIRE_TIMEOUT); @@ -511,10 +503,9 @@ ip_mrouter_done(struct socket *so) vifi_t vifi; struct vif *vifp; int i; - int s; unsigned int rtableid = inp->inp_rtableid; - s = splsoftnet(); + splsoftassert(IPL_SOFTNET); /* Clear out all the vifs currently in use. */ for (vifi = 0; vifi < numvifs; vifi++) { @@ -526,10 +517,6 @@ ip_mrouter_done(struct socket *so) numvifs = 0; mrt_api_config = 0; -#ifdef PIM - pim_assert = 0; -#endif - timeout_del(_upcalls_ch[rtableid]); /* @@ -551,8 +538,6 @@ ip_mrouter_done(struct socket *so) ip_mrouter[rtableid] = NULL; - splx(s); - return (0); } @@ -658,7 +643,9 @@ add_vif(struct socket *so, struct mbuf * struct ifaddr *ifa; struct ifnet *ifp; struct ifreq ifr; - int error, s; + int error; + + splsoftassert(IPL_SOFTNET); if (m == NULL || m->m_len < sizeof(struct vifctl)) return (EINVAL); @@ -702,8 +689,6 @@ add_vif(struct socket *so, struct mbuf * return (error); } - s = splsoftnet(); - vifp->v_flags = vifcp->vifc_flags; vifp->v_threshold = vifcp->vifc_threshold; vifp->v_lcl_addr = vifcp->vifc_lcl_addr; @@ -715,8 +700,6 @@ add_vif(struct socket *so, struct mbuf * vifp->v_bytes_in = 0; vifp->v_bytes_out = 0; - splx(s); - /* Adjust numvifs up if the vifi is higher than numvifs. */ if (numvifs <= vifcp->vifc_vifi) numvifs = vifcp->vifc_vifi + 1; @@ -750,7 +733,8 @@ del_vif(struct mbuf *m) vifi_t *vifip; struct vif *vifp; vifi_t vifi; - int s; + + splsoftassert(IPL_SOFTNET); if (m == NULL || m->m_len < sizeof(vifi_t)) return (EINVAL); @@ -763,8 +747,6 @@ del_vif(struct mbuf *m) if (in_nullhost(vifp->v_lcl_addr)) return (EADDRNOTAVAIL); - s = splsoftnet(); - reset_vif(vifp); /* Adjust numvifs down */ @@ -773,8 +755,6 @@ del_vif(struct mbuf *m) break; numvifs = vifi; - splx(s); - return (0); } @@ -881,10 +861,11 @@ add_mfc(struct socket *so, struct mbuf * u_int32_t hash = 0; struct rtdetq *rte, *nrte; u_short nstl; - int s; int mfcctl_size = sizeof(struct mfcctl); unsigned int rtableid = inp->inp_rtableid; + splsoftassert(IPL_SOFTNET); + if (mrt_api_config & MRT_API_FLAGS_ALL) mfcctl_size = sizeof(struct mfcctl2); @@ -905,19 +886,15 @@ add_mfc(struct socket *so, struct mbuf * } mfccp = - s = splsoftnet(); /* No hash table allocated for this. */ - if (mfchashtbl[rtableid] == NULL) { - splx(s); + if (mfchashtbl[rtableid] == NULL) return (0); - } rt = mfc_find(rtableid, >mfcc_origin, >mfcc_mcastgrp); /* If an entry already exists, just update the fields */ if (rt) { update_mfc_params(rt, mfccp); - splx(s); return (0); } @@ -977,10 +954,8 @@ add_mfc(struct socket *so, struct mbuf * } if (rt == NULL) { /* no upcall, so make a new entry */ rt = malloc(sizeof(*rt), M_MRTABLE, M_NOWAIT); - if (rt == NULL) { -
Re: if attach/detach netlocks
On Tue, Jan 03, 2017 at 11:42:21AM +0100, Martin Pieuchot wrote: > On 02/01/17(Mon) 21:51, Mike Belopuhov wrote: > > On Fri, Dec 30, 2016 at 18:57 +0100, Mike Belopuhov wrote: > > > On Thu, Dec 29, 2016 at 09:30 +0100, Martin Pieuchot wrote: > > > > On 29/12/16(Thu) 01:15, Alexander Bluhm wrote: > > > > > On Fri, Dec 23, 2016 at 12:09:32AM +0100, Martin Pieuchot wrote: > > > > > > On 22/12/16(Thu) 20:45, Mike Belopuhov wrote: > > > > > > > I think this is what is required here. Works here, but YMMV. > > > > > > > > > > > > splnet() in a pseudo-driver seems completely wrong, you could get > > > > > > rid of > > > > > > it. > > > > > > > > > > Yes, but that is another issue. Can we get the netlock splasserts > > > > > fixed first? This diff looks good to me. > > > > > > > > Sure I'm ok with the diff. > > > > > > > > > > I agree with Martin and have cooked a diff but couldn't test it yet. > > > This is it for the reference. > > > > > > > I got to test the diff and I had to make another adjustment: > > vxlan_if_change is setup as a detach hook, however dohooks is > > called very early in if_detach before we remove IP addresses > > from the interface. It makes vxlan_config find these IP > > addresses just fine and re-add its own detach hook again. > > Why not fix vxlan_if_change()? > > > This > > repeats ad infinitum hogging the machine. I couldn't think of > > anything better than deferring an operation via a task. Seems > > to do the trick. > > That's ugly. Why would you re-add anything in a detach hook? This > is obviously broken. > It is used for the multicast address (only) and it made sense when the source address wasn't mandatory, eg. 0.0.0.0 -> 239.1.1.100 would find the next interface that points to the group after detaching the current one. The source is mandatory now, so the diff below should work as well. Reyk Index: sys/net/if_vxlan.c === RCS file: /cvs/src/sys/net/if_vxlan.c,v retrieving revision 1.54 diff -u -p -u -p -r1.54 if_vxlan.c --- sys/net/if_vxlan.c 13 Dec 2016 06:51:11 - 1.54 +++ sys/net/if_vxlan.c 3 Jan 2017 11:05:36 - @@ -947,17 +947,16 @@ vxlan_if_change(void *arg) { struct vxlan_softc *sc = arg; struct ifnet*ifp = >sc_ac.ac_if; - int s, error; + int s; /* * Reset the configuration after the parent interface disappeared. */ s = splnet(); - if ((error = vxlan_config(ifp, NULL, NULL)) != 0) { - /* The configured tunnel addresses are invalid, remove them */ - bzero(>sc_src, sizeof(sc->sc_src)); - bzero(>sc_dst, sizeof(sc->sc_dst)); - } + vxlan_multicast_cleanup(ifp); + memset(>sc_src, 0, sizeof(sc->sc_src)); + memset(>sc_dst, 0, sizeof(sc->sc_dst)); + sc->sc_dstport = htons(VXLAN_PORT); splx(s); }
Re: if attach/detach netlocks
On 02/01/17(Mon) 21:51, Mike Belopuhov wrote: > On Fri, Dec 30, 2016 at 18:57 +0100, Mike Belopuhov wrote: > > On Thu, Dec 29, 2016 at 09:30 +0100, Martin Pieuchot wrote: > > > On 29/12/16(Thu) 01:15, Alexander Bluhm wrote: > > > > On Fri, Dec 23, 2016 at 12:09:32AM +0100, Martin Pieuchot wrote: > > > > > On 22/12/16(Thu) 20:45, Mike Belopuhov wrote: > > > > > > I think this is what is required here. Works here, but YMMV. > > > > > > > > > > splnet() in a pseudo-driver seems completely wrong, you could get rid > > > > > of > > > > > it. > > > > > > > > Yes, but that is another issue. Can we get the netlock splasserts > > > > fixed first? This diff looks good to me. > > > > > > Sure I'm ok with the diff. > > > > > > > I agree with Martin and have cooked a diff but couldn't test it yet. > > This is it for the reference. > > > > I got to test the diff and I had to make another adjustment: > vxlan_if_change is setup as a detach hook, however dohooks is > called very early in if_detach before we remove IP addresses > from the interface. It makes vxlan_config find these IP > addresses just fine and re-add its own detach hook again. Why not fix vxlan_if_change()? > This > repeats ad infinitum hogging the machine. I couldn't think of > anything better than deferring an operation via a task. Seems > to do the trick. That's ugly. Why would you re-add anything in a detach hook? This is obviously broken.
Re: find -delete
On Tue, Jan 03, 2017 at 12:15:02AM -0500, Ted Unangst wrote: > This option is not posix (not like that's stopped find accumulating a dozen > extensions), but it is in gnu and freebsd (for 20 years). it's also somewhat > popular among sysadmins and blogs, etc. and perhaps most importantly, it > nicely solves one of the more troublesome caveats of find (which the man page > actually covers twice because it's so common and easy to screw up). So I think > it makes a good addition. > > Code snatched from freebsd. > > In passing, I'll also note that the man page example is very inefficient. > $ find . \( -name \*.jpg -o -name \*.gif \) -exec rm {} \; > This would be much faster with +. We can fix that too, but I'll add that a lot > of the online advice suggests -delete, and if not available, -exec rm {} \;, > instead of the smarter + exec. Not surprising since even the man page gets > this wrong. > no opinion on the addition, but if there is a better way to write the examples that are there, i think you should take the time to do so. i'd also slightly prefer we show the more traditional way to do it, though i appreciate that might not make a ton of sense for find(1). some comments on the man parts: > Index: find.1 > === > RCS file: /cvs/src/usr.bin/find/find.1,v > retrieving revision 1.91 > diff -u -p -r1.91 find.1 > --- find.111 Sep 2015 18:58:16 - 1.91 > +++ find.13 Jan 2017 05:04:52 - > @@ -182,6 +182,23 @@ was started, rounded up to the next full > .Ar n > 24-hour periods. > .Pp > +.It Ic -delete > +Delete found files and/or directories. i think "and" is sufficiently clear. > +Always returns true. > +This executes > +from the current working directory as > +.Nm > +recurses down the tree. > +It will not attempt to delete a filename with a > +.Dq Pa / > +character in its pathname relative to > +.Dq Pa \&. i'd use Sq rather than Dq for single letters if you really need it quoted. and check, but i think you need \& after the dot, not before, or you'll get a double space injected. jmc > +for security reasons. > +Depth-first traversal processing is implied by this option. > +The > +.Ic -delete > +primary will fail to delete a directory if it is not empty. > +Following symlinks is incompatible with this option. > .It Ic -depth > This primary always evaluates to true. > The same as specifying the > @@ -587,6 +604,7 @@ primaries > .Ic -anewer , > .Ic -cmin , > .Ic -cnewer , > +.Ic -delete , > .Ic -empty , > .Ic -execdir , > .Ic -flags ,
Re: libressl symbols
After discussion from jsing and beck, this is wrong. I've fixed my issue in the net/py-cryptography port instead. On 2017 Jan 02 (Mon) at 17:06:46 +0100 (+0100), Reyk Floeter wrote: :Hi, : :the function prototypes have been moved from he header to the .c file - you will have to revert this change as well. : :+1 from me for exposing the API - I recently also ran into it but didn't speak up because my use case was probably not important enough. : :Reyk : : :> Am 02.01.2017 um 16:29 schrieb Peter Hessler: :> :> Looks like when libcrypto was convered to use a Symbol map, some :> functions were not included. :> :> This change lets py-openssl be loaded by python processes. :> :> I did not include the minor version bump, as there might be more issues. :> :> :> :> Index: lib/libcrypto/Symbols.list :> === :> RCS file: /cvs/src/lib/libcrypto/Symbols.list,v :> retrieving revision 1.1 :> diff -u -p -u -p -r1.1 Symbols.list :> --- lib/libcrypto/Symbols.list21 Dec 2016 15:49:29 -1.1 :> +++ lib/libcrypto/Symbols.list2 Jan 2017 15:17:02 - :> @@ -2805,6 +2805,8 @@ X509_VERIFY_PARAM_inherit :> X509_VERIFY_PARAM_lookup :> X509_VERIFY_PARAM_new :> X509_VERIFY_PARAM_set1 :> +X509_VERIFY_PARAM_set1_email :> +X509_VERIFY_PARAM_set1_ip :> X509_VERIFY_PARAM_set1_name :> X509_VERIFY_PARAM_set1_policies :> X509_VERIFY_PARAM_set_depth :> :> :> -- :> Reality is just a convenient measure of complexity. :>-- Alvy Ray Smith :> : -- Death to all fanatics!
uaudio: preliminary patch for yamaha ur12 device support
Hi, Sending this patch to tech@ in case people have usb audio devices to test it. When connecting yamaha ur12 usb audio interface I was getting USBD_INVAL because of the aclen check. netbsd previously removed the check for aclen here: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/uaudio.c.diff?r1=1.119=1.120=h=u So this patch is a copy, without the Roland SD-90 stuff. I originally applied this to uaudio.c r1.116 and it allowed ur12 device to progress further. usb device attach then failed later related to unexpected format type or other sample encoding details. That would need to be addressed later in uaudio_process_as(). - Michael Index: uaudio.c === RCS file: /cvs/src/sys/dev/usb/uaudio.c,v retrieving revision 1.122 diff -u -p -u -r1.122 uaudio.c --- uaudio.c3 Jan 2017 06:45:58 - 1.122 +++ uaudio.c3 Jan 2017 08:14:27 - @@ -1788,7 +1788,7 @@ uaudio_identify_ac(struct uaudio_softc * const struct usb_audio_output_terminal *pot; struct terminal_list *tml; const char *buf, *ibuf, *ibufend; - int size, offs, aclen, ndps, i, j; + int size, offs, ndps, i, j; size = UGETW(cdesc->wTotalLength); buf = (char *)cdesc; @@ -1807,26 +1807,23 @@ uaudio_identify_ac(struct uaudio_softc * /* A class-specific AC interface header should follow. */ ibuf = buf + offs; + ibufend = buf + size; acdp = (const struct usb_audio_control_descriptor *)ibuf; if (acdp->bDescriptorType != UDESC_CS_INTERFACE || acdp->bDescriptorSubtype != UDESCSUB_AC_HEADER) return (USBD_INVAL); - aclen = UGETW(acdp->wTotalLength); - if (offs + aclen > size) - return (USBD_INVAL); if (!(sc->sc_quirks & UAUDIO_FLAG_BAD_ADC) && UGETW(acdp->bcdADC) != UAUDIO_VERSION) return (USBD_INVAL); sc->sc_audio_rev = UGETW(acdp->bcdADC); - DPRINTFN(2,("%s: found AC header, vers=%03x, len=%d\n", -__func__, sc->sc_audio_rev, aclen)); + DPRINTFN(2,("%s: found AC header, vers=%03x\n", +__func__, sc->sc_audio_rev)); sc->sc_nullalt = -1; /* Scan through all the AC specific descriptors */ - ibufend = ibuf + aclen; dp = (const usb_descriptor_t *)ibuf; ndps = 0; iot = malloc(256 * sizeof(struct io_terminal), @@ -1844,11 +1841,8 @@ uaudio_identify_ac(struct uaudio_softc * free(iot, M_TEMP, 0); return (USBD_INVAL); } - if (dp->bDescriptorType != UDESC_CS_INTERFACE) { - printf("%s: skip desc type=0x%02x\n", - __func__, dp->bDescriptorType); - continue; - } + if (dp->bDescriptorType != UDESC_CS_INTERFACE) + break; i = ((const struct usb_audio_input_terminal *)dp)->bTerminalId; iot[i].d.desc = dp; if (i > ndps)