Re: CVS commit: src/usr.sbin/puffs/mount_9p

2020-08-30 Thread Christos Zoulas


> On Aug 30, 2020, at 7:01 PM, Valery Ushakov  wrote:
> 
> On Sun, Aug 30, 2020 at 17:12:45 -0400, Christos Zoulas wrote:
> 
>> Module Name: src
>> Committed By:christos
>> Date:Sun Aug 30 21:12:45 UTC 2020
>> 
>> Modified Files:
>>  src/usr.sbin/puffs/mount_9p: Makefile
>> 
>> Log Message:
>> include bsd.init.mk to avoid:
>> make: Bad conditional expression ` != "no"' in  != "no"? -DINET6 :
> 
> This worked and the :? for was specifically used to so that the ugly
> early include (required for an ifdef) can be avoided.  I don't
> remember who pointed out this form to me (joerg@ or mrg@ I'd guess).
> We have more forms like this in the tree, so not much.
> 
> Is this a recent regression?  Is that fallout from make rototill?  Are
> other similar :? use cases broken too?

I think it is a new warning added with the make changes. We must have more
code like this in the tree. I think it is a good practice (for consistency 
also) to
have the bsd.init.mk included first, so that variables used by the rules are 
defined.

christos



signature.asc
Description: Message signed with OpenPGP


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

2020-07-26 Thread Christos Zoulas
In article <20200726200457.f2522f...@cvs.netbsd.org>,
Roland Illig  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rillig
>Date:  Sun Jul 26 20:04:57 UTC 2020
>
>Modified Files:
>   src/usr.bin/make: Makefile
>
>Log Message:
>make(1): explicitly add dependencies on headers
>
>This prevents partial builds after changing a header.  The declared
>dependencies are more than strictly necessary, but that's still better
>than having inconsistent partial builds because too few dependencies are
>declared.

Isn't that what make depend is for?

christos



Re: CVS commit: othersrc/usr.bin/tnftp

2020-07-07 Thread Christos Zoulas
In article <20200707023354.gv12...@mewburn.net>,
Luke Mewburn   wrote:
>On 20-07-05 22:06, Christos Zoulas wrote:
>  | In article <20200705105511.91226f...@cvs.netbsd.org>,
>  | Luke Mewburn  wrote:
>  | >-=-=-=-=-=-
>  | >
>  | >Module Name:  othersrc
>  | >Committed By: lukem
>  | >Date: Sun Jul  5 10:55:11 UTC 2020
>  | >
>  | >Modified Files:
>  | >  othersrc/usr.bin/tnftp: ChangeLog NEWS configure.ac
>  | >
>  | >Log Message:
>  | >Only replace glob if GLOB_BRACE and GLOB_TILDE aren't available.
>  | 
>  | More importantly for ftp GLOB_LIMIT.
>
>usr.bin/tnftp (from ftp) does not use GLOB_LIMIT, so I don't need to
>check if the system glob() supports it.
>
>libexec/tnftpd (from ftpd) does use GLOB_LIMIT, but that build hasn't
>yet been modified to check if the system glob() is sufficient. I'll do
>that sometime, but I will ensure that configure check also checks for
>GLOB_LIMIT.

Thanks, I confused tnftp and tnftpd.

christos



Re: CVS commit: othersrc/usr.bin/tnftp

2020-07-07 Thread Christos Zoulas
In article <20200707021514.gu12...@mewburn.net>,
Luke Mewburn   wrote:
>On 20-07-05 22:07, Christos Zoulas wrote:
>  | In article <20200705105548.f0265f...@cvs.netbsd.org>,
>  | Luke Mewburn  wrote:
>  | >-=-=-=-=-=-
>  | >
>  | >Module Name:  othersrc
>  | >Committed By: lukem
>  | >Date: Sun Jul  5 10:55:48 UTC 2020
>  | >
>  | >Modified Files:
>  | >  othersrc/usr.bin/tnftp: configure tnftp_config.h.in
>  | 
>  | And GLOB_NOCHECK.
>
>AFAICT, GLOB_NOCHECK is "standard POSIX" and not a BSD/GNU extension,
>so I figured I didn't need to check for it.
>Do you know of systems that provide  and glob() but
>don't support GLOB_NOCHECK() ?

No, I don't but it is simple enough to |GLOB_NOCHECK in the test.
I just listed all the flags tnftp uses I think.

christos



Re: CVS commit: othersrc/usr.bin/tnftp

2020-07-05 Thread Christos Zoulas
In article <20200705105548.f0265f...@cvs.netbsd.org>,
Luke Mewburn  wrote:
>-=-=-=-=-=-
>
>Module Name:   othersrc
>Committed By:  lukem
>Date:  Sun Jul  5 10:55:48 UTC 2020
>
>Modified Files:
>   othersrc/usr.bin/tnftp: configure tnftp_config.h.in

And GLOB_NOCHECK.

christos



Re: CVS commit: othersrc/usr.bin/tnftp

2020-07-05 Thread Christos Zoulas
In article <20200705105511.91226f...@cvs.netbsd.org>,
Luke Mewburn  wrote:
>-=-=-=-=-=-
>
>Module Name:   othersrc
>Committed By:  lukem
>Date:  Sun Jul  5 10:55:11 UTC 2020
>
>Modified Files:
>   othersrc/usr.bin/tnftp: ChangeLog NEWS configure.ac
>
>Log Message:
>Only replace glob if GLOB_BRACE and GLOB_TILDE aren't available.

More importantly for ftp GLOB_LIMIT.

christos



Re: [statfs12] CVS commit: src

2020-07-05 Thread Christos Zoulas


> On Jul 3, 2020, at 2:26 AM, Maxime Villard  wrote:
> 
> Why insist on using the wrong structure, when you could just as easily use
> the correct structure? I don't get the point.

I'll change it.

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/bsd/kyua-cli

2020-07-02 Thread Christos Zoulas
In article <20200702140653.gf12...@mewburn.net>,
Luke Mewburn   wrote:
>On 20-06-21 18:23, Christos Zoulas wrote:
>  | In article <20200621142616.60471f...@cvs.netbsd.org>,
>  | Luke Mewburn  wrote:
>  | >-=-=-=-=-=-
>  | >
>  | >Module Name:  src
>  | >Committed By: lukem
>  | >Date: Sun Jun 21 14:26:16 UTC 2020
>  | >
>  | >Modified Files:
>  | >  src/external/bsd/kyua-cli: Makefile.inc
>  | >
>  | >Log Message:
>  | >kyua-cli: avoid warning about deprecated auto_ptr
>  | 
>  | Can you sed -ie s/auto_ptr/unique_ptr/g instead?
>  | You'll need to do this for c++-17 anyway.
>
>Done. Needed a little bit more than that because kyua-cli
>was passing auto_ptrs around as function arguments or assigning
>to globals; both fixed with std::move().

Cool, thanks!

christos



Re: CVS commit: src/sys/compat/sys

2020-06-28 Thread Christos Zoulas


> On Jun 28, 2020, at 10:24 AM, Robert Elz  wrote:
> 
>Date:Sat, 27 Jun 2020 11:49:30 -0400
>From:    "Christos Zoulas" 
>Message-ID:  <20200627154930.84e22f...@cvs.netbsd.org>
> 
>  | Modified Files:
>  |src/sys/compat/sys: mount.h
>  |
>  | Log Message:
>  | Ignore the supplied size, and always use the argument size that we know.
> 
> Is this fix correct?Certainly looks more reasonable than
> what was there before, as the supplied size (for no seemingly
> good reason) is often 0, but in compat_20_sys_getfsstat() (in
> sys/compat/common/vfs_syscalls_20.c) statvfs_to_statfs12_copy()
> is called, via do_sys_getvfsstat() with a size of
> sizeof(struct statvfs90) and a statvfs90 (compat/sys/statvfs.h)
> is certainly not the same size as a statfs12 (compat/sys/mount.h)
> 
> Or perhaps (probably more likely) compat_20_sys_getfsstat() should
> be passing sizeof(struct statfs12) instead ?   (And now may as well
> just pass 0).

No, it has to be sizeof(struct statfs12) because the function fills an
array of struct statfs12 and needs to know how much to increment.

Thanks,

christos



signature.asc
Description: Message signed with OpenPGP


Re: [statfs12] CVS commit: src

2020-06-27 Thread Christos Zoulas
> 
> Please revert all of this change.
> 
> First, there was a clear vulnerability in this change, which I fixed in:
> 
>   https://mail-index.netbsd.org/source-changes/2020/06/27/msg118731.html
> 
> Then, as I said in the change, there are additional problems:
> 
> 137 static __inline int
> 138 statvfs_to_statfs12_copy(const void *vs, void *vs12, size_t l)
> 139 {
> 140   struct statfs12 *s12 = STATVFSBUF_GET();
> 141   int error;
> 142
> 143   statvfs_to_statfs12(vs, s12);
> 144   error = copyout(s12, vs12, l);
> 145   STATVFSBUF_PUT(s12);
> 146
> 147   return error;
> 148 }
> 
> STATVFSBUF_GET() allocates struct statvfs, but here we're using struct
> statfs12. How can this be expected to be correct?

It is larger than needed, so it works.

> Then the copyout is done with a size, and again there are problems here.
> In compat_20_sys_getfsstat() the size given is struct statvfs90, which
> matches neither the filled size nor the allocated size.

That is a mistake and I have fixed it.

> The other callers have even bigger problems. For example
> compat_20_sys_statfs() passes zero as size. So the result simply never
> gets copied out. How can this be expected to be correct? As far as I can
> tell the syscall simply cannot work now.

Same bug as above.

> Finally, I don't even understand what this change dedups. It just moved
> the functions from one place to another, introduced bugs in them, but
> didn't reduce the code size in any way.

It reduces maintainability, since the conversion was done in two places
(in libc and the kernel) and now it is done in one.

> As I said, please revert all of this change, it is just plain wrong and
> hasn't received any testing.

I have fixed it instead, if you find more bugs please let me know.

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/dev/ic

2020-06-25 Thread Christos Zoulas
In article <18083.1593053...@splode.eterna.com.au>,
matthew green   wrote:
>"Jaromir Dolecek" writes:
>> Module Name: src
>> Committed By:jdolecek
>> Date:Wed Jun 24 19:55:25 UTC 2020
>> 
>> Modified Files:
>>  src/sys/dev/ic: ibm561.c
>> 
>> Log Message:
>> avoid allocating almost 5k struct ibm561data on stack in ibm561_cninit();
>> it's too early for kmem_alloc(), so use static variable in BSS
>
>this seems particularly wasteful for a driver that won't
>be useful for most systems.
>
>seems like a candidate for allow-listing instead, and as
>it seems to only be relevant for alpha systems, that have
>a fairly large stack (16K), and this will be called with
>a fairly short call stack.

I agree; the BSS kludge is ugly in general and should only be
used sparingly.

christos



Re: CVS commit: src/external/bsd/kyua-cli

2020-06-21 Thread Christos Zoulas
In article <20200621142616.60471f...@cvs.netbsd.org>,
Luke Mewburn  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  lukem
>Date:  Sun Jun 21 14:26:16 UTC 2020
>
>Modified Files:
>   src/external/bsd/kyua-cli: Makefile.inc
>
>Log Message:
>kyua-cli: avoid warning about deprecated auto_ptr

Can you sed -ie s/auto_ptr/unique_ptr/g instead?
You'll need to do this for c++-17 anyway.

christos



Re: CVS commit: src/tests/lib/libarchive

2020-06-16 Thread Christos Zoulas
In article <20200616075907.ecafcf...@cvs.netbsd.org>,
Martin Husemann  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  martin
>Date:  Tue Jun 16 07:59:07 UTC 2020
>
>Modified Files:
>   src/tests/lib/libarchive: t_libarchive.sh
>
>Log Message:
>PR kern/55272: skip this test on uniprocessor machines, it is too dangerous
>and can kill the host kernel if a userland watchdog is running

So we are saying that it is ok for process running with regular priority,
to be able to starve another process at the same priority from getting
any runtime for 21 seconds in a uniprocessor kernel, and this does not
indicate any problem with the scheduler implementation? This would mean
that for a HZ=100 kernel in 2100 rescheduling opportunities, the watchdog
thread was never selected to run?

christos



Re: CVS commit: src/common/lib/libprop

2020-06-11 Thread Christos Zoulas
As Joerg mentioned, he believes that the error behavior is the way to go.
I think that it is not useful behavior to error out on these warnings. If
we wanted this behavior, we would not use linker warnings, we'd outright
remove the deprecated symbols.

christos

> On Jun 11, 2020, at 6:58 PM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 12.06.2020 00:55, Christos Zoulas wrote:
>> In article <20200611222544.6d3a6f...@cvs.netbsd.org>,
>> Joerg Sonnenberger  wrote:
>>> -=-=-=-=-=-
>>> 
>>> Module Name:src
>>> Committed By:   joerg
>>> Date:   Thu Jun 11 22:25:44 UTC 2020
>>> 
>>> Modified Files:
>>> src/common/lib/libprop: prop_object_impl.h
>>> 
>>> Log Message:
>>> Unbreak clang builds by removing questionable linker warning sections
>>> trggered all over the place.
>> 
>> Why don't you do this just for clang, so that we can use gcc to track the
>> remaining ones down and finish the job? Now we can't easily find them.
>> 
>> christos
>> 
> 
> Can we please revert this and fix clang?
> 
> I'm strongly for linker warnings as they catch real issues.
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/common/lib/libprop

2020-06-11 Thread Christos Zoulas
In article <20200611222544.6d3a6f...@cvs.netbsd.org>,
Joerg Sonnenberger  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  joerg
>Date:  Thu Jun 11 22:25:44 UTC 2020
>
>Modified Files:
>   src/common/lib/libprop: prop_object_impl.h
>
>Log Message:
>Unbreak clang builds by removing questionable linker warning sections
>trggered all over the place.

Why don't you do this just for clang, so that we can use gcc to track the
remaining ones down and finish the job? Now we can't easily find them.

christos



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

2020-06-06 Thread Christos Zoulas
In article <20200606135850.ge14...@pony.stderr.spb.ru>,
Valery Ushakov   wrote:
>On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
>
>> On 06.06.2020 09:42, Simon Burge wrote:
>> > "Kamil Rytarowski" wrote:
>> > 
>> >> Module Name:  src
>> >> Committed By: kamil
>> >> Date: Fri Jun  5 21:48:04 UTC 2020
>> >>
>> >> Modified Files:
>> >>
>> >>   src/sys/arch/x86/x86: cpu_rng.c
>> >>
>> >> Log Message:
>> >>
>> >> Change const unsigned to preprocessor define
>> >>
>> >> Fixes GCC -O0 build with the stack protector.
>> > 
>> > Surely a gcc bug?  This almost certainly needs an
>> > /* XXX gcc stack protector -O0 bug */ comment and
>> > possibly an entry in doc/HACKS as well otherwise
>> > someone will come along later and de-uglify this
>> > change.
>> 
>> This is not really a GCC bug, as C const is not constexpr.  It's
>> also not the only place with such logic and such workaround.  C++
>> fixed it and have real const.
>
>Doesn't -Wvla help catching these?  Should we enable it?

I think it might catch too much... But we can try it...

christos




Re: CVS commit: src

2020-06-05 Thread Christos Zoulas
In article ,
Kamil Rytarowski   wrote:
>On 09.05.2017 13:14, Robert Elz wrote:
>> Module Name: src
>> Committed By:kre
>> Date:Tue May  9 11:14:16 UTC 2017
>>
>> Modified Files:
>>  src/distrib/sets/lists/base: shl.mi
>>  src/distrib/sets/lists/comp: mi
>>  src/distrib/sets/lists/debug: shl.mi
>>  src/include: signal.h
>>  src/lib/libc: shlib_version
>>  src/lib/libc/gen: Makefile.inc
>> Added Files:
>>  src/lib/libc/gen: signalname.3 signalname.c signalnext.c signalnumber.c
>>
>> Log Message:
>> Add the new signalname/signalnext/signalnumber interface to libc.
>>
>> This as discussed on current-users in the thread
>> entitled:
>>   Proposal: new libc/libutil functions to map SIG <-> ""
>> that can be found (starting at):
>>   http://mail-index.netbsd.org/current-users/2017/04/28/msg031600.html
>>
>> These functions provide the mechanism to enable applications
>> to divorce themselves from internal details of the signal
>> implementation.
>>
>> Libc minor bumped, prototypes in , sets lists updated (and sorted).
>>
>> One and all: feel free to improve the sources & man page (etc), but
>> please do not change the function signatures without discussion.
>>
>
>I have got a strange behavior of kill(1):
>
>$ kill -l
>HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG
>STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1
>USR2 PWR ERR
>
>$ ktruss -i -o /tmp/1.x kill -l
>HUP INT QUITILL TRAPABRTEMT FPE KILL
>BUS SEGVSYS PIPEALRMTERMURG STOPTSTP
>CONTCHLDTTINTTOUIO  XCPUXFSZVTALRM  PROF
>WINCH   INFOUSR1USR2PWR RT0 RT1 RT2 RT3
>RT4 RT5 RT6 RT7 RT8 RT9 RT10RT11RT12
>RT13RT14RT15RT16RT17RT18RT19RT20RT21
>RT22RT23RT24RT25RT26RT27RT28RT29RT30
>
>(gdb) r
>Starting program: /bin/kill -l
>HUP INT QUITILL TRAPABRTEMT FPE KILL
>BUS SEGVSYS PIPEALRMTERMURG STOPTSTP
>CONTCHLDTTINTTOUIO  XCPUXFSZVTALRM  PROF
>WINCH   INFOUSR1USR2PWR RT0 RT1 RT2 RT3
>RT4 RT5 RT6 RT7 RT8 RT9 RT10RT11RT12
>RT13RT14RT15RT16RT17RT18RT19RT20RT21
>RT22RT23RT24RT25RT26RT27RT28RT29RT30
>[Inferior 1 (process 6257) exited normally]
>(gdb)
>
>What happened to RT signal names?
>
>I'm not sure what's wrong as this code works under a debugger.
>
>Sanitizers don't catch anything (at least when sanitizing kill.c).

Builtin kill vs program?

christos



Re: CVS commit: src/lib/libedit (strncpy->strlcpy)

2020-06-01 Thread Christos Zoulas

> This feels not good.
> strncpy->strlcpy has repercussions like how strlcpy doesn't zero out the
> remaining length and thus leaks uninitialized data.
> 
> There has to be a reasonable way to handle these warnings instead of
> rototilling which str*cpy function is used.

Please read the code before commenting. Yes, I know that they are not
equivalent, but in this case the destination strings are all local variables
on the stack used internally only in the functions declared, to be compared
or printed with other NUL-terminated strings. It is pointless to zero out
the rest of the data.

christos


signature.asc
Description: Message signed with OpenPGP


Re: [acl] CVS commit: src

2020-05-20 Thread Christos Zoulas
Fixed, thanks!

christos

> On May 20, 2020, at 2:19 AM, Maxime Villard  wrote:
> 
>> Module Name:src
>> Committed By:   christos
>> Date:   Sat May 16 18:31:54 UTC 2020
>> 
>> Modified Files:
>> [...]
>> 
>> Log Message:
>> Add ACL support for FFS. From FreeBSD.
> 
> This broke compilation on LLVM.
> 
>   https://syzkaller.appspot.com/text?tag=CrashReport=153178f610
> 
> Please fix
> 
> 
> --
> This message has been 'sanitized'.  This means that potentially
> dangerous content has been rewritten or removed.  The following
> log describes which actions were taken.
> 
> Sanitizer (start="1589955582"):
> Split unusually long word(s) in header.
> SanitizeFile (filename="unnamed.txt", mimetype="text/plain"):
>   Match (names="unnamed.txt", rule="9"):
> Enforced policy: accept
> 
> Total modifications so far: 1
> 
> 
> Anomy 0.0.0 : Sanitizer.pm
> $Id: Sanitizer.pm,v 1.94 2006/01/02 16:43:10 bre Exp $



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/tests/rump/modautoload

2020-05-16 Thread Christos Zoulas
That is a completely different issue here. There are no linker tricks.
We want the module loader to include all the symbols any module
can require, this is why we load all the libraries.

While it is questionable if nofifofs is part of the base system or not,
this is the way it was before. Anyway it is easy enough to have it
both ways. If we ever grow a test that needs the real fifo stuff in
an autoloaded module, we can deal with that then.

christos

> On May 16, 2020, at 9:46 AM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 16.05.2020 14:54, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat May 16 12:54:27 UTC 2020
>> 
>> Modified Files:
>>  src/tests/rump/modautoload: Makefile
>> 
>> Log Message:
>> Do the same thing with linker flags instead of directly specifying the 
>> archives.
>> 
>> 
> 
> Is there chance to rename the fifo symbols instead of using linker tricks?
> 
> I'm also not entirely sure that this will be compatible with sanitizers
> (and C++ with the ODR rule) at this point.
> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.10 -r1.11 src/tests/rump/modautoload/Makefile
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
>> 
>> Modified files:
>> 
>> Index: src/tests/rump/modautoload/Makefile
>> diff -u src/tests/rump/modautoload/Makefile:1.10 
>> src/tests/rump/modautoload/Makefile:1.11
>> --- src/tests/rump/modautoload/Makefile:1.10 Sat May 16 08:44:42 2020
>> +++ src/tests/rump/modautoload/Makefile  Sat May 16 08:54:27 2020
>> @@ -1,4 +1,4 @@
>> -#   $NetBSD: Makefile,v 1.10 2020/05/16 12:44:42 christos Exp $
>> +#   $NetBSD: Makefile,v 1.11 2020/05/16 12:54:27 christos Exp $
>> #
>> 
>> .include 
>> @@ -15,11 +15,9 @@ SRCS.t_modautoload+=  t_modautoload.c
>> # subdirectory -- otherwise the LDADD lines would get a little hairy.
>> LDFLAGS+=-Wl,-E
>> LDADD+= \
>> --Wl,--whole-archive \
>> -${DESTDIR}/usr/lib/librumpvfs_nofifofs.a \
>> -${DESTDIR}/usr/lib/librumpvfs.a \
>> -${DESTDIR}/usr/lib/librump.a \
>> --Wl,--no-whole-archive
>> +-Wl,--whole-archive -Wl,-Bstatic \
>> +-lrumpvfs_nofifofs -lrumpvfs -lrump \
>> +-Wl,-Bdynamic -Wl,--no-whole-archive
>> 
>> LDADD+=  -lrumpuser -lpthread
>> DPADD+=  ${LIBRUMPVFS} ${LIBRUMP} ${LIBRUMPUSER}
>> 
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/mpl/dhcp/dist/common

2020-05-15 Thread Christos Zoulas
In article <20200515123104.297c5f...@cvs.netbsd.org>,
Emmanuel Dreyfus  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  manu
>Date:  Fri May 15 12:31:04 UTC 2020
>
>Modified Files:
>   src/external/mpl/dhcp/dist/common: bpf.c discover.c lpf.c packet.c
>   raw.c socket.c
>
>Log Message:
>crunchgen fix
>
>Make sure local_port is not shared within a crunchgen binary. There is
>more to do to get full functionnality in crunchgen, but at least this
>change makes dhcpd listen on the right port again.

Can't this be done with -Dlocal_port= in the Makefile?

christos



Re: CVS commit: src/external/bsd/dhcpcd/dist/src

2020-05-14 Thread Christos Zoulas
In article <95034282-ebf6-c1d5-8bb1-9258ee825...@marples.name>,
Roy Marples   wrote:
>On 10/05/2020 18:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun May 10 17:58:16 UTC 2020
>> 
>> Modified Files:
>>  src/external/bsd/dhcpcd/dist/src: dhcpcd.c
>> 
>> Log Message:
>> Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it.
>
>Why?

Because the forked programs from scripts were executed with SIGPIPE blocked.
If that breaks non-kqueue OS's we should just add SIGPIPE to the signal
mask to default for posix_spawn().

christos



Re: CVS commit: src/sys

2020-05-10 Thread Christos Zoulas
In article <20200508220155.446eef...@cvs.netbsd.org>,
Andrew Doran  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  ad
>Date:  Fri May  8 22:01:55 UTC 2020
>
>Modified Files:
>   src/sys/arch/x86/include: cpu_counter.h
>   src/sys/arch/x86/x86: cpu.c tsc.c
>   src/sys/dev/ic: hpet.c hpetvar.h
>
>Log Message:
>Fix the TSC timecounter (on the systems I have access to):
>
>- Make the early i8254-based calculation of frequency a bit more accurate.
>
>- Keep track of how far the HPET & TSC advance between HPET attach and
>  secondary CPU boot, and use to compute an accurate value before attaching
>  the timecounter.  Initial idea from joerg@.
>
>- When determining skew and drift between CPUs, make each measurement 1000
>  times and pick the lowest observed value.  Increase the error threshold to
>  1000 clock cycles.
>
>- Use the frequency computed on the boot CPU for secondary CPUs too.
>
>- Remove cpu_counter_serializing().

The TSC is still faster than it is supposed to be so ntpd does not sync
(it diverges). It is better than before but not good enough to keep time.

christos



Re: CVS commit: src

2020-05-06 Thread Christos Zoulas
In article <20200506161737.59410f...@cvs.netbsd.org>,
Nia Alarie  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  nia
>Date:  Wed May  6 16:17:37 UTC 2020
>
>Modified Files:
>   src/distrib/sets/lists/comp: mi
>   src/include: unistd.h
>   src/lib/libc/gen: Makefile.inc
>   src/lib/libc/include: namespace.h
>Added Files:
>   src/lib/libc/gen: getentropy.3 getentropy.c
>
>Log Message:
>Add getentropy() to libc - a simple wrapper to access the kernel CSPRNG.
>
>Posted to tech-userlevel@ a week ago and reviewed by riastradh@.

Nia, I think you've jumped the gun here. The discussion was still going
and it is not clear that getentropy() should be added right now.

Best,

christos



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

2020-05-03 Thread Christos Zoulas
In article <28236.1588524...@splode.eterna.com.au>,
matthew green   wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sun May  3 16:32:16 UTC 2020
>> 
>> Modified Files:
>>  src/usr.bin/rlogin: rlogin.c
>> 
>> Log Message:
>> PR/54435: Adjust for new kernel behavior of soreceive(9) clearing MSG_OOB
>> when receiving the oob message. This made SIOCATMARK return always 0 since
>> the oob message was cleared. Instead, use recvmsg(2) to determine if
>> the message was oob or not. This works with both the old and new kernel
>> and it is not racy.
>
>but old binaries still no longer work?

Old binaries no longer work.

>that seems like a binary compatiblility issue to me and you
>should change the kernel to make them work again, not change
>userland to match some new kernel thing, particularly where
>the change itself was debated considerably and not espcially
>necessary for existing OOB using code and no new code should
>be added...

The best way to fix this is to undo the kernel change so that it
behaves the old way. But that makes poll(2) behave incorrectly as
mentioned in the PR. All other uses of SIOCATMARK in the tree
including the example in PSD, use SIOCATMARK before reading to
determine if an OOB packet has arrived.

christos



Re: CVS commit: src/external/gpl3/gdb/lib/libgdb

2020-04-29 Thread Christos Zoulas
In article <20200429110459.0d9bcf...@cvs.netbsd.org>,
Rin Okuyama  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rin
>Date:  Wed Apr 29 11:04:58 UTC 2020
>
>Modified Files:
>   src/external/gpl3/gdb/lib/libgdb: Makefile
>
>Log Message:
>PR toolchain/54820
>PR toolchain/54877
>
>GCC 8.4 miscompiles dwarf2expr.c with -O2 or -O1 for earmv7hf{,eb}, which
>results in crashes described in the PRs. No upstream fixes up to now. So,
>let us disable optimization for this file.
>
>Note that this affects only earmv7hf{,eb} as far as I can see. Crashes do
>not occur neither for earmv6hf{,eb} nor earmv7{,eb}.

Nice catch!

christos



Re: CVS commit: src/tools/binutils

2020-04-03 Thread Christos Zoulas
Yes, I've renamed it to libgnuctf.

christos

> On Apr 3, 2020, at 9:01 PM, Kamil Rytarowski  wrote:
> 
> On 04.04.2020 02:47, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Apr  4 00:47:52 UTC 2020
>> 
>> Modified Files:
>>  src/tools/binutils: mknative-binutils
>> 
>> Log Message:
>> Handle libctf new in binutils 2.34
>> 
>> 
> 
> 
> Please note that the upstreamed libctf version was not (at least when I
> last looked into it) compatible with what we get for CTF from other
> distfiles.



signature.asc
Description: Message signed with OpenPGP


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

2020-04-02 Thread Christos Zoulas
Ah debugging remnants. I'll remove it. Can you look at PR/55128?

static inline union savefpu *
fpu_lwp_area(struct lwp *l)
{
struct pcb *pcb = lwp_getpcb(l);
union savefpu *area = >pcb_savefpu;

KASSERT((l->l_flag & LW_SYSTEM) == 0);
if (l == curlwp) {
fpu_save();
}
KASSERT(!(l->l_md.md_flags & MDL_FPU_IN_CPU)); <- this will fire if the 
debugger calls it with l != curlew and it uses cpu

return area;
}


> On Apr 2, 2020, at 5:31 PM, Kamil Rytarowski  wrote:
> 
> On 02.04.2020 19:40, Christos Zoulas wrote:
>> +set -x
>> +AWK=gawk
>> +
> 
> gawk?



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/modules/examples/fopsmapper

2020-04-01 Thread Christos Zoulas
I think that PAGESIZE is not always a constant in our code.

christos




signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/modules/examples/fopsmapper

2020-04-01 Thread Christos Zoulas

> If PAGE_SIZE is ostensibly a vsize_t / size_t, why not define it as (1U << 
> PAGE_SHIFT)?

It will *probably* work unless we have 'if (negative_int > PAGESIZE)'
somewhere. I guess if you make the change and the kernel boots... :-)

christos


signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/modules/examples/fopsmapper

2020-04-01 Thread Christos Zoulas
In article ,
Paul Goyette   wrote:
>On Wed, 1 Apr 2020, Kamil Rytarowski wrote:
>
>> On 01.04.2020 15:47, Robert Elz wrote:
>>> Date:Wed, 1 Apr 2020 11:45:53 +
>>> From:"Kamil Rytarowski" 
>>> Message-ID:  <20200401114554.05167f...@cvs.netbsd.org>
>>>
>>>   | Log Message:
>>>   | Avoid comparison between signed and unsigned integer
>>>   |
>>>   | Cast PAGE_SIZE to size_t.
>>>
>>> This kind of pedantry is going way too far, PAGE_SIZE is a compile
>>> time constant (1 << PAGE_SHIFT) which is an int (and so signed,
>>> nominally) but one which is known to be positive.
>>>
>>
>> I got reports that certain ports no longer build due to:
>>
>> src/sys/modules/examples/fopsmapper/fopsmapper.c:118:11: error:
>> comparison between signed and unsigned integer expressions
>> [-Werror=sign-compare]
>>  if (size != PAGE_SIZE)
>>   ^~
>> cc1: all warnings being treated as errors
>
>
>There's a lot of modules that fail for this with WARNS=5 when being
>built as loadable modules.
>
>That's why so many of the individual module Makefiles have explicit
>WARNS=4.  (It seems that when modules are built-in as part of the
>kernel, they are by default built with WARNS=4.)

Which we have been slowly fixing. I think in this case the sign-compare
warnings are annoying, but putting casts on each warning is cluttering
the code needlessly. Unfortunately the alternative (to make the PAGESIZE
constant unsigned is more dangerous -- unless of course you are willing to 
examine all the places it is used and make sure that the semantics don't
change). Another way would be to make:

#define PAGESIZE_U ((unsigned)PAGESIZE)

and use that instead; eventually when all instances of PAGESIZE have been
converted to PAGESIZE_U it can be removed. But is it worth it? There are
perhaps better things to do. But anyway you want to proceed should be
discussed in tech-kern. Adding piecemeal casts everywhere does not make
the world a better place.

christos



Re: CVS commit: src/external/cddl/osnet/lib/libdtrace

2020-03-16 Thread Christos Zoulas
In article <20200317005012.daf4af...@cvs.netbsd.org>,
Santhosh Raju  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  fox
>Date:  Tue Mar 17 00:50:12 UTC 2020
>
>Modified Files:
>   src/external/cddl/osnet/lib/libdtrace: Makefile
>
>Log Message:
>external/cddl/osnet: Supress -Werror=maybe-uninitialized error in libdtrace.
>
>It looks like this is a false positive, since the section of code
>triggering the error
>
>external/cddl/osnet/dist/lib/libdtrace/common/dt_proc.c:400:42:
>
>is only accessed after "err" is initialized.
>
>Error was reported when build.sh was run with MKLIBCSANITIZER=yes flag.

You did not just suppress the error; you suppressed the warning too...
There is a difference between -Wno-error=maybe-uninitialized and
-Wno-maybe-uninitialized. I think we want the first flavor, otherwise
this is a large axe that will hide other warnings in the long run.

Now perhaps it is better to do what we've been doing traditionallly:
over-initialize the variable with 'foo = 0; // XXX: gcc', but that's
more book-keeping (but at least it is localized as opposed to suppress
for the entire compilation unit). Please note that we don't have a good
way to go around and test those error-avoidance overrides each time we
upgrade the compiler so they tend to stick forever.

christos1



Re: CVS commit: src/external/gpl3/gdb/dist/bfd

2020-03-14 Thread Christos Zoulas
Yup, undo it.

christos

> On Mar 14, 2020, at 2:35 PM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 26.02.2016 17:28, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Fri Feb 26 16:28:14 UTC 2016
>> 
>> Modified Files:
>>  src/external/gpl3/gdb/dist/bfd: merge.c
>> 
>> Log Message:
>> CID 420802: Avoid NULL deref.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1.1.4 -r1.2 src/external/gpl3/gdb/dist/bfd/merge.c
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
>> 
>> Modified files:
>> 
>> Index: src/external/gpl3/gdb/dist/bfd/merge.c
>> diff -u src/external/gpl3/gdb/dist/bfd/merge.c:1.1.1.4 
>> src/external/gpl3/gdb/dist/bfd/merge.c:1.2
>> --- src/external/gpl3/gdb/dist/bfd/merge.c:1.1.1.4   Tue Feb  2 22:00:11 2016
>> +++ src/external/gpl3/gdb/dist/bfd/merge.c   Fri Feb 26 11:28:14 2016
>> @@ -334,7 +334,7 @@ sec_merge_emit (bfd *abfd, struct sec_me
>> 
>>   /* Trailing alignment needed?  */
>>   off = sec->size - off;
>> -  if (off != 0)
>> +  if (pad != NULL && off != 0)
>> {
>>   if (contents)
>>  memcpy (contents + offset, pad, off);
>> 
> 
> It looks to me like a false positive.
> 
> pad is checked just after bfd_zmalloc():
> 
>  pad = (char *) bfd_zmalloc (pad_len);
>  if (pad == NULL)
>return FALSE;
> 
> If I am not overlooking something, I will drop this local patch as not
> upstreamable.
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
In article <20200314143238.gr5...@pony.stderr.spb.ru>,
Valery Ushakov   wrote:

>How is is affected by the decision to change (or not) 0x%x to %#x?
>

This was in response to the statement:

... with a bit of patience might have been less drastic and as effective.

christos



Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas

> I don't belive that "if".  It's like claiming you got rid of a stain
> on a wallpaper after you demolish a wall (not load-bearing,
> fortunately) and have to put it back and put new wallpaper. :) Get rid
> of the stain, sure; but may be looking closely with a bit of patience
> might have been less drastic and as effective.

To fix the kernhist ones I looked with a lot of patience and even then,
I missed quite a few ones (the ones in the final commit). It is really
difficult to find them, specially because the DPRINTF macros are
used sometimes for regular debugging and other times for kernhist.
In the end I had to add a fake printf function in kernhist.h like below,
and then filter out the error messages about too many arguments for
format.

christos

--- kernhist.h  2020-03-13 23:03:13.973939910 -0400
+++ kernhist.h.orig 2020-03-13 22:59:37.237495925 -0400
@@ -207,6 +207,11 @@
 #define KERNHIST_PRINTNOW(E) /* nothing */
 #endif

+// Just for format checking
+static __inline __printflike(1, 2) void
+__kernhist_printf(const char *fmt __unused, ...) {
+}
+
 #define KERNHIST_LOG(NAME,FMT,A,B,C,D) \
 do { \
unsigned int _i_, _j_; \
@@ -227,6 +232,7 @@
_e_->v[1] = (uintmax_t)(B); \
_e_->v[2] = (uintmax_t)(C); \
_e_->v[3] = (uintmax_t)(D); \
+   __kernhist_printf(FMT, _e_->v[0], _e_->v[1], _e_->v[2], _e_->v[3]); \
KERNHIST_PRINTNOW(_e_); \
 } while (/*CONSTCOND*/ 0)



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas

> Even for the ones without the widths specified.  E.g. I personally
> prefer zero printed as 0x0, not as 0, so I assume that when people
> choose either one that reflects their preference.  Why mess with it?
> It's all so unnecessary.

Yes, now we are discussing cosmetics (if 0 should be printed as
0 or 0x0 mostly in debugging messages), since this is the only change
remaining. In retrospect, perhaps I should have left it alone, but now aside
the cosmetics part, we are strictly better off because all the formats have
been fixed (including the 2 ones which we would not have found if I did not
make the %# change).

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Christos Zoulas


> On Mar 13, 2020, at 10:25 PM, Valery Ushakov  wrote:
> 
> As I wrote in a follow up email, it changes formatting b/c you didn't
> change field widths and IMO using %# with a field width is mostly
> trouble to begin with.  It's not the first time someone tries to do
> this without actually understanding the consequences of the change.
> Please, can we assume that when people write either 0x%x or %#x they
> most likely actaully mean it for whatever reason and that they want
> that specific output format, and it's just rude to change that,
> especially when you do so incorrectly.

I am reverting the fixed width ones, hold on.

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Christos Zoulas

> This was not a part of the PR and is completely cosmetic (surely it
> supports plain %x if it does support %#x).  Why was this necessary?
> (I know I would be quite miffed if someone made a change like that to
> my code).

Yes, that %x formatting change was not part of the PR, but I only changed 0x%x 
not plain %x.
I did it because as I was fixing the 0x%x in the log, I started changing them 
to %#jx so I did it
globally in that directory for consistency. It found two formats that were 
0x%hu...
 So one can view it as a format consistency checker(not just cosmetic).

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Christos Zoulas

> On Mar 13, 2020, at 12:25 PM, Jason Thorpe  wrote:
> 
> 
>> On Mar 13, 2020, at 9:11 AM, Christos Zoulas  wrote:
>> 
>> I think this is better done in the driver, as other ports
>> do the same check and it catches bugs.
> 
> x86 *explcitly* checks for 0 to skip work.  If you want to find bugs, change 
> the most-often-used implementation maybe?
> 
> -- thorpej

I remembered wrong then.

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Christos Zoulas
In article <20200313034939.553d5f...@cvs.netbsd.org>,
Jason R Thorpe  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  thorpej
>Date:  Fri Mar 13 03:49:39 UTC 2020
>
>Modified Files:
>   src/sys/arch/mips/mips: bus_dma.c
>
>Log Message:
>Allow len == 0 in bus_dmamap_sync().

I think this is better done in the driver, as other ports
do the same check and it catches bugs.

christos



Re: CVS commit: src/lib/libcurses

2020-03-13 Thread Christos Zoulas
Thanks for explaining!

christos




signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/lib/libcurses

2020-03-13 Thread Christos Zoulas
In article <20200312155012.1ce50f...@cvs.netbsd.org>,
Roy Marples  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  roy
>Date:  Thu Mar 12 15:50:12 UTC 2020
>
>Modified Files:
>   src/lib/libcurses: initscr.c
>
>Log Message:
>curses: use perror rather than err in initscr
>
>Index: src/lib/libcurses/initscr.c
>diff -u src/lib/libcurses/initscr.c:1.34 src/lib/libcurses/initscr.c:1.35
>--- src/lib/libcurses/initscr.c:1.34   Wed Mar 11 21:33:38 2020
>+++ src/lib/libcurses/initscr.cThu Mar 12 15:50:11 2020
>@@ -1,4 +1,4 @@
>-/*$NetBSD: initscr.c,v 1.34 2020/03/11 21:33:38 roy Exp $ */
>+/*$NetBSD: initscr.c,v 1.35 2020/03/12 15:50:11 roy Exp $ */
> 
> /*
>  * Copyright (c) 1981, 1993, 1994
>@@ -34,11 +34,10 @@
> #if 0
> static char sccsid[] = "@(#)initscr.c 8.2 (Berkeley) 5/4/94";
> #else
>-__RCSID("$NetBSD: initscr.c,v 1.34 2020/03/11 21:33:38 roy Exp $");
>+__RCSID("$NetBSD: initscr.c,v 1.35 2020/03/12 15:50:11 roy Exp $");
> #endif
> #endif/* not lint */
> 
>-#include 
> #include 
> 
> #include "curses.h"
>@@ -66,8 +65,15 @@ initscr(void)
>   sp = Def_term;
> 
>   /* LINTED const castaway; newterm does not modify sp! */
>-  if ((_cursesi_screen = newterm((char *) sp, stdout, stdin)) == NULL)
>-  errx(EXIT_FAILURE, "initscr"); /* POSIX says exit on failure */
>+  if ((_cursesi_screen = newterm((char *) sp, stdout, stdin)) == NULL) {
>+  /*
>+   * POSIX says we should write a diagnostic and exit on error.
>+   * As such some applications don't bother checking the return
>+   * value at all.
>+   */
>+  perror("initscr");
>+  exit(EXIT_FAILURE);
>+  }
> 
>   set_term(_cursesi_screen);
>   wrefresh(curscr);
>

Sorry I don't understand this change? How is that different than using

err(EXIT_FAILURE, "initscr");

christos



Re: CVS commit: src/external/bsd/blacklist

2020-03-12 Thread Christos Zoulas

> 
> I'll revert this for the time being.

Thanks, I am working on fixing the routing socket to have a perms check.

christos


signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/bsd/blacklist/bin

2020-03-12 Thread Christos Zoulas

> If we just re-add the rule, we should either get an error that it already 
> exists which we should gracefully handle or it just overwrites the existing 
> rule.
> I don't see the point in deleting something which by your logic is already 
> deleted.

Yes, we could re-add unconditionally. Is that what the code does now?

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/bsd/blacklist/bin

2020-03-11 Thread Christos Zoulas
In article <20200311023318.c6a7ff...@cvs.netbsd.org>,
Roy Marples  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  roy
>Date:  Wed Mar 11 02:33:18 UTC 2020
>
>Modified Files:
>   src/external/bsd/blacklist/bin: blacklistd.c
>
>Log Message:
>blacklist: Don't remove a ruleset if we have already added it
>
>The noted argument is wrong - if it's already been deleted then the id we
>have for it is invalid.
>Because we don't track deletions to the ruleset, working it out is
>problematic at best.
>
>Instead, if we have already added the rule treat it as a non-op.
>
>This is a valid use case because we might receive a burst of messages
>in the downstream application for the same address and process them
>one by one. It's not the job of the downstream application to track
>blacklistd state.

The comment was correct. You need to consider the case where someone
manually deleted the rule directly from the packet filter. The
database will think it is there, but now you'll never add it again.

christos



Re: CVS commit: src/external/bsd/blacklist

2020-03-11 Thread Christos Zoulas
In article <20200311021208.bfb5cf...@cvs.netbsd.org>,
Roy Marples  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  roy
>Date:  Wed Mar 11 02:12:08 UTC 2020
>
>Modified Files:
>   src/external/bsd/blacklist/bin: blacklistd.c conf.c
>   src/external/bsd/blacklist/lib: bl.c
>
>Log Message:
>blacklist: Allow blacklist_sa to work with an invalid fd
>
>fd -1 is invalid, so don't query it for protocol, port or address.
>
>fd is supposed to represent how the client is connected, but if we are
>parsing route(4) messages or log files then there is no client connection
>to interogate.

Yes, but this (with the cmsg passed in the fd) is how we do access
control. If you can't figure out if the remote owns the socket,
then anyone can DoS the system by writing messages to the daemon?

christos



Re: CVS commit: src/sys/dev/hid

2020-03-08 Thread Christos Zoulas
In article <20200308140933.1b842f...@cvs.netbsd.org>,
SAITOH Masanobu  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  msaitoh
>Date:  Sun Mar  8 14:09:33 UTC 2020
>
>Modified Files:
>   src/sys/dev/hid: hid.h
>
>Log Message:
>Use unsigned to avoid undefined behavior. Found by kUBSan.

I think it is better to add U to all the HUP_ constants for consistency.
It looks funny this way.

christos



Re: CVS commit: src/tests/lib/libc/sys

2020-03-07 Thread Christos Zoulas
In article <5e528f7a-147a-23e7-46da-6b02d76e5...@gmx.com>,
Kamil Rytarowski   wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 07.03.2020 15:53, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Mar  7 14:53:14 UTC 2020
>> 
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h
>> 
>> Log Message:
>> Try to fix the build. This is why all those inlines should really be in a
>> separate file as regular function. The code is too large and hard to manage
>> this way, and only increases in complexity as time goes by.
>> 
>> 
>
>What build configuration was broken?

All of the evbarm ones since t_ptrace_sigchld.c was not including ieefp.h
http://releng.netbsd.org/builds/HEAD/202003070040Z/evbarm-earmhfeb.build.failed

christos



Re: CVS commit: src/sys/dev

2020-03-03 Thread Christos Zoulas
Yes, I thought about providing an ioctl to do this, but it would mean that 
everything
that talks to those devices would need to be modified to issue the ioctl. Raw 
mode
means to call the underlying uhidev write which is the raw usb writes instead of
using the report mechanism. My devices did not work using the report mechanism.
Linux provides a /dev/uhidrawN node.

christos

> On Mar 2, 2020, at 11:26 PM, matthew green  wrote:
> 
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Mon Mar  2 18:15:29 UTC 2020
>> 
>> Modified Files:
>>  src/sys/dev/hid: hid.h
>>  src/sys/dev/usb: uhid.c
>> 
>> Log Message:
>> Add fido constants, and turn hid "raw" mode for fido devices.
> 
> this is gross.
> 
> please don't put device specific stuff into uhid like this.
> 
> without really understanding, it seems that there should be
> a uhid ioctl to enable this mode, and then your userland code
> sets it, instead of this hack.
> 
> also, please actually explain what this "raw" mode means.  is
> there perhaps a way to avoid this entirely?  what's the real
> underlying need here..?
> 
> 
> .mrg.



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/tests/lib/libc/gen

2020-02-24 Thread Christos Zoulas
In article <20200221222550.325a6f...@cvs.netbsd.org>,
Kamil Rytarowski  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kamil
>Date:  Fri Feb 21 22:25:50 UTC 2020
>
>Modified Files:
>   src/tests/lib/libc/gen: t_siginfo.c
>
>Log Message:
>Mark division by 0 as expected in sigfpe_int
>
>Disable ubsan instrumentation on the operation.

>+#if defined(__clang__)
>+__attribute__((no_sanitize("undefined")))
>+#else   
>+__attribute__((no_sanitize_undefined))
>+#endif
>+static long int
>+sigfpe_int_division(long int a, long int b)
>+{
>+
>+  return a / b;
>+}

Have you tested this? I recall I needed to make it a separate function...

christos



Re: CVS commit: src/tests/lib/libc/gen

2020-02-24 Thread Christos Zoulas
In article <20200222191457.87687f...@cvs.netbsd.org>,
Kamil Rytarowski  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kamil
>Date:  Sat Feb 22 19:14:57 UTC 2020
>
>Modified Files:
>   src/tests/lib/libc/gen: Makefile
>
>Log Message:
>Update t_siginfo.c build rules
>
>Add logic for MKSANITIZER/MKLIBCSANITIZER checks.
>
>
>To generate a diff of this commit:
>cvs rdiff -u -r1.53 -r1.54 src/tests/lib/libc/gen/Makefile
>
>Please note that diffs are not public domain; they are subject to the
>copyright notices on the relevant files.
>
>
>-=-=-=-=-=-
>
>Modified files:
>
>Index: src/tests/lib/libc/gen/Makefile
>diff -u src/tests/lib/libc/gen/Makefile:1.53
>src/tests/lib/libc/gen/Makefile:1.54
>--- src/tests/lib/libc/gen/Makefile:1.53   Fri Apr 26 19:17:05 2019
>+++ src/tests/lib/libc/gen/MakefileSat Feb 22 19:14:57 2020
>@@ -1,4 +1,4 @@
>-# $NetBSD: Makefile,v 1.53 2019/04/26 19:17:05 maya Exp $
>+# $NetBSD: Makefile,v 1.54 2020/02/22 19:14:57 kamil Exp $
> 
> .include 
> 
>@@ -39,6 +39,10 @@ TESTS_C+=   t_time
> TESTS_C+= t_ttyname
> TESTS_C+= t_vis
> 
>+.if ${MKSANITIZER:Uno} != "yes" && ${MKLIBCSANITIZER:Uno} != "yes"
>+COPTS.t_siginfo.c+=   -DENABLE_TESTS
>+.endif
>+
> CPPFLAGS.t_siginfo.c+=-D__TEST_FENV
> COPTS.t_fpsetround.c+=${${ACTIVE_CC} == "gcc":? -frounding-math :}

This should be backwards. -DDISABLE_TESTS for the sanitizers and nothing
in the regular build case. Isn't there a cpp macro for the sanitizers?

christos



Re: CVS commit: src/doc

2020-02-20 Thread Christos Zoulas
Yup, I have those in /etc/mk.conf.

HAVE_LLVM=yes
MKLLVM=yes
MKGCC=no

$ fgrep netbsd-clang /usr/src/make.sparc64-sparc64.release.out | head -4
--- sparc64--netbsd-clang ---
#  link  llvm-clang/sparc64--netbsd-clang
c++ -g -O2 -fno-rtti -fno-exceptions -fno-strict-aliasing 
-I/usr/obj/sparc64-sparc64/tools/include/compat 
-I/p/netbsd/cvsroot/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 
-D_FILE_OFFSET_BITS=64 -I. 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/clang/include
 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/llvm/include
 -I/p/netbsd/cvsroot/src/tools/llvm-include/obj.sparc64-sparc64 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/include 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/tools/clang/include
 -std=c++14 -I. 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/clang/include
 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/llvm/include
 -I/p/netbsd/cvsroot/src/tools/llvm-include/obj.sparc64-sparc64 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/include 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/tools/clang/include
   -o sparc64--netbsd-clang driver.lo cc1_main.lo cc1as_main.lo 
cc1gen_reproducer_main.lo -L/usr/obj/sparc64-sparc64/tools/lib -lnbcompat -lrt 
-lz 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontendTool/obj.sparc64-sparc64 
-lclangFrontendTool 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontend/obj.sparc64-sparc64 
-lclangFrontend 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangARCMigrate/obj.sparc64-sparc64 
-lclangARCMigrate 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangStaticAnalyzerFrontend/obj.sparc64-sparc64
 -lclangStaticAnalyzerFrontend 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangStaticAnalyzerCheckers/obj.sparc64-sparc64
 -lclangStaticAnalyzerCheckers 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangStaticAnalyzerCore/obj.sparc64-sparc64
 -lclangStaticAnalyzerCore 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangCrossTU/obj.sparc64-sparc64 
-lclangCrossTU 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangIndex/obj.sparc64-sparc64 
-lclangIndex 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangASTMatchers/obj.sparc64-sparc64 
-lclangASTMatchers 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangCodeGen/obj.sparc64-sparc64 
-lclangCodeGen 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontendRewrite/obj.sparc64-sparc64
 -lclangFrontendRewrite 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontend/obj.sparc64-sparc64 
-lclangFrontend 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangSerialization/ob...

christos

> On Feb 20, 2020, at 4:10 AM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 20.02.2020 01:42, Christos Zoulas wrote:
>> Not reproducible:
> 
> As reported this needs specified:
> 
> -V MKLLVM=yes -V MKGCC=no -V HAVE_LLVM=yes
> 
>> 
>>  build.sh command:./build.sh -P -U -E -x -m sparc64 -a
>> sparc64 -D /usr/obj/sparc64-sparc64/release -R
>> /usr/obj/sparc64-sparc64/media -j 40 release
>>  build.sh started:Wed Feb 19 15:27:23 EST 2020
>>  NetBSD version:  9.99.47
>>  MACHINE: sparc64
>>  MACHINE_ARCH:sparc64
>>  Build platform:  NetBSD 9.99.18 amd64
>>  HOST_SH: /bin/sh
>>  No $TOOLDIR/bin/nbmake, needs building.
>>  Bootstrapping nbmake
>>  MAKECONF file:   /etc/mk.conf
>>  TOOLDIR path:/usr/obj/sparc64-sparc64/tools
>>  DESTDIR path:/usr/obj/sparc64-sparc64/release
>>  RELEASEDIR path: /usr/obj/sparc64-sparc64/media
>>  Created /usr/obj/sparc64-sparc64/tools/bin/nbmake
>>  Updated makewrapper:
>> /usr/obj/sparc64-sparc64/tools/bin/nbmake-sparc64
>>  Tools built to /usr/obj/sparc64-sparc64/tools
>>  MKREPRO_TIMESTAMPWed Feb 19 19:18:01 UTC 2020
>>  Successful make release
>>  build.sh ended:  Wed Feb 19 17:48:15 EST 2020
>> ===> .
>> 
>> 
>> 
>>> On Feb 19, 2020, at 11:09 AM, Kamil Rytarowski >> <mailto:n...@gmx.com>
>>> <mailto:n...@gmx.com <mailto:n...@gmx.com>>> wrote:
>>> 
>>> Signed PGP part
>>> On 19.02.2020 16:32, Kamil Rytarowski wrote:
>>>> On 18.02.2020 22:14, Christos Zoulas wrote:
>>>>> Module Name:src
>>>>> Committed By:christos
>>>>> Date:Tue Feb 18 21:14:16 UTC 2020
>>>>> 
>>>>> Modified Files:
>>>>> src/doc: 3RDPARTY CHANGES
>>>>> 
>>>>> Log Message:
>>&

Re: CVS commit: src/external/apache2/llvm/config/llvm/Config

2020-02-20 Thread Christos Zoulas
So host needs to install terminfo-dev. How is that different from the host 
environment needing to provide other pieces of the development environment? For 
example if another tool needed openssl-dev, would we disable crypto? Or if it 
needed yacc/bison or autoconf/automake wouldn't we rather install those? Isn't 
simple to type one command to install the appropriate packages?

christos

christos



> On Feb 20, 2020, at 7:32 PM, Kamil Rytarowski  wrote:
> 
> On 21.02.2020 01:17, Christos Zoulas wrote:
>> In article <5f8df6c1-bb25-f24a-27fc-b3a752a6d...@gmx.com>,
>> Kamil Rytarowski   wrote:
>> 
>>> We don't have any direct reproducer (we tried) and we must figure it out
>>> from syzkaller bot. We don't have access to the machine and a limited
>>> access to an admin over there (who has no expertise on BSDs). This
>>> failure breaks kMSan build for long time now. There is full build log.
>> 
>> If we don't undestand the problem we don't just disable code to make the
>> tool happy. This is: hand hurts, amputate. Let's try to figure out what's
>> wrong first.
>> 
>>> Calling syzbot report useless does not help. Lack of support in the
>>> build phase will result in removal of the bot instance and turn our work
>>> into futile effort.
>> 
>> We need to have more details in order to fix the problem.
>> 
>> christos
>> 
> 
> ./build.sh tools for LLVM is broken when host ships with no terminfo
> devel libraries. I tried to disable this superfluous feature for tools
> (for colors in a terminal), but it got reverted (breaking TNF rules) here.
> 
> The broken tools logic was workarounded in the syzbot setup and we
> installed there ncurses-dev package and the build passed.
> 
> PR toolchain/54993
> 
> 



Re: CVS commit: src/external/apache2/llvm/config/llvm/Config

2020-02-20 Thread Christos Zoulas
In article <5f8df6c1-bb25-f24a-27fc-b3a752a6d...@gmx.com>,
Kamil Rytarowski   wrote:

>We don't have any direct reproducer (we tried) and we must figure it out
>from syzkaller bot. We don't have access to the machine and a limited
>access to an admin over there (who has no expertise on BSDs). This
>failure breaks kMSan build for long time now. There is full build log.

If we don't undestand the problem we don't just disable code to make the
tool happy. This is: hand hurts, amputate. Let's try to figure out what's
wrong first.

>Calling syzbot report useless does not help. Lack of support in the
>build phase will result in removal of the bot instance and turn our work
>into futile effort.

We need to have more details in order to fix the problem.

christos



Re: CVS commit: src/doc

2020-02-19 Thread Christos Zoulas
Not reproducible:

 build.sh command:./build.sh -P -U -E -x -m sparc64 -a sparc64 -D 
/usr/obj/sparc64-sparc64/release -R /usr/obj/sparc64-sparc64/media -j 40 release
 build.sh started:Wed Feb 19 15:27:23 EST 2020
 NetBSD version:  9.99.47
 MACHINE: sparc64
 MACHINE_ARCH:sparc64
 Build platform:  NetBSD 9.99.18 amd64
 HOST_SH: /bin/sh
 No $TOOLDIR/bin/nbmake, needs building.
 Bootstrapping nbmake
 MAKECONF file:   /etc/mk.conf
 TOOLDIR path:/usr/obj/sparc64-sparc64/tools
 DESTDIR path:/usr/obj/sparc64-sparc64/release
 RELEASEDIR path: /usr/obj/sparc64-sparc64/media
 Created /usr/obj/sparc64-sparc64/tools/bin/nbmake
 Updated makewrapper: /usr/obj/sparc64-sparc64/tools/bin/nbmake-sparc64
 Tools built to /usr/obj/sparc64-sparc64/tools
 MKREPRO_TIMESTAMPWed Feb 19 19:18:01 UTC 2020
 Successful make release
 build.sh ended:  Wed Feb 19 17:48:15 EST 2020
===> .



> On Feb 19, 2020, at 11:09 AM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 19.02.2020 16:32, Kamil Rytarowski wrote:
>> On 18.02.2020 22:14, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By:   christos
>>> Date:   Tue Feb 18 21:14:16 UTC 2020
>>> 
>>> Modified Files:
>>> src/doc: 3RDPARTY CHANGES
>>> 
>>> Log Message:
>>> new awk
>>> 
>>> 
>>> To generate a diff of this commit:
>>> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
>>> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
>>> 
>>> Please note that diffs are not public domain; they are subject to the
>>> copyright notices on the relevant files.
>>> 
>> 
>> This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
>> 
> 
> Log:
> 
> isters.S |  sed "s;\([^:]*\):\([^(]*\)(\([^, )]*\)\(.*\);\3 \1
> /^\2(\3\4$/;"  >> tags.tmp
> In file included from /usr/src/lib/libc/compat/rpc/compat_pmap_rmtcall.c:50:
> In file included from
> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpc.h:75:
> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
> error: unknown type name 'rpcblist'
> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>   ^
> 1 error generated.
> --- compat_pmap_rmtcall.o ---
> *** [compat_pmap_rmtcall.o] Error code 1
> nbmake[6]: stopped in /usr/src/lib/libc
> In file included from /usr/src/lib/libc/compat/rpc/compat_rpcb.c:50:
> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
> error: unknown type name 'rpcblist'
> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>   ^
> 1 error generated.
> --- compat_rpcb.o ---
> *** [compat_rpcb.o] Error code 1
> 
> nbmake[6]: stopped in /usr/src/lib/libc
> 2 errors
> 
> nbmake[6]: stopped in /usr/src/lib/libc
> --- dependall ---
> *** [dependall] Error code 2
> nbmake[5]: stopped in /usr/src/lib/libc
> 1 error
> nbmake[5]: stopped in /usr/src/lib/libc
> *** Failed target:  dependall-libc
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
> /public/netbsd-sparc64/tooldir.NetBSD-9.99.46-amd64/bin/nbmake
> _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget libc dependall
> *** Error code 2
> 
> Stop.
> nbmake[4]: stopped in /usr/src/lib
> --- build_install ---
> *** [build_install] Error code 1
> 
> nbmake[3]: stopped in /usr/src/lib
> 1 error
> 
> nbmake[3]: stopped in /usr/src/lib
> --- do-lib ---
> *** [do-lib] Error code 2
> 
> nbmake[2]: stopped in /usr/src
> 1 error
> 
> nbmake[2]: stopped in /usr/src
> --- build ---
> *** [build] Error code 2
> 
> nbmake[1]: stopped in /usr/src
> 1 error
> 
> nbmake[1]: stopped in /usr/src
> --- distribution ---
> *** [distribution] Error code 2
> 
> nbmake: stopped in /usr/src
> 1 error
> 
> nbmake: stopped in /usr/src
> 
> ERROR: Failed to make distribution
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/doc

2020-02-19 Thread Christos Zoulas
On Feb 19,  5:09pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/doc

| On 19.02.2020 16:32, Kamil Rytarowski wrote:
| > On 18.02.2020 22:14, Christos Zoulas wrote:
| >> Module Name:   src
| >> Committed By:  christos
| >> Date:  Tue Feb 18 21:14:16 UTC 2020
| >>
| >> Modified Files:
| >>src/doc: 3RDPARTY CHANGES
| >>
| >> Log Message:
| >> new awk
| >>
| >>
| >> To generate a diff of this commit:
| >> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
| >> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
| >>
| >> Please note that diffs are not public domain; they are subject to the
| >> copyright notices on the relevant files.
| >>
| >=20
| > This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
| >=20
| 
| Log:
| 
| isters.S |  sed "s;\([^:]*\):\([^(]*\)(\([^, )]*\)\(.*\);\3 \1
| /^\2(\3\4$/;"  >> tags.tmp
| In file included from /usr/src/lib/libc/compat/rpc/compat_pmap_rmtcall.c:50=
| :
| In file included from
| /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpc.h:75:
| /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
| error: unknown type name 'rpcblist'
| extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
|^
| 1 error generated.
| --- compat_pmap_rmtcall.o ---
| *** [compat_pmap_rmtcall.o] Error code 1
| nbmake[6]: stopped in /usr/src/lib/libc
| In file included from /usr/src/lib/libc/compat/rpc/compat_rpcb.c:50:
| /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
| error: unknown type name 'rpcblist'
| extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);

building.

christos


Re: CVS commit: src/tests/lib/libc/sys

2020-02-18 Thread Christos Zoulas
In article <20200213152742.081a9f...@cvs.netbsd.org>,
MichaŠ Górny   wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  mgorny
>Date:  Thu Feb 13 15:27:41 UTC 2020
>
>Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.c
>
>Log Message:
>Enable combined breakpoint, watchpoint and signal tests

Let's split this file up. The name does not reflect anymore what this
is testing and it has become more than 9000 lines long. Because of the
complexity it keeps breaking the build and because of the size it makes
fixing it awkward. Kamil/Michal, can you please work on this?
[ for example the llvm builds are currently broken ]

Thanks,

christos



Re: CVS commit: src/tests/lib/libc/sys

2020-02-13 Thread Christos Zoulas
In article <20200213114904.ga30...@bec.de>,
Joerg Sonnenberger   wrote:
>On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote:
>> On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
>> > Module Name:   src
>> > Committed By:  christos
>> > Date:  Thu Feb 13 02:53:46 UTC 2020
>> > 
>> > Modified Files:
>> >src/tests/lib/libc/sys: t_ptrace_x86_wait.h
>> > 
>> > Log Message:
>> > Turn off optimization on a function which contains constant labels.
>> > The optimizer splits it and we end up with 2 copies and duplicate symbols.
>> 
>> Why not just turn them into local labels instead?
>
>Alternatively, suffixing them with %= would create unique labels.

I was looking for that :-)

christos



Re: CVS commit: src/tests/lib/libc/sys

2020-02-13 Thread Christos Zoulas
In article <20200213095019.ga28...@bec.de>,
Joerg Sonnenberger   wrote:
>On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Feb 13 02:53:46 UTC 2020
>> 
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_x86_wait.h
>> 
>> Log Message:
>> Turn off optimization on a function which contains constant labels.
>> The optimizer splits it and we end up with 2 copies and duplicate symbols.
>
>Why not just turn them into local labels instead?

You mean 1f etc? I was not sure if that would work in the symbol defined case.

christos



Re: CVS commit: src/usr.sbin/sysinst/arch

2020-02-03 Thread Christos Zoulas
In article <20200203130929.9de7df...@cvs.netbsd.org>,
Martin Husemann  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  martin
>Date:  Mon Feb  3 13:09:29 UTC 2020
>
>Modified Files:
>   src/usr.sbin/sysinst/arch/hp300: md.c
>   src/usr.sbin/sysinst/arch/mvme68k: md.c
>   src/usr.sbin/sysinst/arch/x68k: md.c
>
>Log Message:
>PR install/54921: skip non-user partitions when checking for overlaps

Write a function perhaps instead of open-coding it in 3 places?

christos



Re: CVS commit: src/lib/libpthread

2020-01-31 Thread Christos Zoulas
In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
Kamil Rytarowski   wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 31.01.2020 03:38, Christos Zoulas wrote:
>> And it is fixed now.
>> 
>> christos
>> 
>
>OK. I am going to submit a bug report upstream and get some feedback
>what is the way forward here, delaying initialization.

I think that the way forward (on our side) is to do away with libpthread,
merge it with libc and kill all the stub nonsense.

christos



Re: CVS commit: src/lib/libpthread

2020-01-30 Thread Christos Zoulas
And it is fixed now.

christos


signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/lib/libpthread

2020-01-30 Thread Christos Zoulas
At this point I'd say it is simpler to just initialize the mutexattr_t fields 
in a new
libc stub for the attribute init.

christos

> On Jan 30, 2020, at 8:05 PM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 05.03.2019 23:49, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Mar  5 22:49:38 UTC 2019
>> 
>> Modified Files:
>>  src/lib/libpthread: pthread_mutex.c
>> 
>> Log Message:
>> Jemalloc initializes mutexes before we become threaded and expects to use
>> them later.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.64 -r1.65 src/lib/libpthread/pthread_mutex.c
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
>> 
>> Modified files:
>> 
>> Index: src/lib/libpthread/pthread_mutex.c
>> diff -u src/lib/libpthread/pthread_mutex.c:1.64 
>> src/lib/libpthread/pthread_mutex.c:1.65
>> --- src/lib/libpthread/pthread_mutex.c:1.64  Fri Dec  8 04:24:31 2017
>> +++ src/lib/libpthread/pthread_mutex.c   Tue Mar  5 17:49:38 2019
>> @@ -1,4 +1,4 @@
>> -/*  $NetBSD: pthread_mutex.c,v 1.64 2017/12/08 09:24:31 kre Exp $   */
>> +/*  $NetBSD: pthread_mutex.c,v 1.65 2019/03/05 22:49:38 christos Exp $  
>> */
>> 
>> /*-
>>  * Copyright (c) 2001, 2003, 2006, 2007, 2008 The NetBSD Foundation, Inc.
>> @@ -47,7 +47,7 @@
>>  */
>> 
>> #include 
>> -__RCSID("$NetBSD: pthread_mutex.c,v 1.64 2017/12/08 09:24:31 kre Exp $");
>> +__RCSID("$NetBSD: pthread_mutex.c,v 1.65 2019/03/05 22:49:38 christos Exp 
>> $");
>> 
>> #include 
>> #include 
>> @@ -122,8 +122,14 @@ pthread_mutex_init(pthread_mutex_t *ptm,
>> {
>>  uintptr_t type, proto, val, ceil;
>> 
>> +#if 0
>> +/*
>> + * Always initialize the mutex structure, maybe be used later
>> + * and the cost should be minimal.
>> + */
>>  if (__predict_false(__uselibcstub))
>>  return __libc_mutex_init_stub(ptm, attr);
>> +#endif
>> 
>>  if (attr == NULL) {
>>  type = PTHREAD_MUTEX_NORMAL;
>> 
> 
> This change looks questionable.
> 
> Inside external/bsd/jemalloc/lib/../dist/src/mutex.c:
> 
>pthread_mutexattr_t attr;
> 
>if (pthread_mutexattr_init() != 0) {
>return true;
> 
>}
>pthread_mutexattr_settype(, MALLOC_MUTEX_TYPE);
>if (pthread_mutex_init(>lock, ) != 0) {
>pthread_mutexattr_destroy();
>return true;
>}
>pthread_mutexattr_destroy();
> 
> 
> We initialize attr with garbage as we use libc stubs and later pass
> garbage to pthread_mutex_init().
> 
> I want to add this sanity check inside pthread_mutex_init()
> 
> http://netbsd.org/~kamil/patch-00218-pthread_mutex_init-check-attr.txt
> 
> Unfortunately this causes jemalloc to deadlock.
> 
> (gdb) bt
> #0  pthread_rwlock_destroy (ptr=0x0) at
> /usr/src/lib/libpthread/pthread_rwlock.c:112
> #1  0x0246 in ?? ()
> #2  0x7f7fe600 in ?? ()
> #3  0x7f7ff7d0 in ?? ()
> #4  0x7f7ff72d94a0 in je_malloc_mutex_init (mutex=0x7f7fe600,
> mutex@entry=0x7f7ff7d0, name=name@entry=0x7f7ff7387106 "base",
>rank=rank@entry=18,
> lock_order=lock_order@entry=malloc_mutex_rank_exclusive) at
> /usr/src/external/bsd/jemalloc/lib/../dist/src/mutex.c:167
> #5  0x7f7ff731834f in je_base_new (tsdn=tsdn@entry=0x0,
> ind=ind@entry=0, extent_hooks=0x7f7ff75ca120 )
>at /usr/src/external/bsd/jemalloc/lib/../dist/src/base.c:366
> #6  0x7f7ff73185d2 in je_base_boot (tsdn=tsdn@entry=0x0) at
> /usr/src/external/bsd/jemalloc/lib/../dist/src/base.c:512
> #7  0x7f7ff731011d in malloc_init_hard_a0_locked () at
> /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:1327
> #8  0x7f7ff73107f5 in malloc_init_hard () at
> /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:1549
> #9  0x7f7ff723f924 in ?? () from /usr/lib/libc.so.12
> #10 0x7f7ff7ef9800 in ?? ()
> #11 0x7f7ff723ac09 in _init () from /usr/lib/libc.so.12
> #12 0x in ?? ()
> 
> Could we please fix it properly?
> 
> I am not sure what is the proper way here. We probably need to delay
> usage of pthread(3) but it is not that trivial.
> 
> Personally, I preferred the old jemalloc...
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/sys

2020-01-28 Thread Christos Zoulas
In article ,
Christos Zoulas  wrote:
>In article <4251.1580234...@jinx.noi.kre.to>,
>Robert Elz   wrote:
>>Date:Tue, 28 Jan 2020 16:40:27 +
>>From:"Andrew Doran" 
>>Message-ID:  <20200128164027.8558bf...@cvs.netbsd.org>
>>
>>  | Log Message:
>>  | Put pri_t back to an int.  It looks like there might be a sign extension
>>  | issue somewhere but it's not worth the hassle trying to find it.
>>
>>This changes the kernel internal ABI doesn't it?   It would have needed
>>a kernel version bump when the reverted change was made, and now needs
>>one it has been removed, doesn't it?
>
>Yes, but let's try to fix it and put it back the way it was before. It can't
>be used in too many places...

So I just took a quick look and it is non-trivial to change this
to something smaller than int, because it is used as an int in many
places, eg.   int sched_priority; (do_sched_setparam
needs fixing, sys__sched_protect needs fixing), even small issues
like:

--- kern_sleepq.c   21 Nov 2019 18:56:55 -  1.52
+++ kern_sleepq.c   28 Jan 2020 21:38:06 -
@@ -171,7 +171,7 @@
 
if ((sobj->sobj_flag & SOBJ_SLEEPQ_SORTED) != 0) {
lwp_t *l2;
-   const int pri = lwp_eprio(l);
+   const pri_t pri = lwp_eprio(l);
 
TAILQ_FOREACH(l2, sq, l_sleepchain) {
if (lwp_eprio(l2) < pri) {

christos



Re: CVS commit: src/sys/sys

2020-01-28 Thread Christos Zoulas
In article <4251.1580234...@jinx.noi.kre.to>,
Robert Elz   wrote:
>Date:Tue, 28 Jan 2020 16:40:27 +
>From:"Andrew Doran" 
>Message-ID:  <20200128164027.8558bf...@cvs.netbsd.org>
>
>  | Log Message:
>  | Put pri_t back to an int.  It looks like there might be a sign extension
>  | issue somewhere but it's not worth the hassle trying to find it.
>
>This changes the kernel internal ABI doesn't it?   It would have needed
>a kernel version bump when the reverted change was made, and now needs
>one it has been removed, doesn't it?

Yes, but let's try to fix it and put it back the way it was before. It can't
be used in too many places...

christos



Re: CVS commit: src/external/bsd/dhcpcd/dist/src

2020-01-27 Thread Christos Zoulas
Thanks. Yes, I have the core-dump, no we should not remove the line...

Best,

christos

> On Jan 27, 2020, at 8:03 AM, Roy Marples  wrote:
> 
> On 27/01/2020 09:03, Roy Marples wrote:
>> On 26/01/2020 22:57, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By:christos
>>> Date:Sun Jan 26 22:57:52 UTC 2020
>>> 
>>> Modified Files:
>>> src/external/bsd/dhcpcd/dist/src: script.c
>>> 
>>> Log Message:
>>> prevent coredump when state == NULL
>>> 
>>> 
>>> To generate a diff of this commit:
>>> cvs rdiff -u -r1.1.1.12 -r1.2 src/external/bsd/dhcpcd/dist/src/script.c
>> A quick perusal through the code shows that this should not happen. Every 
>> time IPV4LL is given as a reason, the state should exist.
> 
> There is one code path where there may be no state  when an IPv4LL 
> address exists and dhcpcd no longer controlls it (ie dhcpcd restarted or a 
> 3rd party added it) then we delete it anyway (for say when we obtain a DHCP 
> address).
> We should still run the IPV4LL hook script, but it will be empty.
> 
> I've accepted this patch upstream.
> 
> Roy



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/arch/evbarm/conf

2020-01-25 Thread Christos Zoulas
In article ,
Jason Thorpe   wrote:
>
>> On Jan 25, 2020, at 4:26 AM, Jared D. McNeill  wrote:
>> 
>> Module Name: src
>> Committed By:jmcneill
>> Date:Sat Jan 25 12:26:58 UTC 2020
>> 
>> Modified Files:
>>  src/sys/arch/evbarm/conf: GENERIC GENERIC64
>> 
>> Log Message:
>> Follow amd64 and set AUDIO_BLK_MS=4 by default
>
>This seems a little silly to have in the kernel configuration file.  I
>think there's an argument to be made that there should be a header that
>sets these defaults that can be tuned per-platform (or even some
>functionality to tune this at run-time).

sysctl :-)

christos



Re: CVS commit: src/sys [freeze on boot]

2020-01-20 Thread Christos Zoulas
In article <20200120185023.gd28...@homeworld.netbsd.org>,
Andrew Doran   wrote:
>Fix committed with sys/kern/kern_rwlock.c rev 1.62.  I didn't see the
>problem as I am running with LOCKDEBUG.
>
>Apologies for the disruption.

FYI: powerpc/arm do not build anymore...

http://releng.netbsd.org/builds/HEAD/202001201020Z/

christos



Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)

2020-01-14 Thread Christos Zoulas
In article <98f6e9a8-9d9a-4238-8521-6d86d0f84...@me.com>,
Jason Thorpe   wrote:
>
>
>> On Jan 14, 2020, at 2:37 PM, Christos Zoulas  wrote:
>> 
>> So what's the short term solution?
>> 
>> - Don't define {MIN,MAX}_PAGE_SIZE on m68k?
>> - Define a different constant?
>> - Add a define to tell uvm to ignore {MIN,MAX}_PAGE_SIZE?
>
>#ifdef _KERNEL, define {MIN,MAX}_PAGE_SIZE to a constant that matches
>the system.  For !_KERNEL, define MIN_PAGE_SIZE as 4096 and
>MAX_PAGE_SIZE as 8192.
>
>Seems like that would do the trick.

Ok!

christos



Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)

2020-01-14 Thread Christos Zoulas
In article <6b8ca202-14f6-4ffb-8a78-d2a473645...@me.com>,
Jason Thorpe   wrote:
>
>
>> On Jan 14, 2020, at 10:16 AM, Christos Zoulas  wrote:
>> 
>> We do this to save space, but as you say, not important for now. Perhaps
>> the expedient solution is to define MALLOC_PAGE_SIZE...
>
>I'd rather keep the use of these constants separate... who knows what
>they might be used for in the future?  Optimize #ifdef _KERNEL
>as-needed...

So what's the short term solution?

- Don't define {MIN,MAX}_PAGE_SIZE on m68k?
- Define a different constant?
- Add a define to tell uvm to ignore {MIN,MAX}_PAGE_SIZE?

christos



Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)

2020-01-14 Thread Christos Zoulas
On Jan 14,  8:54am, thor...@me.com (Jason Thorpe) wrote:
-- Subject: Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/inclu

| 
| 
| > On Jan 14, 2020, at 8:41 AM, Izumi Tsutsui  wrot=
| e:
| >=20
| >> b) Modules should be built such that they can use a non-fixed PAGE_SIZE.=
| 
| >=20
| > No, this is not necessary, because modules are built for each $MACHINE
| > and (a) each $MACHINE has fixed PAGE_SIZE.
| 
| Yes, understood.  I think it would eventually be a nice idea to make module=
| s $MACHINE_ARCH-sharable, but it's not critical for now.

We do this to save space, but as you say, not important for now. Perhaps
the expedient solution is to define MALLOC_PAGE_SIZE...

christos


Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)

2020-01-13 Thread Christos Zoulas
In article <20200113163830.e7a6317f...@rebar.astron.com>,
Christos Zoulas  wrote:
>| 
>| Probably this is the same reason of recent arm build failures:
>|  https://releng.netbsd.org/builds/HEAD/202001130720Z/
>|  https://releng.netbsd.org/builds/HEAD/202001130720Z/evbarm-earm.build.failed
>| ---
>| /tmp/genassym.Lq8h9d/assym.c:57:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY VM_MIN_ADDRESS %0" : : "n" (VM_MIN_ADDRESS));
>|  ^
>| /tmp/genassym.Lq8h9d/assym.c:58:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY VM_MAXUSER_ADDRESS %0" : : "n" (VM_MAXUSER_ADDRESS));
>|  ^
>| /tmp/genassym.Lq8h9d/assym.c:97:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY PAGE_MASK %0" : : "n" (PAGE_MASK));
>|  ^
>| /tmp/genassym.Lq8h9d/assym.c:98:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY PAGE_SIZE %0" : : "n" (PAGE_SIZE));
>|  ^
>| ---
>| 
>| Should we prepare independent constant for
>| "possible pagesize value among different MACHINE with the same MACHINE_ARCH"
>| for jemalloc(3)?
>
>Ouch, this hurts. Sure, perhaps MALLOC_PAGE_SIZE?

Talking to myself:

The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the
need for the 8K pages. This leaves us with m68k to deal with...
Do modules work on m68k? Should modules be shared between kernels with
different page sizes? Then perhaps we don't need a new constant?

christos



Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)

2020-01-13 Thread Christos Zoulas
On Jan 14,  1:15am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/incl

| christos@ wrote:
| 
| > >Now I get the following erro during local tests of
| > >"build.sh -U -m hp300 release" on NetBSD/i386 9.0_RC1 host:
| > >
| > >---
| > >#create  compat_util/compat_exec.d
|  :
| > >In file included from /s/cvs/src/sys/sys/param.h:149:0,
| > > from /s/cvs/src/sys/compat/common/compat_exec.c:41:
| > >./m68k/pmap_motorola.h:165:5: error: operator '*' has no left operand
| > > #if PAGE_SIZE == 8192 /* NBPG / (SG4_LEV1SIZE * sizeof(st_entry_t)) */
| > > ^
| > >nbmkdep: compile failed.
| > >*** [compat_exec.d] Error code 1
| > 
| > try cc -E?
| 
| It turns out the problem is more complicated.
| 
|  has the following definitions:
| 
| https://nxr.netbsd.org/xref/src/sys/uvm/uvm_param.h?r=1.38#135
| ---
| 135  * If MIN_PAGE_SIZE and MAX_PAGE_SIZE are not equal, then we must use
| 136  * non-constant PAGE_SIZE, et al for LKMs.
| 137  */
| 138 #if (MIN_PAGE_SIZE != MAX_PAGE_SIZE)
| 139 #define   __uvmexp_pagesize
| 140 #if defined(_LKM) || defined(_MODULE)
| 141 #undef PAGE_SIZE
| 142 #undef PAGE_MASK
| 143 #undef PAGE_SHIFT
| 144 #endif
| 145 #endif
| 146 
| 147 /*
| 148  * Now provide PAGE_SIZE, PAGE_MASK, and PAGE_SHIFT if we do not
| 149  * have ones that are compile-time constants.
| 150  */
| 151 #if !defined(PAGE_SIZE)
| 152 extern const int *const uvmexp_pagesize;
| 153 extern const int *const uvmexp_pagemask;
| 154 extern const int *const uvmexp_pageshift;
| 155 #define   PAGE_SIZE   (*uvmexp_pagesize)  /* size of page 
*/
| 156 #define   PAGE_MASK   (*uvmexp_pagemask)  /* size of page 
- 1 */
| 157 #define   PAGE_SHIFT  (*uvmexp_pageshift) /* bits to 
shift for pages */
| 158 #endif /* PAGE_SIZE */
| ---
| 
| I.e.  assumes PAGE_SIZE is not compile time constant
| for MODULEs if (MIN_PAGE_SIZE != MAX_PAGE_SIZE).
| 
| Probably this is the same reason of recent arm build failures:
|  https://releng.netbsd.org/builds/HEAD/202001130720Z/
|  https://releng.netbsd.org/builds/HEAD/202001130720Z/evbarm-earm.build.failed
| ---
| /tmp/genassym.Lq8h9d/assym.c:57:1: error: asm operand 0 probably doesn't 
match constraints [-Werror]
|  __asm("XYZZY VM_MIN_ADDRESS %0" : : "n" (VM_MIN_ADDRESS));
|  ^
| /tmp/genassym.Lq8h9d/assym.c:58:1: error: asm operand 0 probably doesn't 
match constraints [-Werror]
|  __asm("XYZZY VM_MAXUSER_ADDRESS %0" : : "n" (VM_MAXUSER_ADDRESS));
|  ^
| /tmp/genassym.Lq8h9d/assym.c:97:1: error: asm operand 0 probably doesn't 
match constraints [-Werror]
|  __asm("XYZZY PAGE_MASK %0" : : "n" (PAGE_MASK));
|  ^
| /tmp/genassym.Lq8h9d/assym.c:98:1: error: asm operand 0 probably doesn't 
match constraints [-Werror]
|  __asm("XYZZY PAGE_SIZE %0" : : "n" (PAGE_SIZE));
|  ^
| ---
| 
| Should we prepare independent constant for
| "possible pagesize value among different MACHINE with the same MACHINE_ARCH"
| for jemalloc(3)?

Ouch, this hurts. Sure, perhaps MALLOC_PAGE_SIZE?

christos


Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)

2020-01-13 Thread Christos Zoulas
In article <200114002918.m0108...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui   wrote:
>christos@ wrote:
>
>> LGTM too.
>
>> >> thorpej@ wrote:
> :
>> >> How about the attached diff? (untested, just for review)
>> > 
>> > This looks good to me.
>
>Now I get the following erro during local tests of
>"build.sh -U -m hp300 release" on NetBSD/i386 9.0_RC1 host:
>
>---
>#create  compat_util/compat_exec.d
>CC=/s/cvs/src/obj.hp300/tooldir.NetBSD-9.0_RC1-i386/bin/m68k--netbsdelf-gcc
>/s/cvs/src/obj.hp300/tooldir.NetBSD-9.0_RC1-i386/bin/nbmkdep -f
>compat_exec.d.tmp  --   -std=gnu99   -I/s/cvs/src/common/include
>-DDIAGNOSTIC --sysroot=/s/cvs/src/obj.hp300/destdir.hp300
>-I/s/cvs/src/common/include -DDIAGNOSTIC -nostdinc -I.
>-I/s/cvs/src/sys/modules/compat_util -isystem /s/cvs/src/sys -isystem
>/s/cvs/src/sys/arch -isystem /s/cvs/src/sys/../common/include -D_KERNEL
>-D_LKM -D_MODULE -DSYSCTL_INCLUDE_DESCR
>/s/cvs/src/sys/compat/common/compat_exec.c &&  mv -f compat_exec.d.tmp
>compat_exec.d
>In file included from /s/cvs/src/sys/sys/param.h:149:0,
> from /s/cvs/src/sys/compat/common/compat_exec.c:41:
>./m68k/pmap_motorola.h:165:5: error: operator '*' has no left operand
> #if PAGE_SIZE == 8192 /* NBPG / (SG4_LEV1SIZE * sizeof(st_entry_t)) */
> ^
>nbmkdep: compile failed.
>*** [compat_exec.d] Error code 1
>
>---
>
>I'm not sure why my  change causes this error,
>but I also wonder if we should use "PGSHIFT == 13" rather than
>"PAGE_SIZE == 8192" in ..

try cc -E?

christos



Re: CVS commit: src/sys/arch/arm/include/arm32

2020-01-12 Thread Christos Zoulas
LGTM too.

christos

> On Jan 12, 2020, at 10:09 AM, Jason Thorpe  wrote:
> 
> 
> 
>> On Jan 11, 2020, at 10:47 PM, Izumi Tsutsui  wrote:
>> 
>> thorpej@ wrote:
>> 
 PGSHIFT is defined in  and
 PAGE_SHIFT and PAGE_SIZE is in ,
 but there is no common .
>>> 
>>> Make a common  that all of the platforms can #include, and 
>>> just put these common definitions in it (for now)?
>> 
>> How about the attached diff? (untested, just for review)
> 
> This looks good to me.
> 
> -- thorpej



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/arch/arm/include/arm32

2020-01-11 Thread Christos Zoulas
In article <200112121414.m0101...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui   wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jan 11 19:06:35 UTC 2020
>> 
>> Modified Files:
>>  src/sys/arch/arm/include/arm32: vmparam.h
>> 
>> Log Message:
>> Define the min and max page size supported for the benefit of jemalloc
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.45 -r1.46 src/sys/arch/arm/include/arm32/vmparam.h
>
>--- src/sys/arch/arm/include/arm32/vmparam.h:1.45  Wed Jun 19 09:54:42 2019
>+++ src/sys/arch/arm/include/arm32/vmparam.h   Sat Jan 11 19:06:34 2020
>@@ -84,6 +84,11 @@
> #define   PAGE_SIZE   (1 << PAGE_SHIFT)
> #define   PAGE_MASK   (PAGE_SIZE - 1)
> 
>+#define   MIN_PAGE_SHIFT  12  /* normal */
>+#define   MAX_PAGE_SHIFT  13  /* _ARM_ARCH_6 */
>+#define   MIN_PAGE_SIZE   (1 << MIN_PAGE_SHIFT)
>+#define   MAX_PAGE_SIZE   (1 << MAX_PAGE_SHIFT)
>+
> /*
>  * Mach derived constants
>  */
>
>---
>
>m68k also needs this? (currently no common  though)

Good catch. Yup, looks like it:

$ fgrep PGSHIFT 
{amiga,atari,hp300,luna68k,mac68k,mvme68k,next68k,sun2,sun3,x68k}/
param.h
amiga/include/param.h:#define   PGSHIFT 13  /* LOG2(NBPG) */
atari/include/param.h:#define   PGSHIFT 13  /* LOG2(NBPG) */
hp300/include/param.h:#define   PGSHIFT 12  /* LOG2(NBPG) */
luna68k/include/param.h:#define PGSHIFT 12  /* LOG2(NBPG) */
mac68k/include/param.h:#define  PGSHIFT 12  /* LOG2(NBPG) */
mvme68k/include/param.h:#define PGSHIFT 12  /* LOG2(NBPG) */
next68k/include/param.h:#define PGSHIFT 12  /* LOG2(NBPG) */
sun2/include/param.h:#define PGSHIFT11  /* LOG2(NBPG) */
sun3/include/param.h:#definePGSHIFT 13  /* LOG2(NBPG) */
x68k/include/param.h:#definePGSHIFT 12  /* LOG2(NBPG) */

...

#define   MIN_PAGE_SHIFT  11  /* sun2 */
#define   MAX_PAGE_SHIFT  13  /* amiga,atari,sun3 */
#define   MIN_PAGE_SIZE   (1 << MIN_PAGE_SHIFT)
#define   MAX_PAGE_SIZE   (1 << MAX_PAGE_SHIFT)

Should I take care of it or can you?

christos



Re: CVS commit: src/lib/libc/sys

2020-01-06 Thread Christos Zoulas
In article <20200104044017.c44aef...@cvs.netbsd.org>,
Kamil Rytarowski  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kamil
>Date:  Sat Jan  4 04:40:17 UTC 2020
>
>Modified Files:
>   src/lib/libc/sys: ptrace.2
>
>Log Message:
>/tmp/cvsbigmGa

You need to read the commit message in, not pass the name of the file!

christos



Re: CVS commit: src/share/tmac

2019-12-24 Thread Christos Zoulas
In article <20191224113037.gl24...@pony.stderr.spb.ru>,
Valery Ushakov   wrote:
>On Tue, Dec 24, 2019 at 08:46:49 +0700, Robert Elz wrote:
>
>> Date:Mon, 23 Dec 2019 23:45:34 +0100
>> From:Steffen Nurpmeso 
>> Message-ID:  <20191223224534.8ufgy%stef...@sdaoden.eu>
>> 
>> 
>>   |  |Troff reads .ie and checks the condition.  The condition is true and
>>   |  |so the rest of the line is executed.  Then troff reads .el that
>>   |  |matches successful .ie, so the .el is discarded.
>>   |  |
>>   |  |Then it reads .el which is not matched with any .ie that troff has
>>   |  |seen.  It's usually silently discarded,
>> 
>> That is what is (always was) intended to happen.
>
>Sure.
>
>
>>   |  |but since we run with -ww we
>>   |  |get the warning about an unbalanced .el
>> 
>> That's a broken warning.
>
>Amen.  But let's be honest, in this day and age *very* few people can
>can read troff, never mind write it (and I don't count myself as one),
>so a warning from groff, however broken, will just confuse and upset
>the users.  Since silencing this warning doesn't require that much of
>an effort and doesn't mutilate the code that much, it's easier to just
>shut it up.

We should file a bug report with groff though (and optionally supply a fix).

christos



Re: CVS commit: src

2019-12-21 Thread Christos Zoulas
In article <15520611-7273-9567-33a4-ff2490b2e...@m00nbsd.net>,
Maxime Villard   wrote:
>Le 21/12/2019 à 00:05, Taylor R Campbell a écrit :
>> Security-team is not perfect.  We're happy to discuss a better way to
>> disable filemon provisionally, and/or how to better address the
>> existing users if we are to delete it -- after you do as core asked
>> you to do to resolve the interim dispute by restoring the tree.
>>
>> This is a social process.  We can work together to make it better for
>> everyone, but you have to be willing to work with the community,
>> including accepting rulings by core to resolve disputes.
>
>I'm afraid you, Taylor, don't have a monopoly on representing the community.

He does represent the community since he represents core. If you
are unhappy with core@ talk to board@. If you are unhappy with
core@ and board@, get the community to vote for you in the next
elections, or get signatures to impeach them. They are the elected
leadership of the project.

>It just so happens that I, too, as a regular member and also as a main
>kernel developer, represent the community; and I don't think the community
>is really happy with how secteam disabled filemon without discussion. The
>community is likely even less happy with how it was disabled, considering
>that a quick discussion has already highlighted two apparent better ways
>to disable it.
>
>It appears that core and secteam failed to work properly with the
>community.

See above.

>To resolve this dispute, I have proposed to revert both my removal, and
>secteam's broken disabling. This gives a clear basis to start a discussion
>on what to do with filemon exactly.
>
>Is core fine with that? Or are there double standards at play here?

Core has been very clear. They've asked you to revert your commits, not
other commits. If they had been unhappy with other commits they would
have asked the committers of the other commits to revert them.

christos



Re: CVS commit: src/usr.bin/crunch/crunchgen

2019-12-19 Thread Christos Zoulas
On Dec 19,  4:19pm, jo...@bec.de (Joerg Sonnenberger) wrote:
-- Subject: Re: CVS commit: src/usr.bin/crunch/crunchgen

| > I think that there are two uses: install media and rescue. I can reinstate
| > it for rescue. Is that ok? Note that by default both ssp and fortify are
| > off for most things, so my change was mostly a no-op for the default 
settings.
| 
| We seem to default to off for more things, PIE too for example.

Indeed, I also dislike the alphabet soup of flags for disabling
things.  I propose that instead we provide a way to add a preamble
to the generated Makefile via -f  file, default to a
either a built-in configuration file, or one installed in the tree.
It is inappropriate for crunchgen to have knowledge of variables
specific to our build system that change over time.

So I propose:

1. to make that change [configuration file]
2. leave the defaults as they are for the installation binaries
3. change the defaults to turn nothing off for the rescue binaries

christos


Re: CVS commit: src/usr.bin/crunch/crunchgen

2019-12-19 Thread Christos Zoulas
In article <20191218222723.ga17...@bec.de>,
Joerg Sonnenberger   wrote:
>On Wed, Dec 18, 2019 at 03:51:21PM -, Christos Zoulas wrote:
>> In article <20191218152113.ga7...@bec.de>,
>> Joerg Sonnenberger   wrote:
>> >On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote:
>> >> Module Name:  src
>> >> Committed By: christos
>> >> Date: Wed Dec 18 02:16:04 UTC 2019
>> >> 
>> >> Modified Files:
>> >>   src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c
>> >> 
>> >> Log Message:
>> >> Also disable ssp and fortify by default.
>> >
>> >Why?
>> 
>> Size reduction on install media. There are flags to turn it on.
>
>Not all users of crunchgen are space constrained, so this seems like a
>bad default to me.

I think that there are two uses: install media and rescue. I can reinstate
it for rescue. Is that ok? Note that by default both ssp and fortify are
off for most things, so my change was mostly a no-op for the default settings.

christos



Re: CVS commit: src/usr.bin/crunch/crunchgen

2019-12-18 Thread Christos Zoulas
In article <20191218152113.ga7...@bec.de>,
Joerg Sonnenberger   wrote:
>On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Dec 18 02:16:04 UTC 2019
>> 
>> Modified Files:
>>  src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c
>> 
>> Log Message:
>> Also disable ssp and fortify by default.
>
>Why?

Size reduction on install media. There are flags to turn it on.

christos



Re: CVS commit: src

2019-12-18 Thread Christos Zoulas
While there was no discussion, it is more efficient to have the discussion
whether we should put it back or not (instead of putting it back first and
having the discussion). Of course we should fix the build first since it seems
to be broken.

The reality of the situation is that the syscall race has been there for months
and nobody has taken responsibility to fix it. The code is in version control,
so someone should fix it first and then we can discuss if we should bring it
back.


christos

> On Dec 18, 2019, at 4:58 AM, John Nemeth  wrote:
> 
> On Dec 18,  7:37am, "Maxime Villard" wrote:
> }
> } This is a multi-part message in MIME format.
> }
> } --_--=_1576654639170820
> } Content-Disposition: inline
> } Content-Transfer-Encoding: 8bit
> } Content-Type: text/plain; charset="US-ASCII"
> }
> } Module Name:src
> } Committed By:   maxv
> } Date:   Wed Dec 18 07:37:19 UTC 2019
> }
> } Modified Files:
> } src/distrib/sets/lists/base: mi
> } src/distrib/sets/lists/comp: mi
> } src/distrib/sets/lists/man: mi
> } src/etc: MAKEDEV.tmpl
> } src/etc/mtree: NetBSD.dist.base
> } src/share/man/man4: Makefile
> } src/sys/arch/amd64/conf: ALL
> } src/sys/arch/i386/conf: ALL
> } src/sys/conf: files majors
> } src/sys/dev: Makefile
> } src/sys/modules: Makefile
> } src/usr.bin/make: Makefile compat.c make.1 meta.c
> } src/usr.sbin/makemandb: nostem.txt
> } Removed Files:
> } src/share/man/man4: filemon.4
> } src/sys/dev/filemon: Makefile filemon.c filemon.h filemon_wrapper.c
> } mknod-sh
> } src/sys/modules/filemon: Makefile filemon.ioconf
> }
> } Log Message:
> } Retire filemon, discussed on tech-kern@.
> 
> What discussion?  In a message dated, Tue Dec 17 13:58:19
> 2019, you stated, "I will prepare the removal of filemon."  That
> doesn't exactly look like a proposal to me.  After that, I don't
> see any discussion about its removal.
> 
>Please revert this commit, make a proper proposal and allow
> for a proper discussion as per the policy for removing features.
> 
> }-- End of excerpt from "Maxime Villard"



signature.asc
Description: Message signed with OpenPGP


CVS commit: src/external/mpl/bind/dist/lib/isc/include/isc

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Thu Nov 28 00:18:36 UTC 2019

Modified Files:
src/external/mpl/bind/dist/lib/isc/include/isc: types.h

Log Message:
match ifdefs with stats.c atomic selection


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 \
src/external/mpl/bind/dist/lib/isc/include/isc/types.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/external/mpl/bind/dist/lib/isc/include/isc

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Thu Nov 28 00:18:36 UTC 2019

Modified Files:
src/external/mpl/bind/dist/lib/isc/include/isc: types.h

Log Message:
match ifdefs with stats.c atomic selection


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 \
src/external/mpl/bind/dist/lib/isc/include/isc/types.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/external/mpl/bind/dist/lib/isc/include/isc/types.h
diff -u src/external/mpl/bind/dist/lib/isc/include/isc/types.h:1.5 src/external/mpl/bind/dist/lib/isc/include/isc/types.h:1.6
--- src/external/mpl/bind/dist/lib/isc/include/isc/types.h:1.5	Wed Nov 27 00:48:42 2019
+++ src/external/mpl/bind/dist/lib/isc/include/isc/types.h	Wed Nov 27 19:18:36 2019
@@ -1,4 +1,4 @@
-/*	$NetBSD: types.h,v 1.5 2019/11/27 05:48:42 christos Exp $	*/
+/*	$NetBSD: types.h,v 1.6 2019/11/28 00:18:36 christos Exp $	*/
 
 /*
  * Copyright (C) Internet Systems Consortium, Inc. ("ISC")
@@ -78,7 +78,7 @@ typedef struct isc_socket		isc_socket_t;
 typedef struct isc_socketevent		isc_socketevent_t;	/*%< Socket Event */
 typedef struct isc_socketmgr		isc_socketmgr_t;	/*%< Socket Manager */
 typedef struct isc_stats		isc_stats_t;		/*%< Statistics */
-#if defined(_WIN32) && !defined(_WIN64)
+#if defined(_WIN32) && !defined(_WIN64) || !defined(_LP64)
 	typedef int_fast32_t 		isc_statscounter_t;	/*%< Statistics Counter */
 #else
 	typedef int_fast64_t 		isc_statscounter_t;



CVS commit: src/share/terminfo

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 19:00:25 UTC 2019

Added Files:
src/share/terminfo: import

Log Message:
simple import script


To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/share/terminfo/import

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Added files:

Index: src/share/terminfo/import
diff -u /dev/null src/share/terminfo/import:1.1
--- /dev/null	Wed Nov 27 14:00:25 2019
+++ src/share/terminfo/import	Wed Nov 27 14:00:25 2019
@@ -0,0 +1,27 @@
+#!/bin/sh
+# $NetBSD: import,v 1.1 2019/11/27 19:00:25 christos Exp $
+#
+# Simple shell script to import the newest version of terminfo
+# Download it from ftp://ftp.invisible-island.net/ncurses/current
+
+input=$1
+case "${input}" in 
+terminfo-[0-9]*.src)
+	;;
+*)
+	echo "$0: Invalid input file name" 1>&2
+	exit 1
+	;;
+esac
+
+tag=${input%%.src}
+vendor=NCURSES
+
+TMP=$(mktemp -d /tmp/import-terminfo)
+trap rm -fr "${TMP}" 0 1 2 15
+
+cp "$1" "${TMP}/terminfo"
+cd "${TMP}"
+cleantags terminfo
+cvs -d cvs.netbsd.org:/cvsroot import \
+	-m "Import $1" src/share/terminfo "${vendor}" "${tag}"



CVS commit: src/share/terminfo

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 19:00:25 UTC 2019

Added Files:
src/share/terminfo: import

Log Message:
simple import script


To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/share/terminfo/import

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/doc

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 19:04:45 UTC 2019

Modified Files:
src/doc: 3RDPARTY CHANGES

Log Message:
new terminfo


To generate a diff of this commit:
cvs rdiff -u -r1.1671 -r1.1672 src/doc/3RDPARTY
cvs rdiff -u -r1.2617 -r1.2618 src/doc/CHANGES

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/doc/3RDPARTY
diff -u src/doc/3RDPARTY:1.1671 src/doc/3RDPARTY:1.1672
--- src/doc/3RDPARTY:1.1671	Wed Nov 27 00:50:26 2019
+++ src/doc/3RDPARTY	Wed Nov 27 14:04:45 2019
@@ -1,4 +1,4 @@
-#	$NetBSD: 3RDPARTY,v 1.1671 2019/11/27 05:50:26 christos Exp $
+#	$NetBSD: 3RDPARTY,v 1.1672 2019/11/27 19:04:45 christos Exp $
 #
 # This file contains a list of the software that has been integrated into
 # NetBSD where we are not the primary maintainer.
@@ -2177,3 +2177,18 @@ Responsible:
 License:	BSD-like (2 and 3-clause)
 Location:	sys/external/bsd/ena-com
 Notes:
+
+Package:	terminfo
+Version:	20190609
+
+Current Vers:	20190609
+Maintainer:	Thomas Dickey (ncurses)
+Archive Site:	ftp://ftp.invisible-island.net/ncurses/current
+Home Page:	https://invisible-island.net/ncurses/
+Date:		2019-11-27
+Mailing List:	bug-ncur...@gnu.org
+Responsible:
+License:	none
+Location:	sys/external/bsd/ena-com
+Notes:
+Use the import script in /usr/src/share/terminfo

Index: src/doc/CHANGES
diff -u src/doc/CHANGES:1.2617 src/doc/CHANGES:1.2618
--- src/doc/CHANGES:1.2617	Wed Nov 27 00:50:26 2019
+++ src/doc/CHANGES	Wed Nov 27 14:04:45 2019
@@ -1,4 +1,4 @@
-# LIST OF CHANGES FROM LAST RELEASE:			<$Revision: 1.2617 $>
+# LIST OF CHANGES FROM LAST RELEASE:			<$Revision: 1.2618 $>
 #
 #
 # [Note: This file does not mention every change made to the NetBSD source tree.
@@ -74,3 +74,4 @@ Changes from NetBSD 9.0 to NetBSD 10.0:
 		QuickAssist Adapter 8960/8970.
 		[hikaru 20191120]
 	bind: Import version 9.14.8. [christos 20191127]
+	terminfo: Import 20190609 [christos 20191127]



CVS commit: src/doc

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 19:04:45 UTC 2019

Modified Files:
src/doc: 3RDPARTY CHANGES

Log Message:
new terminfo


To generate a diff of this commit:
cvs rdiff -u -r1.1671 -r1.1672 src/doc/3RDPARTY
cvs rdiff -u -r1.2617 -r1.2618 src/doc/CHANGES

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS import: src/share/terminfo

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 18:48:58 UTC 2019

Update of /cvsroot/src/share/terminfo
In directory ivanova.netbsd.org:/tmp/cvs-serv6791

Log Message:
Import terminfo-20190609.src

Status:

Vendor Tag: NCURSES
Release Tags:   terminfo-20190609

C src/share/terminfo/terminfo

1 conflicts created by this import.
Use the following command to help the merge:

cvs checkout -jNCURSES:yesterday -jNCURSES src/share/terminfo



CVS import: src/share/terminfo

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 18:48:58 UTC 2019

Update of /cvsroot/src/share/terminfo
In directory ivanova.netbsd.org:/tmp/cvs-serv6791

Log Message:
Import terminfo-20190609.src

Status:

Vendor Tag: NCURSES
Release Tags:   terminfo-20190609

C src/share/terminfo/terminfo

1 conflicts created by this import.
Use the following command to help the merge:

cvs checkout -jNCURSES:yesterday -jNCURSES src/share/terminfo



CVS commit: src/usr.sbin/usbdevs

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 17:56:09 UTC 2019

Modified Files:
src/usr.sbin/usbdevs: usbdevs.c

Log Message:
Use strtoi instead of atoi() to catch bad input (Alexander Kuleshov)


To generate a diff of this commit:
cvs rdiff -u -r1.39 -r1.40 src/usr.sbin/usbdevs/usbdevs.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.sbin/usbdevs

2019-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 17:56:09 UTC 2019

Modified Files:
src/usr.sbin/usbdevs: usbdevs.c

Log Message:
Use strtoi instead of atoi() to catch bad input (Alexander Kuleshov)


To generate a diff of this commit:
cvs rdiff -u -r1.39 -r1.40 src/usr.sbin/usbdevs/usbdevs.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.sbin/usbdevs/usbdevs.c
diff -u src/usr.sbin/usbdevs/usbdevs.c:1.39 src/usr.sbin/usbdevs/usbdevs.c:1.40
--- src/usr.sbin/usbdevs/usbdevs.c:1.39	Tue Nov 12 02:41:50 2019
+++ src/usr.sbin/usbdevs/usbdevs.c	Wed Nov 27 12:56:08 2019
@@ -1,4 +1,4 @@
-/*	$NetBSD: usbdevs.c,v 1.39 2019/11/12 07:41:50 mrg Exp $	*/
+/*	$NetBSD: usbdevs.c,v 1.40 2019/11/27 17:56:08 christos Exp $	*/
 
 /*
  * Copyright (c) 1998 The NetBSD Foundation, Inc.
@@ -31,7 +31,7 @@
 
 #include 
 #ifndef lint
-__RCSID("$NetBSD: usbdevs.c,v 1.39 2019/11/12 07:41:50 mrg Exp $");
+__RCSID("$NetBSD: usbdevs.c,v 1.40 2019/11/27 17:56:08 christos Exp $");
 #endif
 
 #include 
@@ -48,6 +48,7 @@ __RCSID("$NetBSD: usbdevs.c,v 1.39 2019/
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -367,7 +368,7 @@ getusbcount_device(int fd, const char *d
 int
 main(int argc, char **argv)
 {
-	int ch, i, f;
+	int ch, i, f, error;
 	char buf[50];
 	char *dev = NULL;
 	int addr = -1;
@@ -376,7 +377,13 @@ main(int argc, char **argv)
 	while ((ch = getopt(argc, argv, "a:df:v?")) != -1) {
 		switch(ch) {
 		case 'a':
-			addr = atoi(optarg);
+			addr = strtoi(optarg, NULL, 10, 0, USB_MAX_DEVICES - 1,
+			);
+			if (error) {
+errc(EXIT_FAILURE, error,
+"Bad value for device address: `%s'",
+optarg);
+			}
 			break;
 		case 'd':
 			showdevs++;
