Re: CVS commit: src
On Tue, Oct 23, 2018 at 10:05:27PM +0900, Rin Okuyama wrote: > Well, it makes sense on one hand. But, on the other hand, your argument > can be very dangerous if it is abused; I really hate an attitude like > "Oh, discussion is falling into a bike shed! Let's commit it to shut them > up!" Of course, I do understand you are not a person to do such a thing. > However, I believe that we must prove it, we do not behave like that, by > our daily actions. Otherwise, the community will break up. This is why > I'm writing this sequence of unpleasant messages which must "discourage" > everyone --- I am really sorry for it. I thought there were no big objections to it, as kamil stated something that I read as a withdrawal of his more fundamental objection to markdown & preferring a different style of document, the other complaint was really small (arm64->aarch64) so I changed it without posting a second revision. > Yes, we must explain the relation between CVS master and GitHub mirror, > at least. Others are minor problems although I feel it better to be > consistent with our existing documents. For example, architecture > names in http://wiki.netbsd.org/ports/ are not capitalized at all. Sure. > Maya, why don't you express your opinion in a public ML instead of > sending a private massage to me? Rather, let us get back to technical > discussions... I've had multiple complaints about mentioning details of non-public conversations to a wide audience. Considering it's also the only conduct rule netbsd has, I should probably be extra careful about it.
Re: CVS commit: src/share/man/man9
On Mon, Oct 16, 2017 at 04:53:17PM +0300, Valery Ushakov wrote: > On Mon, Oct 16, 2017 at 11:53:00 +, Maya Rashish wrote: > > Modified Files: > > src/share/man/man9: byteorder.9 > > > > Log Message: > > Suggest to include the POSIX rather than BSD > > Section 9 is kernel internals, so is the correct header. > Please revert. It's also in the wrong section.
Re: CVS commit: src/sys/arch
I'm not randomly seeking out code to delete. I was poking at nearby code due to a bug report. I saw dead code, so I deleted it. I have some more changes to nearby code that I haven't committed / was debating.
Re: CVS commit: src/sys/arch
On Tue, Oct 10, 2017 at 05:02:48AM +, Martin Husemann wrote: > I think you are confusing things. We do not support FPU emulation in the > kernel, but booting on FPU-less machines should still work (with a softfloat > userland). I don't think we should support every esoteric case just in case someone wants to complete support it. We haven't run on such machines in over a decade.
Re: CVS commit: src/distrib
On Sun, Sep 17, 2017 at 09:51:31AM +0200, Martin Husemann wrote: > I haven't checked, but the other arch that imediately came to my mind > when doing this was VAX, and the CD image (including debug sets) fits > just fine there. > > Could you create a list of architectures where DVD is unlikely and CD image > does not fit? I'm not sufficiently familiar with how the different archs are installed. flxd was specifically mentioning shark being too big
Re: CVS import: xsrc/external/mit/fontconfig/dist
Now I get: $ fc-match anything Fontconfig warning: line 148: blank doesn't take any effect anymore. please remove it from your fonts.conf Vera.ttf: "Bitstream Vera Sans" "Roman" I can't find where the lines in fonts.conf come from. any ideas?
Re: CVS commit: xsrc/external/mit/libpciaccess/dist
On Tue, Aug 29, 2017 at 05:52:34AM +, matthew green wrote: > @@ -175,6 +179,9 @@ insert( uint16_t vendor ) > struct pci_id_node * child = > calloc( 1, sizeof( struct pci_id_node ) ); > > + if ( tree == NULL ) > + return NULL; > + > child->bits = 4; > > n->children[ idx ] = child; > @@ -183,6 +190,9 @@ insert( uint16_t vendor ) > struct pci_id_leaf * leaf = > calloc( 1, sizeof( struct pci_id_leaf ) ); > > + if ( tree == NULL ) > + return NULL; > + > leaf->vendor = vendor; > should check child & leaf instead, I think
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 22, 2017 at 05:09:40AM +1000, matthew green wrote: > please put it back on ERLITE. that system is *not* "stable enough now". > all it takes is some heavy work. > > i can't comment on other platforms platforms you changed. should we use 'options OCTEON_MEMSIZE="(256*1024*1024)"' in -8? it can't use the upper 256MB. ftp'ing a 300MB file did the trick to reproduce.
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 22, 2017 at 05:09:40AM +1000, matthew green wrote: > please put it back on ERLITE. that system is *not* "stable enough now". > all it takes is some heavy work. > > i can't comment on other platforms platforms you changed. I'll have a stab at fixing the glaring flaws again. But I wouldn't be surprised if it doesn't survive build.sh due to overheating - mine gets crazy hot when I leave it in u-boot.
Re: CVS commit: src/sys/ufs/ffs
On Sun, Aug 20, 2017 at 12:51:39PM +, Maya Rashish wrote: > - panic("%s: dup alloc ino=%" PRId64 " on %s: mode %x/%x " > + panic("%s: dup alloc ino=%" PRId64 " on %s: mode %o/%o " Can I do this in a panic message btw?
Re: CVS commit: src/sys/arch/mips/mips
spoiler alert: we can dedup a lot more > @@ -1288,10 +1295,7 @@ NESTED_NOPROFILE(MIPSX(user_reserved_ins > /* >* Save a minimum of registers to see if this is rdhwr $3,$29 >*/ > -#ifdef MIPS3_LOONGSON2 > - li k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE > - mtc0k0, MIPS_COP_0_DIAG > -#endif > + KERN_ENTRY_ERRATA > /* K1 already has CURLWP */ > PTR_L k0, L_PCB(k1) # XXXuvm_lwp_getuarea > PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ > @@ -1353,10 +1357,7 @@ NESTED_NOPROFILE(MIPSX(user_gen_exceptio > /* >* Save all the registers except the kernel temporaries onto the stack. >*/ > -#ifdef MIPS3_LOONGSON2 > - li k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE > - mtc0k0, MIPS_COP_0_DIAG > -#endif > + KERN_ENTRY_ERRATA > /* K1 already has CURLWP */ > PTR_L k0, L_PCB(k1) # XXXuvm_lwp_getuarea > PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ > @@ -1468,10 +1469,7 @@ NESTED_NOPROFILE(MIPSX(user_intr), CALLF > * Save the relevant user registers onto the kernel stack. > * We don't need to save s0 - s8 because the compiler does it for us. > */ > -#ifdef MIPS3_LOONGSON2 > - li k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE > - mtc0k0, MIPS_COP_0_DIAG > -#endif > + KERN_ENTRY_ERRATA > /* k1 contains curlwp */ > PTR_L k0, L_PCB(k1) # XXXuvm_lwp_getuarea > PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ > @@ -1660,10 +1658,7 @@ NESTED_NOPROFILE(MIPSX(systemcall), CALL > /* >* Save all the registers but kernel temporaries onto the stack. >*/ > -#ifdef MIPS3_LOONGSON2 > - li k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE > - mtc0k0, MIPS_COP_0_DIAG > -#endif > + KERN_ENTRY_ERRATA > /* k1 already contains cpulwp */ > PTR_L k0, L_PCB(k1) # XXXuvm_lwp_getuarea > PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ >
Re: CVS commit: src/sys/arch/amd64/conf
try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run. Its non-compatibility is probably buried deep within a switch statement for a generic function. The only way we can reasonably make it work is: - lie about what compat is, and build it inot the kernel, which also hurts people who want to remove it because they are using weak archs - make networking modular? - kernel hot patching (runtime cost) We can drop the pretense. it doesn't work.
Re: CVS commit: src/sys/arch
On Fri, Aug 18, 2017 at 10:02:37AM +, Maxime Villard wrote: > Remove unused and broken code. On amd64 we won't want int3 from kernel > mode to be valid. > - /* > - * DTrace Function Boundary Trace (fbt) probes are triggered > - * by int3 (0xcc). > - */ Is there some other trap instruction that could be used? the removal of dtrace functions breaks the ability to load the dtrace module.
Re: CVS commit: src
On Sat, Aug 12, 2017 at 07:35:08AM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sat Aug 12 07:35:08 UTC 2017 > > Modified Files: > src/distrib/sets/lists/comp: md.amd64 md.i386 > src/sys/arch/i386/include: Makefile mcontext.h segments.h > Removed Files: > src/sys/arch/i386/include: vm86.h > > Log Message: > Remove vm86. Cool. There is one leftover in lib/libarch/i386/i386_vm86.* It's including vm86.h Remember to bump major if you remove a function
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 08, 2017 at 05:48:47PM +, co...@sdf.org wrote: > Also not sure if it's necessary to do on user_return... After finding docs, I think I should probably use this opportunity to re-enable RAS (and not clear) :-)
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 08, 2017 at 05:48:47PM +, co...@sdf.org wrote: > Currently we do not do the empty jumps. the code claims it is flushing > the BTB but it's hard to tell as the docs are in Chinese. Never mind, it's right. Also docs in English: http://dev.lemote.com/files/resource/documents/Loongson/ls2f/Loongson2FUserGuide.pdf
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 08, 2017 at 12:22:21PM +, Maya Rashish wrote: > This only need to be performed on kernel code, because only there we can have > accesses not translated/limited by TLB. For user code, it is impossible to > generate accesses to unwanted physical address. So it is safe. > > Also, to prevent addresses generated by user mode code to be used by the > kernel, we add a few empty jumps to flush the BTB upon entrance to kernel." Currently we do not do the empty jumps. the code claims it is flushing the BTB but it's hard to tell as the docs are in Chinese. Linux does this: /* * Clear BTB (branch target buffer), forbid RAS (return address * stack) to workaround the Out-of-order Issue in Loongson2F * via its diagnostic register. */ movek0, ra jal 1f nop 1: jal 1f nop 1: jal 1f nop 1: jal 1f nop 1: movera, k0 li k0, 3 mtc0k0, $22 I've changed the code be effectively: li k0, 3 mtc0 k0 $22 Also not sure if it's necessary to do on user_return...
Re: CVS commit: src/sys/arch
On Fri, Aug 04, 2017 at 12:26:01PM +0200, Maxime Villard wrote: > We can; but this would be an executable page at a fixed location, and by > definition it violates ASLR. Even more so if the page happens to contain > instruction patterns suitable for all kinds of exploits... linux seems to randomize their vDSO page location, so it's possible not to violate ASLR
Re: CVS commit: src/sys/ufs/lfs
> Log Message: > fix buffer overflow/KASSERT when cookies are supplied > lfs no longer uses the ffs-style struct direct, use the correct minimum > size For kicks, 'found by running COMPAT_LINUX', which does this (so does NFS). LFS still comes with this warning that is very hard to miss: WARNING: the log-structured file system is experimental WARNING: it may cause system crashes and/or corrupt data root file system type: lfs
Re: CVS commit: src/sys/arch/amd64/conf
paulg adds: This is not making GENERIC fail because COMPAT_43 is not really removed on it. $ nm /home/fly/amd/sys/arch/amd64/compile/GENERIC/netbsd |grep compat_43 80403485 T compat_43_netbsd32_fstat43 8040371a T compat_43_netbsd32_killpg 80403431 T compat_43_netbsd32_lstat43 804037b5 T compat_43_netbsd32_oaccept ... This is from: sys/compat/netbsd32/files.netbsd32: filecompat/netbsd32/netbsd32_compat_43.ccompat_netbsd32 & (compat_43 | compat_sunos | compat_linux32) So with COMPAT_LINUX32, it still builds the COMPAT_43 code.
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, Jul 28, 2017 at 04:10:29PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Fri Jul 28 16:10:29 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU > > Log Message: > After a careful review, and all things considered, disable compat43 by > default on amd64. The use case is limited, the potential for damage too > high, and it is safer to run a BSD4.3 binary on i386 since the kernel does > not have to go through netbsd32 - which may not correctly reproduce i386. > > > To generate a diff of this commit: > cvs rdiff -u -r1.461 -r1.462 src/sys/arch/amd64/conf/GENERIC > cvs rdiff -u -r1.136 -r1.137 src/sys/arch/amd64/conf/XEN3_DOM0 > cvs rdiff -u -r1.75 -r1.76 src/sys/arch/amd64/conf/XEN3_DOMU This breaks running compat_linux as a kernel module: Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_sethostname' not found Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_lseek' not found Aug 4 00:19:19 loggy /netbsd: WARNING: module error: unable to affix module `compat_linux', error 8 I believe paulg made PR kern/51597 for similar issues
Re: CVS commit: src
On Tue, Aug 01, 2017 at 06:28:39PM +0200, Joerg Sonnenberger wrote: > Correct, do not remove obsolete entries from the set files without a > very good reason. This one is plain wrong. Thanks, I reverted that part.
Re: CVS commit: src
On Tue, Aug 01, 2017 at 01:57:03PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Tue Aug 1 13:57:03 UTC 2017 > > Modified Files: > src/distrib/sets/lists/comp: md.amd64 md.i386 > Removed Files: > src/sys/arch/i386/include: svr4_machdep.h > > Log Message: > Remove svr4_machdep.h right away, no one should include it. I think obsolete means it will be removed by postinstall if asked to remove obsolete files
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 01, 2017 at 04:12:33PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Tue Aug 1 16:12:33 UTC 2017 > > Modified Files: > src/sys/arch/evbmips/conf: CPMBR1400 LINKITSMART7688 ZYXELKX > > Log Message: > Wrong architecture for IBCS2 compat! it's stringly an x86 thing. Strictly. :-)
Re: CVS commit: src/sys
On Sat, Jul 29, 2017 at 10:39:49AM +, Maxime Villard wrote: > Log Message: > Remove exec_aout support in compat_freebsd. The only reason we still have > compat_freebsd is because of tw_cli, and it is an elf32 binary (could test, > manuel sent it to me). How far is this binary from working? http://mirror.trouble-free.net/3ware/tw_cli-linux-x86_64-9.5.3.tgz
Re: CVS commit: src/tests/lib/libm
There is no other way to find and fix these problems. nobody runs sh3 tests, and non-x86 ports have so many failures that it's going to be drowned in the noise. And it adds an actual test for functionality, to be sure we weren't wrong in adding the function for that arch. This is causing packages to fail in a way that cannot be fixed in an existing release.
Re: CVS commit: src/tests/lib/libm
On Wed, Jul 26, 2017 at 05:32:42AM +0700, Robert Elz wrote: > Date:Wed, 26 Jul 2017 00:31:48 +0300 > From:Valery Ushakov > Message-ID: <20170725213148.ga16...@pony.stderr.spb.ru> > > | You can do that in your tree, not in the public repo. > > coypu - an alternative would be to make a test that (when run as a test, > rather than when being built) attempts to compile code to use whatever > interface that is, so that the test fails if the interface doesn't exist, > rather than actually breaking the build, if the test cannot be compiled and > installed. It's a minor inconvenience to fix a critical bug. we have a lot more of those, as libm's makefile is a trainwreck.
Re: CVS commit: src/tests/lib/libm
On Tue, Jul 25, 2017 at 09:26:56PM +, Valeriy E. Ushakov wrote: > Module Name: src > Committed By: uwe > Date: Tue Jul 25 21:26:56 UTC 2017 > > Modified Files: > src/tests/lib/libm: t_fe_round.c > > Log Message: > Revert previous as it breaks at least sparc and hpcsh builds. > nearbyint() is not included in libm on all platforms. The intention was to find which platforms do not install it and change them to install it
Re: CVS commit: [perseant-stdc-iso10646, trunk] src
(Add it to set lists though)
Re: CVS commit: src/common/lib/libc/string
Although now I see that strchrnul is p widely accepted so I guess it's not that bad (freebsd and illumos have it, too)
Re: CVS commit: src/sys/uvm
On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote: > Module Name: src > Committed By: chs > Date: Fri May 19 15:30:19 UTC 2017 > > Modified Files: > src/sys/uvm: uvm_map.c uvm_mmap.c > > Log Message: > make MAP_FIXED mapping operations atomic. fixes PR 52239. > previously, unmapping any entries being replaced was done separately > from entering the new mapping, which allowed another thread doing > a non-MAP_FIXED mapping to allocate the range out from under the > MAP_FIXED thread. Does that have security ramifications? it sounds like something that won't be good if not atomic, but I don't know enough to tell if it can be abused. Thanks.
Re: CVS commit: src/lib/libm
Diff to 7.1 (also libm.so.0.11) libm diff to 7.1 4a5 > r __GNU_EH_FRAME_HDR 10c11 < w __deregister_frame_info@@GCC_3.0 --- > w __deregister_frame_info 94c95 < w __register_frame_info@@GCC_3.0 --- > w __register_frame_info 96a98 > U __signbitf 111d112 < T _casinl 114d114 < T _catanl 129a130,131 > T _erfcl > T _erfl 134a137,150 > T _feclearexcept > T _fedisableexcept > T _feenableexcept > T _fegetenv > T _fegetexcept > T _fegetexceptflag > T _fegetround > T _feholdexcept > T _feraiseexcept > T _fesetenv > T _fesetexceptflag > T _fesetround > T _fetestexcept > T _feupdateenv 193,194d208 < T cacoshl < T cacosl 202,203d215 < T casinhl < W casinl 208,209d219 < T catanhl < W catanl 271a282 > W erfcl 272a284 > W erfl 286,299c298,311 < T feclearexcept < T fedisableexcept < T feenableexcept < T fegetenv < T fegetexcept < T fegetexceptflag < T fegetround < T feholdexcept < T feraiseexcept < T fesetenv < T fesetexceptflag < T fesetround < T fetestexcept < T feupdateenv --- > W feclearexcept > W fedisableexcept > W feenableexcept > W fegetenv > W fegetexcept > W fegetexceptflag > W fegetround > W feholdexcept > W feraiseexcept > W fesetenv > W fesetexceptflag > W fesetround > W fetestexcept > W feupdateenv 351a364 > T llroundl 368a382 > T lroundl 418a433 > U strlen
Re: CVS commit: src/lib/libm
On Sat, May 06, 2017 at 02:03:25PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat May 6 18:03:25 UTC 2017 > > Modified Files: > src/lib/libm: Makefile > Added Files: > src/lib/libm/src: s_llrint.c s_llrintf.c s_llrintl.c s_llround.c > s_llroundf.c s_llroundl.c s_lrint.c s_lrintf.c s_lrintl.c > s_lround.c s_lroundf.c s_lroundl.c > Removed Files: > src/lib/libm/src: llrint.c llrintf.c llround.c llroundf.c lrint.c > lrintf.c lround.c lroundf.c > > Log Message: > Replace our rounding functions with the ones from FreeBSD > > nm /usr/lib/libm.so.0.11 | awk '{print $(NF-1),"\t",$NF}' > old nm /usr/src/lib/libm/libm.so.0.11 | awk '{print $(NF-1),"\t",$NF}' > new diff old new 363a364 > T llroundl 380a382 > T lroundl Bump?
Re: CVS commit: [prg-localcount2] src
src/sys/external/bsd/drm2/drm/drm_drv.c isn't an upstream file, no need to worry about changing it
Re: CVS commit: [jdolecek-ncq] src/sys/dev/ata
Re: CVS commit: src/usr.bin/make
On Tue, Apr 11, 2017 at 05:30:13PM +, Simon J. Gerraty wrote: > Log Message: > Str_Match: allow [^a-z] to behave as expected. % env A=NetBSD-7-x86_64 make -V '${A:MNetBSD-[^0-1]-i386}' NetBSD-7-x86_64
Re: CVS commit: src/sbin/fsck_ext2fs
On Fri, Apr 21, 2017 at 07:46:27PM +0200, Kamil Rytarowski wrote: > > It's a valid code. > Other things fail: http://releng.netbsd.org/builds/HEAD/201704202350Z/evbarm64-aarch64.build.failed /home/source/ab/HEAD/src/bin/ln/ln.c:357:1: error: function 'usage' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn] { ^ 1 error generated. I think that one is even more valid :-)
Re: CVS commit: src/sbin/fsck_ext2fs
On Fri, Apr 21, 2017 at 01:33:05PM -0400, Christos Zoulas wrote: > e2di_block is an array; can't be NULL, (clang) I'm guessing this is from http://releng.netbsd.org/builds/HEAD-llvm/201704191240Z/amd64.build.failed /home/source/ab/HEAD-llvm/src/sbin/fsck_ext2fs/pass1.c:242:39: warning: comparison of array 'dp->e2di_blocks' equal to a null pointer is always false [-Wtautological-pointer-compare] (EXT2_MAXSYMLINKLEN == 0 && dp->e2di_blocks == 0)) { ^~~~ 1 warning generated. How come that warning wasn't fatal?
Re: CVS commit: src/sys/opencrypto
On Tue, Apr 18, 2017 at 05:05:06PM +, Maya Rashish wrote: > XXX surrounding code seems fishy > > @@ -759,7 +759,6 @@ swcr_compdec(struct cryptodesc *crd, con > if (result < crd->crd_len) { > adj = result - crd->crd_len; > if (outtype == CRYPTO_BUF_MBUF) { > - adj = result - crd->crd_len; > m_adj((struct mbuf *)buf, adj); > } > /* Don't adjust the iov_len, it breaks the kmem_free */ > calling m_adj with negative adj sounds possibly unintended
Re: CVS commit: src/external/bsd/bc/dist
joerg mentions you can get around the dummy returns/breaks after bc_exit to quiet compiler warnings by tagging it dead
Re: CVS commit: src/external/bsd/bc/dist
Hi, -DIGIT [0-9A-F] +DIGIT [0-9A-Z] Looks off, is that intended? Thanks.
Re: CVS commit: [netbsd-7] src
On Wed, Apr 05, 2017 at 07:54:27PM +, Soren Jacobsen wrote: > Module Name: src > Committed By: snj > Date: Wed Apr 5 19:54:23 UTC 2017 > > Modified Files: .. > src/sys/external/bsd/common/include/linux [netbsd-7]: kernel.h > src/sys/external/bsd/drm2/dist/drm/radeon [netbsd-7]: > atombios_encoders.c radeon_legacy_encoders.c > src/sys/external/bsd/drm2/drm [netbsd-7]: files.drmkms > src/sys/external/bsd/drm2/i915drm [netbsd-7]: files.i915drmkms Mistake?
Re: CVS commit: src/sys/arch/amd64/amd64
On Thu, Mar 23, 2017 at 05:25:51PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Thu Mar 23 17:25:51 UTC 2017 > > Modified Files: > src/sys/arch/amd64/amd64: locore.S machdep.c trap.c > > Log Message: > Remove this call gate on amd64, it is useless and vulnerable. > > Call gates do not modify %rflags, so interrupts are not disabled when > entering the gate. There is a small window where we are in kernel mode and > with a userland %gs, and if an interrupt happens here we will rejump into > the kernel but not switch to the kernel TLS. > > Userland can simply perform a gate call in a loop, and hope that at some > point an interrupt will be received in this window - which necessarily will > be the case. With a specially-crafted %gs it is certainly enough to > escalate privileges. > > > To generate a diff of this commit: > cvs rdiff -u -r1.121 -r1.122 src/sys/arch/amd64/amd64/locore.S > cvs rdiff -u -r1.253 -r1.254 src/sys/arch/amd64/amd64/machdep.c > cvs rdiff -u -r1.94 -r1.95 src/sys/arch/amd64/amd64/trap.c > cool! I see in arch/i386/i386/locore.S that there is another call gate and there's: 1246 IDTVEC(osyscall) 1247 #ifndef XEN 1248 /* XXX we are in trouble! interrupts be off here. */ 1249 cli /* must be first instruction */ 1250 #endif 1251 pushfl /* set eflags in trap frame */ Is 'cli' as first instruction what should've been done here, if it wasn't been otherwise useless? can xen not do it? thanks.
Re: CVS commit: src/usr.bin/elf2ecoff
On Thu, Mar 02, 2017 at 08:41:33AM -0500, Christos Zoulas wrote: > Can you try to find the patches? It is a bit complicated because it involves > many parts... (system headers, tools/compat)... I believe it is: usr.bin/elf2ecoff/elf2ecoff.c 1.31, 1.32, 1.33 sys/sys/exec_ecoff.h 1.21 sys/arch/mips/include/ecoff_machdep.h 1.23 tools/mips-elf2ecoff/machine/ecoff_machdep.h 1.3 commit messages: http://mail-index.netbsd.org/source-changes/2017/02/23/msg082320.html http://mail-index.netbsd.org/source-changes/2017/02/23/msg082321.html http://mail-index.netbsd.org/source-changes/2017/02/23/msg082322.html http://mail-index.netbsd.org/source-changes/2017/02/24/msg082329.html http://mail-index.netbsd.org/source-changes/2017/02/24/msg082339.html http://mail-index.netbsd.org/source-changes/2017/02/24/msg082344.html
Re: CVS commit: src/usr.bin/elf2ecoff
On Thu, Feb 23, 2017 at 01:49:00PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Thu Feb 23 18:49:00 UTC 2017 > > Modified Files: > src/usr.bin/elf2ecoff: elf2ecoff.c > > Log Message: > This only works with 32 bit Elf and COFF files, make it specific this way > and use sized types so that it works on 64 bit systems (so it can become > a tool). > > > To generate a diff of this commit: > cvs rdiff -u -r1.30 -r1.31 src/usr.bin/elf2ecoff/elf2ecoff.c > Can you please request a pullup to -7, -6? The original report mentioned that releases after -5 don't boot because of it.
Re: CVS commit: src/sys/arch
On Sun, Feb 26, 2017 at 09:30:49PM +0900, Rin Okuyama wrote: > On 2017/02/26 21:12, co...@sdf.org wrote: > > On Sun, Feb 26, 2017 at 12:03:15PM +, Rin Okuyama wrote: > > > Add DKWEDGE_METHOD_RDB option, which is enabled for x86, commented out for > > > other platforms by default. > > > > > > > Please disable this on x86. It shouldn't be everyone's junkyard. > > OK, I will disabled it except for ALL. > > rin Thanks.
Re: CVS commit: src/sys/arch
On Sun, Feb 26, 2017 at 12:03:15PM +, Rin Okuyama wrote: > Add DKWEDGE_METHOD_RDB option, which is enabled for x86, commented out for > other platforms by default. > Please disable this on x86. It shouldn't be everyone's junkyard.
Re: CVS commit: xsrc/external/mit
On Mon, Feb 20, 2017 at 02:55:47PM +, Rin Okuyama wrote: > Module Name: xsrc > Committed By: rin > Date: Mon Feb 20 14:55:47 UTC 2017 > > Modified Files: > xsrc/external/mit/libXfont/dist/src/fc: fserve.c > xsrc/external/mit/libXt/dist/src: Convert.c ResConfig.c > xsrc/external/mit/libxkbui/dist/src: XKBui.c > xsrc/external/mit/xtrans/dist: Xtranssock.c > > Log Message: > appease clang -Wformat errors with MKDEBUG=yes > Hi, If you're not too busy, could you send the same patches to xorg-de...@lists.x.org? They will likely apply as-is, xsrc is pretty up to date. Thanks.
Re: CVS commit: src/lib/libc/gen
On Mon, Feb 13, 2017 at 12:04:02PM +, co...@sdf.org wrote: > ASan is wrong about where the problem happens, This can be dealt with -fno-omit-frame-pointer.
Re: CVS commit: src/lib/libc/gen
On Sun, Feb 12, 2017 at 05:37:49PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Feb 12 22:37:49 UTC 2017 > > Modified Files: > src/lib/libc/gen: vis.c > > Log Message: > fix off-by-one, found by asan. > It fails in another case, attached ASan is wrong about where the problem happens, so I ran it in gdb - it's here: 514 for (start = dst; len > 0; len--) { 515 c = *src++; 516 dst = (*f)(dst, c, flags, len >= 1 ? *src : L'\0', extra); breakpoint on do_svis /* gcc -fsanitize=address -lasan asan.c && ./a.out */ #include #include #include #include #include #include #include static void h_mbtowc(const char *locale, const char *legal) { char buf[64]; setlocale(LC_ALL, "C"); setlocale(LC_CTYPE, locale); /* re-initialize internal state */ mbtowc(NULL, NULL, 0); /* valid multibyte sequence case */ (void)strvis(buf, legal, VIS_WHITE | VIS_OCTAL); } int main() { h_mbtowc("zh_TW.eucTW", "\241\241"); }
Re: CVS commit: src/sys/dev/pci
On Thu, Feb 02, 2017 at 03:41:22AM +, Jonathan A. Kollasch wrote: > @@ -432,6 +433,10 @@ wpi_detach(device_t self, int flags __un > pci_intr_disestablish(sc->sc_pct, sc->sc_ih); > sc->sc_ih = NULL; > } > + if (sc->sc_pihp != NULL) { > + pci_intr_release(sc->sc_pct, sc->sc_pihp, 1); > + sc->sc_pihp = NULL; > + } > mutex_enter(&sc->sc_rsw_mtx); > sc->sc_dying = 1; > cv_signal(&sc->sc_rsw_cv); > hmm, not introduced by you now, but is it safe that this function is mutex_entering so late? shouldn't it mutex enter and set sc_dying first thing? thanks
Re: CVS commit: src/sys/net
oops, I was wrong here, please disregard :-)
Re: CVS commit: src/sys/net
On Thu, Jan 26, 2017 at 09:13:19PM +, Nick Hudson wrote: > @@ -803,32 +790,14 @@ tunread(dev_t dev, struct uio *uio, int > goto out; > } > tp->tun_flags |= TUN_RWAIT; > - if (mtsleep((void *)tp, PZERO|PCATCH|PNORELOCK, > - "tunread", 0, &tp->tun_lock) != 0) { > + if (cv_wait_sig(&tp->tun_cv, &tp->tun_lock)) { > error = EINTR; > - goto out_nolock; > - } else { > - /* > - * Maybe the interface was destroyed while > - * we were sleeping, so let's ensure that > - * we're looking at the same (valid) tun > - * interface before looping. > - */ > - tp = tun_find_unit(dev); > - if (tp == NULL) { > - error = ENXIO; > - goto out_nolock; > - } > - if (tp->tun_if.if_index != index) { > - error = ENXIO; > - goto out; > - } > + goto out; > } > } If you goto out if tp is NULL, it will dereference it trying to mutex_exit(&tp->tun_lock);
Re: CVS commit: src/sys/net
Hi, On Thu, Jan 26, 2017 at 09:13:19PM +, Nick Hudson wrote: > @@ -534,14 +527,12 @@ tun_output(struct ifnet *ifp, struct mbu > const struct rtentry *rt) > { > struct tun_softc *tp = ifp->if_softc; > - int s; > int error; > #if defined(INET) || defined(INET6) > int mlen; > uint32_t*af; > #endif > > - s = splnet(); > mutex_enter(&tp->tun_lock); > TUNDEBUG ("%s: tun_output\n", ifp->if_xname); > > @@ -551,6 +542,8 @@ tun_output(struct ifnet *ifp, struct mbu > error = EHOSTDOWN; > goto out; > } > + // XXXrmind > + mutex_exit(&tp->tun_lock); > > /* >* if the queueing discipline needs packet classification, > @@ -576,7 +569,7 @@ tun_output(struct ifnet *ifp, struct mbu > error = ENOBUFS; > goto out; > } > - bcopy(dst, mtod(m0, char *), dst->sa_len); > + memcpy(mtod(m0, char *), dst, dst->sa_len); > } > > if (tp->tun_flags & TUN_IFHEAD) { > @@ -617,9 +610,10 @@ tun_output(struct ifnet *ifp, struct mbu > goto out; > } > > + mutex_enter(&tp->tun_lock); you call goto out; with &tp->tun-lock not held, it then mutex_exits it.
Re: CVS commit: src/sys/kern
> @@ -162,7 +162,7 @@ module_load_plist_vfs(const char *modpat > base = NULL; > > proppath = PNBUF_GET(); > - strcpy(proppath, modpath); > + strlcpy(proppath, modpath, MAXPATHLEN); > pathlen = strlen(proppath); > if ((pathlen >= 6) && (strcmp(&proppath[pathlen - 5], ".kmod") == 0)) { > strcpy(&proppath[pathlen - 5], ".plist"); > The sole caller to this function is in the same file. It uses snprintf with MAXPATHLEN to set path.
Re: CVS commit: src/sys/kern
On Sun, Jan 15, 2017 at 01:28:14AM +, Maya Rashish wrote: > - strcpy(name, t->l_name); > + strlcpy(name, t->l_name, sizeof(name)); > This seems limited in setname, and getname was unlimited. I don't see where else it is set, let me know if I'm wrong!
Re: CVS commit: src/sys/dev/raidframe
It's still a behaviour change.. On Thu, Jan 12, 2017 at 11:22:16PM -0500, Christos Zoulas wrote: > +static void > +rf_handle_hosed(RF_Raid_t *raidPtr, RF_Config_t *cfgPtr, int hosed_column) > +{ > + if (raidPtr->Disks[hosed_column].status == rf_ds_failed) > + return; equivalent to if (raidPtr->Disks[hosed_column].status != rf_ds_failed) { do stuff } in the second check, but this is first one: > > - printf("Hosed component: %s\n", > -&cfgPtr->devnames[0][hosed_column][0]); > - if (!force) { > - /* we'll fail this component, as if there are > -other major errors, we arn't forcing things > -and we'll abort the config anyways */ > - raidPtr->Disks[hosed_column].status > - = rf_ds_failed; > - raidPtr->numFailures++; > - raidPtr->status = rf_rs_degraded; > - } > + if (hosed_column != -1) > + rf_handle_hosed(raidPtr, cfgPtr, hosed_column); > It always increments numfailures, even if this column has failed in the distant past.
Re: CVS commit: src/sys/dev/raidframe
On Thu, Jan 12, 2017 at 11:22:16PM -0500, Christos Zoulas wrote: > +rf_handle_hosed(RF_Raid_t *raidPtr, RF_Config_t *cfgPtr, int hosed_column) > +{ : > + if (raidPtr->Disks[hosed_column].status == rf_ds_failed) > + return; equivalent to if (raidPtr->Disks[hosed_column].status != rf_ds_failed) { do stuff This is not in the first part: > - printf("Hosed component: %s\n", > -&cfgPtr->devnames[0][hosed_column][0]); > - if (!force) { > - /* we'll fail this component, as if there are > -other major errors, we arn't forcing things > -and we'll abort the config anyways */ > - raidPtr->Disks[hosed_column].status > - = rf_ds_failed; > - raidPtr->numFailures++; > - raidPtr->status = rf_rs_degraded; > - } > + if (hosed_column != -1) > + rf_handle_hosed(raidPtr, cfgPtr, hosed_column); It is only in the second part: > - printf("Hosed component: %s\n", > -&cfgPtr->devnames[0][hosed_column][0]); > - if (!force) { > - /* we'll fail this component, as if there are > -other major errors, we arn't forcing things > -and we'll abort the config anyways */ > - if (raidPtr->Disks[hosed_column].status != > rf_ds_failed) { > - raidPtr->Disks[hosed_column].status > - = rf_ds_failed; > - raidPtr->numFailures++; > - raidPtr->status = rf_rs_degraded; > - } > - } > + if (hosed_column != -1) > + rf_handle_hosed(raidPtr, cfgPtr, hosed_column); I didn't want to commit it because it introduces a functional change. Now if the status was failed from long before, we will not increment numFailures, so numFailures > 1 is probably not possible.
Re: CVS commit: src/sys/dev/pcmcia
By the way, this code appears to do bogus things with i_len, like "clear trailing garbage" except using the wrong (constant) length. it's possible it doesn't work for SSIDs longer than NETWORK_NAME due to that, but I don't have one or have the confidence to fix it blindly. On Thu, Jan 12, 2017 at 05:11:22PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Thu Jan 12 17:11:22 UTC 2017 > > Modified Files: > src/sys/dev/pcmcia: if_ray.c > > Log Message: > Remove dead code. RAY_DEF_NWID is a constant string, its length will never > be above 32. > > > To generate a diff of this commit: > cvs rdiff -u -r1.84 -r1.85 src/sys/dev/pcmcia/if_ray.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/sys/dev/pcmcia/if_ray.c > diff -u src/sys/dev/pcmcia/if_ray.c:1.84 src/sys/dev/pcmcia/if_ray.c:1.85 > --- src/sys/dev/pcmcia/if_ray.c:1.84 Thu Jul 7 06:55:42 2016 > +++ src/sys/dev/pcmcia/if_ray.c Thu Jan 12 17:11:22 2017 > @@ -1,4 +1,4 @@ > -/* $NetBSD: if_ray.c,v 1.84 2016/07/07 06:55:42 msaitoh Exp $ */ > +/* $NetBSD: if_ray.c,v 1.85 2017/01/12 17:11:22 maya Exp $ */ > > /* > * Copyright (c) 2000 Christian E. Hopps > @@ -57,7 +57,7 @@ > */ > > #include > -__KERNEL_RCSID(0, "$NetBSD: if_ray.c,v 1.84 2016/07/07 06:55:42 msaitoh Exp > $"); > +__KERNEL_RCSID(0, "$NetBSD: if_ray.c,v 1.85 2017/01/12 17:11:22 maya Exp $"); > > #include "opt_inet.h" > > @@ -553,8 +553,6 @@ ray_attach(device_t parent, device_t sel >*/ > memset(&sc->sc_dnwid, 0, sizeof(sc->sc_dnwid)); > sc->sc_dnwid.i_len = strlen(RAY_DEF_NWID); > - if (sc->sc_dnwid.i_len > IEEE80211_NWID_LEN) > - sc->sc_dnwid.i_len = IEEE80211_NWID_LEN; > if (sc->sc_dnwid.i_len > 0) > memcpy(sc->sc_dnwid.i_nwid, RAY_DEF_NWID, sc->sc_dnwid.i_len); > memcpy(&sc->sc_cnwid, &sc->sc_dnwid, sizeof(sc->sc_cnwid)); >
Re: CVS commit: src/sys/arch/x86/pci
> #define VMXNET3_CORE_LOCK_ASSERT(_sc)mutex_owned((_sc)->vmx_mtx) > > #define VMXNET3_RXQ_LOCK_ASSERT(_rxq)\ > mutex_owned((_rxq)->vxrxq_mtx) > #define VMXNET3_TXQ_LOCK_ASSERT(_txq)\ > mutex_owned((_txq)->vxtxq_mtx) These should probably assert for real (coverity is complaining of this :)), but I'm not sure that the asserts don't fire.
Re: CVS commit: src/doc
On Sun, Jan 08, 2017 at 04:17:44PM +, Thomas Klausner wrote: > Module Name: src > Committed By: wiz > Date: Sun Jan 8 16:17:44 UTC 2017 > > Modified Files: > src/doc: 3RDPARTY > > Log Message: > zlib-1.2.9 out. > 1.2.10 is out
Re: CVS commit: src/lib/libm/complex
On Sat, Dec 31, 2016 at 03:33:03PM +, Maya Rashish wrote: > - w = r + y * I; > + r = sqrt(x); > + w = r; > } > } > return w; I'm an alignment newbie. Could this create alignment issues? Return type is double complex, and r is just double. Thanks.
Re: CVS commit: src/sys/kern
On Wed, Dec 28, 2016 at 12:05:58AM +, Roy Marples wrote: > Can you please explain how the security model was broken? > intention with securelevel is to do less things kernel-side if it is raised (which, I hope, reduces our attack surface). I don't think it's worth adding this complexity for better npfctl warnings (it's just a warning and doesn't change its behaviour). If you want, I can modify npfctl not to warn for the EPERM case. I'm not sure whether that is better.
Re: CVS commit: src/sys/uvm
On Fri, Dec 23, 2016 at 09:22:22AM +1100, matthew green wrote: > > Log Message: > > Use uvm_physseg.h:uvm_page_physload() instead of uvm_extern.h > > > > For this, include uvm_physseg.h in the build and include tree, make a > > cosmetic modification to the prototype for uvm_page_physload(). > > why does this need to be installed? > > this header seems kernel-only, it should be not installed > and it should not be included if !_KERNEL. > > note that should work in user or kernel > sanely to include from anywhere outside of sys/uvm itself, > but we shouldn't export things to userland we don't need. > I've made it kernel-only as a quick fix because it uses paddr_t which isn't available to userland, and it's breaking pkgsrc packages, to keep -current usable. see: http://mail-index.netbsd.org/pkgsrc-users/2016/12/24/msg024178.html (devel/libuv).
Re: CVS commit: src/tests/lib/libm
On Mon, Dec 19, 2016 at 05:44:56PM +, co...@sdf.org wrote: > I suppose the name is dumb, but I only thought about it > after committing. sorry. > It should crash with SIGFPE on alpha, which is why I thought > of exceptions when naming it! ... except it shouldn't do that either now. I'm gonna stop talking now
Re: CVS commit: src/tests/lib/libm
On Mon, Dec 19, 2016 at 05:38:24PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Mon Dec 19 17:38:24 UTC 2016 > > Modified Files: > src/tests/lib/libm: Makefile > Added Files: > src/tests/lib/libm: t_fe_round.c > > Log Message: > add test for fesetround/fegetround that uses lrint (and tests it a bunch). > It doesn't fail on amd64. > I suppose the name is dumb, but I only thought about it after committing. sorry. It should crash with SIGFPE on alpha, which is why I thought of exceptions when naming it!
Re: CVS commit: src/sys
On Fri, Dec 16, 2016 at 11:35:04PM +, Taylor R Campbell wrote: > Fix return value of nommap. > pullups?
Re: CVS commit: src/sys/sys
On Mon, Dec 12, 2016 at 10:07:12PM +, co...@sdf.org wrote: > > This unfortunately presents a problem with pulling up > the fix to -7. on icb someone mentioned 7.1 is a different version anyway. so it shouldn't be an issue here, yay.
Re: CVS commit: src/sys/sys
On Mon, Dec 12, 2016 at 09:56:00PM +, Maya Rashish wrote: > Bump for drm2 da_fb_linebytes > This unfortunately presents a problem with pulling up the fix to -7. it's not normally a module. thoughts?
Re: CVS commit: src/sys/dev/raidframe
err, this does introduce a functional change... oops it's if panicstr != NULL, but that's not the argument.
Re: CVS commit: src
On Thu, Dec 08, 2016 at 05:03:04PM +0100, J. Hannken-Illjes wrote: > > > On 08 Dec 2016, at 15:41, Nathanial Sloss wrote: > > > > On Thu, 8 Dec 2016 23:57:51 J. Hannken-Illjes wrote: > >> +#defineD_MCLOSE0x0004 > >> > >> What is a MCLOSE device class? > >> > > > > Normally character devices are don't execute the close function untill the > > last instance of device is closed. MCLOSE is short for multiple close, for > > use when you want the close function to run when any instance of the > > device, > > in this case audio, is closed. > > So it should become a flag like 0x0400, not a class in the 0x00ff range. > > Where was this change discussed? > Whole change was introduced in a fairly long thread, starting here: http://mail-index.netbsd.org/tech-kern/2016/05/thread1.html#020572
Re: CVS commit: src/sys/arch
On Fri, Nov 25, 2016 at 01:04:20PM +0100, Maxime Villard wrote: > > ? It probably means there is some kind of stupid assumption or hack in > emacs. If you could send me the core, the binary and tell me which arch it > is, that would be nice. AFAICT, emacs is known to be buggy on netbsd. For context "However, it works a bit differently for Emacs. After loading up the bare minimum temacs executable with all necessary Emacs Lisp files, the so-called unexec function reads in it own executable it???s originating from, scans over the entire process memory, then modifies the file to contain the state obtained and saves it into the emacs executable. In other words, this file contains a partial and very platform-specific reimplementation of a linker. " http://emacshorrors.com/posts/unexecute.html
Re: CVS commit: src/sys/dev/pci
On Sun, Nov 27, 2016 at 12:15:56AM +0900, Kimihiro Nonaka wrote: > Hi, > > 2016-11-26 17:29 GMT+09:00 : > > > This strangely causes fallpoint for sandpoint because: > > sandpoint/include/pci_machdep.h:38:#define __HAVE_PCI_MSI_MSIX > > Does it really? > > fixed > > http://mail-index.netbsd.org/source-changes/2016/11/26/msg079370.html > > regards, > -- > Kimihiro Nonaka Thanks!
Re: CVS commit: src/sys/dev/pci
This strangely causes fallpoint for sandpoint because: sandpoint/include/pci_machdep.h:38:#define __HAVE_PCI_MSI_MSIX Does it really? Failure at http://releng.netbsd.org/builds/HEAD/201611252110Z/sandpoint.build.failed if_re_pci.o: In function `re_pci_detach': if_re_pci.c:(.text+0x70): undefined reference to `pci_intr_release' if_re_pci.o: In function `re_pci_attach': if_re_pci.c:(.text+0x37c): undefined reference to `pci_intr_alloc' if_re_pci.c:(.text+0x3e0): undefined reference to `pci_intr_alloc' On Fri, Nov 25, 2016 at 12:10:59PM +, Kengo NAKAHARA wrote: > Module Name: src > Committed By: knakahara > Date: Fri Nov 25 12:10:59 UTC 2016 > > Modified Files: > src/sys/dev/pci: pci_stub.c pcivar.h > > Log Message: > provide all PCI MSI/MSI-X manipulation stub functions. > > "#ifdef __HAVE_PCI_MSI_MSIX" workaround such as nvme_pci(4) is not required > any more. > http://mail-index.netbsd.org/source-changes/2016/09/17/msg077799.html > > > To generate a diff of this commit: > cvs rdiff -u -r1.5 -r1.6 src/sys/dev/pci/pci_stub.c > cvs rdiff -u -r1.108 -r1.109 src/sys/dev/pci/pcivar.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/lib/librumpuser/build-aux
For the record, this is because the build server is running -6-1..
Re: CVS commit: src/lib/librumpuser/build-aux
On Wed, Oct 19, 2016 at 09:41:30AM +, Antti Kantee wrote: > No idea about the cause, but there seem to be other variants of the same > theme in the build logs, suggesting a more general problem, e.g.: > https://releng.netbsd.org/builds/HEAD/201610171520Z/sbmips-mipseb.build.failed > > In all of the cases I looked at, it was a lib, but don't know if that holds > universally. > Yes. there are many occurences of this script. If it had been the cause, that would still make sense. I reverted my change.
Re: CVS commit: src/lib/librumpuser/build-aux
On Tue, Oct 18, 2016 at 10:28:04PM +, Antti Kantee wrote: > On 17/10/16 18:24, Maya Rashish wrote: > >Module Name: src > >Committed By:maya > >Date:Mon Oct 17 18:24:42 UTC 2016 > > > >Modified Files: > > src/lib/librumpuser/build-aux: install-sh > > > >Log Message: > >use mktemp instead of $RANDOM for tmpdir > > > >..$RANDOM won't work with our /bin/sh. > > > >unsure if this script is used, but it is wrong. > >might help the spurious build failures that occasionally > >show up on autobuilds. > > Are you planning to adjust all of the unused install-sh files around the > tree to make them consistently less wrong? Maybe I should revert it because I misunderstood things and it does not matter... sorry for the noise I was trying to do something about the random failures in builds http://releng.netbsd.org/builds/netbsd-6/201610160430Z/ews4800mips.build.failed http://releng.netbsd.org/builds/netbsd-6/201610181650Z/sbmips-mipsel.build.failed
Re: CVS commit: src/lib/librumpuser/build-aux
On Mon, Oct 17, 2016 at 06:24:42PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Mon Oct 17 18:24:42 UTC 2016 > > Modified Files: > src/lib/librumpuser/build-aux: install-sh > > Log Message: > use mktemp instead of $RANDOM for tmpdir > Woops, this is totally redundant, but harmless...
Re: CVS commit: src/sys/arch/arm/omap
Hi, On Sat, Oct 15, 2016 at 03:09:00PM +, KIYOHARA Takashi wrote: > + fifo = OMAP2_I2C_FIFOBYTES(fifodepth); >From >http://releng.netbsd.org/builds/HEAD/201610160020Z/evbarm-earmv7hf.build.failed --- kern-BEAGLEBONE --- /home/source/ab/HEAD/src/sys/arch/arm/omap/ti_iic.c: In function 'ti_iic_attach': /home/source/ab/HEAD/src/sys/arch/arm/omap/ti_iic.c:281:9: error: implicit declaration of function 'OMAP2_I2C_FIFOBYTES' [-Werror=implicit-function-declaration] fifo = OMAP2_I2C_FIFOBYTES(fifodepth); ^
Re: CVS commit: src/sbin/mount
On Sun, Oct 09, 2016 at 12:57:50PM -0600, Greg Oster wrote: > > mount -t ext2 /dev/sd0e /mnt1 > mount -t ext2 /dev/sd1e /mnt2 > mount -t ext2 /dev/sd2e /mnt3 > mount -t ext2 /dev/sd3e /mnt4 > - > > and getting the message: > > mount: mount_ext2 not found > > Now: which of those mounts failed? > I feel like in any case you learn that you shouldn't be using mount -t ext2. and you'd want to correct all of them.
Re: CVS commit: src/share/mk
On Fri, Sep 09, 2016 at 09:26:40PM +, co...@sdf.org wrote: > On Fri, Sep 09, 2016 at 04:02:18PM +, co...@sdf.org wrote: > > On Thu, Sep 08, 2016 at 09:37:25PM -0400, Christos Zoulas wrote: > > > On Sep 8, 8:40pm, co...@sdf.org (co...@sdf.org) wrote: > > > -- Subject: Re: CVS commit: src/share/mk > > > > > > | I think we need to revert this commit. I see issues with awk on pmax > > > | too. > > > | I don't have a nice hardfloat case like martin in PR 51026 but > > > | attempting to build anything from pkgsrc will fail on checksum compare. > > > > > > Can you make a unit test? > > > > > > christos > > > > Sorry, my problem seems unrelated. I just assumed because it's awk + bad > > results. I'll try to dig more. > > a reduced case which shows the failure I had with pkgsrc (even with > gcc 4.8.5) is: > awk 'BEGIN { print x++; }' > > it prints 2.22507e-308 on gxemul-emulated pmax with gcc 4.8.5. > it might be a gxemul bug, too. > > I didn't know all numbers in awk are doubles. it's a gxemul bug (flxd doesn't see it on real hardware :) sorry for the noise.
Re: CVS commit: src/share/mk
On Fri, Sep 09, 2016 at 04:02:18PM +, co...@sdf.org wrote: > On Thu, Sep 08, 2016 at 09:37:25PM -0400, Christos Zoulas wrote: > > On Sep 8, 8:40pm, co...@sdf.org (co...@sdf.org) wrote: > > -- Subject: Re: CVS commit: src/share/mk > > > > | I think we need to revert this commit. I see issues with awk on pmax > > | too. > > | I don't have a nice hardfloat case like martin in PR 51026 but > > | attempting to build anything from pkgsrc will fail on checksum compare. > > > > Can you make a unit test? > > > > christos > > Sorry, my problem seems unrelated. I just assumed because it's awk + bad > results. I'll try to dig more. a reduced case which shows the failure I had with pkgsrc (even with gcc 4.8.5) is: awk 'BEGIN { print x++; }' it prints 2.22507e-308 on gxemul-emulated pmax with gcc 4.8.5. it might be a gxemul bug, too. I didn't know all numbers in awk are doubles.
Re: CVS commit: src/share/mk
On Thu, Sep 08, 2016 at 09:37:25PM -0400, Christos Zoulas wrote: > On Sep 8, 8:40pm, co...@sdf.org (co...@sdf.org) wrote: > -- Subject: Re: CVS commit: src/share/mk > > | I think we need to revert this commit. I see issues with awk on pmax > | too. > | I don't have a nice hardfloat case like martin in PR 51026 but > | attempting to build anything from pkgsrc will fail on checksum compare. > > Can you make a unit test? > > christos Sorry, my problem seems unrelated. I just assumed because it's awk + bad results. I'll try to dig more.
Re: CVS commit: src/share/mk
I think we need to revert this commit. I see issues with awk on pmax too. I don't have a nice hardfloat case like martin in PR 51026 but attempting to build anything from pkgsrc will fail on checksum compare. On Sat, Sep 03, 2016 at 08:32:12AM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Sep 3 12:32:12 UTC 2016 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Switch mips32 to new binutils/gcc/gdb/pie. Tested with gxemul+pmax > > > To generate a diff of this commit: > cvs rdiff -u -r1.950 -r1.951 src/share/mk/bsd.own.mk > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: >
Re: CVS commit: src/sys/dev
On Wed, Jul 27, 2016 at 01:09:44AM +, Paul Goyette wrote: > Module Name: src > Committed By: pgoyette > Date: Wed Jul 27 01:09:44 UTC 2016 > > Modified Files: > src/sys/dev: md.c > > Log Message: > If we're going to check for a NULL pointer, do the check before we > dereference it (to get the lock address). > > > To generate a diff of this commit: > cvs rdiff -u -r1.76 -r1.77 src/sys/dev/md.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/sys/dev/md.c > diff -u src/sys/dev/md.c:1.76 src/sys/dev/md.c:1.77 > --- src/sys/dev/md.c:1.76 Mon Jan 4 16:24:52 2016 > +++ src/sys/dev/md.c Wed Jul 27 01:09:44 2016 > @@ -1,4 +1,4 @@ > -/* $NetBSD: md.c,v 1.76 2016/01/04 16:24:52 hannken Exp $ */ > +/* $NetBSD: md.c,v 1.77 2016/07/27 01:09:44 pgoyette Exp $ */ > > /* > * Copyright (c) 1995 Gordon W. Ross, Leo Weppelman. > @@ -40,7 +40,7 @@ > */ > > #include > -__KERNEL_RCSID(0, "$NetBSD: md.c,v 1.76 2016/01/04 16:24:52 hannken Exp $"); > +__KERNEL_RCSID(0, "$NetBSD: md.c,v 1.77 2016/07/27 01:09:44 pgoyette Exp $"); > > #ifdef _KERNEL_OPT > #include "opt_md.h" > @@ -414,13 +414,13 @@ mdstrategy(struct buf *bp) > > sc = device_lookup_private(&md_cd, MD_UNIT(bp->b_dev)); > > - mutex_enter(&sc->sc_lock); > - > if (sc == NULL || sc->sc_type == MD_UNCONFIGURED) { > bp->b_error = ENXIO; > goto done; > } > > + mutex_enter(&sc->sc_lock); > + > switch (sc->sc_type) { > #if MEMORY_DISK_SERVER > case MD_UMEM_SERVER: > goto done; will exit mutex not entered now, I think.
Re: CVS commit: src/sys/arch/arm/arm32
On Fri, Jul 15, 2016 at 05:59:46AM +, Nick Hudson wrote: > + > +bool > +mm_md_page_color(paddr_t pa, int *colorp) > +{ > + *colorp = atop(pa & arm_cache_prefer_mask); > + > + return arm_cache_prefer_mask ? false : true; > +} > arm_cache_prefer_mask only exists for armv6/armv7 now
Re: CVS commit: src/sys/arch/arm/arm32
On Fri, Jul 15, 2016 at 05:59:46AM +, Nick Hudson wrote: > Module Name: src > Committed By: skrll > Date: Fri Jul 15 05:59:46 UTC 2016 > > Modified Files: > src/sys/arch/arm/arm32: arm32_machdep.c > > Log Message: > Provide a mm_md_page_color and fix some kernel builds > > Seems it broke the rest of them. I can build with this diff, but I don't know if it is correct. Index: arm32_machdep.c === RCS file: /cvsroot/src/sys/arch/arm/arm32/arm32_machdep.c,v retrieving revision 1.111 diff -u -r1.111 arm32_machdep.c --- arm32_machdep.c 15 Jul 2016 05:59:46 - 1.111 +++ arm32_machdep.c 15 Jul 2016 19:31:34 - @@ -746,11 +746,3 @@ return rv; } #endif - -bool -mm_md_page_color(paddr_t pa, int *colorp) -{ - *colorp = atop(pa & arm_cache_prefer_mask); - - return arm_cache_prefer_mask ? false : true; -} Index: pmap.c === RCS file: /cvsroot/src/sys/arch/arm/arm32/pmap.c,v retrieving revision 1.335 diff -u -r1.335 pmap.c --- pmap.c 14 Jul 2016 15:51:41 - 1.335 +++ pmap.c 15 Jul 2016 19:31:37 - @@ -519,6 +519,13 @@ vaddr_t pmap_directlimit; #endif +static inline bool +mm_md_page_color(paddr_t pa, int *colorp) +{ + *colorp = atop(pa & arm_cache_prefer_mask); + + return arm_cache_prefer_mask ? false : true; +} /* * Misc. locking data structures */ @@ -7945,3 +7952,4 @@ #endif } #endif /* __HAVE_MM_MD_DIRECT_MAPPED_PHYS */ +
Re: CVS commit: src/sys/arch/x86/x86
On Fri, Jul 01, 2016 at 11:44:05AM +, Maxime Villard wrote: > Log Message: > Use pmap_bootstrap_valloc and pmap_bootstrap_palloc under XEN at least > once, for these not to appear as unused functions (not tested, but I > guess). Maybe __used or ifndef XEN?