Re: boot_macppc.8: fix file specification
On Sat, Sep 03, 2022 at 06:12:16PM +, Klemens Nanni wrote: > The current text is badly formatted and incomplete as to which optional > parts can be omitted in which way > > The file specification used is of the form: > promdev:partition/filename options > where: ???promdev??? is an optional Open Firmware device name (such as > ???hd??? > or ???ide???) and ???partition??? is an optional disk partition number. > Normal > line editing characters can be used when typing the file specification. > > 1. 'partition' seems like an artifact that is not at all parsed as such, >see sys/arch/macppc/stand/ ofwdev.c and main.c where the double colon is >parsed; the comments confirm this with > * this function is passed [device specifier]:[kernel] >and > * if the kernel image specified contains a ':' it is > * [device]:[kernel], so separate the two fields. > >Manual tests confirm this. > > 2. if promdev is given, the double-colon MUST exist. double colon? >'boot hd' tries to boot the kernel "hd" >'boot hd:' tries to boot the kernel "hd:" >'boot hd:/bsd' does what it says >'boot hd:bsd' is equivalent to the previous line since ofwboot prepends > trailing slashes; don't document to keep it simple > > 3. no vertical spacing makes the manual harder to read. > > We could zap the entire specification and rely on wording, similar to what > boot_sparc64(8) does, but I prefer fixing the specification by removing > partition from it and adding proper markup, yielding: > > The file specification used is of the form: > > [promdev:]filename [-acds] > > where promdev is an optional Open Firmware device name (such as hd or > ide). Normal line editing characters can be used when typing the file > specification. > > That should be much clearer. > > gkoehler greatly helped in confirming/testing various lines on his hardware. > > Feedback? Objection? OK? > ok by me, but you probably want a technical ok as well. jmc > NB: boot(8/macppc) also mentions this, but some parts are plain wrong... > I suggest fixing that in a separate diff. > > > Index: share/man/man8/man8.macppc/boot_macppc.8 > === > RCS file: /cvs/src/share/man/man8/man8.macppc/boot_macppc.8,v > retrieving revision 1.21 > diff -u -p -r1.21 boot_macppc.8 > --- share/man/man8/man8.macppc/boot_macppc.8 14 Feb 2014 12:18:27 - > 1.21 > +++ share/man/man8/man8.macppc/boot_macppc.8 3 Sep 2022 18:08:42 - > @@ -93,16 +93,15 @@ If the special line > is entered, the bootloader will attempt to restart the machine. > .Pp > The file specification used is of the form: > -.Dl promdev:partition/filename options > -where: > -.Dq promdev > +.Pp > +.Dl Oo Ar promdev : Oc Ns Ar filename Op Fl acds > +.Pp > +where > +.Ar promdev > is an optional Open Firmware device name (such as > .Dq hd > or > -.Dq ide ) > -and > -.Dq partition > -is an optional disk partition number. > +.Dq ide ) . > Normal line editing characters can be used when typing the file > specification. > .Pp > Index: sys/arch/macppc/stand//ofdev.c > === > RCS file: /cvs/src/sys/arch/macppc/stand/ofdev.c,v > retrieving revision 1.26 > diff -u -p -r1.26 ofdev.c > --- sys/arch/macppc/stand//ofdev.c11 Mar 2021 11:16:59 - 1.26 > +++ sys/arch/macppc/stand//ofdev.c3 Sep 2022 17:45:13 - > @@ -55,7 +55,6 @@ char opened_name[256]; > > /* > * this function is passed [device specifier]:[kernel] > - * however a device specifier may contain a ':' > */ > static int > parsename(char *str, char **file) >
Re: [please test] pvclock(4): fix several bugs
On Sat, Sep 03, 2022 at 05:33:01PM -0500, Scott Cheloha wrote:
> On Sat, Sep 03, 2022 at 10:37:31PM +1000, Jonathan Gray wrote:
> > On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > > > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> > > >
> > > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > > >> dv@ suggested coming to the list to request testing for the pvclock(4)
> > > >> driver. Attached is a patch that corrects several bugs. Most of
> > > >> these changes will only matter in the non-TSC_STABLE case on a
> > > >> multiprocessor VM.
> > > >>
> > > >> Ideally, nothing should break.
> > > >>
> > > >> - pvclock yields a 64-bit value. The BSD timecounter layer can only
> > > >> use the lower 32 bits, but internally we need to track the full
> > > >> 64-bit value to allow comparisons with the full value in the
> > > >> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity.
> > > >>
> > > >> - In pvclock_get_timecount(), move rdtsc() up into the lockless read
> > > >> loop to get a more accurate timestamp.
> > > >>
> > > >> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc().
> > > >>
> > > >> - In pvclock_get_timecount(), check that our TSC value doesn't predate
> > > >> ti->ti_tsc_timestamp, otherwise we will produce an enormous value.
> > > >>
> > > >> - In pvclock_get_timecount(), update pvclock_lastcount in the
> > > >> non-TSC_STABLE case with more care. On amd64 we can do this with an
> > > >> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need
> > > >> to introduce a mutex to protect our comparison and read/write.
> > > >
> > > > i386 has cmpxchg8b, no need to disable interrupts
> > > > the ifdefs seem excessive
> > >
> > > How do I make use of CMPXCHG8B on i386
> > > in this context?
> > >
> > > atomic_cas_ulong(9) is a 32-bit CAS on
> > > i386.
> >
> > static inline uint64_t
> > atomic_cas_64(volatile uint64_t *p, uint64_t o, uint64_t n)
> > {
> > return __sync_val_compare_and_swap(p, o, n);
> > }
> >
> > Or md atomic.h files could have an equivalent.
> > Not possible on all 32-bit archs.
> >
> > >
> > > We can't use FP registers in the kernel, no?
> >
> > What do FP registers have to do with it?
> >
> > >
> > > Am I missing some other avenue?
> >
> > There is no rdtsc_lfence() on i386. Initial diff doesn't build.
>
> LFENCE is an SSE2 extension. As is MFENCE. I don't think I can just
> drop rdtsc_lfence() into cpufunc.h and proceed without causing some
> kind of fault on an older CPU.
>
> What are my options on a 586-class CPU for forcing RDTSC to complete
> before later instructions?
"3.3.2. Serializing Operations
After executing certain instructions the Pentium processor serializes
instruction execution. This means that any modifications to flags,
registers, and memory for previous instructions are completed before
the next instruction is fetched and executed. The prefetch queue
is flushed as a result of serializing operations.
The Pentium processor serializes instruction execution after executing
one of the following instructions: Move to Special Register (except
CRO), INVD, INVLPG, IRET, IRETD, LGDT, LLDT, LIDT, LTR, WBINVD,
CPUID, RSM and WRMSR."
from:
Pentium Processor User's Manual
Volume 1: Pentium Processor Data Book
Order Number 241428
http://bitsavers.org/components/intel/pentium/1993_Intel_Pentium_Processor_Users_Manual_Volume_1.pdf
So it could be rdtsc ; cpuid.
lfence; rdtsc should still be preferred.
It could be tested during boot and set a function pointer.
Or the codepatch bits could be used.
In the specific case of pvclock, can it be assumed that the host
has hardware virt and would then have lfence?
Re: Support Wacom One S (CTL-472)
On 2022/09/03 21:37, Marcus Glocker wrote:
> On Sat, Sep 03, 2022 at 05:43:25PM +0200, Caspar Schutijser wrote:
>
> > Hi,
> >
> > On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> > > This is a better version of an earlier attempt to make my wacom tablet
> > > work. I have the tablet here in Bad Liebenzell if you want to give it a
> > > spin (on my or on your machine).
> > >
> > > Comments? OK?
> >
> > I don't feel entirely qualified to give OKs in this area so I won't do
> > that. But I tested it on my machine with sdk@'s tablet and it works well
> > here. Nice!
> >
> > Is there any chance it breaks other supported tablets? Should it be
> > tested there as well?
>
> The driver only attaches to specific products, currently
> Intuos Draw, CTL-490. So there shouldn't be too much to break I guess.
Agreed, I don't see how it can break anything that already works.
> > One whitespace nit below.
+1
also make sure to commit usbdevs first to uodate rcsid, then re-run
"make" to copy the new rcsid to the "generated from" comment before
commiting the usbdevs/usbdevs_data.j files.
OK sthen
> > Caspar
> >
> > >
> > > Best Regards,
> > > Stefan
>
> I have an Wacom One CTL-672, never used it on OpenBSD. Currently
> it attaches to ums(4). Works fine with that. It also works fine
> when attaching to uwacom(4), without and with your diff. It doesn't
> seem to require specific 'tsscale' nor 'loc_tip_press' settings.
> I wonder if it would change something.
>
> Some very few comments inline.
>
> > > Index: share/man/man4/uwacom.4
> > > ===
> > > RCS file: /cvs/src/share/man/man4/uwacom.4,v
> > > retrieving revision 1.2
> > > diff -u -p -u -p -r1.2 uwacom.4
> > > --- share/man/man4/uwacom.4 12 Sep 2016 10:39:06 - 1.2
> > > +++ share/man/man4/uwacom.4 1 Sep 2022 19:57:37 -
> > > @@ -42,6 +42,7 @@ driver supports the following Wacom tabl
> > > .Bl -column "Intuos Draw" "Model Number" -offset 6n
> > > .It Em Name Ta Em Model Number
> > > .It Li Intuos Draw Ta CTL-490
> > > +.It Li One Ta CTL-472
>
> Shouldn't that be 'One S'?
>
> > > .El
> > > .Sh SEE ALSO
> > > .Xr uhidev 4 ,
> > > Index: sys/dev/usb/usbdevs
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> > > retrieving revision 1.748
> > > diff -u -p -u -p -r1.748 usbdevs
> > > --- sys/dev/usb/usbdevs 23 Aug 2022 08:10:35 - 1.748
> > > +++ sys/dev/usb/usbdevs 1 Sep 2022 19:57:38 -
> > > @@ -4613,6 +4613,7 @@ product WACOM GRAPHIRE3_4X5 0x0013 Graph
> > > product WACOM GRAPHIRE4_4X5 0x0015 Graphire4 Classic A6
> > > product WACOM INTUOSA5 0x0021 Intuos A5
> > > product WACOM INTUOS_DRAW0x033b Intuos Draw (CTL-490)
> > > +product WACOM ONE_S 0x037a One S (CTL-472)
> > > product WACOM INTUOS_PRO_S 0x0392 Intuos Pro S
> > >
> > > /* WAGO Kontakttechnik products */
> > > Index: sys/dev/usb/usbdevs.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> > > retrieving revision 1.760
> > > diff -u -p -u -p -r1.760 usbdevs.h
> > > --- sys/dev/usb/usbdevs.h 23 Aug 2022 08:11:01 - 1.760
> > > +++ sys/dev/usb/usbdevs.h 1 Sep 2022 19:57:38 -
> > > @@ -1,4 +1,4 @@
> > > -/* $OpenBSD: usbdevs.h,v 1.760 2022/08/23 08:11:01 jsg Exp $
> > > */
> > > +/* $OpenBSD$ */
> > >
> > > /*
> > > * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> > > @@ -4620,6 +4620,7 @@
> > > #define USB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015 /* Graphire4
> > > Classic A6 */
> > > #define USB_PRODUCT_WACOM_INTUOSA5 0x0021 /* Intuos A5 */
> > > #define USB_PRODUCT_WACOM_INTUOS_DRAW 0x033b /* Intuos Draw
> > > (CTL-490) */
> > > +#define USB_PRODUCT_WACOM_ONE_S 0x037a /* One S (CTL-472) */
> > > #define USB_PRODUCT_WACOM_INTUOS_PRO_S 0x0392 /* Intuos Pro S
> > > */
> > >
> > > /* WAGO Kontakttechnik products */
> > > Index: sys/dev/usb/usbdevs_data.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> > > retrieving revision 1.754
> > > diff -u -p -u -p -r1.754 usbdevs_data.h
> > > --- sys/dev/usb/usbdevs_data.h23 Aug 2022 08:11:01 - 1.754
> > > +++ sys/dev/usb/usbdevs_data.h1 Sep 2022 19:57:39 -
> > > @@ -1,4 +1,4 @@
> > > -/* $OpenBSD: usbdevs_data.h,v 1.754 2022/08/23 08:11:01 jsg Exp $
> > > */
> > > +/* $OpenBSD$ */
> > >
> > > /*
> > > * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> > > @@ -11824,6 +11824,10 @@ const struct usb_known_product usb_known
> > > {
> > > USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW,
> > > "Intuos Draw (CTL-490)",
> > > + },
> > > + {
> > > + USB_VENDOR_WACOM, USB_PRODUCT_WACOM_ONE_S,
Re: soreceive with shared netlock
> On 3 Sep 2022, at 23:47, Alexander Bluhm wrote:
>
> Hi,
>
> The next small step towards parallel network stack is to use shared
> netlock in soreceive(). The UDP and IP divert layer provide locking
> of the PCB. If that is possible, use shared instead of exclusive
> netlock in soreceive(). The PCB mutex provides a per socket lock
> against multiple soreceive() running in parallel.
>
> The solock_shared() is a bit hacky. Especially where we have to
> release and regrab both locks in sosleep_nsec(). But it does what
> we need.
>
> The udp_input() keeps exclusive lock for now. Socket splicing and
> IP header chains are not completely MP safe yet. Also udp_input()
> has some tentacles that need more testing.
>
> Ok to procceed with soreceive() unlocking before release? I think
> udp_input() has to wait post 7.2.
>
I have no objections.
> bluhm
>
> Index: kern/uipc_socket.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.287
> diff -u -p -r1.287 uipc_socket.c
> --- kern/uipc_socket.c3 Sep 2022 13:29:33 - 1.287
> +++ kern/uipc_socket.c3 Sep 2022 19:23:43 -
> @@ -822,10 +822,10 @@ bad:
> if (mp)
> *mp = NULL;
>
> - solock(so);
> + solock_shared(so);
> restart:
> if ((error = sblock(so, >so_rcv, SBLOCKWAIT(flags))) != 0) {
> - sounlock(so);
> + sounlock_shared(so);
> return (error);
> }
>
> @@ -893,7 +893,7 @@ restart:
> sbunlock(so, >so_rcv);
> error = sbwait(so, >so_rcv);
> if (error) {
> - sounlock(so);
> + sounlock_shared(so);
> return (error);
> }
> goto restart;
> @@ -962,11 +962,11 @@ dontblock:
> sbsync(>so_rcv, nextrecord);
> if (controlp) {
> if (pr->pr_domain->dom_externalize) {
> - sounlock(so);
> + sounlock_shared(so);
> error =
> (*pr->pr_domain->dom_externalize)
> (cm, controllen, flags);
> - solock(so);
> + solock_shared(so);
> }
> *controlp = cm;
> } else {
> @@ -1040,9 +1040,9 @@ dontblock:
> SBLASTRECORDCHK(>so_rcv, "soreceive uiomove");
> SBLASTMBUFCHK(>so_rcv, "soreceive uiomove");
> resid = uio->uio_resid;
> - sounlock(so);
> + sounlock_shared(so);
> uio_error = uiomove(mtod(m, caddr_t) + moff, len, uio);
> - solock(so);
> + solock_shared(so);
> if (uio_error)
> uio->uio_resid = resid - len;
> } else
> @@ -1126,7 +1126,7 @@ dontblock:
> error = sbwait(so, >so_rcv);
> if (error) {
> sbunlock(so, >so_rcv);
> - sounlock(so);
> + sounlock_shared(so);
> return (0);
> }
> if ((m = so->so_rcv.sb_mb) != NULL)
> @@ -1171,7 +1171,7 @@ dontblock:
> *flagsp |= flags;
> release:
> sbunlock(so, >so_rcv);
> - sounlock(so);
> + sounlock_shared(so);
> return (error);
> }
>
> Index: kern/uipc_socket2.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.127
> diff -u -p -r1.127 uipc_socket2.c
> --- kern/uipc_socket2.c 13 Aug 2022 21:01:46 - 1.127
> +++ kern/uipc_socket2.c 3 Sep 2022 19:23:43 -
> @@ -360,6 +360,24 @@ solock(struct socket *so)
> }
> }
>
> +void
> +solock_shared(struct socket *so)
> +{
> + switch (so->so_proto->pr_domain->dom_family) {
> + case PF_INET:
> + case PF_INET6:
> + if (so->so_proto->pr_usrreqs->pru_lock != NULL) {
> + NET_LOCK_SHARED();
> + pru_lock(so);
> + } else
> + NET_LOCK();
> + break;
> + default:
> + rw_enter_write(>so_lock);
> + break;
> + }
> +}
> +
> int
> solock_persocket(struct socket *so)
> {
> @@ -403,6 +421,24 @@ sounlock(struct socket *so)
> }
>
> void
> +sounlock_shared(struct socket *so)
> +{
> + switch (so->so_proto->pr_domain->dom_family) {
> + case PF_INET:
> + case PF_INET6:
> + if
/etc/rc.d/iked regression after r1.9
Hello tech@,
commit r1.9 removed the rc_exec call in iked's rc_pre. Because of that,
the exit code of rc_pre is that of the && list. In the case of
sasyncd_flags=NO, this means that rc_pre fails and triggers the break
in the while true loop in rc_cmd start case. I solved this using the
same approach as in isakmpd rc file: hardcoding a return 0 afterwards.
The other alternative is using an if instead of && list, idiom which I
prefer, but haven't seen much in these files.
-Lucas
diff /usr/src
commit - a300f670c8e17f72646e4eaedfbfeb3ce01a295f
path + /usr/src
blob - 8cfb786e6a883c83d4d27de65fb55ce894632cab
file + etc/rc.d/iked
--- etc/rc.d/iked
+++ etc/rc.d/iked
@@ -15,6 +15,7 @@ rc_configtest() {
rc_pre() {
[[ ${sasyncd_flags} != NO ]] &&
daemon_flags="-S ${daemon_flags}"
+ return 0
}
rc_cmd $1
Re: [please test] pvclock(4): fix several bugs
On Sat, Sep 03, 2022 at 10:37:31PM +1000, Jonathan Gray wrote:
> On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> > >
> > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > >> dv@ suggested coming to the list to request testing for the pvclock(4)
> > >> driver. Attached is a patch that corrects several bugs. Most of
> > >> these changes will only matter in the non-TSC_STABLE case on a
> > >> multiprocessor VM.
> > >>
> > >> Ideally, nothing should break.
> > >>
> > >> - pvclock yields a 64-bit value. The BSD timecounter layer can only
> > >> use the lower 32 bits, but internally we need to track the full
> > >> 64-bit value to allow comparisons with the full value in the
> > >> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity.
> > >>
> > >> - In pvclock_get_timecount(), move rdtsc() up into the lockless read
> > >> loop to get a more accurate timestamp.
> > >>
> > >> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc().
> > >>
> > >> - In pvclock_get_timecount(), check that our TSC value doesn't predate
> > >> ti->ti_tsc_timestamp, otherwise we will produce an enormous value.
> > >>
> > >> - In pvclock_get_timecount(), update pvclock_lastcount in the
> > >> non-TSC_STABLE case with more care. On amd64 we can do this with an
> > >> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need
> > >> to introduce a mutex to protect our comparison and read/write.
> > >
> > > i386 has cmpxchg8b, no need to disable interrupts
> > > the ifdefs seem excessive
> >
> > How do I make use of CMPXCHG8B on i386
> > in this context?
> >
> > atomic_cas_ulong(9) is a 32-bit CAS on
> > i386.
>
> static inline uint64_t
> atomic_cas_64(volatile uint64_t *p, uint64_t o, uint64_t n)
> {
> return __sync_val_compare_and_swap(p, o, n);
> }
>
> Or md atomic.h files could have an equivalent.
> Not possible on all 32-bit archs.
>
> >
> > We can't use FP registers in the kernel, no?
>
> What do FP registers have to do with it?
>
> >
> > Am I missing some other avenue?
>
> There is no rdtsc_lfence() on i386. Initial diff doesn't build.
LFENCE is an SSE2 extension. As is MFENCE. I don't think I can just
drop rdtsc_lfence() into cpufunc.h and proceed without causing some
kind of fault on an older CPU.
What are my options on a 586-class CPU for forcing RDTSC to complete
before later instructions?
Re: move PRU_PEERADDR request to (*pru_peeraddr)()
On Sat, Sep 03, 2022 at 10:29:14PM +0300, Vitaliy Makkoveev wrote:
> The last one.
>
> As for the previous PRU_SOCKADDR, introduce in{,6}_peeraddr() and use it
> for inet and inet sockets, except tcp(4).
>
> Also remove *_usrreq() handlers. This makes diff bigger, but I guess we
> don't want to commit code like below:
OK bluhm@
> Index: sys/kern/uipc_usrreq.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
> retrieving revision 1.184
> diff -u -p -r1.184 uipc_usrreq.c
> --- sys/kern/uipc_usrreq.c3 Sep 2022 18:48:49 - 1.184
> +++ sys/kern/uipc_usrreq.c3 Sep 2022 19:50:49 -
> @@ -127,7 +127,6 @@ int unp_defer; /* [G] number of deferred
> int unp_gcing; /* [G] GC task currently running */
>
> const struct pr_usrreqs uipc_usrreqs = {
> - .pru_usrreq = uipc_usrreq,
> .pru_attach = uipc_attach,
> .pru_detach = uipc_detach,
> .pru_bind = uipc_bind,
> @@ -141,6 +140,7 @@ const struct pr_usrreqs uipc_usrreqs = {
> .pru_abort = uipc_abort,
> .pru_sense = uipc_sense,
> .pru_sockaddr = uipc_sockaddr,
> + .pru_peeraddr = uipc_peeraddr,
> .pru_connect2 = uipc_connect2,
> };
>
> @@ -212,46 +212,6 @@ uipc_setaddr(const struct unpcb *unp, st
> }
> }
>
> -int
> -uipc_usrreq(struct socket *so, int req, struct mbuf *m, struct mbuf *nam,
> -struct mbuf *control, struct proc *p)
> -{
> - struct unpcb *unp = sotounpcb(so);
> - struct socket *so2;
> - int error = 0;
> -
> - if (req != PRU_SEND && control && control->m_len) {
> - error = EOPNOTSUPP;
> - goto release;
> - }
> - if (unp == NULL) {
> - error = EINVAL;
> - goto release;
> - }
> -
> - switch (req) {
> -
> - case PRU_PEERADDR:
> - so2 = unp_solock_peer(so);
> - uipc_setaddr(unp->unp_conn, nam);
> - if (so2 != NULL && so2 != so)
> - sounlock(so2);
> - break;
> -
> - case PRU_SLOWTIMO:
> - break;
> -
> - default:
> - panic("uipc_usrreq");
> - }
> -release:
> - if (req != PRU_RCVD && req != PRU_RCVOOB && req != PRU_SENSE) {
> - m_freem(control);
> - m_freem(m);
> - }
> - return (error);
> -}
> -
> /*
> * Both send and receive buffers are allocated PIPSIZ bytes of buffering
> * for stream sockets, although the total for sender and receiver is
> @@ -582,6 +542,19 @@ uipc_sockaddr(struct socket *so, struct
> struct unpcb *unp = sotounpcb(so);
>
> uipc_setaddr(unp, nam);
> + return (0);
> +}
> +
> +int
> +uipc_peeraddr(struct socket *so, struct mbuf *nam)
> +{
> + struct unpcb *unp = sotounpcb(so);
> + struct socket *so2;
> +
> + so2 = unp_solock_peer(so);
> + uipc_setaddr(unp->unp_conn, nam);
> + if (so2 != NULL && so2 != so)
> + sounlock(so2);
> return (0);
> }
>
> Index: sys/net/pfkeyv2.c
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.251
> diff -u -p -r1.251 pfkeyv2.c
> --- sys/net/pfkeyv2.c 3 Sep 2022 18:48:50 - 1.251
> +++ sys/net/pfkeyv2.c 3 Sep 2022 19:50:49 -
> @@ -177,8 +177,7 @@ int pfkeyv2_send(struct socket *, struct
> struct mbuf *);
> int pfkeyv2_abort(struct socket *);
> int pfkeyv2_sockaddr(struct socket *, struct mbuf *);
> -int pfkeyv2_usrreq(struct socket *, int, struct mbuf *, struct mbuf *,
> -struct mbuf *, struct proc *);
> +int pfkeyv2_peeraddr(struct socket *, struct mbuf *);
> int pfkeyv2_output(struct mbuf *, struct socket *);
> int pfkey_sendup(struct pkpcb *, struct mbuf *, int);
> int pfkeyv2_sa_flush(struct tdb *, void *, int);
> @@ -205,7 +204,6 @@ pfdatatopacket(void *data, int len, stru
> }
>
> const struct pr_usrreqs pfkeyv2_usrreqs = {
> - .pru_usrreq = pfkeyv2_usrreq,
> .pru_attach = pfkeyv2_attach,
> .pru_detach = pfkeyv2_detach,
> .pru_disconnect = pfkeyv2_disconnect,
> @@ -213,6 +211,7 @@ const struct pr_usrreqs pfkeyv2_usrreqs
> .pru_send = pfkeyv2_send,
> .pru_abort = pfkeyv2_abort,
> .pru_sockaddr = pfkeyv2_sockaddr,
> + .pru_peeraddr = pfkeyv2_peeraddr,
> };
>
> const struct protosw pfkeysw[] = {
> @@ -397,42 +396,12 @@ pfkeyv2_sockaddr(struct socket *so, stru
> }
>
> int
> -pfkeyv2_usrreq(struct socket *so, int req, struct mbuf *m,
> -struct mbuf *nam, struct mbuf *control, struct proc *p)
> +pfkeyv2_peeraddr(struct socket *so, struct mbuf *nam)
> {
> - struct pkpcb *kp;
> - int error = 0;
> -
> - soassertlocked(so);
> -
> - if (control && control->m_len) {
> - error = EOPNOTSUPP;
> - goto release;
> - }
> -
> - kp = sotokeycb(so);
> - if (kp == NULL) {
> - error = EINVAL;
Re: soreceive with shared netlock
> On 4 Sep 2022, at 00:56, Alexander Bluhm wrote: > > On Sat, Sep 03, 2022 at 11:20:17PM +0200, Hrvoje Popovski wrote: >> with this diff while booting I'm getting this witness trace > > It is not related to soreceive() diff, but TCP diff I commited > before. I forgot a mutex initalization which is fatal with witness. > Fix below. > ok mvs@ > bluhm > > Index: netinet/tcp_subr.c > === > RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_subr.c,v > retrieving revision 1.187 > diff -u -p -r1.187 tcp_subr.c > --- netinet/tcp_subr.c3 Sep 2022 19:22:19 - 1.187 > +++ netinet/tcp_subr.c3 Sep 2022 21:54:48 - > @@ -105,7 +105,7 @@ > *T tcp_timer_mtx global tcp timer data structures > */ > > -struct mutex tcp_timer_mtx; > +struct mutex tcp_timer_mtx = MUTEX_INITIALIZER(IPL_SOFTNET); > > /* patchable/settable parameters for tcp */ > int tcp_mssdflt = TCP_MSS; >
Re: soreceive with shared netlock
On Sat, Sep 03, 2022 at 11:20:17PM +0200, Hrvoje Popovski wrote: > with this diff while booting I'm getting this witness trace It is not related to soreceive() diff, but TCP diff I commited before. I forgot a mutex initalization which is fatal with witness. Fix below. bluhm Index: netinet/tcp_subr.c === RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.187 diff -u -p -r1.187 tcp_subr.c --- netinet/tcp_subr.c 3 Sep 2022 19:22:19 - 1.187 +++ netinet/tcp_subr.c 3 Sep 2022 21:54:48 - @@ -105,7 +105,7 @@ * T tcp_timer_mtx global tcp timer data structures */ -struct mutex tcp_timer_mtx; +struct mutex tcp_timer_mtx = MUTEX_INITIALIZER(IPL_SOFTNET); /* patchable/settable parameters for tcp */ inttcp_mssdflt = TCP_MSS;
Re: soreceive with shared netlock
On 3.9.2022. 22:47, Alexander Bluhm wrote: > Hi, > > The next small step towards parallel network stack is to use shared > netlock in soreceive(). The UDP and IP divert layer provide locking > of the PCB. If that is possible, use shared instead of exclusive > netlock in soreceive(). The PCB mutex provides a per socket lock > against multiple soreceive() running in parallel. > > The solock_shared() is a bit hacky. Especially where we have to > release and regrab both locks in sosleep_nsec(). But it does what > we need. > > The udp_input() keeps exclusive lock for now. Socket splicing and > IP header chains are not completely MP safe yet. Also udp_input() > has some tentacles that need more testing. > > Ok to procceed with soreceive() unlocking before release? I think > udp_input() has to wait post 7.2. Hi, with this diff while booting I'm getting this witness trace iic0 at ichiic0 isa0 at pcib0 isadma0 at isa0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vmm0 at mainbus0: VMX/EPT witness: lock_object uninitialized: 0x82379880 Starting stack trace... witness_checkorder(82379880,9,0,82379880,8a214bc08a1c5075,822b0ff0) at witness_checkorder+0xad mtx_enter(82379870,82379870,6e3a311a0ad2ae1e,82097020,824c12c0,9) at mtx_enter+0x34 tcp_slowtimo(812dd160,800020bf3110,82379870,82379870,6e3a311a0ad2ae1e,82097020) at tcp_slowtimo+0x10 pfslowtimo(824c12c0,824c12c0,824c12c0,81ed1820,822b3148,d) at pfslowtimo+0xc7 timeout_run(824c12c0,824c12c0,82301e90,800020bf31a0,81277b90,82301e90) at timeout_run+0x93 softclock_thread(800020be2fc0,800020be2fc0,0,0,0,4) at softclock_thread+0x11d end trace frame: 0x0, count: 251 End of stack trace.
Re: rpki-client: fix todo item about freeing in parser process
On Sat, Sep 03, 2022 at 08:42:53PM +, Job Snijders wrote:
> Found a small todo item in proc_parser() to free the entries in the auth
> and crl trees.
Reworked the diff to retain RB_GENERATE_STATIC() scope
OK?
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.88
diff -u -p -r1.88 cert.c
--- cert.c 3 Sep 2022 14:40:09 - 1.88
+++ cert.c 3 Sep 2022 20:58:55 -
@@ -978,6 +978,17 @@ authcmp(struct auth *a, struct auth *b)
RB_GENERATE_STATIC(auth_tree, auth, entry, authcmp);
+void
+authtree_free(struct auth_tree *auths)
+{
+ struct auth *auth, *tauth;
+
+ RB_FOREACH_SAFE(auth, auth_tree, auths, tauth) {
+ RB_REMOVE(auth_tree, auths, auth);
+ free(auth);
+ }
+}
+
struct auth *
auth_find(struct auth_tree *auths, const char *aki)
{
Index: crl.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/crl.c,v
retrieving revision 1.15
diff -u -p -r1.15 crl.c
--- crl.c 21 Apr 2022 09:53:07 - 1.15
+++ crl.c 3 Sep 2022 20:58:55 -
@@ -118,3 +118,14 @@ crl_free(struct crl *crl)
X509_CRL_free(crl->x509_crl);
free(crl);
}
+
+void
+crltree_free(struct crl_tree *crlt)
+{
+ struct crl *crl, *tcrl;
+
+ RB_FOREACH_SAFE(crl, crl_tree, crlt, tcrl) {
+ RB_REMOVE(crl_tree, crlt, crl);
+ free(crl);
+ }
+}
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.155
diff -u -p -r1.155 extern.h
--- extern.h3 Sep 2022 14:40:09 - 1.155
+++ extern.h3 Sep 2022 20:58:58 -
@@ -511,6 +511,7 @@ struct tal *tal_read(struct ibuf *);
voidcert_buffer(struct ibuf *, const struct cert *);
voidcert_free(struct cert *);
+voidauthtree_free(struct auth_tree *);
struct cert*cert_parse_ee_cert(const char *, X509 *);
struct cert*cert_parse_pre(const char *, const unsigned char *, size_t);
struct cert*cert_parse(const char *, struct cert *);
@@ -556,6 +557,7 @@ struct crl *crl_parse(const char *, cons
struct crl *crl_get(struct crl_tree *, const struct auth *);
int crl_insert(struct crl_tree *, struct crl *);
voidcrl_free(struct crl *);
+voidcrltree_free(struct crl_tree *);
/* Validation of our objects. */
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.76
diff -u -p -r1.76 parser.c
--- parser.c3 Sep 2022 13:30:27 - 1.76
+++ parser.c3 Sep 2022 20:58:59 -
@@ -744,7 +744,8 @@ proc_parser(int fd)
entity_free(entp);
}
- /* XXX free auths and crl tree */
+ authtree_free();
+ crltree_free();
X509_STORE_CTX_free(ctx);
msgbuf_clear();
soreceive with shared netlock
Hi,
The next small step towards parallel network stack is to use shared
netlock in soreceive(). The UDP and IP divert layer provide locking
of the PCB. If that is possible, use shared instead of exclusive
netlock in soreceive(). The PCB mutex provides a per socket lock
against multiple soreceive() running in parallel.
The solock_shared() is a bit hacky. Especially where we have to
release and regrab both locks in sosleep_nsec(). But it does what
we need.
The udp_input() keeps exclusive lock for now. Socket splicing and
IP header chains are not completely MP safe yet. Also udp_input()
has some tentacles that need more testing.
Ok to procceed with soreceive() unlocking before release? I think
udp_input() has to wait post 7.2.
bluhm
Index: kern/uipc_socket.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.287
diff -u -p -r1.287 uipc_socket.c
--- kern/uipc_socket.c 3 Sep 2022 13:29:33 - 1.287
+++ kern/uipc_socket.c 3 Sep 2022 19:23:43 -
@@ -822,10 +822,10 @@ bad:
if (mp)
*mp = NULL;
- solock(so);
+ solock_shared(so);
restart:
if ((error = sblock(so, >so_rcv, SBLOCKWAIT(flags))) != 0) {
- sounlock(so);
+ sounlock_shared(so);
return (error);
}
@@ -893,7 +893,7 @@ restart:
sbunlock(so, >so_rcv);
error = sbwait(so, >so_rcv);
if (error) {
- sounlock(so);
+ sounlock_shared(so);
return (error);
}
goto restart;
@@ -962,11 +962,11 @@ dontblock:
sbsync(>so_rcv, nextrecord);
if (controlp) {
if (pr->pr_domain->dom_externalize) {
- sounlock(so);
+ sounlock_shared(so);
error =
(*pr->pr_domain->dom_externalize)
(cm, controllen, flags);
- solock(so);
+ solock_shared(so);
}
*controlp = cm;
} else {
@@ -1040,9 +1040,9 @@ dontblock:
SBLASTRECORDCHK(>so_rcv, "soreceive uiomove");
SBLASTMBUFCHK(>so_rcv, "soreceive uiomove");
resid = uio->uio_resid;
- sounlock(so);
+ sounlock_shared(so);
uio_error = uiomove(mtod(m, caddr_t) + moff, len, uio);
- solock(so);
+ solock_shared(so);
if (uio_error)
uio->uio_resid = resid - len;
} else
@@ -1126,7 +1126,7 @@ dontblock:
error = sbwait(so, >so_rcv);
if (error) {
sbunlock(so, >so_rcv);
- sounlock(so);
+ sounlock_shared(so);
return (0);
}
if ((m = so->so_rcv.sb_mb) != NULL)
@@ -1171,7 +1171,7 @@ dontblock:
*flagsp |= flags;
release:
sbunlock(so, >so_rcv);
- sounlock(so);
+ sounlock_shared(so);
return (error);
}
Index: kern/uipc_socket2.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.127
diff -u -p -r1.127 uipc_socket2.c
--- kern/uipc_socket2.c 13 Aug 2022 21:01:46 - 1.127
+++ kern/uipc_socket2.c 3 Sep 2022 19:23:43 -
@@ -360,6 +360,24 @@ solock(struct socket *so)
}
}
+void
+solock_shared(struct socket *so)
+{
+ switch (so->so_proto->pr_domain->dom_family) {
+ case PF_INET:
+ case PF_INET6:
+ if (so->so_proto->pr_usrreqs->pru_lock != NULL) {
+ NET_LOCK_SHARED();
+ pru_lock(so);
+ } else
+ NET_LOCK();
+ break;
+ default:
+ rw_enter_write(>so_lock);
+ break;
+ }
+}
+
int
solock_persocket(struct socket *so)
{
@@ -403,6 +421,24 @@ sounlock(struct socket *so)
}
void
+sounlock_shared(struct socket *so)
+{
+ switch (so->so_proto->pr_domain->dom_family) {
+ case PF_INET:
+ case PF_INET6:
+ if (so->so_proto->pr_usrreqs->pru_unlock != NULL) {
+ pru_unlock(so);
+ NET_UNLOCK_SHARED();
+ } else
+ NET_UNLOCK();
+ break;
+ default:
+
rpki-client: fix todo item about freeing in parser process
Found a small todo item in proc_parser() to free the entries in the auth
and crl trees.
OK?
Kind regards,
Job
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.88
diff -u -p -r1.88 cert.c
--- cert.c 3 Sep 2022 14:40:09 - 1.88
+++ cert.c 3 Sep 2022 20:34:19 -
@@ -976,7 +976,7 @@ authcmp(struct auth *a, struct auth *b)
return strcmp(a->cert->ski, b->cert->ski);
}
-RB_GENERATE_STATIC(auth_tree, auth, entry, authcmp);
+RB_GENERATE(auth_tree, auth, entry, authcmp);
struct auth *
auth_find(struct auth_tree *auths, const char *aki)
Index: crl.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/crl.c,v
retrieving revision 1.15
diff -u -p -r1.15 crl.c
--- crl.c 21 Apr 2022 09:53:07 - 1.15
+++ crl.c 3 Sep 2022 20:34:19 -
@@ -87,7 +87,7 @@ crlcmp(struct crl *a, struct crl *b)
return strcmp(a->aki, b->aki);
}
-RB_GENERATE_STATIC(crl_tree, crl, entry, crlcmp);
+RB_GENERATE(crl_tree, crl, entry, crlcmp);
/*
* Find a CRL based on the auth SKI value.
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.155
diff -u -p -r1.155 extern.h
--- extern.h3 Sep 2022 14:40:09 - 1.155
+++ extern.h3 Sep 2022 20:34:20 -
@@ -372,6 +372,7 @@ struct crl {
* Tree of CRLs sorted by uri
*/
RB_HEAD(crl_tree, crl);
+RB_PROTOTYPE(crl_tree, crl, entry, crlcmp);
/*
* An authentication tuple.
@@ -387,6 +388,7 @@ struct auth {
* Tree of auth sorted by ski
*/
RB_HEAD(auth_tree, auth);
+RB_PROTOTYPE(auth_tree, auth, entry, authcmp);
struct auth*auth_find(struct auth_tree *, const char *);
struct auth*auth_insert(struct auth_tree *, struct cert *, struct auth *);
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.76
diff -u -p -r1.76 parser.c
--- parser.c3 Sep 2022 13:30:27 - 1.76
+++ parser.c3 Sep 2022 20:34:20 -
@@ -675,6 +675,8 @@ proc_parser(int fd)
struct pollfdpfd;
struct entity *entp;
struct ibuf *b, *inbuf = NULL;
+ struct auth *auth, *tauth;
+ struct crl *crl, *tcrl;
/* Only allow access to the cache directory. */
if (unveil(".", "r") == -1)
@@ -744,7 +746,15 @@ proc_parser(int fd)
entity_free(entp);
}
- /* XXX free auths and crl tree */
+ RB_FOREACH_SAFE(auth, auth_tree, , tauth) {
+ RB_REMOVE(auth_tree, , auth);
+ free(auth);
+ }
+
+ RB_FOREACH_SAFE(crl, crl_tree, , tcrl) {
+ RB_REMOVE(crl_tree, , crl);
+ free(crl);
+ }
X509_STORE_CTX_free(ctx);
msgbuf_clear();
move PRU_PEERADDR request to (*pru_peeraddr)()
The last one.
As for the previous PRU_SOCKADDR, introduce in{,6}_peeraddr() and use it
for inet and inet sockets, except tcp(4).
Also remove *_usrreq() handlers. This makes diff bigger, but I guess we
don't want to commit code like below:
rip_usrreq(struct socket *so, int req, struct mbuf *m, struct mbuf *nam,
struct mbuf *control, struct proc *p)
{
struct inpcb *inp;
int error = 0;
soassertlocked(so);
inp = sotoinpcb(so);
if (inp == NULL) {
error = EINVAL;
goto release;
}
switch (req) {
default:
panic("rip_usrreq");
}
release:
if (req != PRU_RCVD && req != PRU_RCVOOB && req != PRU_SENSE) {
m_freem(control);
m_freem(m);
}
return (error);
}
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.184
diff -u -p -r1.184 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 3 Sep 2022 18:48:49 - 1.184
+++ sys/kern/uipc_usrreq.c 3 Sep 2022 19:50:49 -
@@ -127,7 +127,6 @@ int unp_defer; /* [G] number of deferred
intunp_gcing; /* [G] GC task currently running */
const struct pr_usrreqs uipc_usrreqs = {
- .pru_usrreq = uipc_usrreq,
.pru_attach = uipc_attach,
.pru_detach = uipc_detach,
.pru_bind = uipc_bind,
@@ -141,6 +140,7 @@ const struct pr_usrreqs uipc_usrreqs = {
.pru_abort = uipc_abort,
.pru_sense = uipc_sense,
.pru_sockaddr = uipc_sockaddr,
+ .pru_peeraddr = uipc_peeraddr,
.pru_connect2 = uipc_connect2,
};
@@ -212,46 +212,6 @@ uipc_setaddr(const struct unpcb *unp, st
}
}
-int
-uipc_usrreq(struct socket *so, int req, struct mbuf *m, struct mbuf *nam,
-struct mbuf *control, struct proc *p)
-{
- struct unpcb *unp = sotounpcb(so);
- struct socket *so2;
- int error = 0;
-
- if (req != PRU_SEND && control && control->m_len) {
- error = EOPNOTSUPP;
- goto release;
- }
- if (unp == NULL) {
- error = EINVAL;
- goto release;
- }
-
- switch (req) {
-
- case PRU_PEERADDR:
- so2 = unp_solock_peer(so);
- uipc_setaddr(unp->unp_conn, nam);
- if (so2 != NULL && so2 != so)
- sounlock(so2);
- break;
-
- case PRU_SLOWTIMO:
- break;
-
- default:
- panic("uipc_usrreq");
- }
-release:
- if (req != PRU_RCVD && req != PRU_RCVOOB && req != PRU_SENSE) {
- m_freem(control);
- m_freem(m);
- }
- return (error);
-}
-
/*
* Both send and receive buffers are allocated PIPSIZ bytes of buffering
* for stream sockets, although the total for sender and receiver is
@@ -582,6 +542,19 @@ uipc_sockaddr(struct socket *so, struct
struct unpcb *unp = sotounpcb(so);
uipc_setaddr(unp, nam);
+ return (0);
+}
+
+int
+uipc_peeraddr(struct socket *so, struct mbuf *nam)
+{
+ struct unpcb *unp = sotounpcb(so);
+ struct socket *so2;
+
+ so2 = unp_solock_peer(so);
+ uipc_setaddr(unp->unp_conn, nam);
+ if (so2 != NULL && so2 != so)
+ sounlock(so2);
return (0);
}
Index: sys/net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.251
diff -u -p -r1.251 pfkeyv2.c
--- sys/net/pfkeyv2.c 3 Sep 2022 18:48:50 - 1.251
+++ sys/net/pfkeyv2.c 3 Sep 2022 19:50:49 -
@@ -177,8 +177,7 @@ int pfkeyv2_send(struct socket *, struct
struct mbuf *);
int pfkeyv2_abort(struct socket *);
int pfkeyv2_sockaddr(struct socket *, struct mbuf *);
-int pfkeyv2_usrreq(struct socket *, int, struct mbuf *, struct mbuf *,
-struct mbuf *, struct proc *);
+int pfkeyv2_peeraddr(struct socket *, struct mbuf *);
int pfkeyv2_output(struct mbuf *, struct socket *);
int pfkey_sendup(struct pkpcb *, struct mbuf *, int);
int pfkeyv2_sa_flush(struct tdb *, void *, int);
@@ -205,7 +204,6 @@ pfdatatopacket(void *data, int len, stru
}
const struct pr_usrreqs pfkeyv2_usrreqs = {
- .pru_usrreq = pfkeyv2_usrreq,
.pru_attach = pfkeyv2_attach,
.pru_detach = pfkeyv2_detach,
.pru_disconnect = pfkeyv2_disconnect,
@@ -213,6 +211,7 @@ const struct pr_usrreqs pfkeyv2_usrreqs
.pru_send = pfkeyv2_send,
.pru_abort = pfkeyv2_abort,
.pru_sockaddr = pfkeyv2_sockaddr,
+ .pru_peeraddr = pfkeyv2_peeraddr,
};
const struct protosw pfkeysw[] = {
@@ -397,42 +396,12 @@ pfkeyv2_sockaddr(struct socket *so, stru
}
int
-pfkeyv2_usrreq(struct socket *so, int req, struct mbuf *m,
-struct mbuf *nam, struct mbuf *control, struct proc *p)
Re: Support Wacom One S (CTL-472)
On Sat, Sep 03, 2022 at 05:43:25PM +0200, Caspar Schutijser wrote:
> Hi,
>
> On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> > This is a better version of an earlier attempt to make my wacom tablet
> > work. I have the tablet here in Bad Liebenzell if you want to give it a
> > spin (on my or on your machine).
> >
> > Comments? OK?
>
> I don't feel entirely qualified to give OKs in this area so I won't do
> that. But I tested it on my machine with sdk@'s tablet and it works well
> here. Nice!
>
> Is there any chance it breaks other supported tablets? Should it be
> tested there as well?
The driver only attaches to specific products, currently
Intuos Draw, CTL-490. So there shouldn't be too much to break I guess.
> One whitespace nit below.
>
> Caspar
>
> >
> > Best Regards,
> > Stefan
I have an Wacom One CTL-672, never used it on OpenBSD. Currently
it attaches to ums(4). Works fine with that. It also works fine
when attaching to uwacom(4), without and with your diff. It doesn't
seem to require specific 'tsscale' nor 'loc_tip_press' settings.
I wonder if it would change something.
Some very few comments inline.
> > Index: share/man/man4/uwacom.4
> > ===
> > RCS file: /cvs/src/share/man/man4/uwacom.4,v
> > retrieving revision 1.2
> > diff -u -p -u -p -r1.2 uwacom.4
> > --- share/man/man4/uwacom.4 12 Sep 2016 10:39:06 - 1.2
> > +++ share/man/man4/uwacom.4 1 Sep 2022 19:57:37 -
> > @@ -42,6 +42,7 @@ driver supports the following Wacom tabl
> > .Bl -column "Intuos Draw" "Model Number" -offset 6n
> > .It Em Name Ta Em Model Number
> > .It Li Intuos Draw Ta CTL-490
> > +.It Li One Ta CTL-472
Shouldn't that be 'One S'?
> > .El
> > .Sh SEE ALSO
> > .Xr uhidev 4 ,
> > Index: sys/dev/usb/usbdevs
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> > retrieving revision 1.748
> > diff -u -p -u -p -r1.748 usbdevs
> > --- sys/dev/usb/usbdevs 23 Aug 2022 08:10:35 - 1.748
> > +++ sys/dev/usb/usbdevs 1 Sep 2022 19:57:38 -
> > @@ -4613,6 +4613,7 @@ product WACOM GRAPHIRE3_4X5 0x0013 Graph
> > product WACOM GRAPHIRE4_4X50x0015 Graphire4 Classic A6
> > product WACOM INTUOSA5 0x0021 Intuos A5
> > product WACOM INTUOS_DRAW 0x033b Intuos Draw (CTL-490)
> > +product WACOM ONE_S0x037a One S (CTL-472)
> > product WACOM INTUOS_PRO_S 0x0392 Intuos Pro S
> >
> > /* WAGO Kontakttechnik products */
> > Index: sys/dev/usb/usbdevs.h
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> > retrieving revision 1.760
> > diff -u -p -u -p -r1.760 usbdevs.h
> > --- sys/dev/usb/usbdevs.h 23 Aug 2022 08:11:01 - 1.760
> > +++ sys/dev/usb/usbdevs.h 1 Sep 2022 19:57:38 -
> > @@ -1,4 +1,4 @@
> > -/* $OpenBSD: usbdevs.h,v 1.760 2022/08/23 08:11:01 jsg Exp $ */
> > +/* $OpenBSD$ */
> >
> > /*
> > * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> > @@ -4620,6 +4620,7 @@
> > #defineUSB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015 /* Graphire4
> > Classic A6 */
> > #defineUSB_PRODUCT_WACOM_INTUOSA5 0x0021 /* Intuos A5 */
> > #defineUSB_PRODUCT_WACOM_INTUOS_DRAW 0x033b /* Intuos Draw
> > (CTL-490) */
> > +#defineUSB_PRODUCT_WACOM_ONE_S 0x037a /* One S (CTL-472) */
> > #defineUSB_PRODUCT_WACOM_INTUOS_PRO_S 0x0392 /* Intuos Pro S
> > */
> >
> > /* WAGO Kontakttechnik products */
> > Index: sys/dev/usb/usbdevs_data.h
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> > retrieving revision 1.754
> > diff -u -p -u -p -r1.754 usbdevs_data.h
> > --- sys/dev/usb/usbdevs_data.h 23 Aug 2022 08:11:01 - 1.754
> > +++ sys/dev/usb/usbdevs_data.h 1 Sep 2022 19:57:39 -
> > @@ -1,4 +1,4 @@
> > -/* $OpenBSD: usbdevs_data.h,v 1.754 2022/08/23 08:11:01 jsg Exp $ */
> > +/* $OpenBSD$ */
> >
> > /*
> > * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> > @@ -11824,6 +11824,10 @@ const struct usb_known_product usb_known
> > {
> > USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW,
> > "Intuos Draw (CTL-490)",
> > + },
> > + {
> > + USB_VENDOR_WACOM, USB_PRODUCT_WACOM_ONE_S,
> > + "One S (CTL-472)",
> > },
> > {
> > USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_PRO_S,
> > Index: sys/dev/usb/uwacom.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/uwacom.c,v
> > retrieving revision 1.5
> > diff -u -p -u -p -r1.5 uwacom.c
> > --- sys/dev/usb/uwacom.c22 Nov 2021 11:29:18 - 1.5
> > +++ sys/dev/usb/uwacom.c1 Sep 2022 19:57:39 -
> > @@ -35,10 +35,14 @@
> >
> > #include
> >
> > +#defineUWACOM_USE_PRESSURE
boot_macppc.8: fix file specification
The current text is badly formatted and incomplete as to which optional parts can be omitted in which way The file specification used is of the form: promdev:partition/filename options where: “promdev” is an optional Open Firmware device name (such as “hd” or “ide”) and “partition” is an optional disk partition number. Normal line editing characters can be used when typing the file specification. 1. 'partition' seems like an artifact that is not at all parsed as such, see sys/arch/macppc/stand/ ofwdev.c and main.c where the double colon is parsed; the comments confirm this with * this function is passed [device specifier]:[kernel] and * if the kernel image specified contains a ':' it is * [device]:[kernel], so separate the two fields. Manual tests confirm this. 2. if promdev is given, the double-colon MUST exist. 'boot hd' tries to boot the kernel "hd" 'boot hd:' tries to boot the kernel "hd:" 'boot hd:/bsd' does what it says 'boot hd:bsd' is equivalent to the previous line since ofwboot prepends trailing slashes; don't document to keep it simple 3. no vertical spacing makes the manual harder to read. We could zap the entire specification and rely on wording, similar to what boot_sparc64(8) does, but I prefer fixing the specification by removing partition from it and adding proper markup, yielding: The file specification used is of the form: [promdev:]filename [-acds] where promdev is an optional Open Firmware device name (such as hd or ide). Normal line editing characters can be used when typing the file specification. That should be much clearer. gkoehler greatly helped in confirming/testing various lines on his hardware. Feedback? Objection? OK? NB: boot(8/macppc) also mentions this, but some parts are plain wrong... I suggest fixing that in a separate diff. Index: share/man/man8/man8.macppc/boot_macppc.8 === RCS file: /cvs/src/share/man/man8/man8.macppc/boot_macppc.8,v retrieving revision 1.21 diff -u -p -r1.21 boot_macppc.8 --- share/man/man8/man8.macppc/boot_macppc.814 Feb 2014 12:18:27 - 1.21 +++ share/man/man8/man8.macppc/boot_macppc.83 Sep 2022 18:08:42 - @@ -93,16 +93,15 @@ If the special line is entered, the bootloader will attempt to restart the machine. .Pp The file specification used is of the form: -.Dl promdev:partition/filename options -where: -.Dq promdev +.Pp +.Dl Oo Ar promdev : Oc Ns Ar filename Op Fl acds +.Pp +where +.Ar promdev is an optional Open Firmware device name (such as .Dq hd or -.Dq ide ) -and -.Dq partition -is an optional disk partition number. +.Dq ide ) . Normal line editing characters can be used when typing the file specification. .Pp Index: sys/arch/macppc/stand//ofdev.c === RCS file: /cvs/src/sys/arch/macppc/stand/ofdev.c,v retrieving revision 1.26 diff -u -p -r1.26 ofdev.c --- sys/arch/macppc/stand//ofdev.c 11 Mar 2021 11:16:59 - 1.26 +++ sys/arch/macppc/stand//ofdev.c 3 Sep 2022 17:45:13 - @@ -55,7 +55,6 @@ char opened_name[256]; /* * this function is passed [device specifier]:[kernel] - * however a device specifier may contain a ':' */ static int parsename(char *str, char **file)
Re: immutable userland mappings
Theo de Raadt wrote:
> In this version of the diff, the kernel manages to mark immutable most of
> the main binary, and in the shared-binary case, also most of ld.so. But it
> cannot mark all of the ELF mapping -- because of two remaining problems (RELRO
> in .data, and the malloc.c self-protected bookkeeping page in .bss). I am
> looking into various solutions for both of those.
I have mostly succeeded at changing this to a better model. The
previous version had a real difficult time finding the specific objects
which cannot become immutable, so I found a way to describe them to the
kernel.
The ELF program headers now contain a new PHDR for section
".openbsd.mutable", aka OPENBSD_MUTABLE. This is placed on the malloc
self-protected bookkeeping page.
When the main binary & ld.so are loaded the kernel can make all LOAD
regions immutable, and then in a later pass the kernel is permitted to
undo the immutable on the OPENBSD_MUTABLE and GNU_RELRO regions. Only
the kernel can undo immutability, in these specific cases.
When crt0 finishes RELRO adjustment and mprotects PROT_READ, it also
marks the region immutable. ld.so does the same for it's RELRO.
The libc malloc self-protection scheme can mprotect RW and R back and
forth when it wants, and it will never make this region immutable.
When ld.so loads a library, it creates a queue of immutable and mutable
work actions to do after the library is done. ld.so cannot reverse an
immutable, so it must clip the mutable regions out of the immutables.
This clip piece of the diff is embarrassingly poor. It is very forgiving,
which is why I can run multiuser. I do know that the system libraries are
clean, and anyways the big problems were with the malloc, relro, main
programs, and ld.so, not the other libraries
This version is harder to cross compile through, but I wanted to show in
case someone is interested. There are numberous gaps (binutils lacks
support, other architectures, but the worst part is the immutuble
clipping code.
Index: gnu/llvm/lld/ELF/ScriptParser.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/ScriptParser.cpp,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 ScriptParser.cpp
--- gnu/llvm/lld/ELF/ScriptParser.cpp 17 Dec 2021 12:25:02 - 1.1.1.4
+++ gnu/llvm/lld/ELF/ScriptParser.cpp 2 Sep 2022 15:23:20 -
@@ -1478,6 +1478,7 @@
.Case("PT_GNU_EH_FRAME", PT_GNU_EH_FRAME)
.Case("PT_GNU_STACK", PT_GNU_STACK)
.Case("PT_GNU_RELRO", PT_GNU_RELRO)
+ .Case("PT_OPENBSD_MUTABLE", PT_OPENBSD_MUTABLE)
.Case("PT_OPENBSD_RANDOMIZE", PT_OPENBSD_RANDOMIZE)
.Case("PT_OPENBSD_WXNEEDED", PT_OPENBSD_WXNEEDED)
.Case("PT_OPENBSD_BOOTDATA", PT_OPENBSD_BOOTDATA)
Index: gnu/llvm/lld/ELF/Writer.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Writer.cpp,v
retrieving revision 1.3
diff -u -r1.3 Writer.cpp
--- gnu/llvm/lld/ELF/Writer.cpp 17 Dec 2021 14:46:47 - 1.3
+++ gnu/llvm/lld/ELF/Writer.cpp 2 Sep 2022 21:53:22 -
@@ -146,7 +146,7 @@
{".text.", ".rodata.", ".data.rel.ro.", ".data.", ".bss.rel.ro.",
".bss.", ".init_array.", ".fini_array.", ".ctors.", ".dtors.",
".tbss.",
".gcc_except_table.", ".tdata.", ".ARM.exidx.", ".ARM.extab.",
-".openbsd.randomdata."})
+".openbsd.randomdata.", ".openbsd.mutable." })
if (isSectionPrefix(v, s->name))
return v.drop_back();
@@ -2469,6 +2469,12 @@
part.ehFrame->getParent() && part.ehFrameHdr->getParent())
addHdr(PT_GNU_EH_FRAME, part.ehFrameHdr->getParent()->getPhdrFlags())
->add(part.ehFrameHdr->getParent());
+
+ // PT_OPENBSD_MUTABLE is an OpenBSD-specific feature. That makes
+ // the dynamic linker fill the segment with zero data, like bss, but
+ // it can be treated differently.
+ if (OutputSection *cmd = findSection(".openbsd.mutable", partNo))
+addHdr(PT_OPENBSD_MUTABLE, cmd->getPhdrFlags())->add(cmd);
// PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes
// the dynamic linker fill the segment with random data.
Index: gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h
===
RCS file: /cvs/src/gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 ELF.h
--- gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h 17 Dec 2021 12:23:22
- 1.1.1.3
+++ gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h 2 Sep 2022 12:12:47
-
@@ -1303,6 +1303,7 @@
PT_GNU_RELRO = 0x6474e552,// Read-only after relocation.
PT_GNU_PROPERTY = 0x6474e553, // .note.gnu.property notes sections.
+ PT_OPENBSD_MUTABLE = 0x65a3dbe5, // Like bss, but not immutable
PT_OPENBSD_RANDOMIZE = 0x65a3dbe6, // Fill with random data.
Re: document disklabel's new RAID template
On Sat, Sep 03, 2022 at 02:32:55PM +, Klemens Nanni wrote: > The softraid(4) example could also use > echo 'raid 1m-* 100%' | disklabel -wAT/dev/stdin wd1 > > but that's not as clear as > echo 'RAID 1M-* 100%' > template > disklabel -wAT template wd1 > > Feedback? OK? > reads fine. ok. jmc > Index: sbin/disklabel/disklabel.8 > === > RCS file: /cvs/src/sbin/disklabel/disklabel.8,v > retrieving revision 1.148 > diff -u -p -r1.148 disklabel.8 > --- sbin/disklabel/disklabel.831 Jul 2022 14:29:19 - 1.148 > +++ sbin/disklabel/disklabel.83 Sep 2022 14:23:47 - > @@ -538,11 +538,11 @@ A template for the automatic allocation > the > .Fl T > option. > -The template consists of one line per partition, with each line giving > +The template consists of one line per partition, each giving partition type > or > mount point, min-max size range, and percentage of disk, space-separated. > Max can be unlimited by specifying '*'. > -If only mount point and min size are given, the partition is created with > that > -exact size. > +If max size and percentage of disk are omitted, the partition is > +created with the exact min size. > .Bd -literal -offset indent > /250M > swap 80M-256M 10% > @@ -555,6 +555,15 @@ swap 80M-256M 10% > /usr/obj 1.3G-2G 4% > /home1G-*45% > .Ed > +.Pp > +The partition type > +.Dq RAID > +denotes partitions suitable as > +.Xr softraid 4 > +chunks. > +.Bd -literal -offset indent > +RAID 1M-*100% > +.Ed > .Sh FILES > .Bl -tag -width Pa -compact > .It Pa /etc/disktab > @@ -597,6 +606,7 @@ setting the label on the new partition w > .Sq a > partition. > .Sh SEE ALSO > +.Xr softraid 4 , > .Xr disklabel 5 , > .Xr disktab 5 , > .Xr installboot 8 , > Index: share/man/man4/softraid.4 > === > RCS file: /cvs/src/share/man/man4/softraid.4,v > retrieving revision 1.48 > diff -u -p -r1.48 softraid.4 > --- share/man/man4/softraid.4 13 Aug 2022 11:13:17 - 1.48 > +++ share/man/man4/softraid.4 3 Sep 2022 14:05:22 - > @@ -183,9 +183,10 @@ Initialize the partition tables of all d > .Pp > Now create RAID partitions on all disks: > .Bd -literal -offset indent > -# printf "a\en\en\en\enRAID\enw\enq\en" | disklabel -E wd1 > -# printf "a\en\en\en\enRAID\enw\enq\en" | disklabel -E wd2 > -# printf "a\en\en\en\enRAID\enw\enq\en" | disklabel -E wd3 > +$ echo 'RAID 1M-* 100%' > template > +# disklabel -wAT template wd1 > +# disklabel -wAT template wd2 > +# disklabel -wAT template wd3 > .Ed > .Pp > Assemble the RAID volume: >
Re: ifconfig, wireguard output less verbose, unless -A or
On Sat, Sep 03, 2022 at 08:55:51AM +, Mikolaj Kucharski wrote: > Hi, > > I tried to address what jmc@ mentioned below. I don't really know > mdoc(7) and English is not my native language, so I imagine there is > place for improvement in the wg(4) diff. > hi. after looking again, i think maybe ifconfig.8 is the better place, but just not where it was originally proposed. by way of a peace offering, how about the diff below? jmc Index: ifconfig.8 === RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.384 diff -u -p -r1.384 ifconfig.8 --- ifconfig.8 27 Jun 2022 16:27:03 - 1.384 +++ ifconfig.8 3 Sep 2022 15:50:35 - @@ -2195,6 +2195,14 @@ Packets on a VLAN interface without a ta .Ek .nr nS 0 .Pp +Detailed peer information is available to the superuser when +.Nm +is run with the +.Fl A +flag or when passed specific +.Ar wg-interface +names. +.Pp The following options are available for .Xr wg 4 interfaces:
Re: Support Wacom One S (CTL-472)
Hi,
On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> This is a better version of an earlier attempt to make my wacom tablet
> work. I have the tablet here in Bad Liebenzell if you want to give it a
> spin (on my or on your machine).
>
> Comments? OK?
I don't feel entirely qualified to give OKs in this area so I won't do
that. But I tested it on my machine with sdk@'s tablet and it works well
here. Nice!
Is there any chance it breaks other supported tablets? Should it be
tested there as well?
One whitespace nit below.
Caspar
>
> Best Regards,
> Stefan
>
> Index: share/man/man4/uwacom.4
> ===
> RCS file: /cvs/src/share/man/man4/uwacom.4,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 uwacom.4
> --- share/man/man4/uwacom.4 12 Sep 2016 10:39:06 - 1.2
> +++ share/man/man4/uwacom.4 1 Sep 2022 19:57:37 -
> @@ -42,6 +42,7 @@ driver supports the following Wacom tabl
> .Bl -column "Intuos Draw" "Model Number" -offset 6n
> .It Em Name Ta Em Model Number
> .It Li Intuos Draw Ta CTL-490
> +.It Li One Ta CTL-472
> .El
> .Sh SEE ALSO
> .Xr uhidev 4 ,
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.748
> diff -u -p -u -p -r1.748 usbdevs
> --- sys/dev/usb/usbdevs 23 Aug 2022 08:10:35 - 1.748
> +++ sys/dev/usb/usbdevs 1 Sep 2022 19:57:38 -
> @@ -4613,6 +4613,7 @@ product WACOM GRAPHIRE3_4X5 0x0013 Graph
> product WACOM GRAPHIRE4_4X5 0x0015 Graphire4 Classic A6
> product WACOM INTUOSA5 0x0021 Intuos A5
> product WACOM INTUOS_DRAW0x033b Intuos Draw (CTL-490)
> +product WACOM ONE_S 0x037a One S (CTL-472)
> product WACOM INTUOS_PRO_S 0x0392 Intuos Pro S
>
> /* WAGO Kontakttechnik products */
> Index: sys/dev/usb/usbdevs.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> retrieving revision 1.760
> diff -u -p -u -p -r1.760 usbdevs.h
> --- sys/dev/usb/usbdevs.h 23 Aug 2022 08:11:01 - 1.760
> +++ sys/dev/usb/usbdevs.h 1 Sep 2022 19:57:38 -
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: usbdevs.h,v 1.760 2022/08/23 08:11:01 jsg Exp $ */
> +/* $OpenBSD$ */
>
> /*
> * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> @@ -4620,6 +4620,7 @@
> #define USB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015 /* Graphire4
> Classic A6 */
> #define USB_PRODUCT_WACOM_INTUOSA5 0x0021 /* Intuos A5 */
> #define USB_PRODUCT_WACOM_INTUOS_DRAW 0x033b /* Intuos Draw
> (CTL-490) */
> +#define USB_PRODUCT_WACOM_ONE_S 0x037a /* One S (CTL-472) */
> #define USB_PRODUCT_WACOM_INTUOS_PRO_S 0x0392 /* Intuos Pro S
> */
>
> /* WAGO Kontakttechnik products */
> Index: sys/dev/usb/usbdevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> retrieving revision 1.754
> diff -u -p -u -p -r1.754 usbdevs_data.h
> --- sys/dev/usb/usbdevs_data.h23 Aug 2022 08:11:01 - 1.754
> +++ sys/dev/usb/usbdevs_data.h1 Sep 2022 19:57:39 -
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: usbdevs_data.h,v 1.754 2022/08/23 08:11:01 jsg Exp $ */
> +/* $OpenBSD$ */
>
> /*
> * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> @@ -11824,6 +11824,10 @@ const struct usb_known_product usb_known
> {
> USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW,
> "Intuos Draw (CTL-490)",
> + },
> + {
> + USB_VENDOR_WACOM, USB_PRODUCT_WACOM_ONE_S,
> + "One S (CTL-472)",
> },
> {
> USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_PRO_S,
> Index: sys/dev/usb/uwacom.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uwacom.c,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 uwacom.c
> --- sys/dev/usb/uwacom.c 22 Nov 2021 11:29:18 - 1.5
> +++ sys/dev/usb/uwacom.c 1 Sep 2022 19:57:39 -
> @@ -35,10 +35,14 @@
>
> #include
>
> +#define UWACOM_USE_PRESSURE 0x0001 /* button 0 is flaky, use tip
> pressure */
> +#define UWACOM_BIG_ENDIAN 0x0002 /* XY reporting byte order */
> +
> struct uwacom_softc {
> struct uhidev sc_hdev;
> struct hidmssc_ms;
> struct hid_location sc_loc_tip_press;
> + int sc_flags;
> };
>
> struct cfdriver uwacom_cd = {
> @@ -47,7 +51,8 @@ struct cfdriver uwacom_cd = {
>
>
> const struct usb_devno uwacom_devs[] = {
> - { USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW }
> + { USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW },
> + { USB_VENDOR_WACOM, USB_PRODUCT_WACOM_ONE_S }
> };
>
> int uwacom_match(struct device *, void *, void *);
> @@ -110,6
document disklabel's new RAID template
The softraid(4) example could also use echo 'raid 1m-* 100%' | disklabel -wAT/dev/stdin wd1 but that's not as clear as echo 'RAID 1M-* 100%' > template disklabel -wAT template wd1 Feedback? OK? Index: sbin/disklabel/disklabel.8 === RCS file: /cvs/src/sbin/disklabel/disklabel.8,v retrieving revision 1.148 diff -u -p -r1.148 disklabel.8 --- sbin/disklabel/disklabel.8 31 Jul 2022 14:29:19 - 1.148 +++ sbin/disklabel/disklabel.8 3 Sep 2022 14:23:47 - @@ -538,11 +538,11 @@ A template for the automatic allocation the .Fl T option. -The template consists of one line per partition, with each line giving +The template consists of one line per partition, each giving partition type or mount point, min-max size range, and percentage of disk, space-separated. Max can be unlimited by specifying '*'. -If only mount point and min size are given, the partition is created with that -exact size. +If max size and percentage of disk are omitted, the partition is +created with the exact min size. .Bd -literal -offset indent / 250M swap 80M-256M 10% @@ -555,6 +555,15 @@ swap 80M-256M 10% /usr/obj 1.3G-2G 4% /home 1G-*45% .Ed +.Pp +The partition type +.Dq RAID +denotes partitions suitable as +.Xr softraid 4 +chunks. +.Bd -literal -offset indent +RAID 1M-*100% +.Ed .Sh FILES .Bl -tag -width Pa -compact .It Pa /etc/disktab @@ -597,6 +606,7 @@ setting the label on the new partition w .Sq a partition. .Sh SEE ALSO +.Xr softraid 4 , .Xr disklabel 5 , .Xr disktab 5 , .Xr installboot 8 , Index: share/man/man4/softraid.4 === RCS file: /cvs/src/share/man/man4/softraid.4,v retrieving revision 1.48 diff -u -p -r1.48 softraid.4 --- share/man/man4/softraid.4 13 Aug 2022 11:13:17 - 1.48 +++ share/man/man4/softraid.4 3 Sep 2022 14:05:22 - @@ -183,9 +183,10 @@ Initialize the partition tables of all d .Pp Now create RAID partitions on all disks: .Bd -literal -offset indent -# printf "a\en\en\en\enRAID\enw\enq\en" | disklabel -E wd1 -# printf "a\en\en\en\enRAID\enw\enq\en" | disklabel -E wd2 -# printf "a\en\en\en\enRAID\enw\enq\en" | disklabel -E wd3 +$ echo 'RAID 1M-* 100%' > template +# disklabel -wAT template wd1 +# disklabel -wAT template wd2 +# disklabel -wAT template wd3 .Ed .Pp Assemble the RAID volume:
Re: divert-reply: keep pf state after pcb is dropped
On Fri, Sep 02, 2022 at 07:03:54PM +0200, YASUOKA Masahiko wrote:
> The diff already considers that situation.
You explanation makes sense.
> > I am running regress test with diff right now, we will see if it
> > still works.
Regress passes.
OK bluhm@
> >> Index: sys/net/pf.c
> >> ===
> >> RCS file: /cvs/src/sys/net/pf.c,v
> >> retrieving revision 1.1138
> >> diff -u -p -r1.1138 pf.c
> >> --- sys/net/pf.c 30 Aug 2022 11:53:03 - 1.1138
> >> +++ sys/net/pf.c 2 Sep 2022 12:54:36 -
> >> @@ -1148,6 +1148,8 @@ pf_find_state(struct pf_pdesc *pd, struc
> >>
> >>if (s == NULL)
> >>return (PF_DROP);
> >> + if (ISSET(s->state_flags, PFSTATE_INP_UNLINKED))
> >> + return (PF_DROP);
> >>
> >>if (s->rule.ptr->pktrate.limit && pd->dir == s->direction) {
> >>pf_add_threshold(>rule.ptr->pktrate);
> >> @@ -1461,7 +1463,23 @@ pf_remove_divert_state(struct pf_state_k
> >>if (sk == si->s->key[PF_SK_STACK] && si->s->rule.ptr &&
> >>(si->s->rule.ptr->divert.type == PF_DIVERT_TO ||
> >>si->s->rule.ptr->divert.type == PF_DIVERT_REPLY)) {
> >> - pf_remove_state(si->s);
> >> + if (si->s->key[PF_SK_STACK]->proto == IPPROTO_TCP &&
> >> + si->s->key[PF_SK_WIRE] != si->s->key[PF_SK_STACK]) {
> >> + /*
> >> + * If the local address is translated, keep
> >> + * the state for "tcp.closed" seconds to
> >> + * prevent its source port from being reused.
> >> + */
> >> + if (si->s->src.state < TCPS_FIN_WAIT_2 ||
> >> + si->s->dst.state < TCPS_FIN_WAIT_2) {
> >> + pf_set_protostate(si->s, PF_PEER_BOTH,
> >> + TCPS_TIME_WAIT);
> >> + si->s->timeout = PFTM_TCP_CLOSED;
> >> + si->s->expire = getuptime();
> >> + }
> >> + si->s->state_flags |= PFSTATE_INP_UNLINKED;
> >> + } else
> >> + pf_remove_state(si->s);
> >>break;
> >>}
> >>}
> >> Index: sys/net/pfvar.h
> >> ===
> >> RCS file: /cvs/src/sys/net/pfvar.h,v
> >> retrieving revision 1.509
> >> diff -u -p -r1.509 pfvar.h
> >> --- sys/net/pfvar.h20 Jul 2022 09:33:11 - 1.509
> >> +++ sys/net/pfvar.h2 Sep 2022 12:54:37 -
> >> @@ -784,6 +784,7 @@ struct pf_state {
> >> #define PFSTATE_RANDOMID0x0080
> >> #define PFSTATE_SCRUB_TCP 0x0100
> >> #define PFSTATE_SETPRIO 0x0200
> >> +#define PFSTATE_INP_UNLINKED0x0400
> >> #define PFSTATE_SCRUBMASK
> >> (PFSTATE_NODF|PFSTATE_RANDOMID|PFSTATE_SCRUB_TCP)
> >> #define PFSTATE_SETMASK (PFSTATE_SETTOS|PFSTATE_SETPRIO)
> >>u_int8_t log;
> >>
> >>
> >>
Re: protocol attach wait
On Sat, Sep 03, 2022 at 03:39:00AM +0300, Vitaliy Makkoveev wrote:
> Since we are not the special case where we have no resource allocation
> in runtime, because all required resources are pre-allocated by design,
During packet processing we do not wait, but drop the packet.
Network semantics allows packet loss.
> the memory errors are absolutely normal
Yes. But in system call you wait. Then userland gets consistent
behavior. System call must not fail due to temporary memory shortage.
System call fails if it is a persistent failure. The persistent
failure is caused by bad behavior from the userland, like exceeding
some limit. Temporary failure can happen anytime.
> and should be handled by userland.
Userland does not retry. Kernel is buggy and does not do it either.
I have a diff that introduces random malloc failures. You cannot
boot to multiuser as handling NULL is incomplete. The kernel should
recover by waiting. Only if this is not feasable, pass the error
to userland. Then the userland has to do something smart.
In theory OpenBSD should run with the diff below. But we would
have to fix a lot of bugs for that. Currently these are races that
are not triggered.
The design of malloc(9) is that if some userland process needs
memory, but there is not enough in the system, it has to wait. Some
other part of the kernel or userland will free it eventually. Then
the request can succeed.
bluhm
Index: kern/kern_malloc.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.148
diff -u -p -r1.148 kern_malloc.c
--- kern/kern_malloc.c 14 Aug 2022 01:58:27 - 1.148
+++ kern/kern_malloc.c 3 Sep 2022 13:18:24 -
@@ -184,6 +184,15 @@ malloc(size_t size, int type, int flags)
}
#endif
+ if (!cold && (flags & (M_NOWAIT|M_CANFAIL))) {
+ static int failcount;
+
+ if (failcount == 0)
+ failcount = arc4random();
+ if ((failcount++ & 0xfff) == 0)
+ return (NULL);
+ }
+
if (size > 65535 * PAGE_SIZE) {
if (flags & M_CANFAIL) {
#ifndef SMALL_KERNEL
Index: kern/subr_pool.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/subr_pool.c,v
retrieving revision 1.236
diff -u -p -r1.236 subr_pool.c
--- kern/subr_pool.c14 Aug 2022 01:58:28 - 1.236
+++ kern/subr_pool.c3 Sep 2022 13:17:33 -
@@ -567,6 +567,15 @@ pool_get(struct pool *pp, int flags)
if (pp->pr_flags & PR_RWLOCK)
KASSERT(flags & PR_WAITOK);
+ if (!cold && (flags & (PR_NOWAIT|PR_LIMITFAIL))) {
+ static int failcount;
+
+ if (failcount == 0)
+ failcount = arc4random();
+ if ((failcount++ & 0xfff) == 0)
+ return (NULL);
+ }
+
#ifdef MULTIPROCESSOR
if (pp->pr_cache != NULL) {
v = pool_cache_get(pp);
Re: tcp timer mutex
ok yasuoka
On Fri, 2 Sep 2022 14:44:29 +0200
Alexander Bluhm wrote:
> + now = READ_ONCE(tcp_now);
> +
> /*
>* Determine length of data that should be transmitted,
>* and flags that will be used.
> @@ -228,7 +231,7 @@ tcp_output(struct tcpcb *tp)
>* to send, then transmit; otherwise, investigate further.
>*/
> idle = (tp->t_flags & TF_LASTIDLE) || (tp->snd_max == tp->snd_una);
> - if (idle && (tcp_now - tp->t_rcvtime) >= tp->t_rxtcur)
> + if (idle && (now - tp->t_rcvtime) >= tp->t_rxtcur)
> /*
>* We have been idle for "a while" and no acks are
>* expected to clock out any data we send --
> @@ -539,13 +542,13 @@ send:
>
> /* Form timestamp option as shown in appendix A of RFC 1323. */
> *lp++ = htonl(TCPOPT_TSTAMP_HDR);
> - *lp++ = htonl(tcp_now + tp->ts_modulate);
> + *lp++ = htonl(now + tp->ts_modulate);
> *lp = htonl(tp->ts_recent);
> optlen += TCPOLEN_TSTAMP_APPA;
>
> /* Set receive buffer autosizing timestamp. */
> if (tp->rfbuf_ts == 0)
> - tp->rfbuf_ts = tcp_now;
> + tp->rfbuf_ts = now;
>
> }
>
> @@ -691,7 +694,7 @@ send:
>*/
> if (off + len == so->so_snd.sb_cc && !soissending(so))
> flags |= TH_PUSH;
> - tp->t_sndtime = tcp_now;
> + tp->t_sndtime = now;
> } else {
> if (tp->t_flags & TF_ACKNOW)
> tcpstat_inc(tcps_sndacks);
> @@ -924,7 +927,7 @@ send:
>* not currently timing anything.
>*/
> if (tp->t_rtttime == 0) {
> - tp->t_rtttime = tcp_now;
> + tp->t_rtttime = now;
> tp->t_rtseq = startseq;
> tcpstat_inc(tcps_segstimed);
> }
> @@ -1123,7 +1126,7 @@ out:
> if (win > 0 && SEQ_GT(tp->rcv_nxt+win, tp->rcv_adv))
> tp->rcv_adv = tp->rcv_nxt + win;
> tp->last_ack_sent = tp->rcv_nxt;
> - tp->t_sndacktime = tcp_now;
> + tp->t_sndacktime = now;
> tp->t_flags &= ~TF_ACKNOW;
> TCP_TIMER_DISARM(tp, TCPT_DELACK);
> if (sendalot)
> Index: netinet/tcp_subr.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_subr.c,v
> retrieving revision 1.186
> diff -u -p -r1.186 tcp_subr.c
> --- netinet/tcp_subr.c30 Aug 2022 11:53:04 - 1.186
> +++ netinet/tcp_subr.c1 Sep 2022 14:47:22 -
> @@ -71,6 +71,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -98,6 +99,14 @@
> #include
> #include
>
> +/*
> + * Locks used to protect struct members in this file:
> + * I immutable after creation
> + * T tcp_timer_mtx global tcp timer data structures
> + */
> +
> +struct mutex tcp_timer_mtx;
> +
> /* patchable/settable parameters for tcp */
> int tcp_mssdflt = TCP_MSS;
> int tcp_rttdflt = TCPTV_SRTTDFLT / PR_SLOWHZ;
> @@ -111,8 +120,6 @@ int tcp_do_ecn = 0; /* RFC3168 ECN enab
> #endif
> int tcp_do_rfc3390 = 2; /* Increase TCP's Initial Window to 10*mss */
>
> -u_int32_ttcp_now = 1;
> -
> #ifndef TCB_INITIAL_HASH_SIZE
> #define TCB_INITIAL_HASH_SIZE 128
> #endif
> @@ -126,9 +133,10 @@ struct pool sackhl_pool;
>
> struct cpumem *tcpcounters; /* tcp statistics */
>
> -u_char tcp_secret[16];
> -SHA2_CTX tcp_secret_ctx;
> -tcp_seq tcp_iss;
> +u_char tcp_secret[16]; /* [I] */
> +SHA2_CTX tcp_secret_ctx; /* [I] */
> +tcp_seq tcp_iss;/* [T] updated by timer and connection
> */
> +uint32_t tcp_now;/* [T] incremented by slow timer */
>
> /*
> * Tcp initialization
> @@ -137,6 +145,7 @@ void
> tcp_init(void)
> {
> tcp_iss = 1;/* wrong */
> + tcp_now = 1;
> pool_init(_pool, sizeof(struct tcpcb), 0, IPL_SOFTNET, 0,
> "tcpcb", NULL);
> pool_init(_pool, sizeof(struct tcpqent), 0, IPL_SOFTNET, 0,
> @@ -281,7 +290,7 @@ tcp_template(struct tcpcb *tp)
> */
> void
> tcp_respond(struct tcpcb *tp, caddr_t template, struct tcphdr *th0,
> -tcp_seq ack, tcp_seq seq, int flags, u_int rtableid)
> +tcp_seq ack, tcp_seq seq, int flags, u_int rtableid, uint32_t now)
> {
> int tlen;
> int win = 0;
> @@ -362,7 +371,7 @@ tcp_respond(struct tcpcb *tp, caddr_t te
> u_int32_t *lp = (u_int32_t *)(th + 1);
> /* Form timestamp option as shown in appendix A of RFC 1323. */
> *lp++ = htonl(TCPOPT_TSTAMP_HDR);
> - *lp++ = htonl(tcp_now + tp->ts_modulate);
> + *lp++ = htonl(now + tp->ts_modulate);
>
Re: rpki-client: check inherit constraint on TAs earlier on
On Sat, Sep 03, 2022 at 01:08:35PM +, Job Snijders wrote:
> RPKI Trust Anchors (self-signed root certificates) MAY NOT contain
> 'inherit' elements in their RFC 3779 resource extensions according to
> RFC 6490 section 2.2.
>
> We could check way earlier on in the validation process whether the TA
> certificate conforms to this constraint. The below changeset moves the
> check from be applied on a 'struct cert'; to apply on a 'struct X509'.
I'm not against this although I think it makes sense how it curently is.
It is not really that much earlier. We do ta_parse() and almost
immediately afterward valid_ta() in both paths.
In general, the split between parse and validate is not super clear cut,
and more of a result of how filemode was added.
> @@ -391,6 +391,34 @@ x509_inherits(X509 *x)
>
> rc = 1;
> out:
> + ASIdentifiers_free(asidentifiers);
> + sk_IPAddressFamily_pop_free(addrblk, IPAddressFamily_free);
> + return rc;
> +}
> +
> +/*
> + * Check whether at least one RFC 3779 extension is set to inherit.
> + * Return 1 if an inherit element is encountered in AS or IP.
> + * Return 0 otherwise.
> + */
> +int
> +x509_any_inherits(X509 *x)
> +{
> + STACK_OF(IPAddressFamily) *addrblk = NULL;
> + ASIdentifiers *asidentifiers = NULL;
> + int rc = 0;
> +
> + addrblk = X509_get_ext_d2i(x, NID_sbgp_ipAddrBlock, NULL, NULL);
> + if (addrblk != NULL)
This NULL check is not needed. X509v3_addr_inherits() returns 0 on NULL.
> + if (X509v3_addr_inherits(addrblk))
> + rc = 1;
> +
> + asidentifiers = X509_get_ext_d2i(x, NID_sbgp_autonomousSysNum, NULL,
> + NULL);
> + if (asidentifiers != NULL)
Same here.
> + if (X509v3_asid_inherits(asidentifiers))
> + rc = 1;
> +
> ASIdentifiers_free(asidentifiers);
> sk_IPAddressFamily_pop_free(addrblk, IPAddressFamily_free);
> return rc;
>
rpki-client: check inherit constraint on TAs earlier on
RPKI Trust Anchors (self-signed root certificates) MAY NOT contain
'inherit' elements in their RFC 3779 resource extensions according to
RFC 6490 section 2.2.
We could check way earlier on in the validation process whether the TA
certificate conforms to this constraint. The below changeset moves the
check from be applied on a 'struct cert'; to apply on a 'struct X509'.
Kind regards,
Job
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.86
diff -u -p -r1.86 cert.c
--- cert.c 3 Sep 2022 13:01:43 - 1.86
+++ cert.c 3 Sep 2022 13:07:06 -
@@ -861,6 +861,10 @@ ta_parse(const char *fn, struct cert *p,
warnx("%s: BGPsec cert cannot be a trust anchor", fn);
goto badcert;
}
+ if (x509_any_inherits(p->x509)) {
+ warnx("%s: Trust anchor IP/AS resources may not inherit", fn);
+ goto badcert;
+ }
EVP_PKEY_free(pk);
return p;
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.153
diff -u -p -r1.153 extern.h
--- extern.h2 Sep 2022 19:10:36 - 1.153
+++ extern.h3 Sep 2022 13:07:06 -
@@ -710,6 +710,7 @@ char*x509_convert_seqnum(const char *,
int x509_location(const char *, const char *, const char *,
GENERAL_NAME *, char **);
int x509_inherits(X509 *);
+int x509_any_inherits(X509 *);
/* printers */
char *time2str(time_t);
Index: validate.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
retrieving revision 1.43
diff -u -p -r1.43 validate.c
--- validate.c 3 Sep 2022 13:01:43 - 1.43
+++ validate.c 3 Sep 2022 13:07:06 -
@@ -106,28 +106,12 @@ valid_ski_aki(const char *fn, struct aut
}
/*
- * Authenticate a trust anchor by making sure its resources are not
- * inheriting and that the SKI is unique.
+ * Validate a trust anchor by making sure that the SKI is unique.
* Returns 1 if valid, 0 otherwise.
*/
int
valid_ta(const char *fn, struct auth_tree *auths, const struct cert *cert)
{
- size_t i;
-
- /* AS and IP resources must not inherit. */
- if (cert->asz && cert->as[0].type == CERT_AS_INHERIT) {
- warnx("%s: RFC 6487 (trust anchor): "
- "inheriting AS resources", fn);
- return 0;
- }
- for (i = 0; i < cert->ipsz; i++)
- if (cert->ips[i].type == CERT_IP_INHERIT) {
- warnx("%s: RFC 6487 (trust anchor): "
- "inheriting IP resources", fn);
- return 0;
- }
-
/* SKI must not be a dupe. */
if (auth_find(auths, cert->ski) != NULL) {
warnx("%s: RFC 6487: duplicate SKI", fn);
Index: x509.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/x509.c,v
retrieving revision 1.49
diff -u -p -r1.49 x509.c
--- x509.c 3 Sep 2022 13:06:15 - 1.49
+++ x509.c 3 Sep 2022 13:07:06 -
@@ -352,7 +352,7 @@ x509_get_expire(X509 *x, const char *fn,
}
/*
- * Check whether the RFC 3779 extensions are set to inherit.
+ * Check whether all RFC 3779 extensions are set to inherit.
* Return 1 if both AS & IP are set to inherit.
* Return 0 on failure (such as missing extensions or no inheritance).
*/
@@ -391,6 +391,34 @@ x509_inherits(X509 *x)
rc = 1;
out:
+ ASIdentifiers_free(asidentifiers);
+ sk_IPAddressFamily_pop_free(addrblk, IPAddressFamily_free);
+ return rc;
+}
+
+/*
+ * Check whether at least one RFC 3779 extension is set to inherit.
+ * Return 1 if an inherit element is encountered in AS or IP.
+ * Return 0 otherwise.
+ */
+int
+x509_any_inherits(X509 *x)
+{
+ STACK_OF(IPAddressFamily) *addrblk = NULL;
+ ASIdentifiers *asidentifiers = NULL;
+ int rc = 0;
+
+ addrblk = X509_get_ext_d2i(x, NID_sbgp_ipAddrBlock, NULL, NULL);
+ if (addrblk != NULL)
+ if (X509v3_addr_inherits(addrblk))
+ rc = 1;
+
+ asidentifiers = X509_get_ext_d2i(x, NID_sbgp_autonomousSysNum, NULL,
+ NULL);
+ if (asidentifiers != NULL)
+ if (X509v3_asid_inherits(asidentifiers))
+ rc = 1;
+
ASIdentifiers_free(asidentifiers);
sk_IPAddressFamily_pop_free(addrblk, IPAddressFamily_free);
return rc;
Re: [please test] pvclock(4): fix several bugs
> On Sep 3, 2022, at 07:37, Jonathan Gray wrote:
>
> On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
>>>
>>> On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
dv@ suggested coming to the list to request testing for the pvclock(4)
driver. Attached is a patch that corrects several bugs. Most of
these changes will only matter in the non-TSC_STABLE case on a
multiprocessor VM.
Ideally, nothing should break.
- pvclock yields a 64-bit value. The BSD timecounter layer can only
use the lower 32 bits, but internally we need to track the full
64-bit value to allow comparisons with the full value in the
non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity.
- In pvclock_get_timecount(), move rdtsc() up into the lockless read
loop to get a more accurate timestamp.
- In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc().
- In pvclock_get_timecount(), check that our TSC value doesn't predate
ti->ti_tsc_timestamp, otherwise we will produce an enormous value.
- In pvclock_get_timecount(), update pvclock_lastcount in the
non-TSC_STABLE case with more care. On amd64 we can do this with an
atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need
to introduce a mutex to protect our comparison and read/write.
>>>
>>> i386 has cmpxchg8b, no need to disable interrupts
>>> the ifdefs seem excessive
>>
>> How do I make use of CMPXCHG8B on i386
>> in this context?
>>
>> atomic_cas_ulong(9) is a 32-bit CAS on
>> i386.
>
> static inline uint64_t
> atomic_cas_64(volatile uint64_t *p, uint64_t o, uint64_t n)
> {
>return __sync_val_compare_and_swap(p, o, n);
> }
>
> Or md atomic.h files could have an equivalent.
> Not possible on all 32-bit archs.
Gotcha.
>> We can't use FP registers in the kernel, no?
>
> What do FP registers have to do with it?
I read someplace that using FP registers was
a quick and dirty way to take advantage of
the 64-bit-aligned atomic access guarantees
of the Pentium.
>> Am I missing some other avenue?
>
> There is no rdtsc_lfence() on i386. Initial diff doesn't build.
I will come back with a fuller patch in a bit.
Re: [please test] pvclock(4): fix several bugs
On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> >
> > On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> >> dv@ suggested coming to the list to request testing for the pvclock(4)
> >> driver. Attached is a patch that corrects several bugs. Most of
> >> these changes will only matter in the non-TSC_STABLE case on a
> >> multiprocessor VM.
> >>
> >> Ideally, nothing should break.
> >>
> >> - pvclock yields a 64-bit value. The BSD timecounter layer can only
> >> use the lower 32 bits, but internally we need to track the full
> >> 64-bit value to allow comparisons with the full value in the
> >> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity.
> >>
> >> - In pvclock_get_timecount(), move rdtsc() up into the lockless read
> >> loop to get a more accurate timestamp.
> >>
> >> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc().
> >>
> >> - In pvclock_get_timecount(), check that our TSC value doesn't predate
> >> ti->ti_tsc_timestamp, otherwise we will produce an enormous value.
> >>
> >> - In pvclock_get_timecount(), update pvclock_lastcount in the
> >> non-TSC_STABLE case with more care. On amd64 we can do this with an
> >> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need
> >> to introduce a mutex to protect our comparison and read/write.
> >
> > i386 has cmpxchg8b, no need to disable interrupts
> > the ifdefs seem excessive
>
> How do I make use of CMPXCHG8B on i386
> in this context?
>
> atomic_cas_ulong(9) is a 32-bit CAS on
> i386.
static inline uint64_t
atomic_cas_64(volatile uint64_t *p, uint64_t o, uint64_t n)
{
return __sync_val_compare_and_swap(p, o, n);
}
Or md atomic.h files could have an equivalent.
Not possible on all 32-bit archs.
>
> We can't use FP registers in the kernel, no?
What do FP registers have to do with it?
>
> Am I missing some other avenue?
There is no rdtsc_lfence() on i386. Initial diff doesn't build.
Re: installboot: reflect script failure in exit code
On Fri, Aug 26, 2022 at 09:12:59AM +, Klemens Nanni wrote:
> installboot(8) runs newfs_msdos(8) via system(3) but only checks failures
> of the function itself, always returning zero no matter what newfs_msdos
> returned.
>
> This is bad for regress tests relying on correct return codes.
Also the installer uses 'install -p' and will do so on even more
architectures soon.
It's invocations in distrib/$(machine)/ramdisk/install.md are currently
unchecked, but even if we used 'set -e' of
if ! installboot -p $_disk ; then
...
fi
they would not have any effect as -p always reports success upon
fsck/newfs failure.
>
> create_filesystem() itself must not exit as write_filesystem() calls it and
> cleans up temporary files upon failure.
>
> Make it return -1 if the script returned non-zero so write_filesystem()
> handles it as error, cleans up and makes installboot exit 1.
>
> Stop ignoring create_filesystem()'s return code in md_prepareboot() and
> exit the same way.
>
> Here's the change in behaviour on arm64 (newfs_msdos fails because of the
> vnd/disklabel race, see "Race in disk_attach_callback?" on tech@):
>
> # installboot -vp $( newfsing 6694ae5b0d7596ed.i
> newfs_msdos: /dev/r6694ae5b0d7596ed.i: No such file or directory
> 0
> # ./obj/installboot -vp vnd0 ; echo $?
> newfsing 6694ae5b0d7596ed.i
> newfs_msdos: /dev/r6694ae5b0d7596ed.i: No such file or directory
> 1
>
> Feedback?
>
> If this direction seems OK, I'll fix all other MD specific copies of this
> code.
>
> It seems like write_filesystem() is identical across all MD copies,
> so maybe it could even be merged into a common filesystem.c and be fixed
> once for all of them?
Anyone?
>
> write_filesystem() system(3)ing fsck_msdos(8) has the same problem and
> ought to be fixed as well.
>
>
> Index: efi_installboot.c
> ===
> RCS file: /mount/openbsd/cvs/src/usr.sbin/installboot/efi_installboot.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 efi_installboot.c
> --- efi_installboot.c 3 Feb 2022 10:25:14 - 1.2
> +++ efi_installboot.c 25 Aug 2022 08:30:11 -
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -100,16 +103,11 @@ md_prepareboot(int devfd, char *dev)
> warnx("disklabel type unknown");
>
> part = findgptefisys(devfd, );
> - if (part != -1) {
> - create_filesystem(, (char)part);
> - return;
> - }
> -
> - part = findmbrfat(devfd, );
> - if (part != -1) {
> - create_filesystem(, (char)part);
> - return;
> - }
> + if (part == -1)
> + part = findmbrfat(devfd, );
> + if (part != -1)
> + if (create_filesystem(, (char)part) == -1)
> + exit(1);
> }
>
> void
> @@ -177,6 +175,9 @@ create_filesystem(struct disklabel *dl,
> warn("system('%s') failed", cmd);
> return rslt;
> }
> +
> + if (WIFEXITED(rslt) && WEXITSTATUS(rslt))
> + return -1;
> }
>
> return 0;
>
Re: add sendmmsg and recvmmsg systemcalls
On Sat, Sep 03, 2022 at 01:49:27AM +0200, Moritz Buhl wrote:
> Here is an updated version of the kernel part for sendmmsg.
OK bluhm@
> Index: sys/kern/syscalls.master
> ===
> RCS file: /mount/openbsd/cvs/src/sys/kern/syscalls.master,v
> retrieving revision 1.230
> diff -u -p -r1.230 syscalls.master
> --- sys/kern/syscalls.master 2 Sep 2022 13:18:06 - 1.230
> +++ sys/kern/syscalls.master 2 Sep 2022 20:34:15 -
> @@ -247,7 +247,9 @@
> 116 STD NOLOCK { int sys_recvmmsg(int s, struct mmsghdr *mmsg, \
> unsigned int vlen, unsigned int flags, \
> struct timespec *timeout); }
> -117 UNIMPL sendmmsg
> +117 STD NOLOCK { int sys_sendmmsg(int s, \
> + struct mmsghdr *mmsg, unsigned int vlen, \
> + unsigned int flags); }
> 118 STD { int sys_getsockopt(int s, int level, int name, \
> void *val, socklen_t *avalsize); }
> 119 STD { int sys_thrkill(pid_t tid, int signum, void *tcb); }
> Index: sys/kern/uipc_syscalls.c
> ===
> RCS file: /mount/openbsd/cvs/src/sys/kern/uipc_syscalls.c,v
> retrieving revision 1.202
> diff -u -p -r1.202 uipc_syscalls.c
> --- sys/kern/uipc_syscalls.c 2 Sep 2022 13:18:06 - 1.202
> +++ sys/kern/uipc_syscalls.c 2 Sep 2022 23:26:08 -
> @@ -606,6 +606,92 @@ done:
> }
>
> int
> +sys_sendmmsg(struct proc *p, void *v, register_t *retval)
> +{
> + struct sys_sendmmsg_args /* {
> + syscallarg(int) s;
> + syscallarg(struct mmsghdr *)mmsg;
> + syscallarg(unsigned int)vlen;
> + syscallarg(unsigned int)flags;
> + } */ *uap = v;
> + struct mmsghdr mmsg, *mmsgp;
> + struct iovec aiov[UIO_SMALLIOV], *iov = aiov, *uiov;
> + size_t iovlen = UIO_SMALLIOV;
> + register_t retsnd;
> + unsigned int vlen, dgrams;
> + int error = 0;
> +
> + /* Arbitrarily capped at 1024 datagrams. */
> + vlen = SCARG(uap, vlen);
> + if (vlen > 1024)
> + vlen = 1024;
> +
> + mmsgp = SCARG(uap, mmsg);
> + for (dgrams = 0; dgrams < vlen; dgrams++) {
> + error = copyin([dgrams], , sizeof(mmsg));
> + if (error)
> + break;
> +
> +#ifdef KTRACE
> + if (KTRPOINT(p, KTR_STRUCT))
> + ktrmmsghdr(p, );
> +#endif
> +
> + if (mmsg.msg_hdr.msg_iovlen > IOV_MAX) {
> + error = EMSGSIZE;
> + break;
> + }
> +
> + if (mmsg.msg_hdr.msg_iovlen > iovlen) {
> + if (iov != aiov)
> + free(iov, M_IOV, iovlen *
> + sizeof(struct iovec));
> +
> + iovlen = mmsg.msg_hdr.msg_iovlen;
> + iov = mallocarray(iovlen, sizeof(struct iovec),
> + M_IOV, M_WAITOK);
> + }
> +
> + if (mmsg.msg_hdr.msg_iovlen > 0) {
> + error = copyin(mmsg.msg_hdr.msg_iov, iov,
> + mmsg.msg_hdr.msg_iovlen * sizeof(struct iovec));
> + if (error)
> + break;
> + }
> +
> +#ifdef KTRACE
> + if (mmsg.msg_hdr.msg_iovlen && KTRPOINT(p, KTR_STRUCT))
> + ktriovec(p, iov, mmsg.msg_hdr.msg_iovlen);
> +#endif
> +
> + uiov = mmsg.msg_hdr.msg_iov;
> + mmsg.msg_hdr.msg_iov = iov;
> + mmsg.msg_hdr.msg_flags = 0;
> +
> + error = sendit(p, SCARG(uap, s), _hdr,
> + SCARG(uap, flags), );
> + if (error)
> + break;
> +
> + mmsg.msg_hdr.msg_iov = uiov;
> + mmsg.msg_len = retsnd;
> +
> + error = copyout(, [dgrams], sizeof(mmsg));
> + if (error)
> + break;
> + }
> +
> + if (iov != aiov)
> + free(iov, M_IOV, sizeof(struct iovec) * iovlen);
> +
> + *retval = dgrams;
> +
> + if (dgrams)
> + return 0;
> + return error;
> +}
> +
> +int
> sendit(struct proc *p, int s, struct msghdr *mp, int flags, register_t
> *retsize)
> {
> struct file *fp;
> Index: sys/sys/socket.h
> ===
> RCS file: /mount/openbsd/cvs/src/sys/sys/socket.h,v
> retrieving revision 1.103
> diff -u -p -r1.103 socket.h
> --- sys/sys/socket.h 2 Sep 2022 13:18:07 - 1.103
> +++ sys/sys/socket.h 2 Sep 2022 22:31:09 -
> @@ -579,6 +579,7 @@ ssize_t send(int, const void *, size_t,
> ssize_t sendto(int, const void *,
> size_t, int, const struct sockaddr *, socklen_t);
> ssize_t sendmsg(int, const struct msghdr *, int);
> +int
Re: [please test] pvclock(4): fix several bugs
> On Sep 3, 2022, at 02:22, Jonathan Gray wrote: > > On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote: >> dv@ suggested coming to the list to request testing for the pvclock(4) >> driver. Attached is a patch that corrects several bugs. Most of >> these changes will only matter in the non-TSC_STABLE case on a >> multiprocessor VM. >> >> Ideally, nothing should break. >> >> - pvclock yields a 64-bit value. The BSD timecounter layer can only >> use the lower 32 bits, but internally we need to track the full >> 64-bit value to allow comparisons with the full value in the >> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity. >> >> - In pvclock_get_timecount(), move rdtsc() up into the lockless read >> loop to get a more accurate timestamp. >> >> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc(). >> >> - In pvclock_get_timecount(), check that our TSC value doesn't predate >> ti->ti_tsc_timestamp, otherwise we will produce an enormous value. >> >> - In pvclock_get_timecount(), update pvclock_lastcount in the >> non-TSC_STABLE case with more care. On amd64 we can do this with an >> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need >> to introduce a mutex to protect our comparison and read/write. > > i386 has cmpxchg8b, no need to disable interrupts > the ifdefs seem excessive How do I make use of CMPXCHG8B on i386 in this context? atomic_cas_ulong(9) is a 32-bit CAS on i386. We can't use FP registers in the kernel, no? Am I missing some other avenue?
Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()
After these changes, OpenBSD VMware guest's clock is galloping into the future like this: Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by -116.270573s Aug 31 02:47:40 build ntpd[55904]: adjusting local clock by -281.085430s Aug 31 02:52:01 build ntpd[55904]: adjusting local clock by -320.064639s Aug 31 02:53:09 build ntpd[55904]: adjusting local clock by -385.095886s Aug 31 02:54:47 build ntpd[55904]: adjusting local clock by -532.542486s Aug 31 02:58:33 build ntpd[55904]: adjusting local clock by -572.363323s Aug 31 02:59:38 build ntpd[55904]: adjusting local clock by -655.253598s Aug 31 03:01:54 build ntpd[55904]: adjusting local clock by -823.653978s Aug 31 03:06:14 build ntpd[55904]: adjusting local clock by -926.705093s Aug 31 03:09:00 build ntpd[55904]: adjusting local clock by -1071.837887s VM time right after boot: rdate -pn $ntp; date Sat Sep 3 13:39:43 MSK 2022 Sat Sep 3 13:43:24 MSK 2022 $ sysctl -a | grep tsc kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) machdep.tscfreq=580245275 machdep.invarianttsc=1 And in a couple of minutes after boot the timeskew getting like this: $ rdate -pn $ntp; date Sat Sep 3 13:41:49 MSK 2022 Sat Sep 3 13:48:46 MSK 2022 After several hours the VM lives in tomorrow. As a workaround, changing TSC source helps: # sysctl kern.timecounter.hardware=acpihpet0 -- With best regards, Pavel Korovin
Re: rpki-client include "parent" repo id in certs
On Sat, Sep 03, 2022 at 01:27:03PM +0200, Theo Buehler wrote: > On Sat, Sep 03, 2022 at 01:18:13PM +0200, Claudio Jeker wrote: > > This diff adds the parentid to struct cert. The parentid is the id of the > > repository the cert lives in. This information will be used to track the > > parent repository in the repositories list/tree. > > > > The naming is confusing and I'm happy for better suggestions. > > I wouldn't mind being more explicit and call it parentrepoid. Might be better to call it 'repoid'. A "repository" can contain one or more "publication points". A single "publication point" is the list of files on a manifest + the manifest itself. Looking at the filesystem, a directory may contain multiple "publication points" (which are like ships in the night). table of phrase + example value: "repository": rsync://chloe.sobornost.net/rpki "repository": https://chloe.sobornost.net/rpki/news.xml "publication point": rsync://chloe.sobornost.net/rpki/RIPE-nljobsnijders/ Confusingly, RFCs mention the phrase "publication point" which I think meant to map that phrase to the X.509 SIA attribute "CA Repository". Kind regards, Job
Re: rpki-client include "parent" repo id in certs
On Sat, Sep 03, 2022 at 01:18:13PM +0200, Claudio Jeker wrote:
> This diff adds the parentid to struct cert. The parentid is the id of the
> repository the cert lives in. This information will be used to track the
> parent repository in the repositories list/tree.
>
> The naming is confusing and I'm happy for better suggestions.
I wouldn't mind being more explicit and call it parentrepoid.
ok
> --
> :wq Claudio
>
> Index: cert.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 cert.c
> --- cert.c19 Aug 2022 12:45:53 - 1.85
> +++ cert.c3 Sep 2022 11:03:46 -
> @@ -898,6 +898,7 @@ cert_buffer(struct ibuf *b, const struct
> io_simple_buffer(b, >expires, sizeof(p->expires));
> io_simple_buffer(b, >purpose, sizeof(p->purpose));
> io_simple_buffer(b, >talid, sizeof(p->talid));
> + io_simple_buffer(b, >parentid, sizeof(p->parentid));
> io_simple_buffer(b, >ipsz, sizeof(p->ipsz));
> io_simple_buffer(b, >asz, sizeof(p->asz));
>
> @@ -930,6 +931,7 @@ cert_read(struct ibuf *b)
> io_read_buf(b, >expires, sizeof(p->expires));
> io_read_buf(b, >purpose, sizeof(p->purpose));
> io_read_buf(b, >talid, sizeof(p->talid));
> + io_read_buf(b, >parentid, sizeof(p->parentid));
> io_read_buf(b, >ipsz, sizeof(p->ipsz));
> io_read_buf(b, >asz, sizeof(p->asz));
>
> Index: extern.h
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
> retrieving revision 1.153
> diff -u -p -r1.153 extern.h
> --- extern.h 2 Sep 2022 19:10:36 - 1.153
> +++ extern.h 3 Sep 2022 11:03:46 -
> @@ -137,6 +137,7 @@ struct cert {
> struct cert_as *as; /* list of AS numbers and ranges */
> size_t asz; /* length of "asz" */
> int talid; /* cert is covered by which TAL */
> + unsigned int parentid; /* parent repository of this cert */
> char*repo; /* CA repository (rsync:// uri) */
> char*mft; /* manifest (rsync:// uri) */
> char*notify; /* RRDP notify (https:// uri) */
> Index: parser.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
> retrieving revision 1.75
> diff -u -p -r1.75 parser.c
> --- parser.c 30 Aug 2022 18:56:49 - 1.75
> +++ parser.c 3 Sep 2022 11:03:46 -
> @@ -596,8 +596,10 @@ parse_entity(struct entityq *q, struct m
> cert = proc_parser_cert(file, f, flen);
> c = (cert != NULL);
> io_simple_buffer(b, , sizeof(int));
> - if (cert != NULL)
> + if (cert != NULL) {
> + cert->parentid = entp->repoid;
> cert_buffer(b, cert);
> + }
> /*
>* The parsed certificate data "cert" is now
>* managed in the "auths" table, so don't free
>
rpki-client include "parent" repo id in certs
This diff adds the parentid to struct cert. The parentid is the id of the
repository the cert lives in. This information will be used to track the
parent repository in the repositories list/tree.
The naming is confusing and I'm happy for better suggestions.
--
:wq Claudio
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.85
diff -u -p -r1.85 cert.c
--- cert.c 19 Aug 2022 12:45:53 - 1.85
+++ cert.c 3 Sep 2022 11:03:46 -
@@ -898,6 +898,7 @@ cert_buffer(struct ibuf *b, const struct
io_simple_buffer(b, >expires, sizeof(p->expires));
io_simple_buffer(b, >purpose, sizeof(p->purpose));
io_simple_buffer(b, >talid, sizeof(p->talid));
+ io_simple_buffer(b, >parentid, sizeof(p->parentid));
io_simple_buffer(b, >ipsz, sizeof(p->ipsz));
io_simple_buffer(b, >asz, sizeof(p->asz));
@@ -930,6 +931,7 @@ cert_read(struct ibuf *b)
io_read_buf(b, >expires, sizeof(p->expires));
io_read_buf(b, >purpose, sizeof(p->purpose));
io_read_buf(b, >talid, sizeof(p->talid));
+ io_read_buf(b, >parentid, sizeof(p->parentid));
io_read_buf(b, >ipsz, sizeof(p->ipsz));
io_read_buf(b, >asz, sizeof(p->asz));
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.153
diff -u -p -r1.153 extern.h
--- extern.h2 Sep 2022 19:10:36 - 1.153
+++ extern.h3 Sep 2022 11:03:46 -
@@ -137,6 +137,7 @@ struct cert {
struct cert_as *as; /* list of AS numbers and ranges */
size_t asz; /* length of "asz" */
int talid; /* cert is covered by which TAL */
+ unsigned int parentid; /* parent repository of this cert */
char*repo; /* CA repository (rsync:// uri) */
char*mft; /* manifest (rsync:// uri) */
char*notify; /* RRDP notify (https:// uri) */
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.75
diff -u -p -r1.75 parser.c
--- parser.c30 Aug 2022 18:56:49 - 1.75
+++ parser.c3 Sep 2022 11:03:46 -
@@ -596,8 +596,10 @@ parse_entity(struct entityq *q, struct m
cert = proc_parser_cert(file, f, flen);
c = (cert != NULL);
io_simple_buffer(b, , sizeof(int));
- if (cert != NULL)
+ if (cert != NULL) {
+ cert->parentid = entp->repoid;
cert_buffer(b, cert);
+ }
/*
* The parsed certificate data "cert" is now
* managed in the "auths" table, so don't free
vmd: Add support for agentx
Already had an OK dv@ for a slightly older version, but I found a issue
with reloading after and would like to give other people a chance to
give their input.
To test simply put the agentx keyword in both snmpd.conf and vm.conf and
walk over mib-2.236 (or in quirky snmp(1) terms mib_2.236)
martijn@
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/vmd/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile5 Apr 2021 18:09:48 - 1.26
+++ Makefile3 Sep 2022 11:06:31 -
@@ -7,6 +7,7 @@ SRCS= vmd.c control.c log.c priv.c proc
SRCS+= vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c
SRCS+= ns8250.c i8253.c dhcp.c packet.c
SRCS+= parse.y atomicio.c vioscsi.c vioraw.c vioqcow2.c fw_cfg.c
+SRCS+= vm_agentx.c
CFLAGS+= -Wall -I${.CURDIR}
CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
@@ -14,8 +15,8 @@ CFLAGS+= -Wmissing-declarations
CFLAGS+= -Wshadow -Wpointer-arith -Wcast-qual
CFLAGS+= -Wsign-compare
-LDADD+=-lutil -lpthread -levent -lz
-DPADD+=${LIBUTIL} ${LIBPTHREAD} ${LIBEVENT} ${LIBZ}
+LDADD+=-lutil -lpthread -levent -lz -lagentx
+DPADD+=${LIBUTIL} ${LIBPTHREAD} ${LIBEVENT} ${LIBZ}
${LIBAGENTX}
YFLAGS=
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/vmd/parse.y,v
retrieving revision 1.61
diff -u -p -r1.61 parse.y
--- parse.y 4 May 2022 23:17:25 - 1.61
+++ parse.y 3 Sep 2022 11:06:31 -
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
#include
#include
@@ -119,7 +120,8 @@ typedef struct {
%token INCLUDE ERROR
-%token ADD ALLOW BOOT CDROM DEVICE DISABLE DISK DOWN ENABLE FORMAT GROUP
+%token ADD AGENTX ALLOW BOOT CDROM CONTEXT DEVICE DISABLE DISK DOWN ENABLE
+%token FORMAT GROUP
%token INET6 INSTANCE INTERFACE LLADDR LOCAL LOCKED MEMORY NET NIFS OWNER
%token PATH PREFIX RDOMAIN SIZE SOCKET SWITCH UP VM VMID STAGGERED START
%token PARALLEL DELAY
@@ -217,6 +219,18 @@ main : LOCAL INET6 {
env->vmd_ps.ps_csock.cs_uid = $3.uid;
env->vmd_ps.ps_csock.cs_gid = $3.gid == -1 ? 0 : $3.gid;
}
+ | AGENTX {
+ env->vmd_cfg.cfg_agentx.ax_enabled = 1;
+ } agentxopts {
+ if (env->vmd_cfg.cfg_agentx.ax_path[0] == '\0')
+ if (strlcpy(env->vmd_cfg.cfg_agentx.ax_path,
+ AGENTX_MASTER_PATH,
+ sizeof(env->vmd_cfg.cfg_agentx.ax_path)) >=
+ sizeof(env->vmd_cfg.cfg_agentx.ax_path)) {
+ yyerror("invalid agentx path");
+ YYERROR;
+ }
+ }
| STAGGERED START PARALLEL NUMBER DELAY NUMBER {
env->vmd_cfg.cfg_flags |= VMD_CFG_STAGGERED_START;
env->vmd_cfg.delay.tv_sec = $6;
@@ -595,6 +609,35 @@ owner_id : NUMBER{
}
;
+agentxopt : CONTEXT STRING {
+ if (strlcpy(env->vmd_cfg.cfg_agentx.ax_context, $2,
+ sizeof(env->vmd_cfg.cfg_agentx.ax_context)) >=
+ sizeof(env->vmd_cfg.cfg_agentx.ax_context)) {
+ yyerror("agentx context too large");
+ free($2);
+ YYERROR;
+ }
+ free($2);
+ }
+ | PATH STRING {
+ if (strlcpy(env->vmd_cfg.cfg_agentx.ax_path, $2,
+ sizeof(env->vmd_cfg.cfg_agentx.ax_path)) >=
+ sizeof(env->vmd_cfg.cfg_agentx.ax_path)) {
+ yyerror("agentx path too large");
+ free($2);
+ YYERROR;
+ }
+ free($2);
+ if (env->vmd_cfg.cfg_agentx.ax_path[0] != '/') {
+ yyerror("agentx path is not absolute");
+ YYERROR;
+ }
+ }
+
+agentxopts : /* none */
+ | agentxopts agentxopt
+ ;
+
image_format : /* none */ {
$$ = 0;
}
@@ -769,9 +812,11 @@ lookup(char *s)
/* this has to be sorted always */
static const struct keywords keywords[] = {
{ "add",ADD },
+ { "agentx", AGENTX },
{ "allow", ALLOW },
{ "boot", BOOT },
rm -P and no-write on files - perm denied, bail out?
Hi,
I wanted to rm -rP some files on my disk and didn't notice that
they lacked write permission for the user who executed rm(1)
command.
$ echo foo > file-mode-444.txt
$ chmod 0444 file-mode-444.txt
$ ls -ln file-mode-444.txt
-r--r--r-- 1 5001 5001 4 Sep 3 09:36 file-mode-444.txt
$ rm -vfP file-mode-444.txt
rm: file-mode-444.txt: Permission denied
file-mode-444.txt
$ echo $?
1
$ ls -l file-mode-444.txt
ls: file-mode-444.txt: No such file or directory
I was not expecting this behaviour. My expectation was the file would
NOT be removed. Hence the diff below:
Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.44
diff -u -p -u -r1.44 rm.c
--- rm.c16 Aug 2022 13:52:41 - 1.44
+++ rm.c3 Sep 2022 09:37:44 -
@@ -215,8 +215,11 @@ rm_tree(char **argv)
case FTS_F:
case FTS_NSOK:
if (Pflag)
- rm_overwrite(p->fts_accpath, p->fts_info ==
- FTS_NSOK ? NULL : p->fts_statp);
+ if (!rm_overwrite(p->fts_accpath, p->fts_info ==
+ FTS_NSOK ? NULL : p->fts_statp)) {
+ eval = 1;
+ continue;
+ }
/* FALLTHROUGH */
default:
if (!unlink(p->fts_accpath)) {
@@ -267,7 +270,10 @@ rm_file(char **argv)
rval = rmdir(f);
else {
if (Pflag)
- rm_overwrite(f, );
+ if (!rm_overwrite(f, )) {
+ eval = 1;
+ continue;
+ }
rval = unlink(f);
}
if (rval && (!fflag || errno != ENOENT)) {
What do you guys think?
$ ./obj/rm -vfP file-mode-444.txt
rm: file-mode-444.txt: Permission denied
$ echo $?
1
$ ls -ln file-mode-444.txt
-r--r--r-- 1 5001 5001 4 Sep 3 09:36 file-mode-444.txt
I did use `rm -fP` in the invocation, and reading the rm(1) manual page:
-f Attempt to remove the files without prompting for confirmation,
regardless of the file's permissions. If the file does not
exist, do not display a diagnostic message or modify the exit
status to reflect an error. The -f option overrides any previous
-i options.
but not sure then what exactly should happen when -P and -f and no write
permission.
--
Regards,
Mikolaj
Re: rpki-client mini refactor
On Sat, Sep 03, 2022 at 11:12:41AM +0200, Claudio Jeker wrote: > Instead of passing the repo to queue_from_mft() do the lookup in the > function. Looks like a simplification missed in a previous refactor. ok
rpki-client mini refactor
Instead of passing the repo to queue_from_mft() do the lookup in the
function.
--
:wq Claudio
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.218
diff -u -p -r1.218 main.c
--- main.c 2 Sep 2022 21:56:45 - 1.218
+++ main.c 3 Sep 2022 09:09:25 -
@@ -359,12 +359,14 @@ rrdp_http_done(unsigned int id, enum htt
* These are always relative to the directory in which "mft" sits.
*/
static void
-queue_add_from_mft(const struct mft *mft, struct repo *rp)
+queue_add_from_mft(const struct mft *mft)
{
size_t i;
+ struct repo *rp;
const struct mftfile*f;
char*nfile, *npath = NULL;
+ rp = repo_byid(mft->repoid);
for (i = 0; i < mft->filesz; i++) {
f = >files[i];
@@ -568,7 +570,7 @@ entity_process(struct ibuf *b, struct st
}
mft = mft_read(b);
if (!mft->stale)
- queue_add_from_mft(mft, repo_byid(mft->repoid));
+ queue_add_from_mft(mft);
else
st->mfts_stale++;
mft_free(mft);
Re: ifconfig, wireguard output less verbose, unless -A or
Hi,
I tried to address what jmc@ mentioned below. I don't really know
mdoc(7) and English is not my native language, so I imagine there is
place for improvement in the wg(4) diff.
Full diff at the very end of this email, below here `diff -wu` to
visualize how minimal ifconfig.c changes are:
| Index: sbin/ifconfig/ifconfig.c
| ===
| RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
| retrieving revision 1.456
| diff -u -p -w -u -r1.456 ifconfig.c
| --- sbin/ifconfig/ifconfig.c 8 Jul 2022 07:04:54 - 1.456
| +++ sbin/ifconfig/ifconfig.c 3 Sep 2022 08:25:00 -
| @@ -363,7 +363,7 @@ void unsetwgpeer(const char *, int);
| void unsetwgpeerpsk(const char *, int);
| void unsetwgpeerall(const char *, int);
|
| -void wg_status();
| +void wg_status(int);
| #else
| void setignore(const char *, int);
| #endif
| @@ -679,7 +679,7 @@ void printgroupattribs(char *);
| void printif(char *, int);
| void printb_status(unsigned short, unsigned char *);
| const char *get_linkstate(int, int);
| -void status(int, struct sockaddr_dl *, int);
| +void status(int, struct sockaddr_dl *, int, int);
| __dead void usage(void);
| const char *get_string(const char *, const char *, u_int8_t *, int *);
| int len_string(const u_int8_t *, int);
| @@ -1195,7 +1195,7 @@ printif(char *name, int ifaliases)
| continue;
| ifdata = ifa->ifa_data;
| status(1, (struct sockaddr_dl *)ifa->ifa_addr,
| - ifdata->ifi_link_state);
| + ifdata->ifi_link_state, ifaliases);
| count++;
| noinet = 1;
| continue;
| @@ -3316,7 +3316,7 @@ get_linkstate(int mt, int link_state)
| * specified, show it and it only; otherwise, show them all.
| */
| void
| -status(int link, struct sockaddr_dl *sdl, int ls)
| +status(int link, struct sockaddr_dl *sdl, int ls, int ifaliases)
| {
| const struct afswtch *p = afp;
| struct ifmediareq ifmr;
| @@ -3391,7 +3391,7 @@ status(int link, struct sockaddr_dl *sdl
| mpls_status();
| pflow_status();
| umb_status();
| - wg_status();
| + wg_status(ifaliases);
| #endif
| trunk_status();
| getifgroups();
| @@ -5907,7 +5907,7 @@ process_wg_commands(void)
| }
|
| void
| -wg_status(void)
| +wg_status(int ifaliases)
| {
| size_t i, j, last_size;
| struct timespec now;
| @@ -5942,6 +5942,7 @@ wg_status(void)
| printf("\twgpubkey %s\n", key);
| }
|
| + if (ifaliases) {
| wg_peer = _interface->i_peers[0];
| for (i = 0; i < wg_interface->i_peers_count; i++) {
| b64_ntop(wg_peer->p_public, WG_KEY_LEN,
| @@ -5981,6 +5982,7 @@ wg_status(void)
| wg_aip++;
| }
| wg_peer = (struct wg_peer_io *)wg_aip;
| + }
| }
| out:
| free(wgdata.wgd_interface);
On Sat, Aug 20, 2022 at 07:15:39PM +0100, Jason McIntyre wrote:
> On Sat, Aug 20, 2022 at 02:25:25PM +0100, Stuart Henderson wrote:
> > >
> > > Long output with as an argument, wgpeers section present:
> > >
> > > pce-0067# ifconfig.ifaliases wg0
> > > wg0: flags=80c3 mtu 1420
> > > index 8 priority 0 llprio 3
> > > wgport 51820
> > > wgpubkey qcb...
> > > wgpeer klM...
> > > wgpsk (present)
> > > wgpka 25 (sec)
> > > wgendpoint xxx.xxx.xxx.xxx 51820
> > > tx: 178764, rx: 65100
> > > last handshake: 7 seconds ago
> > > wgaip fde4:f456:48c2:13c0::/64
> > > groups: wg
> > > inet6 fde4:f456:48c2:13c0::cc67 prefixlen 64
> > >
> > >
> > > Above long output works with group as an argument (ifconfig wg) and with
> > > option -A (ifconfig -A), so I think from user experience perspective,
> > > works as expected.
> > >
> > > Manual page changes not provided, as I'm not sure are they needed with
> > > this diff.
> >
> > At least a small change is needed. Maybe some different text would
> > be more appropriate though.
> >
> > Index: ifconfig.8
> > ===
> > RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
> > retrieving revision 1.384
> > diff -u -p -r1.384 ifconfig.8
> > --- ifconfig.8 27 Jun 2022 16:27:03 - 1.384
> > +++ ifconfig.8 20 Aug 2022 13:22:43 -
> > @@ -75,7 +75,7 @@ Only the superuser may modify the config
> > The following options are available:
> > .Bl -tag -width Ds
> > .It Fl A
> > -Causes full interface alias information for each interface to
> > +Causes full interface alias and wgpeer information for each interface to
> > be displayed.
> > .It Fl a
> > Causes
> >
>
> hi.
>
> i think this just muddies the simple explanation of -A. i don;t think
> it's worth
ikbd(4) as console keyboard
Diff below makes it possible for ikbd(4) to become the console. This
in turn means it is usable in DDB. This probably needs a little bit
of testing. If you have an (amd64) laptop with ikbd(4), please give
this a go and report whether it still works.
ok?
Index: dev/i2c/ihidev.h
===
RCS file: /cvs/src/sys/dev/i2c/ihidev.h,v
retrieving revision 1.8
diff -u -p -r1.8 ihidev.h
--- dev/i2c/ihidev.h9 Jul 2020 21:01:56 - 1.8
+++ dev/i2c/ihidev.h3 Sep 2022 08:21:50 -
@@ -135,3 +135,5 @@ int ihidev_ioctl(struct ihidev *, u_long
int ihidev_report_type_conv(int);
int ihidev_set_report(struct device *, int, int, void *, int);
int ihidev_get_report(struct device *, int, int, void *, int);
+
+void ihidev_poll(void *);
Index: dev/i2c/ikbd.c
===
RCS file: /cvs/src/sys/dev/i2c/ikbd.c,v
retrieving revision 1.1
diff -u -p -r1.1 ikbd.c
--- dev/i2c/ikbd.c 14 Jan 2016 21:01:49 - 1.1
+++ dev/i2c/ikbd.c 3 Sep 2022 08:21:50 -
@@ -37,10 +37,21 @@
struct ikbd_softc {
struct ihidev sc_hdev;
struct hidkbd sc_kbd;
+ int sc_spl;
};
void ikbd_intr(struct ihidev *addr, void *ibuf, u_int len);
+void ikbd_cngetc(void *, u_int *, int *);
+void ikbd_cnpollc(void *, int);
+void ikbd_cnbell(void *, u_int, u_int, u_int);
+
+const struct wskbd_consops ikbd_consops = {
+ ikbd_cngetc,
+ ikbd_cnpollc,
+ ikbd_cnbell,
+};
+
intikbd_enable(void *, int);
void ikbd_set_leds(void *, int);
intikbd_ioctl(void *, u_long, caddr_t, int, struct proc *);
@@ -100,11 +111,19 @@ ikbd_attach(struct device *parent, struc
sc->sc_hdev.sc_osize = hid_report_size(desc, dlen, hid_output, repid);
sc->sc_hdev.sc_fsize = hid_report_size(desc, dlen, hid_feature, repid);
- if (hidkbd_attach(self, kbd, 0, 0, repid, desc, dlen) != 0)
+ if (hidkbd_attach(self, kbd, 1, 0, repid, desc, dlen) != 0)
return;
printf("\n");
+ if (kbd->sc_console_keyboard) {
+ extern struct wskbd_mapdata ukbd_keymapdata;
+
+ ukbd_keymapdata.layout = KB_US | KB_DEFAULT;
+ wskbd_cnattach(_consops, sc, _keymapdata);
+ ikbd_enable(sc, 1);
+ }
+
hidkbd_attach_wskbd(kbd, KB_US | KB_DEFAULT, _accessops);
}
@@ -169,4 +188,37 @@ ikbd_ioctl(void *v, u_long cmd, caddr_t
else
return hidkbd_ioctl(kbd, cmd, data, flag, p);
}
+}
+
+/* Console interface. */
+void
+ikbd_cngetc(void *v, u_int *type, int *data)
+{
+ struct ikbd_softc *sc = v;
+ struct hidkbd *kbd = >sc_kbd;
+
+ kbd->sc_polling = 1;
+ while (kbd->sc_npollchar <= 0) {
+ ihidev_poll(sc->sc_hdev.sc_parent);
+ delay(1000);
+ }
+ kbd->sc_polling = 0;
+ hidkbd_cngetc(kbd, type, data);
+}
+
+void
+ikbd_cnpollc(void *v, int on)
+{
+ struct ikbd_softc *sc = v;
+
+ if (on)
+ sc->sc_spl = spltty();
+ else
+ splx(sc->sc_spl);
+}
+
+void
+ikbd_cnbell(void *v, u_int pitch, u_int period, u_int volume)
+{
+ hidkbd_bell(pitch, period, volume, 1);
}
Re: dwctwo(4) periodic transfers improvement
> Date: Sat, 3 Sep 2022 09:31:39 +0200 > From: Marcus Glocker > > On Tue, Aug 30, 2022 at 07:17:19AM +0200, Marcus Glocker wrote: > > > Periodic transfers on dwctwo(4) work very unreliable today. If I want > > to use my RPI3B+ as a workstation, the keyboard is working so > > unreliable, I can't hardly log-in to X. Playing USB audio isn't fun > > either. > > > > After circulating this diff internally for a while, and merging back the > > received feedback, I'm sending it out here. This is version seven of > > the diff. It includes another change, which is to run dwctwo(4) on > > IPL_VM instead of IPL_USB, like NetBSD does it already, and as briefly > > discussed with kettenis@. It enhances the reliability of the periodic > > transfers further by prioritizing them against IPL_BIO interrupts, as > > i.e. coming from bcmsdhost(4). > > > > The other majority of the diff contains the merging with the > > Linux driver, which did a large rework on the periodic scheduling > > to overcome similar issues we are seeing currently. Also being > > in sync with the Linux driver will make future adaption of improvements > > much more easy. Today we are so much out of sync, we can hardly adapt > > patches from there. > > > > With this diff following tasks can run in parallel on my RPI3B+: > > > > * Reliable keyboard. > > * USB audio streaming. > > * USB video streaming. > > * Disk operations. > > > > Still on high system interrupts, audio will crackle a bit, and the > > keyboard will sometimes miss or repeat keystrokes. I have some ideas > > on how to further improve that once the diff should make it in, like > > scheduling continuous transfers for isoc and interrupt pipes. See my > > recent diff about 'Continuous USB transfers'. > > > > I have tested it for quite a while on arm64 and regression tested on > > octeon. As a summary; It's still not perfect, but it's better than > > before, and I think it's the way forward to get still better :-) > > > > Further testing, comments, and OKs welcome. > > In the meantime I also have tested the uaudio(4) recording on the > RPI3B+; While with a snapshot kernel there is consistent noise in > the recording, the recording with the synced driver is clear. go for it
Re: [please test] pvclock(4): fix several bugs
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote: > dv@ suggested coming to the list to request testing for the pvclock(4) > driver. Attached is a patch that corrects several bugs. Most of > these changes will only matter in the non-TSC_STABLE case on a > multiprocessor VM. > > Ideally, nothing should break. > I've put this on an OpenBSD VM hosted on a proxmox VE 7 hypervisor. It uses pvclock as the time source both before and after the patch : kern.timecounter.hardware=pvclock0 kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) acpitimer0(1000) OpenBSD 7.2-beta (GENERIC.MP) #300: Sat Sep 3 09:34:42 CEST 2022 matth...@zuma.herrb.net:/usr/obj/GENERIC.MP real mem = 4278005760 (4079MB) avail mem = 4130959360 (3939MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf59a0 (10 entries) bios0: vendor SeaBIOS version "rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org" date 04/01/2014 bios0: QEMU Standard PC (Q35 + ICH9, 2009) acpi0 at bios0: ACPI 3.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC SSDT HPET MCFG WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Common KVM processor, 2000.60 MHz, 0f-06-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured "QEMUVGID" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 16 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 17 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 18 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 0 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi azalia0: no HD-Audio codecs ppb0 at pci0 dev 28 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 16 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 16 pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 16 pci3 at ppb2 bus 3 ppb3 at pci0 dev 28 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 16 pci4 at ppb3 bus 4 uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 16 uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 17 uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 18 ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x03: apic 0 int 19 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92 pci5 at ppb4 bus 5 ppb5 at pci5 dev 1 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci6 at ppb5 bus 6 virtio0 at pci6 dev 3 function 0 "Qumranet Virtio Memory Balloon" rev 0x00 viomb0 at virtio0 virtio0: apic 0 int 20 virtio1 at pci6 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio1 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: sd0: 40960MB, 512 bytes/sector, 83886080 sectors virtio1: msix shared virtio2 at pci6 dev 18 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio2: address 82:da:9e:53:3e:6b virtio2: msix shared ppb6 at pci5 dev 2 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci7 at ppb6 bus 7 ppb7 at pci5 dev 3 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci8 at ppb7 bus 8 ppb8 at pci5 dev 4 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci9 at ppb8 bus 9 pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi,
Re: dwctwo(4) periodic transfers improvement
On Tue, Aug 30, 2022 at 07:17:19AM +0200, Marcus Glocker wrote: > Periodic transfers on dwctwo(4) work very unreliable today. If I want > to use my RPI3B+ as a workstation, the keyboard is working so > unreliable, I can't hardly log-in to X. Playing USB audio isn't fun > either. > > After circulating this diff internally for a while, and merging back the > received feedback, I'm sending it out here. This is version seven of > the diff. It includes another change, which is to run dwctwo(4) on > IPL_VM instead of IPL_USB, like NetBSD does it already, and as briefly > discussed with kettenis@. It enhances the reliability of the periodic > transfers further by prioritizing them against IPL_BIO interrupts, as > i.e. coming from bcmsdhost(4). > > The other majority of the diff contains the merging with the > Linux driver, which did a large rework on the periodic scheduling > to overcome similar issues we are seeing currently. Also being > in sync with the Linux driver will make future adaption of improvements > much more easy. Today we are so much out of sync, we can hardly adapt > patches from there. > > With this diff following tasks can run in parallel on my RPI3B+: > > * Reliable keyboard. > * USB audio streaming. > * USB video streaming. > * Disk operations. > > Still on high system interrupts, audio will crackle a bit, and the > keyboard will sometimes miss or repeat keystrokes. I have some ideas > on how to further improve that once the diff should make it in, like > scheduling continuous transfers for isoc and interrupt pipes. See my > recent diff about 'Continuous USB transfers'. > > I have tested it for quite a while on arm64 and regression tested on > octeon. As a summary; It's still not perfect, but it's better than > before, and I think it's the way forward to get still better :-) > > Further testing, comments, and OKs welcome. In the meantime I also have tested the uaudio(4) recording on the RPI3B+; While with a snapshot kernel there is consistent noise in the recording, the recording with the synced driver is clear.
Re: [please test] pvclock(4): fix several bugs
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multiprocessor VM.
>
> Ideally, nothing should break.
>
> - pvclock yields a 64-bit value. The BSD timecounter layer can only
> use the lower 32 bits, but internally we need to track the full
> 64-bit value to allow comparisons with the full value in the
> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity.
>
> - In pvclock_get_timecount(), move rdtsc() up into the lockless read
> loop to get a more accurate timestamp.
>
> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc().
>
> - In pvclock_get_timecount(), check that our TSC value doesn't predate
> ti->ti_tsc_timestamp, otherwise we will produce an enormous value.
>
> - In pvclock_get_timecount(), update pvclock_lastcount in the
> non-TSC_STABLE case with more care. On amd64 we can do this with an
> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need
> to introduce a mutex to protect our comparison and read/write.
i386 has cmpxchg8b, no need to disable interrupts
the ifdefs seem excessive
>
> Index: pvclock.c
> ===
> RCS file: /cvs/src/sys/dev/pv/pvclock.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 pvclock.c
> --- pvclock.c 5 Nov 2021 11:38:29 - 1.8
> +++ pvclock.c 2 Sep 2022 22:54:08 -
> @@ -27,6 +27,10 @@
> #include
> #include
> #include
> +#include
> +#if defined(__i386__)
> +#include
> +#endif
>
> #include
> #include
> @@ -35,7 +39,12 @@
> #include
> #include
>
> -uint pvclock_lastcount;
> +#if defined(__amd64__)
> +volatile u_long pvclock_lastcount;
> +#elif defined(__i386__)
> +struct mutex pvclock_mtx = MUTEX_INITIALIZER(IPL_HIGH);
> +uint64_t pvclock_lastcount;
> +#endif
>
> struct pvclock_softc {
> struct devicesc_dev;
> @@ -212,7 +221,7 @@ pvclock_get_timecount(struct timecounter
> {
> struct pvclock_softc*sc = tc->tc_priv;
> struct pvclock_time_info*ti;
> - uint64_t tsc_timestamp, system_time, delta, ctr;
> + uint64_t system_time, delta, ctr, tsc;
> uint32_t version, mul_frac;
> int8_t shift;
> uint8_t flags;
> @@ -220,8 +229,12 @@ pvclock_get_timecount(struct timecounter
> ti = sc->sc_time;
> do {
> version = pvclock_read_begin(ti);
> + tsc = rdtsc_lfence();
> + if (ti->ti_tsc_timestamp < tsc)
> + delta = tsc - ti->ti_tsc_timestamp;
> + else
> + delta = 0;
> system_time = ti->ti_system_time;
> - tsc_timestamp = ti->ti_tsc_timestamp;
> mul_frac = ti->ti_tsc_to_system_mul;
> shift = ti->ti_tsc_shift;
> flags = ti->ti_flags;
> @@ -231,7 +244,6 @@ pvclock_get_timecount(struct timecounter
>* The algorithm is described in
>* linux/Documentation/virtual/kvm/msr.txt
>*/
> - delta = rdtsc() - tsc_timestamp;
> if (shift < 0)
> delta >>= -shift;
> else
> @@ -241,10 +253,20 @@ pvclock_get_timecount(struct timecounter
> if ((flags & PVCLOCK_FLAG_TSC_STABLE) != 0)
> return (ctr);
>
> - if (ctr < pvclock_lastcount)
> - return (pvclock_lastcount);
> -
> - atomic_swap_uint(_lastcount, ctr);
> -
> +#if defined(__amd64__)
> + u_long last;
> + do {
> + last = pvclock_lastcount;
> + if (ctr < last)
> + return last;
> + } while (atomic_cas_ulong(_lastcount, last, ctr) != last);
> +#elif defined(__i386__)
> + mtx_enter(_mtx);
> + if (pvclock_lastcount < ctr)
> + pvclock_lastcount = ctr;
> + else
> + ctr = pvclock_lastcount;
> + mtx_leave(_mtx);
> +#endif
> return (ctr);
> }
>
>
Re: [please test] pvclock(4): fix several bugs
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multiprocessor VM.
>
> Ideally, nothing should break.
>
> - pvclock yields a 64-bit value. The BSD timecounter layer can only
> use the lower 32 bits, but internally we need to track the full
> 64-bit value to allow comparisons with the full value in the
> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity.
>
> - In pvclock_get_timecount(), move rdtsc() up into the lockless read
> loop to get a more accurate timestamp.
>
> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc().
>
> - In pvclock_get_timecount(), check that our TSC value doesn't predate
> ti->ti_tsc_timestamp, otherwise we will produce an enormous value.
>
> - In pvclock_get_timecount(), update pvclock_lastcount in the
> non-TSC_STABLE case with more care. On amd64 we can do this with an
> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need
> to introduce a mutex to protect our comparison and read/write.
>
I tested on an 8 core ESXi VM, nothing broke. But it doesn't even
have pvclock as a timesource, so I'm not sure the test is meaningful or
useful.
-ml
> Index: pvclock.c
> ===
> RCS file: /cvs/src/sys/dev/pv/pvclock.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 pvclock.c
> --- pvclock.c 5 Nov 2021 11:38:29 - 1.8
> +++ pvclock.c 2 Sep 2022 22:54:08 -
> @@ -27,6 +27,10 @@
> #include
> #include
> #include
> +#include
> +#if defined(__i386__)
> +#include
> +#endif
>
> #include
> #include
> @@ -35,7 +39,12 @@
> #include
> #include
>
> -uint pvclock_lastcount;
> +#if defined(__amd64__)
> +volatile u_long pvclock_lastcount;
> +#elif defined(__i386__)
> +struct mutex pvclock_mtx = MUTEX_INITIALIZER(IPL_HIGH);
> +uint64_t pvclock_lastcount;
> +#endif
>
> struct pvclock_softc {
> struct devicesc_dev;
> @@ -212,7 +221,7 @@ pvclock_get_timecount(struct timecounter
> {
> struct pvclock_softc*sc = tc->tc_priv;
> struct pvclock_time_info*ti;
> - uint64_t tsc_timestamp, system_time, delta, ctr;
> + uint64_t system_time, delta, ctr, tsc;
> uint32_t version, mul_frac;
> int8_t shift;
> uint8_t flags;
> @@ -220,8 +229,12 @@ pvclock_get_timecount(struct timecounter
> ti = sc->sc_time;
> do {
> version = pvclock_read_begin(ti);
> + tsc = rdtsc_lfence();
> + if (ti->ti_tsc_timestamp < tsc)
> + delta = tsc - ti->ti_tsc_timestamp;
> + else
> + delta = 0;
> system_time = ti->ti_system_time;
> - tsc_timestamp = ti->ti_tsc_timestamp;
> mul_frac = ti->ti_tsc_to_system_mul;
> shift = ti->ti_tsc_shift;
> flags = ti->ti_flags;
> @@ -231,7 +244,6 @@ pvclock_get_timecount(struct timecounter
>* The algorithm is described in
>* linux/Documentation/virtual/kvm/msr.txt
>*/
> - delta = rdtsc() - tsc_timestamp;
> if (shift < 0)
> delta >>= -shift;
> else
> @@ -241,10 +253,20 @@ pvclock_get_timecount(struct timecounter
> if ((flags & PVCLOCK_FLAG_TSC_STABLE) != 0)
> return (ctr);
>
> - if (ctr < pvclock_lastcount)
> - return (pvclock_lastcount);
> -
> - atomic_swap_uint(_lastcount, ctr);
> -
> +#if defined(__amd64__)
> + u_long last;
> + do {
> + last = pvclock_lastcount;
> + if (ctr < last)
> + return last;
> + } while (atomic_cas_ulong(_lastcount, last, ctr) != last);
> +#elif defined(__i386__)
> + mtx_enter(_mtx);
> + if (pvclock_lastcount < ctr)
> + pvclock_lastcount = ctr;
> + else
> + ctr = pvclock_lastcount;
> + mtx_leave(_mtx);
> +#endif
> return (ctr);
> }