@@ -429,5 +436,5 @@ main(int argc, char **argv)
 		else
 			err(1, "%s", dev);
 	}
-	exit(EXIT_SUCCESS);
+	return EXIT_SUCCESS;
 }



CVS commit: src/doc

2019-11-26 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 05:50:26 UTC 2019

Modified Files:
src/doc: 3RDPARTY CHANGES

Log Message:
new bind (tcp DoS security fix)


To generate a diff of this commit:
cvs rdiff -u -r1.1670 -r1.1671 src/doc/3RDPARTY
cvs rdiff -u -r1.2616 -r1.2617 src/doc/CHANGES

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/doc

2019-11-26 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 05:50:26 UTC 2019

Modified Files:
src/doc: 3RDPARTY CHANGES

Log Message:
new bind (tcp DoS security fix)


To generate a diff of this commit:
cvs rdiff -u -r1.1670 -r1.1671 src/doc/3RDPARTY
cvs rdiff -u -r1.2616 -r1.2617 src/doc/CHANGES

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/doc/3RDPARTY
diff -u src/doc/3RDPARTY:1.1670 src/doc/3RDPARTY:1.1671
--- src/doc/3RDPARTY:1.1670	Wed Nov 13 05:52:40 2019
+++ src/doc/3RDPARTY	Wed Nov 27 00:50:26 2019
@@ -1,4 +1,4 @@
-#	$NetBSD: 3RDPARTY,v 1.1670 2019/11/13 10:52:40 roy Exp $
+#	$NetBSD: 3RDPARTY,v 1.1671 2019/11/27 05:50:26 christos Exp $
 #
 # This file contains a list of the software that has been integrated into
 # NetBSD where we are not the primary maintainer.
