Re: CVS commit: src

[coypu]

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

[coypu]

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

[coypu]

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/distrib

[coypu]

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

[coypu]

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

[coypu]

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/ufs/ffs

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

> 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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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 <u...@stderr.spb.ru>
> 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

[coypu]

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: src/sys/uvm

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

Re: CVS commit: src/usr.bin/make

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

Hi,

-DIGIT [0-9A-F]
+DIGIT [0-9A-Z]

Looks off, is that intended?

Thanks.

Re: CVS commit: [netbsd-7] src

[coypu]

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

[coypu]

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/sys/arch

[coypu]

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: src/lib/libc/gen

[coypu]

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

[coypu]

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

[coypu]

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_rsw_mtx);
>   sc->sc_dying = 1;
>   cv_signal(>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

[coypu]

oops, I was wrong here, please disregard :-)

Re: CVS commit: src/sys/net

[coypu]

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, >tun_lock) != 0) {
> + if (cv_wait_sig(>tun_cv, >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(>tun_lock);

Re: CVS commit: src/sys/net

[coypu]

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(>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(>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(>tun_lock);

you call goto out; with >tun-lock not held, it then
mutex_exits it.

Re: CVS commit: src/sys/kern

[coypu]

> @@ -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([pathlen - 5], ".kmod") == 0)) {
>   strcpy([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

[coypu]

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

[coypu]

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",
> ->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

[coypu]

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",
> ->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",
> ->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

[coypu]

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_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_cnwid, >sc_dnwid, sizeof(sc->sc_cnwid));
> 

Re: CVS commit: src/sys/arch/x86/pci

[coypu]

>  #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

[coypu]

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

[coypu]

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/uvm

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

err, this does introduce a functional change... oops
it's if panicstr != NULL, but that's not the argument.

Re: CVS commit: src

[coypu]

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/dev/pci

[coypu]

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

[coypu]

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

[coypu]

For the record, this is because the build server is running -6-1..

Re: CVS commit: src/lib/librumpuser/build-aux

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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

[coypu]

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(_cd, MD_UNIT(bp->b_dev));
>  
> - mutex_enter(>sc_lock);
> -
>   if (sc == NULL || sc->sc_type == MD_UNCONFIGURED) {
>   bp->b_error = ENXIO;
>   goto done;
>   }
>  
> + mutex_enter(>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

[coypu]

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

[coypu]

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

[coypu]

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?