llvm: fix i386 floating point compiler bug
Hi, gerhard@ found a bug in LLVM's i386 code. He noticed that some floating point instructions were "optimized" and thus reordered between other FP instructions that changed floating point modes, so that those reordered instructions were running with an incorrent mode. I don't completely grasp the internals, but it looks someone at LLVM took care of my bug report and changed some pseudo memory instructions to have side effects, so that they aren't reordered. This has fixed our test case. https://github.com/llvm-mirror/llvm/commit/63029e5caea7ef0af525e4f66249ca7ffa7e1280 ok? Patrick diff --git a/gnu/llvm/lib/Target/X86/X86InstrFPStack.td b/gnu/llvm/lib/Target/X86/X86InstrFPStack.td index 11b1d070ef2..fb7eb87c64d 100644 --- a/gnu/llvm/lib/Target/X86/X86InstrFPStack.td +++ b/gnu/llvm/lib/Target/X86/X86InstrFPStack.td @@ -139,6 +139,7 @@ def _Fp80 : FpI_<(outs RFP80:$dst), (ins RFP80:$src1, RFP80:$src2), TwoArgFP, // These instructions cannot address 80-bit memory. multiclass FPBinary { +let mayLoad = 1, hasSideEffects = 1 in { // ST(0) = ST(0) + [mem] def _Fp32m : FpIf32<(outs RFP32:$dst), (ins RFP32:$src1, f32mem:$src2), OneArgFPRW, @@ -175,10 +176,8 @@ def _Fp80m64: FpI_<(outs RFP80:$dst), (OpNode RFP80:$src1, (f80 (extloadf64 addr:$src2, (set RFP80:$dst, (OpNode (f80 (extloadf64 addr:$src2)), RFP80:$src1)))]>; -let mayLoad = 1 in def _F32m : FPI<0xD8, fp, (outs), (ins f32mem:$src), !strconcat("f", asmstring, "{s}\t$src")>; -let mayLoad = 1 in def _F64m : FPI<0xDC, fp, (outs), (ins f64mem:$src), !strconcat("f", asmstring, "{l}\t$src")>; // ST(0) = ST(0) + [memint] @@ -224,12 +223,11 @@ def _FpI32m80 : FpI_<(outs RFP80:$dst), (ins RFP80:$src1, i32mem:$src2), (OpNode RFP80:$src1, (X86fild addr:$src2, i32))), (set RFP80:$dst, (OpNode (X86fild addr:$src2, i32), RFP80:$src1)))]>; -let mayLoad = 1 in def _FI16m : FPI<0xDE, fp, (outs), (ins i16mem:$src), !strconcat("fi", asmstring, "{s}\t$src")>; -let mayLoad = 1 in def _FI32m : FPI<0xDA, fp, (outs), (ins i32mem:$src), !strconcat("fi", asmstring, "{l}\t$src")>; +} // mayLoad = 1, hasSideEffects = 1 } let Defs = [FPSW] in {
Add sizes for free() in glxsb(4)
Hi tech@, Add sizes for free() for the Geode LX Security Block crypto accelerator. Comments? OK? Index: sys/arch/i386/pci/glxsb.c === RCS file: /cvs/src/sys/arch/i386/pci/glxsb.c,v retrieving revision 1.33 diff -u -p -r1.33 glxsb.c --- sys/arch/i386/pci/glxsb.c 8 Sep 2017 05:36:51 - 1.33 +++ sys/arch/i386/pci/glxsb.c 24 Dec 2017 18:37:54 - @@ -525,22 +525,22 @@ glxsb_crypto_freesession(uint64_t tid) if (swd->sw_kschedule) { explicit_bzero(swd->sw_kschedule, txf->ctxsize); - free(swd->sw_kschedule, M_CRYPTO_DATA, 0); + free(swd->sw_kschedule, M_CRYPTO_DATA, txf->ctxsize); } - free(swd, M_CRYPTO_DATA, 0); + free(swd, M_CRYPTO_DATA, sizeof(*swd)); } if ((swd = sc->sc_sessions[sesn].ses_swd_auth)) { axf = swd->sw_axf; if (swd->sw_ictx) { explicit_bzero(swd->sw_ictx, axf->ctxsize); - free(swd->sw_ictx, M_CRYPTO_DATA, 0); + free(swd->sw_ictx, M_CRYPTO_DATA, axf->ctxsize); } if (swd->sw_octx) { explicit_bzero(swd->sw_octx, axf->ctxsize); - free(swd->sw_octx, M_CRYPTO_DATA, 0); + free(swd->sw_octx, M_CRYPTO_DATA, axf->ctxsize); } - free(swd, M_CRYPTO_DATA, sizeof *swd); + free(swd, M_CRYPTO_DATA, sizeof(*swd)); } explicit_bzero(>sc_sessions[sesn], sizeof(sc->sc_sessions[sesn])); return (0);
re-enable unmapping of startup code on arm64
When gap.o was added back, we forgot to re-enable this bit of code. ok? Index: arch/arm64/arm64/autoconf.c === RCS file: /cvs/src/sys/arch/arm64/arm64/autoconf.c,v retrieving revision 1.4 diff -u -p -r1.4 autoconf.c --- arch/arm64/arm64/autoconf.c 29 Jun 2017 05:40:35 - 1.4 +++ arch/arm64/arm64/autoconf.c 24 Dec 2017 22:31:25 - @@ -34,7 +34,6 @@ enum devclass bootdev_class = DV_DULL; void unmap_startup(void) { -#if 0 extern void *_start, *endboot; vaddr_t p = (vaddr_t)&_start; @@ -42,7 +41,6 @@ unmap_startup(void) pmap_kremove(p, PAGE_SIZE); p += PAGE_SIZE; } while (p < (vaddr_t)); -#endif } void
Re: llvm: patch-update to release 5.0.1
On Fri, Dec 22, 2017 at 01:35:28PM +0100, Patrick Wildt wrote: > Feedback appreciated! On i386 I used clang version 5.0.1 to build a kernel and /usr/src. The regression tests passed on that system. bluhm
Re: iked: multiple proposals
On 2017/12/05 12:53, Patrick Wildt wrote: > Hi, > > this diff changes the config parsing code so that we can specify > multiple ikesa and childsa proposals by using the keywords multiple > times. It needs the other payload parsing diff that I posted as well. > > Multiple proposals can be specified like this: > > ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \ > ikesa auth hmac-sha2-256 enc aes-256 group modp2048 \ > ikesa auth hmac-sha1 enc aes-256 group modp2048 \ > childsa auth hmac-sha2-256 enc aes-192 group modp2048 \ > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > childsa auth hmac-sha1 enc aes-256 group modp2048 \ > > ok? Sorry about the slow review. Code diff is OK with me, but it needs a little change to iked.conf(5) to go with it. > Patrick > > diff --git a/sbin/iked/parse.y b/sbin/iked/parse.y > index 58b12e6d0b4..25f9360bf9c 100644 > --- a/sbin/iked/parse.y > +++ b/sbin/iked/parse.y > @@ -120,8 +120,8 @@ struct ipsec_transforms { > }; > > struct ipsec_mode { > - struct ipsec_transforms *xfs; > - uint8_t ike_exch; > + struct ipsec_transforms **xfs; > + unsigned int nxfs; > }; > > struct iked_transform ikev2_default_ike_transforms[] = { > @@ -329,9 +329,8 @@ const struct ipsec_xf *parse_xf(const char *, > unsigned int, > const char *print_xf(unsigned int, unsigned int, > const struct ipsec_xf *); > void copy_transforms(unsigned int, const struct ipsec_xf *, > - const struct ipsec_xf *, > - struct iked_transform *, size_t, > - unsigned int *, struct iked_transform *, size_t); > + struct iked_transform **, unsigned int *, > + struct iked_transform *, size_t); > int create_ike(char *, int, uint8_t, struct ipsec_hosts *, > struct ipsec_hosts *, struct ipsec_mode *, > struct ipsec_mode *, uint8_t, > @@ -347,6 +346,7 @@ intparsekeyfile(char *, struct > iked_auth *); > > struct ipsec_transforms *ipsec_transforms; > struct ipsec_filters *ipsec_filters; > +struct ipsec_mode *ipsec_mode; > > typedef struct { > union { > @@ -405,7 +405,7 @@ typedef struct { > %type ikeflags ikematch ikemode ipcomp > %type ikeauth > %type keyspec > -%typeike_sa child_sa > +%typeike_sas child_sas > %typelifetime > %type byte_spec time_spec ikelifetime > %type name > @@ -463,7 +463,7 @@ user : USER STRING STRING{ > ; > > ikev2rule: IKEV2 name ikeflags satype af proto hosts_list peers > - ike_sa child_sa ids ikelifetime lifetime ikeauth ikecfg > + ike_sas child_sas ids ikelifetime lifetime ikeauth ikecfg > filters { > if (create_ike($2, $5, $6, $7, &$8, $9, $10, $4, $3, > $11.srcid, $11.dstid, $12, &$13, &$14, > @@ -774,27 +774,61 @@ transform : AUTHXF STRING { > } > ; > > -ike_sa : /* empty */ { > +ike_sas : { > + if ((ipsec_mode = calloc(1, > + sizeof(struct ipsec_mode))) == NULL) > + err(1, "ike_sas: calloc"); > + } > + ike_sas_l { > + $$ = ipsec_mode; > + } > + | /* empty */ { > $$ = NULL; > } > - | IKESA { > + ; > + > +ike_sas_l: ike_sas_l ike_sa > + | ike_sa > + ; > + > +ike_sa : IKESA { > + if ((ipsec_mode->xfs = recallocarray(ipsec_mode->xfs, > + ipsec_mode->nxfs, ipsec_mode->nxfs + 1, > + sizeof(struct ipsec_transforms *))) == NULL) > + err(1, "ike_sa: recallocarray"); > + ipsec_mode->nxfs++; > encxfs = ikeencxfs; > } transforms{ > - if (($$ = calloc(1, sizeof(*$$))) == NULL) > - err(1, "ike_sa: calloc"); > - $$->xfs = $3; > + ipsec_mode->xfs[ipsec_mode->nxfs - 1] = $3; > } > ; > > -child_sa : /* empty */ { > +child_sas: { > + if ((ipsec_mode = calloc(1, > + sizeof(struct ipsec_mode))) == NULL) > + err(1,
Re: pom: consolidate printing
On Sun, Dec 24, 2017 at 12:07:36PM -0600, Scott Cheloha wrote: > Hey, > > Next up for pom(6): consolidate the printf(3) calls. > > The inline printing obfuscates what is otherwise a very > simple classification algorithm. I like it. Perhaps the variable 'name' could be made a bit more descriptive, for example 'shape'? Either way, ok > > ok? > > -- > Scott Cheloha > > Index: games/pom/pom.c > === > RCS file: /cvs/src/games/pom/pom.c,v > retrieving revision 1.27 > diff -u -p -r1.27 pom.c > --- games/pom/pom.c 24 Dec 2017 16:59:50 - 1.27 > +++ games/pom/pom.c 24 Dec 2017 17:54:46 - > @@ -75,17 +75,21 @@ main(int argc, char *argv[]) > struct tm *GMT; > time_t tmpt; > double days, today, tomorrow; > - int cnt; > + int cnt, principal, usertime; > char buf[1024]; > + char *descriptor, *name; > + > + principal = 1; > + usertime = 0; > > if (pledge("stdio", NULL) == -1) > err(1, "pledge"); > > if (argc > 1) { > + usertime = 1; > tmpt = parsetime(argv[1]); > strftime(buf, sizeof(buf), "%a %Y %b %e %H:%M:%S (%Z)", > localtime()); > - printf("%s: ", buf); > } else > tmpt = time(NULL); > GMT = gmtime(); > @@ -97,27 +101,36 @@ main(int argc, char *argv[]) > for (cnt = GMT->tm_year; cnt < EPOCH; ++cnt) > days -= isleap(cnt + 1900) ? 366 : 365; > today = potm(days); > - (void)printf("The Moon is "); > if (lround(today) == 100) > - (void)printf("Full\n"); > + name = "Full"; > else if (lround(today) == 0) > - (void)printf("New\n"); > + name = "New"; > else { > tomorrow = potm(days + 1); > - if (lround(today) == 50) > - (void)printf("%s\n", tomorrow > today ? > - "at the First Quarter" : "at the Last Quarter"); > - else { > - (void)printf("%s ", tomorrow > today ? > - "Waxing" : "Waning"); > + if (lround(today) == 50) { > + if (tomorrow > today) > + name = "at the First Quarter"; > + else > + name = "at the Last Quarter"; > + } else { > + principal = 0; > + if (tomorrow > today) > + descriptor = "Waxing"; > + else > + descriptor = "Waning"; > if (today > 50.0) > - (void)printf("Gibbous (%1.0f%% of Full)\n", > - today); > + name = "Gibbous"; > else /* (today < 50.0) */ > - (void)printf("Crescent (%1.0f%% of Full)\n", > - today); > + name = "Crescent"; > } > } > + if (usertime) > + printf("%s: ", buf); > + printf("The Moon is "); > + if (principal) > + printf("%s\n", name); > + else > + printf("%s %s (%1.0f%% of Full)\n", descriptor, name, today); > return 0; > } > >
pom: consolidate printing
Hey, Next up for pom(6): consolidate the printf(3) calls. The inline printing obfuscates what is otherwise a very simple classification algorithm. ok? -- Scott Cheloha Index: games/pom/pom.c === RCS file: /cvs/src/games/pom/pom.c,v retrieving revision 1.27 diff -u -p -r1.27 pom.c --- games/pom/pom.c 24 Dec 2017 16:59:50 - 1.27 +++ games/pom/pom.c 24 Dec 2017 17:54:46 - @@ -75,17 +75,21 @@ main(int argc, char *argv[]) struct tm *GMT; time_t tmpt; double days, today, tomorrow; - int cnt; + int cnt, principal, usertime; char buf[1024]; + char *descriptor, *name; + + principal = 1; + usertime = 0; if (pledge("stdio", NULL) == -1) err(1, "pledge"); if (argc > 1) { + usertime = 1; tmpt = parsetime(argv[1]); strftime(buf, sizeof(buf), "%a %Y %b %e %H:%M:%S (%Z)", localtime()); - printf("%s: ", buf); } else tmpt = time(NULL); GMT = gmtime(); @@ -97,27 +101,36 @@ main(int argc, char *argv[]) for (cnt = GMT->tm_year; cnt < EPOCH; ++cnt) days -= isleap(cnt + 1900) ? 366 : 365; today = potm(days); - (void)printf("The Moon is "); if (lround(today) == 100) - (void)printf("Full\n"); + name = "Full"; else if (lround(today) == 0) - (void)printf("New\n"); + name = "New"; else { tomorrow = potm(days + 1); - if (lround(today) == 50) - (void)printf("%s\n", tomorrow > today ? - "at the First Quarter" : "at the Last Quarter"); - else { - (void)printf("%s ", tomorrow > today ? - "Waxing" : "Waning"); + if (lround(today) == 50) { + if (tomorrow > today) + name = "at the First Quarter"; + else + name = "at the Last Quarter"; + } else { + principal = 0; + if (tomorrow > today) + descriptor = "Waxing"; + else + descriptor = "Waning"; if (today > 50.0) - (void)printf("Gibbous (%1.0f%% of Full)\n", - today); + name = "Gibbous"; else /* (today < 50.0) */ - (void)printf("Crescent (%1.0f%% of Full)\n", - today); + name = "Crescent"; } } + if (usertime) + printf("%s: ", buf); + printf("The Moon is "); + if (principal) + printf("%s\n", name); + else + printf("%s %s (%1.0f%% of Full)\n", descriptor, name, today); return 0; }
Re: sdmmc(4) DMA map tweak
On Sun, Dec 24, 2017 at 02:00:41AM +0100, Mark Kettenis wrote: > I have a diff to add DMA support to dwmmc(4). The hardware is a bit > dumb and can only transfer up to 4K in a single DMA "segment". > Currently sdmmc(4) allocates a bus DMA mapping structure that allows > for segments up to MAXPHYS. Subdividing such segments in my driver > seems a bit dumb. > > So here is a diff that allows a driver to allocate its own DMA mapping > structure, specifying whatever hardware constraints it needs, and pass > it on to sdmmc(4). If no such structure is passed, sdmcc(4) continues > to allocate one for us with the default constraints. > > ok? > Yes, OK. I believe I wanted something like this for rtsx(4) as well but eventually made rtsx(4) work with the existing dma map somehow. > > Index: dev/sdmmc/sdmmc.c > === > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v > retrieving revision 1.47 > diff -u -p -r1.47 sdmmc.c > --- dev/sdmmc/sdmmc.c 6 Apr 2017 07:07:28 - 1.47 > +++ dev/sdmmc/sdmmc.c 24 Dec 2017 00:53:32 - > @@ -115,11 +115,12 @@ sdmmc_attach(struct device *parent, stru > sc->sct = saa->sct; > sc->sch = saa->sch; > sc->sc_dmat = saa->dmat; > + sc->sc_dmap = saa->dmap; > sc->sc_flags = saa->flags; > sc->sc_caps = saa->caps; > sc->sc_max_xfer = saa->max_xfer; > > - if (ISSET(sc->sc_caps, SMC_CAPS_DMA)) { > + if (ISSET(sc->sc_caps, SMC_CAPS_DMA) && sc->sc_dmap == NULL) { > error = bus_dmamap_create(sc->sc_dmat, MAXPHYS, SDMMC_MAXNSEGS, > MAXPHYS, 0, BUS_DMA_NOWAIT|BUS_DMA_ALLOCNOW, >sc_dmap); > if (error) { > Index: dev/sdmmc/sdmmcchip.h > === > RCS file: /cvs/src/sys/dev/sdmmc/sdmmcchip.h,v > retrieving revision 1.9 > diff -u -p -r1.9 sdmmcchip.h > --- dev/sdmmc/sdmmcchip.h 5 May 2016 20:40:48 - 1.9 > +++ dev/sdmmc/sdmmcchip.h 24 Dec 2017 00:53:32 - > @@ -97,6 +97,7 @@ struct sdmmcbus_attach_args { > sdmmc_chipset_tag_t sct; > sdmmc_chipset_handle_t sch; > bus_dma_tag_t dmat; > + bus_dmamap_t dmap; > int flags; > int caps; > longmax_xfer; >
Re: arm64: init a var in _bootstrap()
> Date: Sun, 24 Dec 2017 00:25:30 +0200 > From: Artturi Alm> > On Sat, Dec 23, 2017 at 03:41:02PM +0200, Artturi Alm wrote: > > Hi, > > > > spotted this while looking at how deep the hole suggested by mpi@ is. > > memhook is used by mmrw minor case 0, and the diff below fixes that. > > rest of it should be logically solid improvement, but given the state > > of arm64 internals w/all the "// XXXshit", and how sacred these arch-md > > bootstraps are to be above all cleanup, i guess i'll come up w/minimal > > diff later. > > > > -Artturi > > > > and now with the minimal dirty version to fix this: > a64pine# dmesg | head -1 > OpenBSD 6.2-current (GENERIC) #123: Thu Dec 21 14:27:12 MST 2017 > a64pine# sysctl ddb.trigger=1 > Stopped at ddb_sysctl+0x118: > ddb> pp memhook > memhook:(unsigned char *)0x0 > ddb> c > ddb.trigger: 0 -> 1 > a64pine# > > return value of pmap_map_stolen() is essentially the vstart used in initarm(), > and it's called only once near the end of pmap_bootstrap(), so this does fit > well w/the obscure spirit of arm bootstrap code w/o cleaning anything :) Well, putting it there makes no sense. Anyway, now that you've made it a little bit more obvious what you're fixing, here is a diff that makes a little bit more sense. ok? Index: arch/arm64/arm64/pmap.c === RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v retrieving revision 1.38 diff -u -p -r1.38 pmap.c --- arch/arm64/arm64/pmap.c 27 Aug 2017 19:33:02 - 1.38 +++ arch/arm64/arm64/pmap.c 24 Dec 2017 10:56:10 - @@ -133,6 +133,10 @@ vaddr_t pmap_map_stolen(vaddr_t); void pmap_physload_avail(void); extern caddr_t msgbufaddr; +char *memhook; +vaddr_t zero_page; +vaddr_t copy_src_page; +vaddr_t copy_dst_page; /* XXX - panic on pool get failures? */ struct pool pmap_pmap_pool; @@ -1201,6 +1205,9 @@ pmap_bootstrap(long kvo, paddr_t lpt1, printf("all mapped\n"); + memhook = (char *)vstart; + vstart += PAGE_SIZE; + return vstart; } @@ -1649,11 +1656,6 @@ void pmap_update(pmap_t pm) { } - -char *memhook; -vaddr_t zero_page; -vaddr_t copy_src_page; -vaddr_t copy_dst_page; int pmap_is_referenced(struct vm_page *pg)
Re: malloc cleanup and small optimizations
On Sat, Dec 23, 2017 at 03:39:53PM +0100, Otto Moerbeek wrote: > Hi, > > Largely cleanup and small optimizations: > > - remove over-initializaition of chunks: canary is set only once, > other fields only as-needed. > - remember position of last free bit in chunk_info, so we can start at > the proper spot the next time. To be able to do this a field was added > to chunk_info. To make room, the chunk_info canary is now only a > short. This still detects acccidental overflows. > - the code that scans for a free bit in chunk_info is made more clear > and a bit faster. > - for the page cache, also rememberthe position to continue scanning. Only > randomize when putting things into the cache. > > reviews and tests appreciated, btw, i realized the init of most the other fields of struct chunk_info can be also done exactly once after allocation, no need to redo them in omalloc_make_chunks(). After this is in, I'll work on that, -Otto