@@ -120,8 +120,8 @@ Notes:
 bc includes dc, both of which are in the NetBSD tree.
 
 Package:	bind [named and utils]
-Version:	9.14.7/MPL
-Current Vers:	9.14.7/MPL
+Version:	9.14.8/MPL
+Current Vers:	9.14.8/MPL
 Maintainer:	ISC
 Archive Site:	ftp://ftp.isc.org/isc/bind9/
 Home Page:	http://www.isc.org/software/bind/

Index: src/doc/CHANGES
diff -u src/doc/CHANGES:1.2616 src/doc/CHANGES:1.2617
--- src/doc/CHANGES:1.2616	Tue Nov 26 02:17:42 2019
+++ src/doc/CHANGES	Wed Nov 27 00:50:26 2019
@@ -1,4 +1,4 @@
-# LIST OF CHANGES FROM LAST RELEASE:			<$Revision: 1.2616 $>
+# LIST OF CHANGES FROM LAST RELEASE:			<$Revision: 1.2617 $>
 #
 #
 # [Note: This file does not mention every change made to the NetBSD source tree.
@@ -73,3 +73,4 @@ Changes from NetBSD 9.0 to NetBSD 10.0:
 		Atom C2XXX, C3XXX, Xeon D-21XX and D-15XX, C62X chipsets and
 		QuickAssist Adapter 8960/8970.
 		[hikaru 20191120]
