xenodm: Set MAIL environment variable
xenodm(1) sets the same standard environment variables as login(1) and
ssh(1) in the user session, except for MAIL. Users may expect to
receive mail notifications in X and miss them as a result.
Here's the patch to add MAIL to the environment.
As a side effect, it will enable ksh(1)'s periodic mail checks.
Index: greeter/verify.c
===
RCS file: /cvs/xenocara/app/xenodm/greeter/verify.c,v
retrieving revision 1.10
diff -u -p -r1.10 verify.c
--- greeter/verify.c4 Dec 2019 09:53:47 - 1.10
+++ greeter/verify.c12 Jul 2021 22:46:12 -
@@ -45,6 +45,8 @@ from The Open Group.
#include
#include
#include
+#include
+#include
#include "greet.h"
@@ -56,6 +58,7 @@ static const char *envvars[] = {
static char **
userEnv (struct display *d, int useSystemPath, char *user, char *home, char
*shell)
{
+char mail[sizeof(_PATH_MAILDIR) + 1 + NAME_MAX];
char **env;
const char **envvar;
const char *str;
@@ -67,6 +70,8 @@ userEnv (struct display *d, int useSyste
env = setEnv (env, "USER", user);/* BSD */
env = setEnv (env, "PATH", useSystemPath ? d->systemPath : d->userPath);
env = setEnv (env, "SHELL", shell);
+snprintf (mail, sizeof(mail), "%s/%s", _PATH_MAILDIR, user);
+env = setEnv (env, "MAIL", mail);
for (envvar = envvars; *envvar; envvar++)
{
str = getenv(*envvar);
Index: man/xenodm.man
===
RCS file: /cvs/xenocara/app/xenodm/man/xenodm.man,v
retrieving revision 1.13
diff -u -p -r1.13 xenodm.man
--- man/xenodm.man 13 Mar 2021 12:11:10 - 1.13
+++ man/xenodm.man 12 Jul 2021 22:46:12 -
@@ -1115,6 +1115,8 @@ the value of
.It Ev SHELL
the user's default shell (from
.Xr getpwnam 3 )
+.It Ev MAIL
+the user's mailbox
.It Ev XAUTHORITY
may be set to a non-standard authority file
.It Ev WINDOWPATH
ntpd: Remove -sS compat
deraadt neutered these options in november 2019, I'd say it's time to
remove them so the next release won't have it.
Feedback? Objections? OK?
diff --git a/usr.sbin/ntpd/ntpd.c b/usr.sbin/ntpd/ntpd.c
index 134073117cb..1349234f66a 100644
--- a/usr.sbin/ntpd/ntpd.c
+++ b/usr.sbin/ntpd/ntpd.c
@@ -140,7 +140,6 @@ main(int argc, char *argv[])
char**argv0 = argv;
char*pname = NULL;
time_t settime_deadline;
- int sopt = 0;
if (strcmp(__progname, "ntpctl") == 0) {
ctl_main(argc, argv);
@@ -151,7 +150,7 @@ main(int argc, char *argv[])
memset(&lconf, 0, sizeof(lconf));
- while ((ch = getopt(argc, argv, "df:nP:sSv")) != -1) {
+ while ((ch = getopt(argc, argv, "df:nP:v")) != -1) {
switch (ch) {
case 'd':
lconf.debug = 1;
@@ -166,10 +165,6 @@ main(int argc, char *argv[])
case 'P':
pname = optarg;
break;
- case 's':
- case 'S':
- sopt = ch;
- break;
case 'v':
lconf.verbose++;
break;
@@ -186,12 +181,6 @@ main(int argc, char *argv[])
log_init(logdest, lconf.verbose, LOG_DAEMON);
- if (sopt) {
- log_warnx("-%c option no longer works and will be removed
soon.",
- sopt);
- log_warnx("Please reconfigure to use constraints or trusted
servers.");
- }
-
argc -= optind;
argv += optind;
if (argc > 0)
Re: update xf86-video-amdgpu to latest git
On Thu, Jul 8, 2021, at 7:29 AM, Jonathan Gray wrote: > The latest xf86-video-amdgpu release was in 2019. > > xf86-video-amdgpu-19.1.0..origin/master Hi, Tested this patch on -current with a RX5600XT (Navi 10 XLE). It works great and seems to have fixed the occasional X crash that I would get. - Evan Burkey d...@fputs.com
Re: ddb trace: fix output for too many arguments
> Date: Mon, 12 Jul 2021 20:11:30 +0200
> From: Jasper Lievisse Adriaanse
>
> On Sun, Jul 11, 2021 at 03:58:05PM +0200, Jasper Lievisse Adriaanse wrote:
> > Hi,
> >
> > When printing a trace from ddb, some architectures are limited by the
> > number of
> > registers which are used to pass arguments. If the number of arguments to a
> > function
> > exceeded this number, the code in db_stack_trace_print() would print that
> > many arguments
> > without any indication that one or more arguments aren't printed.
> >
> > Here's a diff that tweaks the output to make it clear there were more
> > arguments.
> > Do we want to print ',...' for each ommited argument (like this diff does)
> > or perhaps just a single ',...'?
>
> I think just printing a single instance of ',...' gets the point across.
> OK?
Actually, since we use -msave-args on amd64 the arguments are saved on
the stack. I think this means there is no limit on the number of
arguments we can print...
> Index: arch/amd64/amd64/db_trace.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/db_trace.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 db_trace.c
> --- arch/amd64/amd64/db_trace.c 14 May 2020 06:58:54 - 1.53
> +++ arch/amd64/amd64/db_trace.c 12 Jul 2021 18:08:21 -
> @@ -137,7 +137,7 @@ db_stack_trace_print(db_expr_t addr, int
>
> lastframe = 0;
> while (count && frame != 0) {
> - int narg;
> + int narg, extra_args = 0;
> unsigned inti;
> char * name;
> db_expr_t offset;
> @@ -165,8 +165,12 @@ db_stack_trace_print(db_expr_t addr, int
> }
>
> narg = db_ctf_func_numargs(sym);
> - if (narg < 0 || narg > 6)
> + if (narg < 0)
> narg = 6;
> + else if (narg > 6) {
> + narg = 6;
> + extra_args = 1;
> + }
>
> if (name == NULL)
> (*pr)("%lx(", callpc);
> @@ -204,6 +208,10 @@ db_stack_trace_print(db_expr_t addr, int
> if (--narg != 0)
> (*pr)(",");
> }
> +
> + if (extra_args)
> + (*pr)(",...");
> +
> (*pr)(") at ");
> db_printsym(callpc, DB_STGY_PROC, pr);
> (*pr)("\n");
> Index: arch/powerpc/ddb/db_trace.c
> ===
> RCS file: /cvs/src/sys/arch/powerpc/ddb/db_trace.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 db_trace.c
> --- arch/powerpc/ddb/db_trace.c 14 May 2020 06:58:54 - 1.17
> +++ arch/powerpc/ddb/db_trace.c 12 Jul 2021 18:08:21 -
> @@ -123,7 +123,7 @@ db_stack_trace_print(db_expr_t addr, int
> Elf_Sym *sym;
> char*name;
> char c, *cp = modif;
> - int i, narg, trace_proc = 0;
> + int i, narg, trace_proc = 0, extra_args = 0;
>
> while ((c = *cp++) != 0) {
> if (c == 't')
> @@ -158,8 +158,12 @@ db_stack_trace_print(db_expr_t addr, int
> (*pr)("at 0x%lx", lr - 4);
> } else {
> narg = db_ctf_func_numargs(sym);
> - if (narg < 0 || narg > 8)
> + if (narg < 0)
> narg = 8;
> + else if (narg > 8) {
> + narg = 8;
> + extra_args = 1;
> + }
>
> (*pr)("%s(", name);
>
> @@ -172,6 +176,9 @@ db_stack_trace_print(db_expr_t addr, int
> (*pr)(",");
> }
> }
> +
> + if (extra_args)
> + (*pr)(",...");
>
> (*pr)(") at ");
> db_printsym(lr - 4, DB_STGY_PROC, pr);
>
> --
> jasper
>
>
Re: ddb trace: fix output for too many arguments
On Sun, Jul 11, 2021 at 03:58:05PM +0200, Jasper Lievisse Adriaanse wrote:
> Hi,
>
> When printing a trace from ddb, some architectures are limited by the number
> of
> registers which are used to pass arguments. If the number of arguments to a
> function
> exceeded this number, the code in db_stack_trace_print() would print that
> many arguments
> without any indication that one or more arguments aren't printed.
>
> Here's a diff that tweaks the output to make it clear there were more
> arguments.
> Do we want to print ',...' for each ommited argument (like this diff does)
> or perhaps just a single ',...'?
I think just printing a single instance of ',...' gets the point across.
OK?
Index: arch/amd64/amd64/db_trace.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/db_trace.c,v
retrieving revision 1.53
diff -u -p -r1.53 db_trace.c
--- arch/amd64/amd64/db_trace.c 14 May 2020 06:58:54 - 1.53
+++ arch/amd64/amd64/db_trace.c 12 Jul 2021 18:08:21 -
@@ -137,7 +137,7 @@ db_stack_trace_print(db_expr_t addr, int
lastframe = 0;
while (count && frame != 0) {
- int narg;
+ int narg, extra_args = 0;
unsigned inti;
char * name;
db_expr_t offset;
@@ -165,8 +165,12 @@ db_stack_trace_print(db_expr_t addr, int
}
narg = db_ctf_func_numargs(sym);
- if (narg < 0 || narg > 6)
+ if (narg < 0)
narg = 6;
+ else if (narg > 6) {
+ narg = 6;
+ extra_args = 1;
+ }
if (name == NULL)
(*pr)("%lx(", callpc);
@@ -204,6 +208,10 @@ db_stack_trace_print(db_expr_t addr, int
if (--narg != 0)
(*pr)(",");
}
+
+ if (extra_args)
+ (*pr)(",...");
+
(*pr)(") at ");
db_printsym(callpc, DB_STGY_PROC, pr);
(*pr)("\n");
Index: arch/powerpc/ddb/db_trace.c
===
RCS file: /cvs/src/sys/arch/powerpc/ddb/db_trace.c,v
retrieving revision 1.17
diff -u -p -r1.17 db_trace.c
--- arch/powerpc/ddb/db_trace.c 14 May 2020 06:58:54 - 1.17
+++ arch/powerpc/ddb/db_trace.c 12 Jul 2021 18:08:21 -
@@ -123,7 +123,7 @@ db_stack_trace_print(db_expr_t addr, int
Elf_Sym *sym;
char*name;
char c, *cp = modif;
- int i, narg, trace_proc = 0;
+ int i, narg, trace_proc = 0, extra_args = 0;
while ((c = *cp++) != 0) {
if (c == 't')
@@ -158,8 +158,12 @@ db_stack_trace_print(db_expr_t addr, int
(*pr)("at 0x%lx", lr - 4);
} else {
narg = db_ctf_func_numargs(sym);
- if (narg < 0 || narg > 8)
+ if (narg < 0)
narg = 8;
+ else if (narg > 8) {
+ narg = 8;
+ extra_args = 1;
+ }
(*pr)("%s(", name);
@@ -172,6 +176,9 @@ db_stack_trace_print(db_expr_t addr, int
(*pr)(",");
}
}
+
+ if (extra_args)
+ (*pr)(",...");
(*pr)(") at ");
db_printsym(lr - 4, DB_STGY_PROC, pr);
--
jasper
Re: ipsec: remove unused `PolicyHead' from 'sockaddr_encap' structure
On Sun, Jul 11, 2021 at 05:33:18AM +0300, Vitaliy Makkoveev wrote:
> This member is never set or used. Also I kept 'SENT_IP6' definition for
> prevent the potential break of third party software. Is it ok to
> redefine it to '0x0002'? At least openswan wants this [1].
>
> 1.
> https://github.com/xelerance/Openswan/blob/master/include/openswan/ipsec_encap.h#L20
I wouldn't worry about third party software. Those defines are within
#ifdef _KERNEL so everyone using those is doing it wrong anyway.
ok with SENT_IP6 changed to 0x0002.
>
> Index: sys/netinet/ip_ipsp.h
> ===
> RCS file: /cvs/src/sys/netinet/ip_ipsp.h,v
> retrieving revision 1.200
> diff -u -p -r1.200 ip_ipsp.h
> --- sys/netinet/ip_ipsp.h 8 Jul 2021 21:07:19 - 1.200
> +++ sys/netinet/ip_ipsp.h 11 Jul 2021 02:25:17 -
> @@ -113,8 +113,6 @@ struct sockaddr_encap {
> u_int16_t Sport;
> u_int16_t Dport;
> } Sip6;
> -
> - struct ipsec_policy *PolicyHead;/* SENT_IPSP */
> } Sen;
> };
>
> @@ -208,7 +206,6 @@ struct m_tag;
> #define sen_ip6_sport Sen.Sip6.Sport
> #define sen_ip6_dport Sen.Sip6.Dport
> #define sen_ip6_direction Sen.Sip6.Direction
> -#define sen_ipspSen.PolicyHead
>
> /*
> * The "type" is really part of the address as far as the routing
> @@ -219,7 +216,6 @@ struct m_tag;
> */
>
> #define SENT_IP40x0001 /* data is two struct in_addr */
> -#define SENT_IPSP 0x0002 /* data as in IP4/6 plus SPI */
> #define SENT_IP60x0004
>
> #define SENT_LENsizeof(struct sockaddr_encap)
>
Re: gprof: Profiling a multi-threaded application
Hi, Martin
n 2021/07/10 16:55, Martin Pieuchot wrote:
> Hello Yuichiro, thanks for your work !
Thanks for the response.
>> On 2021/06/16 16:34, Yuichiro NAITO wrote:
>>> When I compile a multi-threaded application with '-pg' option, I always get
>>> no
>>> results in gmon.out. With bad luck, my application gets SIGSEGV while
>>> running.
>>> Because the buffer that holds number of caller/callee count is the only one
>>> in the process and will be broken by multi-threaded access.
>>>
>>> I get the idea to solve this problem from NetBSD. NetBSD has individual
>>> buffers
>>> for each thread and merges them at the end of profiling.
>
> Note that the kernel use a similar approach but doesn't merge the buffer,
> instead it generates a file for each CPU.
Yes, so the number of output files are limited by the number of CPUs in case of
the kernel profiling. I think number of application threads can be increased
more
casually. I don't want to see dozens of 'gmon.out' files.
>>> NetBSD stores the reference to the individual buffer by
>>> pthread_setspecific(3).
>>> I think it causes infinite recursive call if whole libc library (except
>>> mcount.c) is compiled with -pg.
>>>
>>> The compiler generates '_mcount' function call at the beginning of every
>>> functions. If '_mcount' calls pthread_getspecific(3) to get the individual
>>> buffer, pthread_getspecific() calls '_mcount' again and causes infinite
>>> recursion.
>>>
>>> NetBSD prevents from infinite recursive call by checking a global variable.
>>> But
>>> this approach also prevents simultaneously call of '_mcount' on a
>>> multi-threaded
>>> application. It makes a little bit wrong results of profiling.
>>>
>>> So I added a pointer to the buffer in `struct pthread` that can be
>>> accessible
>>> via macro call as same as pthread_self(3). This approach can prevent of
>>> infinite recursive call of '_mcount'.
>
> Not calling a libc function for this makes sense. However I'm not
> convinced that accessing `tib_thread' before _rthread_init() has been
> called is safe.
Before '_rthread_init’ is called, '__isthreaded' global variable is kept to be
0.
My patch doesn't access tib_thread in this case.
After calling `_rthread_init`, `pthread_create()` changes `__isthreaded` to 1.
Tib_thread will be accessed by all threads that are newly created and the
initial one.
I believe tib of the initial thread has been initialized in `_libc_preinit'
function
in 'lib/libc/dlfcn/init.c'.
> I'm not sure where is the cleanest way to place the per-thread buffer,
> I'd suggest you ask guenther@ about this.
I added guenther@ in CC of this mail.
I hope I can get an advise about per-thread buffer.
> Maybe the initialization can be done outside of _mcount()?
Yes, I think tib is initialized in `pthread_create()` and `_libc_preinit()`.
>>> I obtained merging function from NetBSD that is called in '_mcleanup'
>>> function.
>>> Merging function needs to walk through all the individual buffers,
>>> I added SLIST_ENTRY member in 'struct gmonparam' to make a list of the
>>> buffers.
>>> And also added '#ifndef _KERNEL' for the SLIST_ENTRY member not to be used
>>> for
>>> the kernel.
>>>
>>> But I still use pthread_getspecific(3) for that can call destructor when
>>> a thread is terminated. The individual buffer is moved to free list to reuse
>>> for a new thread.
>>
>> Here is a patch for this approach.
>
> I have various comments:
>
> We choose not to use C++ style comment (// comment) in the tree, could you
> fix yours?
>
> There's two copies of mcount.c, the other one lies in sys/lib/libkern could
> you keep them in sync?
>
> gmon.c is only compiled in userland and don't need #ifndef _KERNEL
>
> In libc there's also the use of _MUTEX_LOCK/UNLOCK() macro instead of
> calling pthread_mutex* directly. This might help reduce the differences
> between ST and MT paths.
Thanks for letting me know them.
I updated my patch as following according to the advice.
diff --git a/lib/libc/gmon/gmon.c b/lib/libc/gmon/gmon.c
index 1ce0a1c289e..5169fa70449 100644
--- a/lib/libc/gmon/gmon.c
+++ b/lib/libc/gmon/gmon.c
@@ -42,6 +42,15 @@
struct gmonparam _gmonparam = { GMON_PROF_OFF };
+#include
+#include
+
+SLIST_HEAD(, gmonparam) _gmonfree = SLIST_HEAD_INITIALIZER(_gmonfree);
+SLIST_HEAD(, gmonparam) _gmoninuse = SLIST_HEAD_INITIALIZER(_gmoninuse);
+void* _gmonlock = NULL;
+pthread_key_t _gmonkey;
+struct gmonparam _gmondummy;
+
static int s_scale;
/* see profil(2) where this is describe (incorrectly) */
#defineSCALE_1_TO_10x1L
@@ -52,6 +61,11 @@ PROTO_NORMAL(moncontrol);
PROTO_DEPRECATED(monstartup);
static int hertz(void);
+static void _gmon_destructor(void *);
+struct gmonparam *_gmon_alloc(void);
+static void _gmon_merge(void);
+static void _gmon_merge_two(struct gmonparam *, struct gmonparam *);
+
void
monstartup(u_long lowpc, u_long highpc)
{
@@ -114,6 +128,9 @@ monstartup(u_long lowpc, u_long highpc)
} else
