Re: uvm_map_inentry() & KERNEL_LOCK()
Ted Unangst wrote: > Theo de Raadt wrote: > > In uvm_map_inentry_fix(), two variables in the map are now being read > > without a per-map read lock, this was previously protected by the > > kernel lock > > > > if (addr < map->min_offset || addr >= map->max_offset) > > return (FALSE); > > > > When I wrote this I was told to either use KERNEL_LOCK() or > > vm_map_lock_read(), which is vm_map_lock_read_ln() .. if > > KERNEL_LOCK() is no longer good should vm_map_lock_read be moved > > upwards, or are you confident those offsets are safe to read > > independently without any locking?? > > indeed, another thread can expand the map, so that should have the read lock. Or the kernel lock. I remember being told a tiny moment of kernel lock might be cheaper than the read lock, unless I could find someone to understand the cost of vm_map_lock_read_ln. I suppose we are at that moment now.
Re: uvm_map_inentry() & KERNEL_LOCK()
Theo de Raadt wrote: > In uvm_map_inentry_fix(), two variables in the map are now being read > without a per-map read lock, this was previously protected by the > kernel lock > > if (addr < map->min_offset || addr >= map->max_offset) > return (FALSE); > > When I wrote this I was told to either use KERNEL_LOCK() or > vm_map_lock_read(), which is vm_map_lock_read_ln() .. if > KERNEL_LOCK() is no longer good should vm_map_lock_read be moved > upwards, or are you confident those offsets are safe to read > independently without any locking?? indeed, another thread can expand the map, so that should have the read lock.
Re: uvm_map_inentry() & KERNEL_LOCK()
In uvm_map_inentry_fix(), two variables in the map are now being read
without a per-map read lock, this was previously protected by the
kernel lock
if (addr < map->min_offset || addr >= map->max_offset)
return (FALSE);
When I wrote this I was told to either use KERNEL_LOCK() or
vm_map_lock_read(), which is vm_map_lock_read_ln() .. if
KERNEL_LOCK() is no longer good should vm_map_lock_read be moved
upwards, or are you confident those offsets are safe to read
independently without any locking??
Martin Pieuchot wrote:
> When a userland program triggers a fault or does a syscall its SP and/or
> PC are checked to be sure they are in expected regions. The result of
> this check is cached in the "struct proc" such that a lookup isn't
> always necessary.
>
> Currently when the cache is outdated the KERNEL_LOCK() is taken before
> doing the lookup. This shouldn't be necessary, uvm_map_lookup_entry()
> is protected by the `vm_map_lock' also taken before the lookup. This
> function is already called w/o KERNEL_LOCK(), like in the futex code,
> so it should be safe to push it down there.
>
> Removing the KERNEL_LOCK() from this code path reduces the overall time
> spinning when executing syscalls from 30% to 25% when building the libc
> on my 16 CPU sparc64.
>
> Even if it doesn't improve the performances significantly I'd like to
> have more code exercising the `vm_map_lock', cause it's one of the
> pieces to unlock uvm_fault().
>
> While here document that `p_spinentry' and `p_pcinentry' are owned by
> the current process and don't need any locking.
>
> Tests, comments and oks welcome :o)
>
> Index: uvm/uvm_map.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.247
> diff -u -p -r1.247 uvm_map.c
> --- uvm/uvm_map.c 9 Sep 2019 20:02:26 - 1.247
> +++ uvm/uvm_map.c 31 Oct 2019 21:45:51 -
> @@ -158,6 +158,10 @@ int uvm_map_findspace(struct
> vm_map*,
> vsize_t uvm_map_addr_augment_get(struct vm_map_entry*);
> void uvm_map_addr_augment(struct vm_map_entry*);
>
> +int uvm_map_inentry_recheck(u_long, vaddr_t,
> + struct p_inentry *);
> +boolean_t uvm_map_inentry_fix(struct proc *, struct p_inentry *,
> + vaddr_t, int (*)(vm_map_entry_t), u_long);
> /*
> * Tree management functions.
> */
> @@ -1868,16 +1872,16 @@ uvm_map_inentry(struct proc *p, struct p
> boolean_t ok = TRUE;
>
> if (uvm_map_inentry_recheck(serial, addr, ie)) {
> - KERNEL_LOCK();
> ok = uvm_map_inentry_fix(p, ie, addr, fn, serial);
> if (!ok) {
> printf(fmt, p->p_p->ps_comm, p->p_p->ps_pid, p->p_tid,
> addr, ie->ie_start, ie->ie_end);
> + KERNEL_LOCK();
> p->p_p->ps_acflag |= AMAP;
> sv.sival_ptr = (void *)PROC_PC(p);
> trapsignal(p, SIGSEGV, 0, SEGV_ACCERR, sv);
> + KERNEL_UNLOCK();
> }
> - KERNEL_UNLOCK();
> }
> return (ok);
> }
> Index: uvm/uvm_map.h
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map.h,v
> retrieving revision 1.62
> diff -u -p -r1.62 uvm_map.h
> --- uvm/uvm_map.h 14 Jun 2019 05:52:43 - 1.62
> +++ uvm/uvm_map.h 31 Oct 2019 21:46:00 -
> @@ -414,12 +414,8 @@ void uvm_unmap_remove(struct vm_map*, v
>
> struct p_inentry;
>
> -int uvm_map_inentry_recheck(u_long serial, vaddr_t,
> - struct p_inentry *);
> int uvm_map_inentry_sp(vm_map_entry_t);
> int uvm_map_inentry_pc(vm_map_entry_t);
> -boolean_tuvm_map_inentry_fix(struct proc *, struct p_inentry *,
> - vaddr_t addr, int (*fn)(vm_map_entry_t), u_long serial);
> boolean_tuvm_map_inentry(struct proc *, struct p_inentry *, vaddr_t addr,
> const char *fmt, int (*fn)(vm_map_entry_t), u_long serial);
>
> Index: sys/proc.h
> ===
> RCS file: /cvs/src/sys/sys/proc.h,v
> retrieving revision 1.275
> diff -u -p -r1.275 proc.h
> --- sys/proc.h22 Oct 2019 21:19:22 - 1.275
> +++ sys/proc.h31 Oct 2019 21:27:43 -
> @@ -318,6 +318,7 @@ struct p_inentry {
> * I immutable after creation
> * s scheduler lock
> * l read only reference, see lim_read_enter()
> + * o owned (read/modified) by the current proc
> */
> struct proc {
> TAILQ_ENTRY(proc) p_runq; /* [s] current run/sleep queue */
> @@ -332,8 +333,8 @@ struct proc {
> /* substructures: */
> struct filedesc *p_fd; /* copy of p_p->ps_fd */
> struct vmspace *p_vmspace; /*
uvm_map_inentry() & KERNEL_LOCK()
When a userland program triggers a fault or does a syscall its SP and/or
PC are checked to be sure they are in expected regions. The result of
this check is cached in the "struct proc" such that a lookup isn't
always necessary.
Currently when the cache is outdated the KERNEL_LOCK() is taken before
doing the lookup. This shouldn't be necessary, uvm_map_lookup_entry()
is protected by the `vm_map_lock' also taken before the lookup. This
function is already called w/o KERNEL_LOCK(), like in the futex code,
so it should be safe to push it down there.
Removing the KERNEL_LOCK() from this code path reduces the overall time
spinning when executing syscalls from 30% to 25% when building the libc
on my 16 CPU sparc64.
Even if it doesn't improve the performances significantly I'd like to
have more code exercising the `vm_map_lock', cause it's one of the
pieces to unlock uvm_fault().
While here document that `p_spinentry' and `p_pcinentry' are owned by
the current process and don't need any locking.
Tests, comments and oks welcome :o)
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.247
diff -u -p -r1.247 uvm_map.c
--- uvm/uvm_map.c 9 Sep 2019 20:02:26 - 1.247
+++ uvm/uvm_map.c 31 Oct 2019 21:45:51 -
@@ -158,6 +158,10 @@ int uvm_map_findspace(struct
vm_map*,
vsize_t uvm_map_addr_augment_get(struct vm_map_entry*);
voiduvm_map_addr_augment(struct vm_map_entry*);
+int uvm_map_inentry_recheck(u_long, vaddr_t,
+struct p_inentry *);
+boolean_t uvm_map_inentry_fix(struct proc *, struct p_inentry *,
+vaddr_t, int (*)(vm_map_entry_t), u_long);
/*
* Tree management functions.
*/
@@ -1868,16 +1872,16 @@ uvm_map_inentry(struct proc *p, struct p
boolean_t ok = TRUE;
if (uvm_map_inentry_recheck(serial, addr, ie)) {
- KERNEL_LOCK();
ok = uvm_map_inentry_fix(p, ie, addr, fn, serial);
if (!ok) {
printf(fmt, p->p_p->ps_comm, p->p_p->ps_pid, p->p_tid,
addr, ie->ie_start, ie->ie_end);
+ KERNEL_LOCK();
p->p_p->ps_acflag |= AMAP;
sv.sival_ptr = (void *)PROC_PC(p);
trapsignal(p, SIGSEGV, 0, SEGV_ACCERR, sv);
+ KERNEL_UNLOCK();
}
- KERNEL_UNLOCK();
}
return (ok);
}
Index: uvm/uvm_map.h
===
RCS file: /cvs/src/sys/uvm/uvm_map.h,v
retrieving revision 1.62
diff -u -p -r1.62 uvm_map.h
--- uvm/uvm_map.h 14 Jun 2019 05:52:43 - 1.62
+++ uvm/uvm_map.h 31 Oct 2019 21:46:00 -
@@ -414,12 +414,8 @@ void uvm_unmap_remove(struct vm_map*, v
struct p_inentry;
-intuvm_map_inentry_recheck(u_long serial, vaddr_t,
- struct p_inentry *);
intuvm_map_inentry_sp(vm_map_entry_t);
intuvm_map_inentry_pc(vm_map_entry_t);
-boolean_t uvm_map_inentry_fix(struct proc *, struct p_inentry *,
- vaddr_t addr, int (*fn)(vm_map_entry_t), u_long serial);
boolean_t uvm_map_inentry(struct proc *, struct p_inentry *, vaddr_t addr,
const char *fmt, int (*fn)(vm_map_entry_t), u_long serial);
Index: sys/proc.h
===
RCS file: /cvs/src/sys/sys/proc.h,v
retrieving revision 1.275
diff -u -p -r1.275 proc.h
--- sys/proc.h 22 Oct 2019 21:19:22 - 1.275
+++ sys/proc.h 31 Oct 2019 21:27:43 -
@@ -318,6 +318,7 @@ struct p_inentry {
* I immutable after creation
* s scheduler lock
* l read only reference, see lim_read_enter()
+ * o owned (read/modified) by the current proc
*/
struct proc {
TAILQ_ENTRY(proc) p_runq; /* [s] current run/sleep queue */
@@ -332,8 +333,8 @@ struct proc {
/* substructures: */
struct filedesc *p_fd; /* copy of p_p->ps_fd */
struct vmspace *p_vmspace; /* [I] copy of p_p->ps_vmspace */
- struct p_inentry p_spinentry;
- struct p_inentry p_pcinentry;
+ struct p_inentry p_spinentry; /* [o] */
+ struct p_inentry p_pcinentry; /* [o] */
struct plimit *p_limit; /* [l] read ref. of p_p->ps_limit */
int p_flag; /* P_* flags. */
_pbuild user to have priority=5
I suggest adding a priority=5 to _pbuild user. I tried on a macppc, a core 2 duo laptop and i7 laptop. It helped a lot the macppc and core2 to stay responsive on ssh or being barely usable while building. On the i7, the benefits are less. At best this allows firefox to stay responsive on bloated "webapps" and avoid a few audio stuttering. I only see benefits and no drawback. Index: etc.alpha/login.conf === RCS file: /data/cvs/src/etc/etc.alpha/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.alpha/login.conf2 Jun 2019 06:46:17 - 1.7 +++ etc.alpha/login.conf31 Oct 2019 22:34:15 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.amd64/login.conf === RCS file: /data/cvs/src/etc/etc.amd64/login.conf,v retrieving revision 1.12 diff -u -p -r1.12 login.conf --- etc.amd64/login.conf19 Aug 2019 20:59:14 - 1.12 +++ etc.amd64/login.conf31 Oct 2019 22:34:20 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=6144M:\ :maxproc-max=1024:\ :maxproc-cur=384:\ + :priority=5:\ :tc=default: # Index: etc.arm64/login.conf === RCS file: /data/cvs/src/etc/etc.arm64/login.conf,v retrieving revision 1.6 diff -u -p -r1.6 login.conf --- etc.arm64/login.conf7 Oct 2019 17:52:59 - 1.6 +++ etc.arm64/login.conf31 Oct 2019 22:34:24 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=6144M:\ :maxproc-max=1024:\ :maxproc-cur=384:\ + :priority=5:\ :tc=default: # Index: etc.armv7/login.conf === RCS file: /data/cvs/src/etc/etc.armv7/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.armv7/login.conf2 Jun 2019 06:46:17 - 1.7 +++ etc.armv7/login.conf31 Oct 2019 22:34:27 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.hppa/login.conf === RCS file: /data/cvs/src/etc/etc.hppa/login.conf,v retrieving revision 1.9 diff -u -p -r1.9 login.conf --- etc.hppa/login.conf 2 Jun 2019 06:46:17 - 1.9 +++ etc.hppa/login.conf 31 Oct 2019 22:34:31 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.i386/login.conf === RCS file: /data/cvs/src/etc/etc.i386/login.conf,v retrieving revision 1.8 diff -u -p -r1.8 login.conf --- etc.i386/login.conf 2 Jun 2019 06:46:18 - 1.8 +++ etc.i386/login.conf 31 Oct 2019 22:34:36 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=2048M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.landisk/login.conf === RCS file: /data/cvs/src/etc/etc.landisk/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.landisk/login.conf 2 Jun 2019 06:46:18 - 1.7 +++ etc.landisk/login.conf 31 Oct 2019 22:34:39 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.loongson/login.conf === RCS file: /data/cvs/src/etc/etc.loongson/login.conf,v retrieving revision 1.9 diff -u -p -r1.9 login.conf --- etc.loongson/login.conf 18 Oct 2019 03:40:22 - 1.9 +++ etc.loongson/login.conf 31 Oct 2019 22:34:42 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=4096M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.luna88k/login.conf === RCS file: /data/cvs/src/etc/etc.luna88k/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.luna88k/login.conf 2 Jun 2019 06:46:18 - 1.7 +++ etc.luna88k/login.conf 31 Oct 2019 22:34:45 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.macppc/login.conf === RCS file: /data/cvs/src/etc/etc.macppc/login.conf,v retrieving revision 1.8 diff -u -p -r1.8 login.conf --- etc.macppc/login.conf 2 Jun 2019 06:46:18 -
Re: Opportunistic DoT for unwind(8)
Hi,
So here's a new diff that incorporates the bug fix mentioned plus
debug printf line changes suggested by Stuart.
Please note that this is a diff on top of very recent current, i.e.
florian's work he committed today. That means that you need to be
up-to-date (including a recent libc update that was committed a few
days ago) to be able to test this version.
-Otto
Index: sbin/unwind/parse.y
===
RCS file: /cvs/src/sbin/unwind/parse.y,v
retrieving revision 1.12
diff -u -p -r1.12 parse.y
--- sbin/unwind/parse.y 31 Oct 2019 12:51:43 - 1.12
+++ sbin/unwind/parse.y 31 Oct 2019 16:32:27 -
@@ -84,7 +84,6 @@ intcheck_pref_uniq(enum uw_resolver_ty
static struct uw_conf *conf;
static int errors;
-static struct uw_forwarder *uw_forwarder;
voidclear_config(struct uw_conf *xconf);
struct sockaddr_storage*host_ip(const char *);
@@ -287,7 +286,9 @@ forwarderopts_l : forwarderopts_l forwa
forwarderoptsl : STRING port authname dot {
int ret, port;
+ struct uw_forwarder *uw_fwd;
struct sockaddr_storage *ss;
+
if ((ss = host_ip($1)) == NULL) {
yyerror("%s is not an ip-address", $1);
free($1);
@@ -305,37 +306,53 @@ forwarderoptsl: STRING port authname d
else
port = $2;
- if ((uw_forwarder = calloc(1,
- sizeof(*uw_forwarder))) == NULL)
+ if ($3 != NULL && $4 == 0) {
+ yyerror("authentication name can only "
+ "be used with DoT");
+ free($1);
+ YYERROR;
+ }
+
+
+ if ((uw_fwd = calloc(1,
+ sizeof(*uw_fwd))) == NULL)
err(1, NULL);
- if ($3 == NULL)
- ret = snprintf(uw_forwarder->name,
- sizeof(uw_forwarder->name),
- "%s@%d", $1, port);
- else
- ret = snprintf(uw_forwarder->name,
- sizeof(uw_forwarder->name),
- "%s@%d#%s", $1, port, $3);
+ if ($4 == DOT) {
+ if ($3 == NULL)
+ ret = snprintf(uw_fwd->name,
+ sizeof(uw_fwd->name),
+ "%s@%d", $1, port);
+ else
+ ret = snprintf(uw_fwd->name,
+ sizeof(uw_fwd->name),
+ "%s@%d#%s", $1, port, $3);
+ } else {
+ uw_fwd->port = $2;
+ /* complete string wil be done later */
+ ret = snprintf(uw_fwd->name,
+ sizeof(uw_fwd->name), "%s", $1);
+ }
if (ret < 0 || (size_t)ret >=
- sizeof(uw_forwarder->name)) {
- free(uw_forwarder);
+ sizeof(uw_fwd->name)) {
+ free(uw_fwd);
yyerror("forwarder %s too long", $1);
free($1);
YYERROR;
}
- free($1);
if ($4 == DOT)
SIMPLEQ_INSERT_TAIL(
>uw_dot_forwarder_list,
- uw_forwarder, entry);
- else
+ uw_fwd, entry);
+ else {
SIMPLEQ_INSERT_TAIL(
>uw_forwarder_list,
- uw_forwarder, entry);
+ uw_fwd, entry);
+ }
+
[PATCH] Add new warning to useradd
Hi
I think I found a scenario with useradd(8) where a warning would be nice.
Given the following setup:
foo# useradd test_user
useradd: Warning: home directory `/home/test_user' doesn't exist, and -m was
not specified
foo# cat /etc/passwd
cvs:*:1003:1003::/home/cvs:/bin/ksh
test_user:*:1002:1002::/home/test_user:/bin/ksh
foo# cat /etc/group
cvs:*:1003:
test_user:*:1002:
Now if I delete the user with userdel(8):
foo# userdel test_user
and then readd the user with useradd(8):
foo# useradd test_user
useradd: Warning: home directory `/home/test_user' doesn't exist, and -m was
not specified
foo# cat /etc/group
cvs:*:1003:
test_user:*:1002:
foo# cat /etc/passwd
cvs:*:1003:1003::/home/cvs:/bin/ksh
test_user:*:1004:1004::/home/test_user:/bin/ksh
the gid of the user (1004) does not match the group id (1002) with the same name
(test_user). I think it would be a good idea to print a warning if that happens,
so that subsequent operations (e.g. chown :test_user ...) involving the group
name don't have unexpected effects.
Below is a patch which implements that. Here is the result of it (starting
again from zero):
foo# useradd test_user
useradd: Warning: home directory `/home/test_user' doesn't exist, and -m was
not specified
foo# cat /etc/passwd
cvs:*:1003:1003::/home/cvs:/bin/ksh
test_user:*:1002:1002::/home/test_user:/bin/ksh
foo# cat /etc/groups
cvs:*:1003:
test_user:*:1002:
foo# useradd test_user
user: Warning: home directory `/home/test_user' doesn't exist, and -m was not
specified
user: Warning: group with name test_user already exists with gid 1002
Comments, thoughts, feedback?
Kind regards,
Martin
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.128
diff -u -p -r1.128 user.c
--- user.c 17 Oct 2019 21:54:29 - 1.128
+++ user.c 31 Oct 2019 18:49:45 -
@@ -1218,12 +1218,20 @@ adduser(char *login_name, user_t *up)
(void) asystem("%s -R u+w %s", CHMOD, home);
}
}
- if (strcmp(up->u_primgrp, "=uid") == 0 && !group_exists(login_name) &&
- !creategid(login_name, gid, "")) {
- close(ptmpfd);
- pw_abort();
- errx(EXIT_FAILURE, "can't create gid %u for login name %s",
- gid, login_name);
+ if (strcmp(up->u_primgrp, "=uid") == 0) {
+ gid_t other_gid;
+ if (gid_from_group(login_name, _gid) != -1 &&
+ gid != other_gid) {
+ warnx("Warning: group with name %s already exists with
gid %u",
+ login_name, other_gid);
+ }
+ if (!group_exists(login_name) &&
+ !creategid(login_name, gid, "")) {
+ close(ptmpfd);
+ pw_abort();
+ errx(EXIT_FAILURE, "can't create gid %u for login name
%s",
+ gid, login_name);
+ }
}
if (up->u_groupc > 0 && !append_group(login_name, up->u_groupc,
up->u_groupv)) {
close(ptmpfd);
Re: iwm: add support for firmware paging
Hi Stefan, I tested it for dozen hours of YT streaming and usual web browsing. No issues observed. iwm0: hw rev 0x230, fw ver 22.361476.0, address e4:0e:ee:81:3d:a0 -- Krystian
Re: ix(4) need support for X553
On Thu, Oct 31, 2019 at 9:49 AM sven falempin wrote: > > > On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson > wrote: > >> On 2019/10/31 08:25, sven falempin wrote: >> > Thank you, the ./dev/pci/pcidevs_data.h, pcidevs.h are completly >> removed from this >> >> The pcidevs update is no longer needed since pcidevs r1.1889. >> >> > I may have time to test it against 6.6, see if it is still working >> since 6.4 (where it was >> > tested, also a cross test revealed >> > that plugin'/unplugging SFP maybe non functionnal) >> >> I can test an already-wprking fibre ix for new problems at some point, >> but I don't >> think I'll have a fibre X553. >> >> > ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11 > "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured > "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured > ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11 > "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured > "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured > > When I look at them , some more involved people was talking about 10gb in > OpenBSD . > > Isn't there some limitations currently or can we expect the X553 to > perform at 10Gb ? > > > Hey looks like my diff still works OpenBSD 6.6-stable (GENERIC.MP) #21: Thu Oct 31 10:53:41 EDT 2019 ix0 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:0b:4a:81 ix1 at pci8 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:0b:4a:82 ix2 at pci9 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:0b:4a:83 ix3 at pci9 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:0b:4a:84 # ifconfig ix ix0: flags=8802 mtu 1500 lladdr 00:30:18:0b:4a:81 index 3 priority 0 llprio 3 media: Ethernet autoselect status: no carrier ix1: flags=8802 mtu 1500 lladdr 00:30:18:0b:4a:82 index 4 priority 0 llprio 3 media: Ethernet autoselect (10GbaseSR full-duplex) status: active ix2: flags=8802 mtu 1500 lladdr 00:30:18:0b:4a:83 index 5 priority 0 llprio 3 media: Ethernet autoselect status: no carrier ix3: flags=8802 mtu 1500 lladdr 00:30:18:0b:4a:84 index 6 priority 0 llprio 3 media: Ethernet autoselect (10GbaseSR full-duplex) status: active # ifconfig ix1 rdomain 1 10.0.0.1 # ifconfig ix3 rdomain 3 10.0.0.3 # ping -V 3 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.573 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.246 ms # route -T 1 exec iperf -c 10.0.0.3 Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 17.0 KByte (default) [ 3] local 10.0.0.1 port 29912 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 871 MBytes 731 Mbits/sec If anyone want to help run it faster, you re welcome. -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: acpivout(4): backlights without method to query current level
> Date: Thu, 31 Oct 2019 11:31:50 +0100
> From: Patrick Wildt
>
> Hi,
>
> some machines have no _BQC method, which is used to query the
> current display backlight level. We can still work on those by
> starting with the highest level (when there's no _BQC method)
> and keeping track of the current level.
That makes (some) sense. I had never noticed this, but the ACPI
standard does document _BQC as "optional".
That said, picking 100% is probably not what we want here. The _BCM
method returns a list whose first two elements are the default
brightness with AC connected and the brightness when on battery. We
should use those instead.
Now checking whether AC has been plugged in probably can't be done
within the attach function. But maybe that can be done in a mountroot
hook.
> diff --git a/sys/dev/acpi/acpivideo.c b/sys/dev/acpi/acpivideo.c
> index 9498465a418..a46a99a67f7 100644
> --- a/sys/dev/acpi/acpivideo.c
> +++ b/sys/dev/acpi/acpivideo.c
> @@ -149,7 +149,7 @@ acpi_foundvout(struct aml_node *node, void *arg)
> if (node->parent != sc->sc_devnode)
> return (0);
>
> - if (aml_searchname(node, "_BCM") && aml_searchname(node, "_BQC")) {
> + if (aml_searchname(node, "_BCM")) {
> memset(, 0, sizeof(aaa));
> aaa.aaa_iot = sc->sc_acpi->sc_iot;
> aaa.aaa_memt = sc->sc_acpi->sc_memt;
> diff --git a/sys/dev/acpi/acpivout.c b/sys/dev/acpi/acpivout.c
> index 5fb6973f595..b63ab5a08f3 100644
> --- a/sys/dev/acpi/acpivout.c
> +++ b/sys/dev/acpi/acpivout.c
> @@ -60,6 +60,7 @@ struct acpivout_softc {
>
> int *sc_bcl;
> size_t sc_bcl_len;
> + int sc_bcl_cur;
> };
>
> void acpivout_brightness_cycle(struct acpivout_softc *);
> @@ -113,10 +114,16 @@ acpivout_attach(struct device *parent, struct device
> *self, void *aux)
> aml_register_notify(sc->sc_devnode, aaa->aaa_dev,
> acpivout_notify, sc, ACPIDEV_NOPOLL);
>
> + acpivout_get_bcl(sc);
> + if (!sc->sc_bcl_len)
> + return;
> +
> + sc->sc_bcl_cur = sc->sc_bcl[sc->sc_bcl_len - 1];
> + sc->sc_bcl_cur = acpivout_get_brightness(sc);
> + acpivout_set_brightness(sc, sc->sc_bcl_cur);
> +
> ws_get_param = acpivout_get_param;
> ws_set_param = acpivout_set_param;
> -
> - acpivout_get_bcl(sc);
> }
>
> int
> @@ -200,7 +207,9 @@ acpivout_get_brightness(struct acpivout_softc *sc)
> struct aml_value res;
> int level;
>
> - aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, );
> + if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, ))
> + return sc->sc_bcl_cur;
> +
> level = aml_val2int();
> aml_freevalue();
> DPRINTF(("%s: BQC = %d\n", DEVNAME(sc), level));
> @@ -242,6 +251,7 @@ acpivout_set_brightness(struct acpivout_softc *sc, int
> level)
> aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BCM", 1, , );
>
> aml_freevalue();
> + sc->sc_bcl_cur = level;
> }
>
> void
>
>
OpenBGPD 6.6p0 released
We have released OpenBGPD 6.6p0, which will be arriving in the OpenBGPD directory of your local OpenBSD mirror soon. This is the first stable release for the 6.6 version. It includes the following changes: * Changed the Adj-RIB-Out to a per-peer set of RB trees, improving speed. * Rewrote community matching and handling code and improved performance for setups using many communities. * Ensure that 'network 192.0.2.0/24' has precedence over the same network announced dynamically via for example 'network inet static'. * Made speed improvements when configuring many peers. * Implemented bgpctl(8) 'show mrt neighbors', to print the neighbor table of MRT TABLE_DUMP_V2 dumps. * Added TCP MD5SIG support for Linux systems and moved bgpd pfkey socket to the parent process. The refreshing of the keys for MD5 and IPSEC is done whenever the session state changes to IDLE or ACTIVE, which should behave better when reloading configs with auth changes. * Fixed reloading of network statements that have no fixed prefix specification. * Extended the maximum size of the bgpd(8) shutdown communication message to 255 bytes. * Fixed reload behaviour of announced networks in the portable version. * Include OpenBSD 6.6 errata 003: bgpd(8) can crash on nexthop changes or during startup in certain configurations. OpenBGPD-portable is known to compile and run on FreeBSD 12.x, and the Linux distributions Debian 9 and Ubuntu 14.04. It is our hope that packagers take interest and help adapt OpenBGPD-portable to more distributions. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
Re: ix(4) need support for X553
On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson wrote: > On 2019/10/31 08:25, sven falempin wrote: > > Thank you, the ./dev/pci/pcidevs_data.h, pcidevs.h are completly > removed from this > > The pcidevs update is no longer needed since pcidevs r1.1889. > > > I may have time to test it against 6.6, see if it is still working since > 6.4 (where it was > > tested, also a cross test revealed > > that plugin'/unplugging SFP maybe non functionnal) > > I can test an already-wprking fibre ix for new problems at some point, but > I don't > think I'll have a fibre X553. > > ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11 "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11 "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured When I look at them , some more involved people was talking about 10gb in OpenBSD . Isn't there some limitations currently or can we expect the X553 to perform at 10Gb ? -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: ix(4) need support for X553
On 2019/10/31 08:25, sven falempin wrote: > Thank you, the ./dev/pci/pcidevs_data.h, pcidevs.h are completly removed > from this The pcidevs update is no longer needed since pcidevs r1.1889. > I may have time to test it against 6.6, see if it is still working since 6.4 > (where it was > tested, also a cross test revealed > that plugin'/unplugging SFP maybe non functionnal) I can test an already-wprking fibre ix for new problems at some point, but I don't think I'll have a fibre X553.
Re: Opportunistic DoT for unwind(8)
On Thu, Oct 31, 2019 at 10:04:07AM +, Stuart Henderson wrote: > Writing as a note to myself to check later when I have more time as > much as anything, is there a hold-off on re-checking if there is a > cert failure (or indeed if DoT port isn't answered), or does it > re-check for every query sent upstream. Also are there excessive > delays if port 853 packets are dropped rather than rejected. > Checking a resolving strategy is decoupled from using a strategy. The global variable struct uw_resolver *resolvers[UW_RES_NONE]; stores the available resolving strategy contexts. best_resolvers() picks the best one according to res_state (VALIDATING > RESOLVING > DEAD) while also consindering the preference (default or from unwind.conf). check_resolver / check_resolver_done are running non blocking via libevent and set res_state in the the resolvers list. So the checking never blocks resolving. When a strategy is found to be DEAD we do an exponatial back-off stopping saturating at ~ 17 minutes (1024 seconds). (re-)checks are triggered when - we got a SERVFAIL for a query - we created a new resolver (config reload, new dhcp forwarders) - we got past a captive portal - we got a RTM_IFINFO on the routing socket (interface going up /down) This is of course the most important part of unwind, resolving stuff is trivial from unwind's point of view, just hand it of to libunbound. Finding out to which libunbound is the tough part. There is still room for improvement. -- I'm not entirely sure you are real.
Re: ix(4) need support for X553
On Wed, Oct 30, 2019 at 5:43 PM Stuart Henderson wrote: > On 2019/10/30 07:34, sven falempin wrote: > > https://github.com/dohnuts/wip/blob/master/ixgbe.diff > > > > Needs lots of cleaning > > > > On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann wrote: > > > > > Hello, > > > > > > I have a new Lanner NCA-1510A (with a Intel C3558) which has some > > > X553 SGMII ethernet ports. Unfortunately there is no support in ix(4) > > > for this type. > > > > > > Is anyone working on an update for the ix(4) to support the new > > > hardware? > > > > > > I took a look at the actual ix(4) and it's a bit confusing. I'm > > > not sure about the "version" of this driver compared to FreeBSD/ > > > Intel version. > > > > > > Wouldn't it be nice to have a more "stock" version of the driver. This > > > would make it much easier to port updates from FreeBSD/Intel to > OpenBSD. > > > > > > Any feedback is appreciated. > > > > > > - Joerg > > > > > Oh I've got a machine coming soon and I have a nasty feeling it's going to > have one of those .. > > That diff is stale, I've merged conflicts at > https://junkpile.org/ixgbe.diff2, > and it builds but totally untested. > > Thank you, the ./dev/pci/pcidevs_data.h, pcidevs.h are completly removed from this I may have time to test it against 6.6, see if it is still working since 6.4 (where it was tested, also a cross test revealed that plugin'/unplugging SFP maybe non functionnal) -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
acpivout(4): backlights without method to query current level
Hi,
some machines have no _BQC method, which is used to query the
current display backlight level. We can still work on those by
starting with the highest level (when there's no _BQC method)
and keeping track of the current level.
Patrick
diff --git a/sys/dev/acpi/acpivideo.c b/sys/dev/acpi/acpivideo.c
index 9498465a418..a46a99a67f7 100644
--- a/sys/dev/acpi/acpivideo.c
+++ b/sys/dev/acpi/acpivideo.c
@@ -149,7 +149,7 @@ acpi_foundvout(struct aml_node *node, void *arg)
if (node->parent != sc->sc_devnode)
return (0);
- if (aml_searchname(node, "_BCM") && aml_searchname(node, "_BQC")) {
+ if (aml_searchname(node, "_BCM")) {
memset(, 0, sizeof(aaa));
aaa.aaa_iot = sc->sc_acpi->sc_iot;
aaa.aaa_memt = sc->sc_acpi->sc_memt;
diff --git a/sys/dev/acpi/acpivout.c b/sys/dev/acpi/acpivout.c
index 5fb6973f595..b63ab5a08f3 100644
--- a/sys/dev/acpi/acpivout.c
+++ b/sys/dev/acpi/acpivout.c
@@ -60,6 +60,7 @@ struct acpivout_softc {
int *sc_bcl;
size_t sc_bcl_len;
+ int sc_bcl_cur;
};
void acpivout_brightness_cycle(struct acpivout_softc *);
@@ -113,10 +114,16 @@ acpivout_attach(struct device *parent, struct device
*self, void *aux)
aml_register_notify(sc->sc_devnode, aaa->aaa_dev,
acpivout_notify, sc, ACPIDEV_NOPOLL);
+ acpivout_get_bcl(sc);
+ if (!sc->sc_bcl_len)
+ return;
+
+ sc->sc_bcl_cur = sc->sc_bcl[sc->sc_bcl_len - 1];
+ sc->sc_bcl_cur = acpivout_get_brightness(sc);
+ acpivout_set_brightness(sc, sc->sc_bcl_cur);
+
ws_get_param = acpivout_get_param;
ws_set_param = acpivout_set_param;
-
- acpivout_get_bcl(sc);
}
int
@@ -200,7 +207,9 @@ acpivout_get_brightness(struct acpivout_softc *sc)
struct aml_value res;
int level;
- aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, );
+ if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, ))
+ return sc->sc_bcl_cur;
+
level = aml_val2int();
aml_freevalue();
DPRINTF(("%s: BQC = %d\n", DEVNAME(sc), level));
@@ -242,6 +251,7 @@ acpivout_set_brightness(struct acpivout_softc *sc, int
level)
aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BCM", 1, , );
aml_freevalue();
+ sc->sc_bcl_cur = level;
}
void
Re: Opportunistic DoT for unwind(8)
On 2019/10/31 10:18, Otto Moerbeek wrote: > On Wed, Oct 30, 2019 at 08:51:00PM +, Stuart Henderson wrote: > > > - unwind doesn't have keepalives, so it's a new TCP session and TLS > > handshake for every query, which can be bad in some cases (and could get > > expensive with metered mobile data connections). for this reason it > > would be helpful to have a way to disable it (though I suppose "block > > out proto tcp to port 853" works at a pinch). > > unwind should cache thogh, can you observe that? Yes, it does cache. (for "every query" I meant "every query sent to the forwarder") > > - several of the public DNS providers do include their IP in the certificate > > so they could be validated even when picking them up opportunistically. > > though I suppose with unwind this doesn't make a lot of difference as > > it's just going to fallback to cleartext if TLS fails. > > For any Dot mode the validity of the cert is checked, for OppDot the > trust check is only: is the cert signed by a trusted CA. We do not > know which DoT providers include a cert with an IP address, so we > cannot force a check for that. Besides that, I could not get > libunbound to accept a authentication IP like 9.9.9.9, only a name > like "quad9.net". Writing as a note to myself to check later when I have more time as much as anything, is there a hold-off on re-checking if there is a cert failure (or indeed if DoT port isn't answered), or does it re-check for every query sent upstream. Also are there excessive delays if port 853 packets are dropped rather than rejected.
Re: Opportunistic DoT for unwind(8)
On Wed, Oct 30, 2019 at 08:51:00PM +, Stuart Henderson wrote:
> On 2019/10/30 15:57, Otto Moerbeek wrote:
> > Hi,
> >
> > I got *very* little feedback on this request for testing.
> >
> > If not enough enough testing is done, I'll either abandon the diff or
> > commit it as-is, introducing bugs that could have been prevented. Both
> > are not good. So get going!
> >
> > -Otto
> >
>
> I'm pointing it at a local dnsdist box via "forwarders { $ip_address }"
> and querying unwind while watching tcpdump, I see it correctly using
> TCP/853, and status correctly says
>
> $ unwindctl status
> captive portal is unchecked
>
> selected type status
>*forwarder validating (OppDoT)
> recursor validating
>
>
>
Thanks for testing.
> Comments:
>
> - unwind doesn't have keepalives, so it's a new TCP session and TLS
> handshake for every query, which can be bad in some cases (and could get
> expensive with metered mobile data connections). for this reason it
> would be helpful to have a way to disable it (though I suppose "block
> out proto tcp to port 853" works at a pinch).
unwind should cache thogh, can you observe that?
>
> - several of the public DNS providers do include their IP in the certificate
> so they could be validated even when picking them up opportunistically.
> though I suppose with unwind this doesn't make a lot of difference as
> it's just going to fallback to cleartext if TLS fails.
For any Dot mode the validity of the cert is checked, for OppDot the
trust check is only: is the cert signed by a trusted CA. We do not
know which DoT providers include a cert with an IP address, so we
cannot force a check for that. Besides that, I could not get
libunbound to accept a authentication IP like 9.9.9.9, only a name
like "quad9.net".
>
> - might be useful to show OppDoT in the "best_resolver" line in debug logs?
>
>
>
> Sample config from the dnsdist server below for anyone interested, this
> is for 1.40rc5 but I think it'll work with the current ports version
> (1.3.3) if you remove the addDOHLocal line.
>
> --snip-
> addACL('0.0.0.0/0')
> addACL('::/0')
> newServer({address="44.33.22.11", name="upstream"})
> addLocal('11.22.33.44:53',{doTCP=true, reusePort=true})
> addTLSLocal("11.22.33.44", "/etc/ssl/xx.fullchain.pem",
> "/etc/ssl/private/xx.key",{ doTCP=true, reusePort=true })
> addDOHLocal("11.22.33.44:5343", "/etc/ssl/xx.fullchain.pem",
> "/etc/ssl/private/xx.key", "/", {doTCP=true, reusePort=true})
> pc = newPacketCache(1, {maxTTL=86400, minTTL=0, temporaryFailureTTL=60,
> staleTTL=60, dontAge=false})
> getPool(""):setCache(pc)
> --snip--
>
Yes , that should work indeed.
-Otto
Re: Opportunistic DoT for unwind(8)
On Wed, Oct 30, 2019 at 11:46:36PM +0100, Remi Locherer wrote:
> Hi Otto,
>
> On Wed, Oct 30, 2019 at 03:57:15PM +0100, Otto Moerbeek wrote:
> > Hi,
> >
> > I got *very* little feedback on this request for testing.
> >
> > If not enough enough testing is done, I'll either abandon the diff or
> > commit it as-is, introducing bugs that could have been prevented. Both
> > are not good. So get going!
> >
> > -Otto
> >
>
> I applied your diff and tried with the following config:
>
> $ unwind -nv
> preference { recursor DoT forwarder dhcp }
> forwarder {
> 9.9.9.9
> }
> captive portal {
> url "http://captive.apple.com/;
> expected status 200
> expected response
> "SuccessSuccess"
> auto yes
> }
> block list "/etc/unwind_blocklist.txt"
> $
>
> To force unwind to use 9.9.9.9 I tested with this pf rules:
>
> $ doas pfctl -sr
> doas (r...@typhoon.relo.ch) password:
> block return log all
> pass log all flags S/SA
> pass out log on egress inet from (vether0:network) to any flags S/SA nat-to
> (egress:0) round-robin
> block return in on ! lo0 proto tcp from any to any port 6000:6010
> block return out log inet proto tcp from any to ! 9.9.9.9 port = 53
> block return out log inet proto udp from any to ! 9.9.9.9 port = 53
> block return out log inet6 proto tcp from any to any port = 53
> block return out log inet6 proto udp from any to any port = 53
> block return out log proto tcp all user = 55
> block return out log proto udp all user = 55
> $
>
> As expected I can now query 9.9.9.9 but 8.8.8.8 fails:
>
> $ dig +short undeadly.org @9.9.9.9
> 94.142.241.173
> typhoon ..c/examples$ dig +short undeadly.org @8.8.8.8
> ;; connection timed out; no servers could be reached
> $
>
> I expected that unwind would choose 9.9.9.9 with OppDoT. But unwind
> selects dhcp which is correctly displayed as dead:
>
> $ unwindctl status
> captive portal is unknown
>
> selected type status
> recursor dead
> forwarder validating
>* dhcp dead
> $
>
> Port 853 on 9.9.9.9 is not blocked:
>
> $ nc -zv 9.9.9.9 853
> Connection to 9.9.9.9 853 port [tcp/domain-s] succeeded!
> $ nc -zv -u 9.9.9.9 853
> Connection to 9.9.9.9 853 port [udp/domain-s] succeeded!
> $
>
> Did I do something wrong in unwind.conf?
>
> Remi
No, you found a bug that happens if the recursor is found dead. In
that case it would switch off OppDot for forwarders as well. Next
version of the diff will have a fix.
As for the unwindctl thing, I could not reproduce that one. Dould it
be that you did not build and install usr.sbin/unwindctl? It looks
like the messaging between unwind and unwindctl is off.
-Otto