+	bind: Import version 9.14.8. [christos 20191127]



CVS commit: src/external/mpl/bind

2019-11-26 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Wed Nov 27 05:48:43 UTC 2019

Modified Files:
src/external/mpl/bind: bind2netbsd
src/external/mpl/bind/dist: configure
src/external/mpl/bind/dist/bin/check: check-tool.c
src/external/mpl/bind/dist/bin/delv: delv.c
src/external/mpl/bind/dist/bin/dig: dighost.c host.c nslookup.c
src/external/mpl/bind/dist/bin/dnssec: dnssec-dsfromkey.c
dnssec-importkey.c dnssec-signzone.c
src/external/mpl/bind/dist/bin/named: config.c main.c server.c
statschannel.c zoneconf.c
src/external/mpl/bind/dist/bin/named/include/named: globals.h
src/external/mpl/bind/dist/bin/named/win32: os.c
src/external/mpl/bind/dist/bin/nsupdate: nsupdate.c
src/external/mpl/bind/dist/bin/tests/optional: zone_test.c
src/external/mpl/bind/dist/bin/tests/system/dlzexternal: driver.c
src/external/mpl/bind/dist/bin/tests/system/dyndb/driver: syncptr.c
src/external/mpl/bind/dist/doc/arm: Bv9ARM.pdf
src/external/mpl/bind/dist/lib/bind9: check.c
src/external/mpl/bind/dist/lib/dns: acl.c adb.c client.c dnsrps.c
ecdb.c geoip2.c gssapi_link.c journal.c lookup.c masterdump.c
message.c name.c nsec3.c nta.c openssldh_link.c opensslrsa_link.c
order.c rbt.c rbtdb.c rcode.c rdata.c rdatalist.c rdataset.c
resolver.c rrl.c sdb.c sdlz.c spnego_asn1.c tkey.c tsig.c ttl.c
update.c validator.c view.c zone.c zoneverify.c
src/external/mpl/bind/dist/lib/dns/include/dns: acl.h name.h tsig.h
src/external/mpl/bind/dist/lib/dns/rdata/any_255: tsig_250.c
src/external/mpl/bind/dist/lib/dns/rdata/ch_3: a_1.c
src/external/mpl/bind/dist/lib/dns/rdata/generic: afsdb_18.c avc_258.c
caa_257.c cds_59.c cert_37.c cname_5.c csync_62.c dlv_32769.c
dname_39.c doa_259.c ds_43.c eui48_108.c eui64_109.c gpos_27.c
hinfo_13.c hip_55.c ipseckey_45.c isdn_20.c key_25.c
keydata_65533.c l32_105.c l64_106.c loc_29.c lp_107.c mb_7.c md_3.c
mf_4.c mg_8.c minfo_14.c mr_9.c mx_15.c naptr_35.c nid_104.c
ninfo_56.c ns_2.c nsec3_50.c nsec3param_51.c nsec_47.c null_10.c
nxt_30.c openpgpkey_61.c opt_41.c proforma.c ptr_12.c rp_17.c
rrsig_46.c rt_21.c sig_24.c sink_40.c smimea_53.c soa_6.c spf_99.c
sshfp_44.c ta_32768.c talink_58.c tkey_249.c tlsa_52.c txt_16.c
uri_256.c x25_19.c
src/external/mpl/bind/dist/lib/dns/rdata/hs_4: a_1.c
src/external/mpl/bind/dist/lib/dns/rdata/in_1: a6_38.c a_1.c _28.c
apl_42.c atma_34.c dhcid_49.c eid_31.c kx_36.c nimloc_32.c
nsap-ptr_23.c nsap_22.c px_26.c srv_33.c wks_11.c
src/external/mpl/bind/dist/lib/dns/tests: dnstap_test.c dnstest.c
master_test.c rbt_serialize_test.c
src/external/mpl/bind/dist/lib/isc: buffer.c pk11.c result.c sockaddr.c
stats.c task.c
src/external/mpl/bind/dist/lib/isc/include/isc: result.h stats.h
types.h util.h
src/external/mpl/bind/dist/lib/isc/tests: hmac_test.c ht_test.c
md_test.c mem_test.c random_test.c
src/external/mpl/bind/dist/lib/isc/unix: meminfo.c net.c resource.c
socket.c
src/external/mpl/bind/dist/lib/isc/win32: app.c socket.c
src/external/mpl/bind/dist/lib/isccfg: aclconf.c parser.c
src/external/mpl/bind/dist/lib/ns: client.c interfacemgr.c query.c
stats.c update.c
src/external/mpl/bind/dist/lib/ns/include/ns: client.h stats.h
src/external/mpl/bind/dist/lib/samples: nsprobe.c
src/external/mpl/bind/include: config.h
Removed Files:
src/external/mpl/bind/dist/bin/tests/system/checkzone/zones:
.gitattributes
src/external/mpl/bind/dist/doc/arm: notes-bug-fixes.xml
notes-new-features.xml notes-sec-fixes.xml

