Re: svn commit: r367433 - in head/sys: compat/linux conf

2020-11-15 Thread Tijl Coosemans
On Fri, 6 Nov 2020 22:04:57 + (UTC) Conrad Meyer 
wrote:
> Author: cem
> Date: Fri Nov  6 22:04:57 2020
> New Revision: 367433
> URL: https://svnweb.freebsd.org/changeset/base/367433
> 
> Log:
>   linux(4): Fix loadable modules after r367395
>   
>   Move dtrace SDT definitions into linux_common module code.  Also, build
>   linux_dummy.c into the linux_common kld -- we don't need separate
>   versions of these stubs for 32- and 64-bit emulation.
>   
>   Reported by:several
>   PR: 250897
>   Discussed with: emaste, trasz
>   Tested by:  John Kennedy, Yasuhiro KIMURA, Oleg Sidorkin
>   X-MFC-With: r367395
>   Differential Revision:  https://reviews.freebsd.org/D27124
> 
> Modified:
>   head/sys/compat/linux/linux_common.c
>   head/sys/compat/linux/linux_dummy.c
>   head/sys/compat/linux/linux_misc.c
>   head/sys/conf/files.i386
> 
> Modified: head/sys/compat/linux/linux_common.c
> ==
> --- head/sys/compat/linux/linux_common.c  Fri Nov  6 21:33:59 2020
> (r367432)
> +++ head/sys/compat/linux/linux_common.c  Fri Nov  6 22:04:57 2020
> (r367433)
> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -48,6 +49,20 @@ FEATURE(linuxulator_v4l, "V4L ioctl wrapper support in
>  FEATURE(linuxulator_v4l2, "V4L2 ioctl wrapper support in the linuxulator");
>  
>  MODULE_VERSION(linux_common, 1);
> +
> +/**
> + * Special DTrace provider for the linuxulator.
> + *
> + * In this file we define the provider for the entire linuxulator. All
> + * modules (= files of the linuxulator) use it.
> + *
> + * We define a different name depending on the emulated bitsize, see
> + * ../..//linux{,32}/linux.h, e.g.:
> + *  native bitsize  = linuxulator
> + *  amd64, 32bit emulation  = linuxulator32
> + */
> +LIN_SDT_PROVIDER_DEFINE(linuxulator);
> +LIN_SDT_PROVIDER_DEFINE(linuxulator32);
>  
>  SET_DECLARE(linux_device_handler_set, struct linux_device_handler);
>  
> 
> Modified: head/sys/compat/linux/linux_dummy.c
> ==
> --- head/sys/compat/linux/linux_dummy.c   Fri Nov  6 21:33:59 2020
> (r367432)
> +++ head/sys/compat/linux/linux_dummy.c   Fri Nov  6 22:04:57 2020
> (r367433)
> @@ -29,21 +29,19 @@
>  #include 
>  __FBSDID("$FreeBSD$");
>  
> -#include "opt_compat.h"
> -
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> -#ifdef COMPAT_LINUX32
> -#include 
> -#include 
> -#else
> +/*
> + * Including linux vs linux32 here is arbitrary -- the syscall args 
> structures
> + * (proto.h) are not dereferenced by the DUMMY stub implementations, and
> + * suitable for use by both native and compat32 entrypoints.
> + */
>  #include 
>  #include 
> -#endif
>  
>  #include 
>  #include 
> 
> Modified: head/sys/compat/linux/linux_misc.c
> ==
> --- head/sys/compat/linux/linux_misc.cFri Nov  6 21:33:59 2020
> (r367432)
> +++ head/sys/compat/linux/linux_misc.cFri Nov  6 22:04:57 2020
> (r367433)
> @@ -99,19 +99,6 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  
> -/**
> - * Special DTrace provider for the linuxulator.
> - *
> - * In this file we define the provider for the entire linuxulator. All
> - * modules (= files of the linuxulator) use it.
> - *
> - * We define a different name depending on the emulated bitsize, see
> - * ../..//linux{,32}/linux.h, e.g.:
> - *  native bitsize  = linuxulator
> - *  amd64, 32bit emulation  = linuxulator32
> - */
> -LIN_SDT_PROVIDER_DEFINE(LINUX_DTRACE);
> -
>  int stclohz; /* Statistics clock frequency */
>  
>  static unsigned int linux_to_bsd_resource[LINUX_RLIM_NLIMITS] = {
> 
> Modified: head/sys/conf/files.i386
> ==
> --- head/sys/conf/files.i386  Fri Nov  6 21:33:59 2020(r367432)
> +++ head/sys/conf/files.i386  Fri Nov  6 22:04:57 2020(r367433)
> @@ -52,6 +52,7 @@ cddl/dev/dtrace/i386/dtrace_asm.S   
> optional dtrace co
>  cddl/dev/dtrace/i386/dtrace_subr.c   optional dtrace 
> compile-with "${DTRACE_C}"
>  compat/linprocfs/linprocfs.c optional linprocfs
>  compat/linsysfs/linsysfs.c   optional linsysfs
> +compat/linux/linux_common.c  optional compat_linux
>  compat/linux/linux_dummy.c   optional compat_linux
>  compat/linux/linux_event.c   optional compat_linux
>  compat/linux/linux_emul.coptional compat_linux

linux_common.c defines the linux_common module which contains stuff that
is common between 64 bit and 32 bit linux on amd64, but there's no such
module on i386, which is why the file wasn't in files.i386.  You should
put LIN_SDT_PROVIDER_DEFINE in a file that is in 

Re: svn commit: r363657 - head/crypto/openssh

2020-07-29 Thread Tijl Coosemans
On Wed, 29 Jul 2020 00:34:24 + (UTC) Ed Maste 
wrote:
> Author: emaste
> Date: Wed Jul 29 00:34:24 2020
> New Revision: 363657
> URL: https://svnweb.freebsd.org/changeset/base/363657
> 
> Log:
>   sshd: allow UseBlocklist alias for UseBlacklist
>   
>   blacklistd has been renamed to blocklistd upstream, and a future
>   import into FreeBSD will follow that change.  Support the new name
>   as an alias in config files.
>   
>   Reviewed by:bz, delphij
>   MFC after:  1 week
>   Sponsored by:   The FreeBSD Foundation
>   Differential Revision:  https://reviews.freebsd.org/D25865
> 
> Modified:
>   head/crypto/openssh/servconf.c
>   head/crypto/openssh/sshd_config.5
> 
> Modified: head/crypto/openssh/servconf.c
> ==
> --- head/crypto/openssh/servconf.cTue Jul 28 22:32:50 2020
> (r363656)
> +++ head/crypto/openssh/servconf.cWed Jul 29 00:34:24 2020
> (r363657)
> @@ -660,6 +660,7 @@ static struct {
>   { "rdomain", sRDomain, SSHCFG_ALL },
>   { "casignaturealgorithms", sCASignatureAlgorithms, SSHCFG_ALL },
>   { "useblacklist", sUseBlacklist, SSHCFG_GLOBAL },
> + { "useblocklist", sUseBlacklist, SSHCFG_GLOBAL }, /* alias */
>   { "noneenabled", sUnsupported, SSHCFG_ALL },
>   { "hpndisabled", sDeprecated, SSHCFG_ALL },
>   { "hpnbuffersize", sDeprecated, SSHCFG_ALL },
> 
> Modified: head/crypto/openssh/sshd_config.5
> ==
> --- head/crypto/openssh/sshd_config.5 Tue Jul 28 22:32:50 2020
> (r363656)
> +++ head/crypto/openssh/sshd_config.5 Wed Jul 29 00:34:24 2020
> (r363657)
> @@ -35,7 +35,7 @@
>  .\"
>  .\" $OpenBSD: sshd_config.5,v 1.282 2018/09/20 03:28:06 djm Exp $
>  .\" $FreeBSD$
> -.Dd $Mdocdate: September 20 2018 $
> +.Dd $Mdocdate: July 28 2020 $
>  .Dt SSHD_CONFIG 5
>  .Os
>  .Sh NAME
> @@ -1602,6 +1602,11 @@ to the
>  daemon.
>  The default is
>  .Cm no .
> +For forward compatibility with an upcoming
> +.Xr blacklistd
> +rename, the
> +.Cm UseBlocklist

I realise this is very pedantic, but my spell checker says it's
"block list", two words, so if you're using camel case it should
be UseBlockList.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r360964 - in head: lib/libclang_rt lib/libthr lib/msun libexec/rtld-elf libexec/tftpd/tests share/mk stand stand/arm/uboot stand/efi stand/efi/boot1 stand/efi/loader stand/i386/boot2 s

2020-05-25 Thread Tijl Coosemans
On Tue, 12 May 2020 15:22:41 + (UTC) Eric van Gyzen
 wrote:
> Author: vangyzen
> Date: Tue May 12 15:22:40 2020
> New Revision: 360964
> URL: https://svnweb.freebsd.org/changeset/base/360964
> 
> Log:
>   Remove tests for obsolete compilers in the build system
>   
>   Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
>   Assume clang is at least 6, which was in 11.2-RELEASE.  Drop conditions
>   for older compilers.
>   
>   Reviewed by:imp (earlier version), emaste, jhb
>   MFC after:  2 weeks
>   Sponsored by:   Dell EMC Isilon
>   Differential Revision:  https://reviews.freebsd.org/D24802

This broke devel/linux_libusb.  It is FreeBSD libusb built with Linux
gcc 4.8.5 (devel/linux-c7-devtools).  It's probably caused by the
changes to share/mk/*.

http://beefy18.nyi.freebsd.org/data/head-amd64-default/p536258_s361404/logs/linux_libusb-13.0r358841.log
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r358483 - head/sys/compat/linux

2020-03-05 Thread Tijl Coosemans
On Thu, 5 Mar 2020 16:15:10 +0300 Yuri Pankov 
wrote:
> Tijl Coosemans wrote:
>> Author: tijl
>> Date: Sun Mar  1 13:12:04 2020
>> New Revision: 358483
>> URL: https://svnweb.freebsd.org/changeset/base/358483
>> 
>> Log:
>>linuxulator: Map scheduler priorities to Linux priorities.
>>
>>On Linux the valid range of priorities for the SCHED_FIFO and SCHED_RR
>>scheduling policies is [1,99].  For SCHED_OTHER the single valid priority 
>> is
>>0.  On FreeBSD it is [0,31] for all policies.  Programs are supposed to
>>query the valid range using sched_get_priority_(min|max), but of course 
>> some
>>programs assume the Linux values are valid.
>>
>>This commit adds a tunable compat.linux.map_sched_prio.  When enabled
>>sched_get_priority_(min|max) return the Linux values and 
>> sched_setscheduler
>>and sched_(get|set)param translate between FreeBSD and Linux values.
>>
>>Because there are more Linux levels than FreeBSD levels, multiple Linux
>>levels map to a single FreeBSD level, which means pre-emption might not
>>happen as it does on Linux, so the tunable allows to disable this 
>> behaviour.
>>It is enabled by default because I think it is unlikely that anyone runs
>>real-time software under Linux emulation on FreeBSD that critically relies
>>on correct pre-emption.
>>
>>This fixes FMOD, a commercial sound library used by several games.
>>
>>PR:   240043
>>Tested by:Alex S 
>>Reviewed by:  dchagin
>>MFC after:2 weeks
>>Differential Revision:https://reviews.freebsd.org/D23790
>> 
>> Modified:
>>head/sys/compat/linux/linux_misc.c
>>head/sys/compat/linux/linux_misc.h
>> 
>> Modified: head/sys/compat/linux/linux_misc.c
>> ==
>> --- head/sys/compat/linux/linux_misc.c   Sun Mar  1 12:34:27 2020
>> (r358482)
>> +++ head/sys/compat/linux/linux_misc.c   Sun Mar  1 13:12:04 2020
>> (r358483)
>> @@ -144,6 +144,11 @@ struct l_pselect6arg {
>>  l_size_tss_len;
>>   };
>>   
>> +static bool map_sched_prio = true;
>> +SYSCTL_BOOL(_compat_linux, OID_AUTO, map_sched_prio, CTLFLAG_RDTUN,
>> +_sched_prio, 0, "Map scheduler priorities to Linux priorities "
>> +"(not POSIX compliant)");  
> 
> I'm seeing the following in the log:
> 
> sysctl_warn_reuse: can't re-use a leaf (compat.linux.map_sched_prio)!
> 
> Should this be done for both linux and linux32 (when one exists) or made 
> to install one time only?

Ah, thanks for the report, I've moved it to linux_common in r358673.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r358164 - in head: . lib/ncurses/ncurses

2020-02-20 Thread Tijl Coosemans
On Thu, 20 Feb 2020 09:12:07 + (UTC) Baptiste Daroussin
 wrote:
> Author: bapt
> Date: Thu Feb 20 09:12:07 2020
> New Revision: 358164
> URL: https://svnweb.freebsd.org/changeset/base/358164
> 
> Log:
>   ncurses: bump shlib number to version 9
>   
>   ABI has change in between ncurses 5 or 6. While theorically ncurses 6 is 
> buildable with
>   backward compatibility, I fail at building in a way where the application 
> linked against
>   the previous version of ncurses are rendering properly.
>   Let's go on the new ABI which provides all the latest features.
>   
>   A compat12x package is cooking for backward compatibility
> 
> Modified:
>   head/ObsoleteFiles.inc
>   head/lib/ncurses/ncurses/Makefile
> 
> Modified: head/ObsoleteFiles.inc
> ==
> --- head/ObsoleteFiles.incThu Feb 20 09:02:59 2020(r358163)
> +++ head/ObsoleteFiles.incThu Feb 20 09:12:07 2020(r358164)
> @@ -36,6 +36,12 @@
>  #   xargs -n1 | sort | uniq -d;
>  # done
>  
> +# 20200220: Upgrade of ncurses, shlib bumped to version 9
> +OLD_FILES+=lib/libncurses.so.8
> +OLD_FILES+=lib/libncursesw.so.8
> +OLD_FILES+=usr/lib32/libncurses.so.8
> +OLD_FILES+=usr/lib32/libncursesw.so.8

This should be OLD_LIBS instead of OLD_FILES.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r355978 - head/usr.bin/top

2020-01-15 Thread Tijl Coosemans
On Sat, 21 Dec 2019 05:03:21 + (UTC) Philip Paeps
 wrote:
> Author: philip
> Date: Sat Dec 21 05:03:21 2019
> New Revision: 355978
> URL: https://svnweb.freebsd.org/changeset/base/355978
> 
> Log:
>   top: display battery capacity remaining
>   
>   Submitted by: Antranig Vartanian 
>   Reviewed by:  imp, philip
>   Differential Revision:https://reviews.freebsd.org/D22871
> 
> Modified:
>   head/usr.bin/top/display.c
>   head/usr.bin/top/display.h
>   head/usr.bin/top/machine.c
>   head/usr.bin/top/machine.h
>   head/usr.bin/top/top.c
> 
> Modified: head/usr.bin/top/display.c
> ==
> --- head/usr.bin/top/display.cSat Dec 21 04:44:17 2019
> (r355977)
> +++ head/usr.bin/top/display.cSat Dec 21 05:03:21 2019
> (r355978)
> @@ -1322,6 +1322,15 @@ i_uptime(struct timeval *bt, time_t *tod)
>  }
>  }
>  
> +void
> +i_battery(int nbat, int batt)
> +{
> +
> + if (nbat > 0) {
> + printf("; battery: %d%%", batt);

It doesn't fit.  There's only room for "; b":

last pid: 33047;  load averages:  1.17,  1.25,  1.34; b up 3+07:35:37  19:08:41
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r351253 - in head/contrib/libc++: include src

2019-08-21 Thread Tijl Coosemans
On Wed, 21 Aug 2019 18:52:31 +0300 Konstantin Belousov
 wrote:
> On Wed, Aug 21, 2019 at 02:49:08PM +0200, Tijl Coosemans wrote:
>> On Tue, 20 Aug 2019 17:39:33 + (UTC) Dimitry Andric
>>  wrote:  
>>> Author: dim
>>> Date: Tue Aug 20 17:39:32 2019
>>> New Revision: 351253
>>> URL: https://svnweb.freebsd.org/changeset/base/351253
>>> 
>>> Log:
>>>   Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
>>>   
>>> Rework recursive_timed_mutex so that it uses __thread_id instead of
>>> using the lower-level __libcpp_thread_id. This is prep for fixing
>>> PR42918. Reviewed as https://reviews.llvm.org/D65895
>>>   
>>>   Pull in r368916 from upstream libc++ trunk (by Marshall Clow):
>>>   
>>> Fix thread comparison by making sure we never pass our special 'not a
>>> thread' value to the underlying implementation. Fixes PR#42918.
>>>   
>>>   This should fix std::thread::id::operator==() attempting to call
>>>   pthread_equal(3) with zero values.
>>>   
>>>   Reported by:  and...@tao11.riddles.org.uk
>>>   PR:   239038, 239550
>>>   MFC after:3 days
>>> 
>>> Modified:
>>>   head/contrib/libc++/include/__threading_support
>>>   head/contrib/libc++/include/mutex
>>>   head/contrib/libc++/include/thread
>>>   head/contrib/libc++/src/mutex.cpp
>>> 
>>> Modified: head/contrib/libc++/include/__threading_support
>>> ==
>>> --- head/contrib/libc++/include/__threading_support Tue Aug 20 17:00:31 
>>> 2019(r351252)
>>> +++ head/contrib/libc++/include/__threading_support Tue Aug 20 17:39:32 
>>> 2019(r351253)
>>> @@ -13,6 +13,7 @@
>>>  
>>>  #include <__config>
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  #ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
>>> @@ -392,6 +393,86 @@ int __libcpp_tls_set(__libcpp_tls_key __key, void *__p
>>>  }
>>>  
>>>  #endif // !_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL || 
>>> _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
>>> +
>>> +class _LIBCPP_TYPE_VIS thread;  
>> 
>> This seems to break building Firefox:
>> 
>> In file included from 
>> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/nricectx.cpp:82:
>> In file included from 
>> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.h:41:
>> In file included from 
>> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun.h:45:
>> In file included from /usr/include/net/if_var.h:84:
>> /usr/include/sys/lock.h:68:15: error: reference to 'thread' is ambiguous
>> struct thread **owner);
>>^
>> /usr/include/sys/lock.h:42:8: note: candidate found by name lookup is 
>> 'thread'
>> struct thread;
>>^
>> /usr/include/c++/v1/__threading_support:397:24: note: candidate found by name
>>   lookup is 'std::__1::thread'
>> class _LIBCPP_TYPE_VIS thread;
>>^
>> 
>> 
>> This "class thread" conflicts with "struct thread" in sys/lock.h.
>> Should everything in sys/lock.h be under #ifdef _KERNEL?  
> Why does firefox pulls if_var.h at all ?  (As I understand, this is how
> the pollution occurs.)

Right, it turns out it doesn't need it:

--- media/mtransport/third_party/nICEr/src/stun/stun.h.orig 2019-08-13 
18:06:44 UTC
+++ media/mtransport/third_party/nICEr/src/stun/stun.h
@@ -41,7 +41,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O
 #include 
 #ifndef LINUX
 #include 
-#if !defined(__OpenBSD__) && !defined(__NetBSD__)
+#if !defined(__OpenBSD__) && !defined(__NetBSD__) && !defined(__FreeBSD__)
 #include 
 #endif
 #include 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r351253 - in head/contrib/libc++: include src

2019-08-21 Thread Tijl Coosemans
On Wed, 21 Aug 2019 15:07:56 +0200 Dimitry Andric 
wrote:
> On 21 Aug 2019, at 14:49, Tijl Coosemans  wrote:
>> On Tue, 20 Aug 2019 17:39:33 + (UTC) Dimitry Andric
>>  wrote:  
>>> Author: dim
>>> Date: Tue Aug 20 17:39:32 2019
>>> New Revision: 351253
>>> URL: https://svnweb.freebsd.org/changeset/base/351253
>>> 
>>> Log:
>>>  Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
>>> 
>>>Rework recursive_timed_mutex so that it uses __thread_id instead of
>>>using the lower-level __libcpp_thread_id. This is prep for fixing
>>>PR42918. Reviewed as https://reviews.llvm.org/D65895
>>> 
>>>  Pull in r368916 from upstream libc++ trunk (by Marshall Clow):
>>> 
>>>Fix thread comparison by making sure we never pass our special 'not a
>>>thread' value to the underlying implementation. Fixes PR#42918.
>>> 
>>>  This should fix std::thread::id::operator==() attempting to call
>>>  pthread_equal(3) with zero values.  
> ...
>> This seems to break building Firefox:
>> 
>> In file included from 
>> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/nricectx.cpp:82:
>> In file included from 
>> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.h:41:
>> In file included from 
>> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun.h:45:
>> In file included from /usr/include/net/if_var.h:84:
>> /usr/include/sys/lock.h:68:15: error: reference to 'thread' is ambiguous
>>struct thread **owner);
>>   ^
>> /usr/include/sys/lock.h:42:8: note: candidate found by name lookup is 
>> 'thread'
>> struct thread;
>>   ^
>> /usr/include/c++/v1/__threading_support:397:24: note: candidate found by name
>>  lookup is 'std::__1::thread'
>> class _LIBCPP_TYPE_VIS thread;
>>   ^
>> 
>> This "class thread" conflicts with "struct thread" in sys/lock.h.
>> Should everything in sys/lock.h be under #ifdef _KERNEL?  
> 
> Maybe, but is Firefox using "using namespace std;" here?  It is a likely
> explanation for the ambiguity between the global struct thread from
> sys/lock.h, and std::thread from libc++.

Yes, several headers in media/mtransport/third_party/nICEr/src start
with:

#ifdef __cplusplus
using namespace std;
extern "C" {
#endif /* __cplusplus */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r351253 - in head/contrib/libc++: include src

2019-08-21 Thread Tijl Coosemans
On Tue, 20 Aug 2019 17:39:33 + (UTC) Dimitry Andric
 wrote:
> Author: dim
> Date: Tue Aug 20 17:39:32 2019
> New Revision: 351253
> URL: https://svnweb.freebsd.org/changeset/base/351253
> 
> Log:
>   Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
>   
> Rework recursive_timed_mutex so that it uses __thread_id instead of
> using the lower-level __libcpp_thread_id. This is prep for fixing
> PR42918. Reviewed as https://reviews.llvm.org/D65895
>   
>   Pull in r368916 from upstream libc++ trunk (by Marshall Clow):
>   
> Fix thread comparison by making sure we never pass our special 'not a
> thread' value to the underlying implementation. Fixes PR#42918.
>   
>   This should fix std::thread::id::operator==() attempting to call
>   pthread_equal(3) with zero values.
>   
>   Reported by:and...@tao11.riddles.org.uk
>   PR: 239038, 239550
>   MFC after:  3 days
> 
> Modified:
>   head/contrib/libc++/include/__threading_support
>   head/contrib/libc++/include/mutex
>   head/contrib/libc++/include/thread
>   head/contrib/libc++/src/mutex.cpp
> 
> Modified: head/contrib/libc++/include/__threading_support
> ==
> --- head/contrib/libc++/include/__threading_support   Tue Aug 20 17:00:31 
> 2019(r351252)
> +++ head/contrib/libc++/include/__threading_support   Tue Aug 20 17:39:32 
> 2019(r351253)
> @@ -13,6 +13,7 @@
>  
>  #include <__config>
>  #include 
> +#include 
>  #include 
>  
>  #ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
> @@ -392,6 +393,86 @@ int __libcpp_tls_set(__libcpp_tls_key __key, void *__p
>  }
>  
>  #endif // !_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL || 
> _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
> +
> +class _LIBCPP_TYPE_VIS thread;

This seems to break building Firefox:

In file included from 
/home/root/obj/ports/home/tijl/projects/freebsd/ports/head/www/firefox/work/firefox-68.0.2/media/mtransport/nricectx.cpp:82:
In file included from 
/home/root/obj/ports/home/tijl/projects/freebsd/ports/head/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.h:41:
In file included from 
/home/root/obj/ports/home/tijl/projects/freebsd/ports/head/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun.h:45:
In file included from /usr/include/net/if_var.h:84:
/usr/include/sys/lock.h:68:15: error: reference to 'thread' is ambiguous
struct thread **owner);
   ^
/usr/include/sys/lock.h:42:8: note: candidate found by name lookup is 'thread'
struct thread;
   ^
/usr/include/c++/v1/__threading_support:397:24: note: candidate found by name
  lookup is 'std::__1::thread'
class _LIBCPP_TYPE_VIS thread;
   ^


This "class thread" conflicts with "struct thread" in sys/lock.h.
Should everything in sys/lock.h be under #ifdef _KERNEL?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r349641 - head/tools/build/mk

2019-07-03 Thread Tijl Coosemans
On Wed, 3 Jul 2019 09:14:48 -0700 John Baldwin  wrote:
> On 7/3/19 2:14 AM, Tijl Coosemans wrote:
>> Author: tijl
>> Date: Wed Jul  3 09:14:39 2019
>> New Revision: 349641
>> URL: https://svnweb.freebsd.org/changeset/base/349641
>> 
>> Log:
>>   Also remove lib32 versions of libradius.
>>   
>>   MFC after: 1 week  
> 
> I do wonder if we shouldn't try to make OLD_LIBS a bit
> smarter by having it expand to also include the lib32
> (and libsoft) variants.  Having some kind of helper
> to deal with the non-dynamic libs would also be nice
> (it would remove libfoo.a, libfoo_p.a, and libfoo.so
> which always live in /usr/lib, /usr/lib32, and /usr/libsoft).

I hope this file just goes away with base packages.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r349640 - head

2019-07-03 Thread Tijl Coosemans
On Wed, 3 Jul 2019 09:11:53 -0700 John Baldwin  wrote:
> On 7/3/19 2:08 AM, Tijl Coosemans wrote:
>> Author: tijl
>> Date: Wed Jul  3 09:08:17 2019
>> New Revision: 349640
>> URL: https://svnweb.freebsd.org/changeset/base/349640
>> 
>> Log:
>>   Also remove lib32 version of libcasper.so.0.
>> 
>> Modified:
>>   head/ObsoleteFiles.inc
>> 
>> Modified: head/ObsoleteFiles.inc
>> ==
>> --- head/ObsoleteFiles.inc   Wed Jul  3 09:06:39 2019(r349639)
>> +++ head/ObsoleteFiles.inc   Wed Jul  3 09:08:17 2019(r349640)
>> @@ -825,6 +825,7 @@ OLD_FILES+=usr/share/man/man3/arc4random_stir.3.gz
>>  OLD_FILES+=usr/bin/send-pr
>>  # 20180725: Cleanup old libcasper.so.0
>>  OLD_LIBS+=lib/libcasper.so.0
>> +OLD_LIBS+=lib32/libcasper.so.0  
> 
> Should this be usr/lib32 instead of lib32?

Yes, fixed in r349706.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r348847 - head/sys/sys

2019-06-13 Thread Tijl Coosemans
On Wed, 12 Jun 2019 16:51:03 -0600 Warner Losh  wrote:
> On Wed, Jun 12, 2019 at 4:49 PM Gleb Smirnoff  wrote:
>> On Mon, Jun 10, 2019 at 11:09:09AM +0200, Tijl Coosemans wrote:  
>>>> Date: Mon Jun 10 05:28:03 2019
>>>> New Revision: 348847
>>>> URL: https://svnweb.freebsd.org/changeset/base/348847
>>>>
>>>> Log:
>>>>   Use C11 anonymous unions.
>>>>
>>>>   PR:  215202
>>>>   Reported by: glebius
>>>>   MFC after:   2 weeks
>>>>
>>>> Modified:
>>>>   head/sys/sys/ucred.h
>>>>
>>>> Modified: head/sys/sys/ucred.h
>>>>  
>>>> ==
>>>>   
>>>> --- head/sys/sys/ucred.h   Mon Jun 10 05:09:34 2019(r348846)
>>>> +++ head/sys/sys/ucred.h   Mon Jun 10 05:28:03 2019(r348847)
>>>> @@ -89,12 +89,11 @@ struct xucred {
>>>>gid_t   cr_groups[XU_NGROUPS];  /* groups */
>>>>union {
>>>>void*_cr_unused1;   /* compatibility with old ucred */
>>>> -  pid_t   _pid;
>>>> -  } _cr;
>>>> +  pid_t   cr_pid;
>>>> +  };
>>>>  };
>>>>  #define   XUCRED_VERSION  0
>>>>
>>>> -#define   cr_pid _cr._pid
>>>>  /* This can be used for both ucred and xucred structures. */
>>>>  #define   cr_gid cr_groups[0]  
>>>
>>> Isn't this a userland header that should work with non-C11 compilers?  
>>
>> It could make sense to keep such low bar for standard headers, but ucred.h
>> is BSD-specific header and struct xucred is FreeBSD specific.
> 
> This is solvable with proper visibility, I'd think..

I think "union {" should be replaced with "__extension__ union {".  That
seems to kill this warning:

/usr/include/sys/ucred.h:90:2: warning: anonymous unions are a C11 extension
  [-Wc11-extensions]
union {
^
1 warning generated.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r348847 - head/sys/sys

2019-06-10 Thread Tijl Coosemans
On Mon, 10 Jun 2019 06:43:26 -0700 Conrad Meyer  wrote:
> On Mon, Jun 10, 2019 at 2:10 AM Tijl Coosemans  wrote:
>> On Mon, 10 Jun 2019 05:28:04 + (UTC) Dmitry Chagin
>>  wrote:
>>> ...
>>> URL: https://svnweb.freebsd.org/changeset/base/348847
>>> Log:
>>>   Use C11 anonymous unions.
>>>
>>> Modified: head/sys/sys/ucred.h
>> ...
>>
>> Isn't this a userland header that should work with non-C11 compilers?
> 
> Why would one expect userland headers to work with non-C11 (gnu89)
> compilers?

I'm thinking of third party software compiled with third party
compilers.  The system headers need to work with various C and C++
standards.  struct xucred is part of a public API documented in unix(4).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r348847 - head/sys/sys

2019-06-10 Thread Tijl Coosemans
On Mon, 10 Jun 2019 05:28:04 + (UTC) Dmitry Chagin
 wrote:
> Author: dchagin
> Date: Mon Jun 10 05:28:03 2019
> New Revision: 348847
> URL: https://svnweb.freebsd.org/changeset/base/348847
> 
> Log:
>   Use C11 anonymous unions.
>   
>   PR: 215202
>   Reported by:glebius
>   MFC after:  2 weeks
> 
> Modified:
>   head/sys/sys/ucred.h
> 
> Modified: head/sys/sys/ucred.h
> ==
> --- head/sys/sys/ucred.h  Mon Jun 10 05:09:34 2019(r348846)
> +++ head/sys/sys/ucred.h  Mon Jun 10 05:28:03 2019(r348847)
> @@ -89,12 +89,11 @@ struct xucred {
>   gid_t   cr_groups[XU_NGROUPS];  /* groups */
>   union {
>   void*_cr_unused1;   /* compatibility with old ucred */
> - pid_t   _pid;
> - } _cr;
> + pid_t   cr_pid;
> + };
>  };
>  #define  XUCRED_VERSION  0
>  
> -#define  cr_pid _cr._pid
>  /* This can be used for both ucred and xucred structures. */
>  #define  cr_gid cr_groups[0]

Isn't this a userland header that should work with non-C11 compilers?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r348798 - head/sys/amd64/amd64

2019-06-08 Thread Tijl Coosemans
On Sat, 8 Jun 2019 13:40:57 + (UTC) Konstantin Belousov
 wrote:
> Author: kib
> Date: Sat Jun  8 13:40:57 2019
> New Revision: 348798
> URL: https://svnweb.freebsd.org/changeset/base/348798
> 
> Log:
>   amd64 trap.c: Modernize syntax around trap_msg[].
>   
>   Convert the array to use C99 initializers.
>   Make it constant.
>   Replace MAX_TRAP_MSG with nitems().
>   
>   Sponsored by:   The FreeBSD Foundation
>   MFC after:  1 week
> 
> Modified:
>   head/sys/amd64/amd64/trap.c
> 
> Modified: head/sys/amd64/amd64/trap.c
> ==
> --- head/sys/amd64/amd64/trap.c   Sat Jun  8 09:34:02 2019
> (r348797)
> +++ head/sys/amd64/amd64/trap.c   Sat Jun  8 13:40:57 2019
> (r348798)
> @@ -118,41 +118,41 @@ static bool trap_user_dtrace(struct trapframe *,
>  int (**hook)(struct trapframe *));
>  #endif
>  
> -#define MAX_TRAP_MSG 32
> -static char *trap_msg[] = {
> - "", /*  0 unused */
> - "privileged instruction fault", /*  1 T_PRIVINFLT */
> - "", /*  2 unused */
> - "breakpoint instruction fault", /*  3 T_BPTFLT */
> - "", /*  4 unused */
> - "", /*  5 unused */
> - "arithmetic trap",  /*  6 T_ARITHTRAP */
> - "", /*  7 unused */
> - "", /*  8 unused */
> - "general protection fault", /*  9 T_PROTFLT */
> - "debug exception",  /* 10 T_TRCTRAP */
> - "", /* 11 unused */
> - "page fault",   /* 12 T_PAGEFLT */
> - "", /* 13 unused */
> - "alignment fault",  /* 14 T_ALIGNFLT */
> - "", /* 15 unused */
> - "", /* 16 unused */
> - "", /* 17 unused */
> - "integer divide fault", /* 18 T_DIVIDE */
> - "non-maskable interrupt trap",  /* 19 T_NMI */
> - "overflow trap",/* 20 T_OFLOW */
> - "FPU bounds check fault",   /* 21 T_BOUND */
> - "FPU device not available", /* 22 T_DNA */
> - "double fault", /* 23 T_DOUBLEFLT */
> - "FPU operand fetch fault",  /* 24 T_FPOPFLT */
> - "invalid TSS fault",/* 25 T_TSSFLT */
> - "segment not present fault",/* 26 T_SEGNPFLT */
> - "stack fault",  /* 27 T_STKFLT */
> - "machine check trap",   /* 28 T_MCHK */
> - "SIMD floating-point exception",/* 29 T_XMMFLT */
> - "reserved (unknown) fault", /* 30 T_RESERVED */
> - "", /* 31 unused (reserved) */
> - "DTrace pid return trap",   /* 32 T_DTRACE_RET */
> +static const char UNKNOWN[] = "unknown";
> +static const char *trap_msg[] = {

Maybe the array itself can also be const:
static const char *const trap_msg[]
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r347533 - in head/sys: compat/linux modules/linux_common

2019-05-19 Thread Tijl Coosemans
On Mon, 13 May 2019 17:48:16 + (UTC) Dmitry Chagin
 wrote:
> Author: dchagin
> Date: Mon May 13 17:48:16 2019
> New Revision: 347533
> URL: https://svnweb.freebsd.org/changeset/base/347533
> 
> Log:
>   Our bsd_to_linux_sockaddr() and linux_to_bsd_sockaddr() functions
>   alter the userspace sockaddr to convert the format between linux and BSD 
> versions.
>   That's the minimum 3 of copyin/copyout operations for one syscall.
>   
>   Also some syscall uses linux_sa_put() and linux_getsockaddr() when load
>   sockaddr to userspace or from userspace accordingly.
>   
>   To avoid this chaos, especially converting sockaddr in the userspace,
>   rewrite these 4 functions to convert sockaddr only in kernel and leave
>   only 2 of this functions.
>   
>   Also in order to reduce duplication between MD parts of the Linuxulator put
>   struct sockaddr conversion functions that are MI out into linux_common 
> module.
>   
>   PR: 232920
>   MFC after:  2 weeks
>   Differential Revision:  https://reviews.freebsd.org/D20157
> 
> Modified:
>   head/sys/compat/linux/linux.c
>   head/sys/compat/linux/linux.h
>   head/sys/compat/linux/linux_common.h
>   head/sys/compat/linux/linux_socket.c
>   head/sys/compat/linux/linux_socket.h
>   head/sys/modules/linux_common/Makefile
> 
> Modified: head/sys/compat/linux/linux_socket.c
> ==
> --- head/sys/compat/linux/linux_socket.c  Mon May 13 16:38:48 2019
> (r347532)
> +++ head/sys/compat/linux/linux_socket.c  Mon May 13 17:48:16 2019
> (r347533)
> @@ -1282,6 +1110,8 @@ linux_recvmsg_common(struct thread *td, l_int s, struc
>   struct mbuf *control = NULL;
>   struct mbuf **controlp;
>   struct timeval *ftmvl;
> + struct l_sockaddr *lsa;
> + struct sockaddr *sa;
>   l_timeval ltmvl;
>   caddr_t outbuf;
>   void *data;
> @@ -1305,36 +1135,34 @@ linux_recvmsg_common(struct thread *td, l_int s, struc
>   return (error);
>  
>   if (msg->msg_name) {
> - error = linux_to_bsd_sockaddr((struct sockaddr *)msg->msg_name,
> - msg->msg_namelen);
> - if (error != 0)
> - goto bad;
> + sa = malloc(msg->msg_namelen, M_SONAME, M_WAITOK);
> + msg->msg_name = sa;
>   }
>  
>   uiov = msg->msg_iov;
>   msg->msg_iov = iov;
>   controlp = (msg->msg_control != NULL) ?  : NULL;
> - error = kern_recvit(td, s, msg, UIO_USERSPACE, controlp);
> + error = kern_recvit(td, s, msg, UIO_SYSSPACE, controlp);
>   msg->msg_iov = uiov;
>   if (error != 0)
>   goto bad;
>  
> - error = bsd_to_linux_msghdr(msg, _msg);
> - if (error != 0)
> - goto bad;
> -
> - if (linux_msg.msg_name) {
> - error = bsd_to_linux_sockaddr((struct sockaddr *)
> - PTRIN(linux_msg.msg_name));
> + if (sa) {

sa may be uninitialised here.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r339618 - head/sys/compat/linuxkpi/common/include/linux

2018-11-18 Thread Tijl Coosemans
On Sun, 18 Nov 2018 12:10:25 -0800 Matthew Macy  wrote:
>> Note that these functions are normally used on uncacheable memory which
>> is strongly ordered on x86.  There should be no reordering at all.  On
>> PowerPC barrier instructions are needed to prevent reordering.  
> 
> Correct. The current lkpi implementation also assumes that device
> endian == host endian. The Linux generic accessors will do use endian
> macros to byte swap where necessary.

Yes, these functions are used to access little-endian registers so byte
swapping is needed on big-endian machines.  For PowerPC Linux also defines
functions to access big-endian registers, but we probably don't need those.

> The following change fixes radeon attach issues:
> https://github.com/POWER9BSD/freebsd/commit/be6c98f5c2e2ed9a4935ac5b67c468b75f3b4457

+/* prevent prefetching of coherent DMA data ahead of a dma-complete */
+#ifndef __io_ar
+#ifdef rmb
+#define __io_ar()  rmb()
+#else
+#define __io_ar()  __compiler_membar();
+#endif
+#endif
+
+/* flush writes to coherent DMA data before possibly triggering a DMA read */
+#ifndef __io_bw
+#ifdef wmb
+#define __io_bw()  wmb()
+#else
+#define __io_bw()  __compiler_membar();
+#endif
+#endif

...

 static inline uint16_t
 readw(const volatile void *addr)
 {
uint16_t v;
 
-   __compiler_membar();
-   v = *(const volatile uint16_t *)addr;
-   __compiler_membar();
+   __io_br();
+   v = le16toh(__raw_readw(addr));
+   __io_ar();
return (v);
 }

For x86 rmb and wmb are defined as lfence and sfence instructions which
shouldn't be necessary here.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r339618 - head/sys/compat/linuxkpi/common/include/linux

2018-11-18 Thread Tijl Coosemans
On Sat, 17 Nov 2018 14:55:05 -0800 Matthew Macy  wrote:
> When looking at powerpc io.h raw and relaxed are not aliases, but it
> appears that on x86, they are:
> https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/io.h
> 
> Sorry for the noise. But let's starting moving the x86 specific
> atomic.h and io.h under asm/x86.

Yes, I agree that the file should be moved to an arch specific location.
And the functions should probably be implemented using inline asm like
they are on Linux in case there are differences in the way compilers treat
the C code versus the asm code.

> On Sat, Nov 17, 2018 at 2:01 PM Matthew Macy  wrote:
>> You should probably revert this. The implied understanding of the
>> _relaxed version is incorrect. compiler_membar is there to prevent
>> instruction reordering which is possible on FreeBSD because the accesses
>> are done in C. The relaxed variants still do not permit instruction
>> reordering. On Linux __compiler_member (referred to as barrier there)
>> isn’t necessary in the mmio accessors because they always use volatile
>> asm which can’t be reordered. The distinction between the relaxed and
>> non relaxed variants is that the relaxed variant lacks memory barriers
>> (sync / lwsync / eieio on ppc, membar on sparc, etc).

Quoting https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html:

"Note that the compiler can move even volatile asm instructions relative
to other code, including across jump instructions."

So I think the Linux implementation of the relaxed variant lacks both CPU
and compiler barriers.

>> Most of the time we don’t run in to problems on x86 because with TSO
>> the only reordering possible is writes that happen before reads can
>> become visible in memory after they occur in the instruction stream.

Note that these functions are normally used on uncacheable memory which
is strongly ordered on x86.  There should be no reordering at all.  On
PowerPC barrier instructions are needed to prevent reordering.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r340181 - in head/sys: amd64/linux32 compat/linux

2018-11-06 Thread Tijl Coosemans
On Tue, 06 Nov 2018 16:17:23 +0100 Alexander Leidinger 
 wrote:
> Targeted for 12.0-release?
> Relnotes yes (linux64 support for NVidia driver)?

Yes, if re@ approves it.  The ports also need to be modified to install
linux64 libraries (PR 217901).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r338807 - in head/sys: amd64/amd64 amd64/include dev/drm2 dev/drm2/i915 i386/i386 i386/include x86/iommu

2018-09-28 Thread Tijl Coosemans
On Fri, 28 Sep 2018 20:26:19 +0300 Konstantin Belousov  
wrote:
> On Fri, Sep 28, 2018 at 07:02:34PM +0200, Tijl Coosemans wrote:
>> The removal of #ifdef DEV_APIC breaks building kernels without device
>> apic:
>> 
>> /usr/src/sys/i386/i386/pmap.c:1465:28: error: 
>>   use of undeclared identifier 'lapic_paddr'
>> if (pmap_kextract(sva) == lapic_paddr)
>>   ^
>> 1 error generated.  
> 
> Does the following work for you ?  If not, please provide me your
> kernel config.

Yes, thanks, everything looks fine.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r338807 - in head/sys: amd64/amd64 amd64/include dev/drm2 dev/drm2/i915 i386/i386 i386/include x86/iommu

2018-09-28 Thread Tijl Coosemans
On Wed, 19 Sep 2018 19:35:02 + (UTC) Konstantin Belousov  
wrote:
> Author: kib
> Date: Wed Sep 19 19:35:02 2018
> New Revision: 338807
> URL: https://svnweb.freebsd.org/changeset/base/338807
> 
> Log:
>   Convert x86 cache invalidation functions to ifuncs.
>   
>   This simplifies the runtime logic and reduces the number of
>   runtime-constant branches.
>   
>   Reviewed by:alc, markj
>   Sponsored by:   The FreeBSD Foundation
>   Approved by:re (gjb)
>   Differential revision:  https://reviews.freebsd.org/D16736
> 
> Modified:
>   head/sys/amd64/amd64/pmap.c
>   head/sys/amd64/include/pmap.h
>   head/sys/dev/drm2/drm_os_freebsd.c
>   head/sys/dev/drm2/i915/intel_ringbuffer.c
>   head/sys/i386/i386/pmap.c
>   head/sys/i386/i386/vm_machdep.c
>   head/sys/i386/include/pmap.h
>   head/sys/x86/iommu/intel_utils.c
> 
> Modified: head/sys/i386/i386/pmap.c
> ==
> --- head/sys/i386/i386/pmap.c Wed Sep 19 19:13:43 2018(r338806)
> +++ head/sys/i386/i386/pmap.c Wed Sep 19 19:35:02 2018(r338807)
> @@ -148,6 +148,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #endif
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -314,6 +315,10 @@ static vm_page_t pmap_enter_quick_locked(pmap_t pmap, 
>  vm_page_t m, vm_prot_t prot, vm_page_t mpte);
>  static void pmap_flush_page(vm_page_t m);
>  static int pmap_insert_pt_page(pmap_t pmap, vm_page_t mpte);
> +static void pmap_invalidate_cache_range_selfsnoop(vm_offset_t sva,
> +vm_offset_t eva);
> +static void pmap_invalidate_cache_range_all(vm_offset_t sva,
> +vm_offset_t eva);
>  static void pmap_invalidate_pde_page(pmap_t pmap, vm_offset_t va,
>   pd_entry_t pde);
>  static void pmap_fill_ptp(pt_entry_t *firstpte, pt_entry_t newpte);
> @@ -1407,37 +1412,62 @@ pmap_invalidate_pde_page(pmap_t pmap, vm_offset_t va, 
>   pmap_invalidate_page(pmap, va);
>  }
>  
> +DEFINE_IFUNC(, void, pmap_invalidate_cache_range, (vm_offset_t, vm_offset_t),
> +static)
> +{
> +
> + if ((cpu_feature & CPUID_SS) != 0)
> + return (pmap_invalidate_cache_range_selfsnoop);
> + if ((cpu_feature & CPUID_CLFSH) != 0)
> + return (pmap_force_invalidate_cache_range);
> + return (pmap_invalidate_cache_range_all);
> +}
> +
>  #define  PMAP_CLFLUSH_THRESHOLD  (2 * 1024 * 1024)
>  
> +static void
> +pmap_invalidate_cache_range_check_align(vm_offset_t sva, vm_offset_t eva)
> +{
> +
> + KASSERT((sva & PAGE_MASK) == 0,
> + ("pmap_invalidate_cache_range: sva not page-aligned"));
> + KASSERT((eva & PAGE_MASK) == 0,
> + ("pmap_invalidate_cache_range: eva not page-aligned"));
> +}
> +
> +static void
> +pmap_invalidate_cache_range_selfsnoop(vm_offset_t sva, vm_offset_t eva)
> +{
> +
> + pmap_invalidate_cache_range_check_align(sva, eva);
> +}
> +
>  void
> -pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva, boolean_t 
> force)
> +pmap_force_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva)
>  {
>  
> - if (force) {
> - sva &= ~(vm_offset_t)(cpu_clflush_line_size - 1);
> - } else {
> - KASSERT((sva & PAGE_MASK) == 0,
> - ("pmap_invalidate_cache_range: sva not page-aligned"));
> - KASSERT((eva & PAGE_MASK) == 0,
> - ("pmap_invalidate_cache_range: eva not page-aligned"));
> + sva &= ~(vm_offset_t)(cpu_clflush_line_size - 1);
> + if (eva - sva >= PMAP_CLFLUSH_THRESHOLD) {
> + /*
> +  * The supplied range is bigger than 2MB.
> +  * Globally invalidate cache.
> +  */
> + pmap_invalidate_cache();
> + return;
>   }
>  
> - if ((cpu_feature & CPUID_SS) != 0 && !force)
> - ; /* If "Self Snoop" is supported and allowed, do nothing. */
> - else if ((cpu_stdext_feature & CPUID_STDEXT_CLFLUSHOPT) != 0 &&
> - eva - sva < PMAP_CLFLUSH_THRESHOLD) {
> -#ifdef DEV_APIC
> + /*
> +  * XXX: Some CPUs fault, hang, or trash the local APIC
> +  * registers if we use CLFLUSH on the local APIC
> +  * range.  The local APIC is always uncached, so we
> +  * don't need to flush for that range anyway.
> +  */
> + if (pmap_kextract(sva) == lapic_paddr)
> + return;
> +
> + if ((cpu_stdext_feature & CPUID_STDEXT_CLFLUSHOPT) != 0) {
>   /*
> -  * XXX: Some CPUs fault, hang, or trash the local APIC
> -  * registers if we use CLFLUSH on the local APIC
> -  * range.  The local APIC is always uncached, so we
> -  * don't need to flush for that range anyway.
> -  */
> - if (pmap_kextract(sva) == lapic_paddr)
> - return;
> -#endif
> - /*
> -  * Otherwise, do per-cache line flush.  Use the sfence
> +  * Do per-cache line flush.  Use the 

Re: svn commit: r336025 - in head/sys: amd64/include i386/include

2018-07-06 Thread Tijl Coosemans
On Fri, 6 Jul 2018 11:09:27 -0700 (PDT) "Rodney W. Grimes" 
 wrote:
> > On Fri, Jul 6, 2018, 12:27 PM Rodney W. Grimes <  
> > free...@pdx.rh.cn85.dnsmgr.net> wrote:  
> >   
> > > > On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes <  
> > > > free...@pdx.rh.cn85.dnsmgr.net> wrote:  
> > > >  
> > > > > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes <  
> > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote:  
> > > > > >  
> > > > > > > > Author: hselasky
> > > > > > > > Date: Fri Jul  6 10:13:42 2018
> > > > > > > > New Revision: 336025
> > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/336025
> > > > > > > >
> > > > > > > > Log:
> > > > > > > >   Make sure kernel modules built by default are portable 
> > > > > > > > between  
> > > UP  
> > > > > and  
> > > > > > > >   SMP systems by extending defined(SMP) to include  
> > > > > defined(KLD_MODULE).  
> > > > > > > >
> > > > > > > >   This is a regression issue after r335873 .
> > > > > > > >
> > > > > > > >   Discussed with: mmacy@
> > > > > > > >   Sponsored by:   Mellanox Technologies  
> > > > > > >
> > > > > > > Though this fixes the issue, it also means that now when
> > > > > > > anyone intentionally builds a UP kernel with modules
> > > > > > > they are getting SMP support in the modules and I am
> > > > > > > not sure they would want that.  I know I don't.
> > > > > > >  
> > > > > >
> > > > > >
> > > > > > On UP systems, these additional opcodes are harmless. They take a 
> > > > > > few  
> > > > > extra  
> > > > > > cycles (since they lock an uncontested bus) and add a couple extra  
> > > memory  
> > > > > > barriers (which will be NOPs). On MP systems, atomics now work by  
> > > > > default.  
> > > > > > Had we not defaulted like this, all modules built outside of a 
> > > > > > kernel  
> > > > > build  
> > > > > > env would have broken atomics. Given that (a) the overwhelming  
> > > majority  
> > > > > > (99% or more) is SMP and (b) the MP code merely adds a few cycles 
> > > > > > to  
> > > > > what's  
> > > > > > already a not-too-expensive operation, this was the right choice.
> > > > > >
> > > > > > It simply doesn't matter for systems that are relevant to the 
> > > > > > project
> > > > > > today. While one could try to optimize this a little (for example, 
> > > > > > by
> > > > > > having SMP defined to be 0 or 1, say, and changing all the ifdef 
> > > > > > SMP  
> > > to  
> > > > > if  
> > > > > > (defined(SMP) && SMP != 0)), it's likely not going to matter enough 
> > > > > >  
> > > for  
> > > > > > anybody to make the effort. UP on x86 is simply not relevant enough 
> > > > > >  
> > > to  
> > > > > > optimize for it. Even in VMs, people run SMP kernels typically even 
> > > > > >  
> > > when  
> > > > > > they just allocate one CPU to the VM.
> > > > > >
> > > > > > So while we still support the UP config, and we'll let people build
> > > > > > optimized kernels for x86, we've flipped the switch from pessimized 
> > > > > >  
> > > for  
> > > > > SMP  
> > > > > > modules to pessimized for UP modules, which seems like quite the  
> > > > > reasonable  
> > > > > > trade-off.
> > > > > >
> > > > > > Were it practical to do so, I'd suggest de-orbiting UP on x86.  
> > > However,  
> > > > > > it's a lot of work for not much benefit and we'd need to invent 
> > > > > > much  
> > > > > crazy  
> > > > > > to get there.  
> > > > >
> > > > > Trivial to fix this with
> > > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) ||
> > > > > !defined(KLD_UP_MODULES)  
> > > >
> > > >
> > > > Nope. Not so trivial. Who defines KLD_UP_MODULES?  
> > >
> > > Call it SMP_KLD_MODULES, and it gets defined the same place SMP does.
> > >  
> > 
> > Not so simple. SMP is defined in the config file, and winds up in one of  
> No problem, that is where I would be defining this anyway, or in the
> latest case removing it and SMP for my UP kernel build.
> 
> > the option files. It will be absent for stand alone builds,  
> I am ok with that.  And it would be reasonable to default to SMP.
> 
> > though. These
> > change tweak the default yo be inlined and to include the sequence that
> > works everywhere.
> >   
> > >  
> > > > And really, it's absolutely not worth it unless someone shows up with
> > > > numbers to show the old 'function call to optimal routine' is actually
> > > > faster than the new 'inline to slightly unoptimal code'. Since I think  
> > > the  
> > > > function call overhead is larger than the pessmizations, I'm not sure  
> > > what  
> > > > the fuss is about.  
> > >
> > > I have no issues with the SMP converting from function calls to
> > > inline locks, I just want to retain the exact same code I had
> > > before any of these changes, and that was A UP built system
> > > without any SMP locking.  Is it too much to ask to keep what
> > > already worked?
> > >  
> > 
> > This doesn't enable or disable locks in the muted sense. It just changes
> > the atomic 

Re: svn commit: r334869 - head/usr.bin/top

2018-06-14 Thread Tijl Coosemans
On Sat, 9 Jun 2018 02:47:02 + (UTC) Eitan Adler  wrote:
> Author: eadler
> Date: Sat Jun  9 02:47:02 2018
> New Revision: 334869
> URL: https://svnweb.freebsd.org/changeset/base/334869
> 
> Log:
>   top(1): correct header, align it.
>   
>   THR is always 6 digits or longer. Now that the PID/THR change is
>   separated, use correct headers.
>   
>   PR: 228823
>   Reported by:trond.endres...@ximalas.info
> 
> Modified:
>   head/usr.bin/top/machine.c
> 
> Modified: head/usr.bin/top/machine.c
> ==
> --- head/usr.bin/top/machine.cSat Jun  9 02:41:51 2018
> (r334868)
> +++ head/usr.bin/top/machine.cSat Jun  9 02:47:02 2018
> (r334869)
> @@ -94,17 +94,20 @@ static const char io_header[] =
>  static const char io_Proc_format[] =
>  "%5d%*s %-*.*s %6ld %6ld %6ld %6ld %6ld %6ld %6.2f%% %.*s";
>  
> +/* XXX: build up header instead of statically defining them.
> + * This will also allow for a "format string" to be supplied
> + * as an argument to top(1) instead of having predefined options */
>  static const char smp_header_thr_and_pid[] =
> -"  PID%*s %-*.*s  THR PRI NICE   SIZERES%*s STATE   C   TIME %7s 
> COMMAND";
> -static const char smp_header_tid_only[] =
> -"  THR%*s %-*.*s "   "PRI NICE   SIZERES%*s STATE   C   TIME %7s 
> COMMAND";
> +"  %s%*s %-*.*s  THR PRI NICE   SIZERES%*s STATE   C   TIME %7s 
> COMMAND";
> +static const char smp_header_id_only[] =
> +"  %s%*s %-*.*s  PRI NICE   SIZERES%*s STATE   C   TIME %7s COMMAND";
>  static const char smp_Proc_format[] =
>  "%5d%*s %-*.*s %s%3d %4s%7s %6s%*.*s %-6.6s %2d%7s %6.2f%% %.*s";
>  
>  static char up_header_thr_and_pid[] =
>  "  PID%*s %-*.*s  THR PRI NICE   SIZERES%*s STATETIME %7s 
> COMMAND";

You need to replace PID with %s here as well.


> -static char up_header_tid_only[] =
> -"  THR%*s %-*.*s "   "PRI NICE   SIZERES%*s STATETIME %7s 
> COMMAND";
> +static char up_header_id_only[] =
> +"  %s%*s %-*.*s   PRI NICE   SIZERES%*s STATETIME %7s COMMAND";
>  static char up_Proc_format[] =
>  "%5d%*s %-*.*s %s%3d %4s%7s %6s%*.*s %-6.6s%.0d%7s %6.2f%% %.*s";
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"