Re: armv7 a4x dsb fix
On Mon, Jul 03, 2017 at 06:14:06AM +0300, Artturi Alm wrote: > Hi, > > just the bug fix, so this diff leaves the unused relics around and so, > but better than current/nothing, and hopefully small enough to get looked at. > > -Artturi > ping? a4x bus_space is supposed to be identical to armv7 bus_space w/ offset << 2. -Artturi diff --git a/sys/arch/arm/armv7/armv7_a4x_io.S b/sys/arch/arm/armv7/armv7_a4x_io.S index 3fa09faa4c2..5e9db421853 100644 --- a/sys/arch/arm/armv7/armv7_a4x_io.S +++ b/sys/arch/arm/armv7/armv7_a4x_io.S @@ -50,14 +50,17 @@ */ ENTRY(a4x_bs_r_1) + dsb sy ldr r0, [r1, r2, LSL #2] mov pc, lr ENTRY(a4x_bs_r_2) + dsb sy ldr r0, [r1, r2, LSL #2] mov pc, lr ENTRY(a4x_bs_r_4) + dsb sy ldr r0, [r1, r2, LSL #2] mov pc, lr @@ -67,14 +70,17 @@ ENTRY(a4x_bs_r_4) ENTRY(a4x_bs_w_1) str r3, [r1, r2, LSL #2] + dsb sy mov pc, lr ENTRY(a4x_bs_w_2) str r3, [r1, r2, LSL #2] + dsb sy mov pc, lr ENTRY(a4x_bs_w_4) str r3, [r1, r2, LSL #2] + dsb sy mov pc, lr /* @@ -82,11 +88,11 @@ ENTRY(a4x_bs_w_4) */ ENTRY(a4x_bs_rm_1) mov r2, r2, LSL #2 - b generic_bs_rm_1 + b armv7_bs_rm_1 ENTRY(a4x_bs_rm_2) mov r2, r2, LSL #2 - b generic_armv4_bs_rm_2 + b armv7_bs_rm_2 @@ -95,8 +101,8 @@ ENTRY(a4x_bs_rm_2) */ ENTRY(a4x_bs_wm_1) mov r2, r2, LSL #2 - b generic_bs_wm_1 + b armv7_bs_wm_1 ENTRY(a4x_bs_wm_2) mov r2, r2, LSL #2 - b generic_armv4_bs_wm_2 + b armv7_bs_wm_2
update mi_switch(9)
Having looked through various parts of the context switching code this week, I noticed that mi_switch() has a man page, and it's quite out of date. tsleep() isn't the only sleep function, but I don't think there's much point listing them all. Additionally, yield() and preempt() also exist, but aren't documented. The 'renice after 10 minutes of cpu time' thing was removed in 2003 (r1.47 of kern_synch.c). It's more useful to mention the scheduler lock rather than a specific (wrong?) spl here, since mi_switch() does a SCHED_ASSERT_LOCKED(). ok? Alternatively, I'm not sure what the audience for this page is. It's mostly a list of reasons you don't need to call mi_switch() because either it happens to you automatically or it's used to implement part of some other function. Maybe we should just remove it and document the more useful kernel functions like yield()/preempt() better? diff --git mi_switch.9 mi_switch.9 index b04179fa79d..c53fb3ec11e 100644 --- mi_switch.9 +++ mi_switch.9 @@ -54,11 +54,12 @@ The three major uses of can be enumerated as follows: .Bl -enum -offset indent .It -From within -.Xr tsleep 9 -when the current process -voluntarily relinquishes the CPU to wait for some resource to become -available. +From within functions like +.Xr tsleep 9 , +when the current process sleeps to wait for some resource to become +available, or from within functions like +.Fn yield , +when it relinquishes the CPU to allow other processes to make progress. .It After handling a trap .Pq e.g., a system call or device interrupt @@ -85,8 +86,6 @@ Exceeding the soft limit results in a signal to be posted to the process, while exceeding the hard limit will cause a .Dv SIGKILL . -For a process which accumulated longer than 10 minutes of -CPU time, its nice level is raised to 4. After these administrative tasks are done, .Fn mi_switch chooses the next process to run and hands over control to the machine @@ -105,8 +104,7 @@ Note that .Fn mi_switch and thus .Fn cpu_switchto -should be called at -.Xr splhigh 9 . +must be called while holding the scheduler lock. .Sh SEE ALSO .Xr spl 9 , .Xr tsleep 9 ,
ksh: use PATH_MAX
ok?
Index: c_ksh.c
===
RCS file: /d/cvs/src/bin/ksh/c_ksh.c,v
retrieving revision 1.50
diff -u -p -r1.50 c_ksh.c
--- c_ksh.c 21 Mar 2016 13:35:00 - 1.50
+++ c_ksh.c 2 Sep 2017 22:18:50 -
@@ -99,7 +99,7 @@ c_cd(char **wp)
return 1;
}
- Xinit(xs, xp, PATH, ATEMP);
+ Xinit(xs, xp, PATH_MAX, ATEMP);
/* xp will have a bogus value after make_path() - set it to 0
* so that if it's used, it will cause a dump
*/
Index: path.c
===
RCS file: /d/cvs/src/bin/ksh/path.c,v
retrieving revision 1.18
diff -u -p -r1.18 path.c
--- path.c 14 Dec 2015 13:59:42 - 1.18
+++ path.c 2 Sep 2017 22:18:50 -
@@ -220,7 +220,7 @@ do_phys_path(XString *xsp, char *xp, con
const char *p, *q;
int len, llen;
int savepos;
- char lbuf[PATH];
+ char lbuf[PATH_MAX];
Xcheck(*xsp, xp);
for (p = path; p; p = q) {
Index: sh.h
===
RCS file: /d/cvs/src/bin/ksh/sh.h,v
retrieving revision 1.63
diff -u -p -r1.63 sh.h
--- sh.h30 Aug 2017 17:08:45 - 1.63
+++ sh.h2 Sep 2017 22:18:50 -
@@ -10,6 +10,7 @@
/* Start of common headers */
+#include
#include
#include
#include
@@ -33,7 +34,6 @@
#define ISMAGIC(c) ((unsigned char)(c) == MAGIC)
#defineLINE4096/* input line size */
-#definePATH1024/* pathname size (todo:
PATH_MAX/pathconf()) */
extern const char *kshname;/* $0 */
extern pid_t kshpid; /* $$, shell pid */
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
teach wsconsctl about efifb
on a laptop with a simplefb[1] display, wsconsctl shows display.type=unknown_71.
With the below patch, it shows display.type=efifb
I checked the other values, and it was the only missing display type.
[1] simplefb claims to be WSDISPLAY_TYPE_EFIFB
OK?
Index: sbin/wsconsctl/util.c
===
RCS file: /cvs/openbsd/src/sbin/wsconsctl/util.c,v
retrieving revision 1.64
diff -u -p -u -p -r1.64 util.c
--- sbin/wsconsctl/util.c 21 Jul 2017 20:38:20 - 1.64
+++ sbin/wsconsctl/util.c 2 Sep 2017 20:55:06 -
@@ -167,7 +167,8 @@ static const struct nameint dpytype_tab[
{ WSDISPLAY_TYPE_NEWPORT, "newport" },
{ WSDISPLAY_TYPE_LIGHT, "light" },
{ WSDISPLAY_TYPE_INTELDRM, "inteldrm" },
- { WSDISPLAY_TYPE_RADEONDRM, "radeondrm" }
+ { WSDISPLAY_TYPE_RADEONDRM, "radeondrm" },
+ { WSDISPLAY_TYPE_EFIFB, "efifb" }
};
static const struct nameint kbdenc_tab[] = {
--
"... the Mayo Clinic, named after its founder, Dr. Ted Clinic ..."
-- Dave Barry
Re: strtok_r(3): mention standards
Hi Jeremie, Jeremie Courreges-Anglas wrote on Mon, Aug 28, 2017 at 02:29:18PM +0200: > Also, mandoc -Tlint warns: > mandoc: strtok.3:90:2: STYLE: useless macro: Tn > s/Tn/Li/ ? No. The messages printed by mandoc -Tlint are terse, but the mandoc(1) manual is intended to provide enough detail to help people fix the issues: $ man mandoc | col -b | grep -A2 'useless macro' useless macro (mdoc) A Bt, Tn, or Ud macro was found. Simply delete it: it serves no useful purpose. > Other manpages are affected. True. Getting rid of .Tn isn't high priority, and doing it systematically would consume some time. No developer wanted to do it yet. Non-developers should not send diffs for it, checking such diffs causes even more work than doing it from scratch. Unless you are terribly bored, the right time for deleting .Tn is when you look at a page anyway, so i just did it for strtok(3), also removing the pointless word "ASCII": just "a NUL character" is the normal wording, without any markup. Yours, Ingo
[patch] ocspcheck: nextUpdate is optional according to RFC 6960
ocspcheck effectively treats a missing nextUpdate like an error, i.e.,
it always provides a warning and no staplefile is written out. According
to RFC 6960, the nextUpdate field is optional. The following patch
should handle this case more gracefully and include a suitable debug
message only in case -vv is specified.
OK?
Index: src/usr.sbin/ocspcheck/ocspcheck.c
===
RCS file: /cvs/src/usr.sbin/ocspcheck/ocspcheck.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 ocspcheck.c
--- src/usr.sbin/ocspcheck/ocspcheck.c 8 May 2017 20:15:34 - 1.21
+++ src/usr.sbin/ocspcheck/ocspcheck.c 2 Sep 2017 17:09:00 -
@@ -368,7 +368,7 @@ validate_response(char *buf, size_t size
{
ASN1_GENERALIZEDTIME *revtime = NULL, *thisupd = NULL, *nextupd = NULL;
const unsigned char **p = (const unsigned char **)
- int status, cert_status=0, crl_reason=0;
+ int status, cert_status=0, crl_reason=0, next_update=0;
time_t now, rev_t = -1, this_t, next_t;
OCSP_RESPONSE *resp;
OCSP_BASICRESP *bresp;
@@ -447,12 +447,14 @@ validate_response(char *buf, size_t size
return 0;
}
if ((next_t = parse_ocsp_time(nextupd)) == -1) {
- warnx("unable to parse next update time in OCSP reply");
- return 0;
+ if (verbose >= 2)
+ fprintf(stderr, "Optional timestamp for next update not included in
OCSP reply\n");
}
+ else
+ next_update = 1;
/* Don't allow this update to precede next update */
- if (this_t >= next_t) {
+ if (next_update == 1 && this_t >= next_t) {
warnx("Invalid OCSP reply: this update >= next update");
return 0;
}
@@ -481,7 +483,7 @@ validate_response(char *buf, size_t size
/*
* Check that next update is still valid
*/
- if (next_t < now - JITTER_SEC) {
+ if (next_update == 1 && next_t < now - JITTER_SEC) {
warnx("Invalid OCSP reply: reply has expired (%s)",
ctime(_t));
return 0;
@@ -489,7 +491,8 @@ validate_response(char *buf, size_t size
vspew("OCSP response validated from %s\n", host);
vspew(" This Update: %s", ctime(_t));
- vspew(" Next Update: %s", ctime(_t));
+ if (next_update == 1)
+ vspew(" Next Update: %s", ctime(_t));
return 1;
}
efiboot: Avoid listing modes when setting one
Currently `machine video 7' will always list all available modes just
like `machine video' before setting mode 7. Since the screen is
reset/cleared when setting the mode, listing them beforehand is
hardly ever useful and rather looks like flickering.
This diff avoids the described behaviour and seperates things more
strictly/clearly. `machine video 7' won't list anymore but keeps
printing the current/new mode *after* resetting the screen now.
Otherwise behaviour and functionality stays unchanged. Successfully
tested on two different amd64 ThinkPads.
Style nit: Lines are kept <73 columns now.
Comments? Feedback?
Index: efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.23
diff -u -p -r1.23 efiboot.c
--- efiboot.c 7 Aug 2017 19:34:53 - 1.23
+++ efiboot.c 2 Sep 2017 16:35:37 -
@@ -844,22 +844,25 @@ int
Xvideo_efi(void)
{
int i, mode = -1;
- char*p;
- for (i = 0; i < nitems(efi_video) && i < conout->Mode->MaxMode; i++) {
- if (efi_video[i].cols > 0)
- printf("Mode %d: %d x %d\n", i,
- efi_video[i].cols, efi_video[i].rows);
- }
- if (cmd.argc == 2) {
- p = cmd.argv[1];
- mode = strtol(p, , 10);
- }
- printf("\nCurrent Mode = %d\n", conout->Mode->Mode);
- if (0 <= mode && mode < i && efi_video[mode].cols > 0) {
- EFI_CALL(conout->SetMode, conout, mode);
- efi_video_reset();
+ if (cmd.argc >= 2) {
+ mode = strtol(cmd.argv[1], NULL, 10);
+ if (0 <= mode && mode < nitems(efi_video) &&
+ efi_video[mode].cols > 0) {
+ EFI_CALL(conout->SetMode, conout, mode);
+ efi_video_reset();
+ }
+ } else {
+ for (i = 0; i < nitems(efi_video) &&
+ i < conout->Mode->MaxMode; i++) {
+ if (efi_video[i].cols > 0)
+ printf("Mode %d: %d x %d\n", i,
+ efi_video[i].cols,
+ efi_video[i].rows);
+ }
+ printf("\n");
}
+ printf("Current Mode = %d\n", conout->Mode->Mode);
return (0);
}
Is it possible for "NOKVM" defined in reality?
Hi tech@,
The code framework of dmesg.c:
..
struct msgbuf cur;
char *allocated = NULL;
..
if (memf == NULL && nlistf == NULL) {
..
} else {
#ifndef NOKVM
..
#endif
}
if (cur.msg_bufx >= cur.msg_bufs)
cur.msg_bufx = 0;
..
free(allocated);
..
In reality, is there possible to have "NOKVM" defined (in else branch)?
If so, the "cur" variable will be messy, and "allocated" will be NULL.
Hope to check it, thanks!
Best Regards
Nan Xiao
Re: refactoring of pf_find_or_create_ruleset()
On 1.9.2017. 22:57, Alexandr Nedvedicky wrote:
> as you can see the kernel sets ruleset.anchor to NULL (see pfattach() and then
> do also a 'grep -n kludge pf_ioctl.c'), while userland links it to
> pf_main_anchor.
>
> I've remember to changing 'parent != NULL' to 'parent != _main_anchor' in
> pf_create_anchor() just to make regression tests passing. Fortunately you did
> run my code in kernel. With change above my patch works for kernel as well as
> for regression tests.
>
> updated patch is attached.
>
> thanks and
> regards
> sasha
Hi,
with this patch i can't trigger panic with or without WITH_PF_LOCK if
that's matter for some reason.
pf conf:
# pfctl -nvf pf.conf
set skip on { lo em0 }
set limit states 100
block drop all
anchor "test1" on ix3 all {
pass all flags S/SA
anchor "test11" all {
pass all flags S/SA
}
}
anchor "test2" on ix2 all {
pass all flags S/SA
anchor "test21" all {
pass all flags S/SA
}
}
thank you sasha for great work on MP pf :)