Log Message:
merge bind 9.14.8


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/external/mpl/bind/bind2netbsd
cvs rdiff -u -r1.7 -r1.8 src/external/mpl/bind/dist/configure
cvs rdiff -u -r1.3 -r1.4 src/external/mpl/bind/dist/bin/check/check-tool.c
cvs rdiff -u -r1.4 -r1.5 src/external/mpl/bind/dist/bin/delv/delv.c
cvs rdiff -u -r1.6 -r1.7 src/external/mpl/bind/dist/bin/dig/dighost.c
cvs rdiff -u -r1.3 -r1.4 src/external/mpl/bind/dist/bin/dig/host.c
cvs rdiff -u -r1.4 -r1.5 src/external/mpl/bind/dist/bin/dig/nslookup.c
cvs rdiff -u -r1.6 -r1.7 \
src/external/mpl/bind/dist/bin/dnssec/dnssec-dsfromkey.c
cvs rdiff -u -r1.3 -r1.4 \
src/external/mpl/bind/dist/bin/dnssec/dnssec-importkey.c \
src/external/mpl/bind/dist/bin/dnssec/dnssec-signzone.c
cvs rdiff -u -r1.6 -r1.7 src/external/mpl/bind/dist/bin/named/config.c \
src/external/mpl/bind/dist/bin/named/main.c
cvs rdiff -u -r1.8 -r1.9 src/external/mpl/bind/dist/bin/named/server.c
cvs rdiff -u -r1.5 -r1.6 

CVS commit: src/external/gpl3/gdb/lib

2019-11-22 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Fri Nov 22 14:57:02 UTC 2019

Modified Files:
src/external/gpl3/gdb/lib/libbfd/arch/x86_64: bfd_stdint.h targmatch.h
src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64: gstdint.h

Log Message:
more regen stuff.


To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 \
src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h
cvs rdiff -u -r1.10 -r1.11 \
src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h
cvs rdiff -u -r1.9 -r1.10 \
src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/external/gpl3/gdb/lib

2019-11-22 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Fri Nov 22 14:57:02 UTC 2019

Modified Files:
src/external/gpl3/gdb/lib/libbfd/arch/x86_64: bfd_stdint.h targmatch.h
src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64: gstdint.h

Log Message:
more regen stuff.


To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 \
src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h
cvs rdiff -u -r1.10 -r1.11 \
src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h
cvs rdiff -u -r1.9 -r1.10 \
src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h
diff -u src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h:1.9 src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h:1.10
--- src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h:1.9	Tue May 28 21:56:33 2019
+++ src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h	Fri Nov 22 09:57:01 2019
@@ -1,8 +1,8 @@
 /* This file is automatically generated.  DO NOT EDIT! */
-/* Generated from: NetBSD: mknative-gdb,v 1.7 2016/10/16 04:37:42 mrg Exp  */
+/* Generated from: NetBSD: mknative-gdb,v 1.8 2019/05/29 01:56:06 christos Exp  */
 /* Generated from: NetBSD: mknative.common,v 1.16 2018/04/15 15:13:37 christos Exp  */
 
-/* generated for  x86_64--netbsd-gcc (NetBSD nb3 20190319) 7.4.0 */
+/* generated for  x86_64--netbsd-gcc (NetBSD nb1 20190930) 8.3.0 */
 
 #ifndef GCC_GENERATED_STDINT_H
 #define GCC_GENERATED_STDINT_H 1

Index: src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h
diff -u src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h:1.10 src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h:1.11
--- src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h:1.10	Tue May 28 21:56:33 2019
+++ src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h	Fri Nov 22 09:57:01 2019
@@ -1,5 +1,5 @@
 /* This file is automatically generated.  DO NOT EDIT! */
-/* Generated from: NetBSD: mknative-gdb,v 1.7 2016/10/16 04:37:42 mrg Exp  */
+/* Generated from: NetBSD: mknative-gdb,v 1.8 2019/05/29 01:56:06 christos Exp  */
 /* Generated from: NetBSD: mknative.common,v 1.16 2018/04/15 15:13:37 christos Exp  */
 
 #ifdef BFD64
@@ -1193,6 +1193,22 @@
 
 
 #ifdef BFD64
+#if !defined (SELECT_VECS) || defined (HAVE_mips_elf32_ntrad_le_vec)
+
+{ "mips64*el-*-netbsd*",
+_elf32_ntrad_le_vec },
+#endif
+
+
+
+#if !defined (SELECT_VECS) || defined (HAVE_mips_elf32_ntrad_be_vec)
+
+{ "mips64*-*-netbsd*",
+_elf32_ntrad_be_vec },
+#endif
+
+
+
 #if !defined (SELECT_VECS) || defined (HAVE_mips_elf32_trad_le_vec)
 
 { "mips*el-*-netbsd*",

Index: src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h
diff -u src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h:1.9 src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h:1.10
--- src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h:1.9	Tue May 28 21:56:33 2019
+++ src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h	Fri Nov 22 09:57:01 2019
@@ -1,8 +1,8 @@
 /* This file is automatically generated.  DO NOT EDIT! */
-/* Generated from: NetBSD: mknative-gdb,v 1.7 2016/10/16 04:37:42 mrg Exp  */
+/* Generated from: NetBSD: mknative-gdb,v 1.8 2019/05/29 01:56:06 christos Exp  */
 /* Generated from: NetBSD: mknative.common,v 1.16 2018/04/15 15:13:37 christos Exp  */
 
-/* generated for  x86_64--netbsd-gcc (NetBSD nb3 20190319) 7.4.0 */
+/* generated for  x86_64--netbsd-gcc (NetBSD nb1 20190930) 8.3.0 */
 
 #ifndef GCC_GENERATED_STDINT_H
 #define GCC_GENERATED_STDINT_H 1



Re: CVS commit: src/external/gpl3/gdb/lib/libgdb/arch/x86_64

2019-11-21 Thread Christos Zoulas
1. It does now (my commit to configure.tgt)
2. ah, ok, thanks. Perhaps they should not.

christos

> On Nov 21, 2019, at 9:49 PM, Kamil Rytarowski  wrote:
> 
> 
> 
> On 22.11.2019 03:40, Christos Zoulas wrote:
>> And why copy the structs? Doesn't #include  work?
>> 
> 
> http://mail-index.netbsd.org/tech-toolchain/2019/06/22/msg003508.html 
> <http://mail-index.netbsd.org/tech-toolchain/2019/06/22/msg003508.html>
> 
> 
> 1. mknative does not include i386 files for x86_64 mode
>   _initialize_i386nbsd_tdep() and associated i386 GDB files are not
> includes in the build
> 
> 2. i386 C files are not buildable for amd64 environment as they pull
> headers from machine/ and that is amd64/, not i386/. If we manually
> include i386/ headers, they still pick machine/ files.
> 
>Including these files on amd64/ certainly never worked. And passing
> types like void* cannot work as-is anyway.
> 
>> christos
>> 
>>> On Nov 21, 2019, at 9:37 PM, Christos Zoulas >> <mailto:chris...@zoulas.com>> wrote:
>>> 
>>> That's for kernel debugging?
>>> 
> 
> I still have not been touching kgdb. It was for building the i386 file
> on amd64 host only.
> 
>>> christos
>>> 
>>>> On Nov 21, 2019, at 9:35 PM, Kamil Rytarowski  wrote:
>>>> 
>>>> On 22.11.2019 02:52, Christos Zoulas wrote:
>>>>> Module Name:  src
>>>>> Committed By: christos
>>>>> Date: Fri Nov 22 01:52:20 UTC 2019
>>>>> 
>>>>> Modified Files:
>>>>>   src/external/gpl3/gdb/lib/libgdb/arch/x86_64: config.h defs.mk init.c
>>>>> 
>>>>> Log Message:
>>>>> regen x86_64 for i386 support
>>>>> 
>>>> 
>>>> For the reference, here is a patch that I shared few months back:
>>>> 
>>>> http://netbsd.org/~kamil/patch-00130-32bit-tracee-64bit-gdb.txt
>>>> 
>>>> 
>> 
> 
> 
> 



Re: CVS commit: src/external/gpl3/gdb/lib/libgdb/arch/x86_64

2019-11-21 Thread Christos Zoulas
And why copy the structs? Doesn't #include  work?

christos

> On Nov 21, 2019, at 9:37 PM, Christos Zoulas  wrote:
> 
> That's for kernel debugging?
> 
> christos
> 
>> On Nov 21, 2019, at 9:35 PM, Kamil Rytarowski  wrote:
>> 
>> On 22.11.2019 02:52, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By:   christos
>>> Date:   Fri Nov 22 01:52:20 UTC 2019
>>> 
>>> Modified Files:
>>> src/external/gpl3/gdb/lib/libgdb/arch/x86_64: config.h defs.mk init.c
>>> 
>>> Log Message:
>>> regen x86_64 for i386 support
>>> 
>> 
>> For the reference, here is a patch that I shared few months back:
>> 
>> http://netbsd.org/~kamil/patch-00130-32bit-tracee-64bit-gdb.txt
>> 
>> 



  1   2   3   4   5   6   7   8   9   10   >