Re: Remove unused code from vmm
On Fri, Jan 31, 2020 at 01:40:14AM +, Adam Steen wrote:
> Hi
>
> While working on a patch, i noticed that vmm_get_guest_faulttype was
> incorrect for amd (VMM_MODE_RVI) cpus, apon further inspection realised
> it was unused. Please see the patch below to remove it.
>
> cheers
> Adam
>
Thanks, will remove.
-ml
> ? div
> Index: sys/arch/amd64/amd64/vmm.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
> retrieving revision 1.257
> diff -u -p -u -p -r1.257 vmm.c
> --- sys/arch/amd64/amd64/vmm.c13 Dec 2019 03:38:15 - 1.257
> +++ sys/arch/amd64/amd64/vmm.c30 Jan 2020 06:47:41 -
> @@ -177,7 +177,6 @@ void vmx_handle_intr(struct vcpu *);
> void vmx_handle_intwin(struct vcpu *);
> void vmx_handle_misc_enable_msr(struct vcpu *);
> int vmm_get_guest_memtype(struct vm *, paddr_t);
> -int vmm_get_guest_faulttype(void);
> int vmx_get_guest_faulttype(void);
> int svm_get_guest_faulttype(struct vmcb *);
> int vmx_get_exit_qualification(uint64_t *);
> @@ -5073,23 +5072,6 @@ vmm_get_guest_memtype(struct vm *vm, pad
>
> DPRINTF("guest memtype @ 0x%llx unknown\n", (uint64_t)gpa);
> return (VMM_MEM_TYPE_UNKNOWN);
> -}
> -
> -/*
> - * vmm_get_guest_faulttype
> - *
> - * Determines the type (R/W/X) of the last fault on the VCPU last run on
> - * this PCPU. Calls the appropriate architecture-specific subroutine.
> - */
> -int
> -vmm_get_guest_faulttype(void)
> -{
> - if (vmm_softc->mode == VMM_MODE_EPT)
> - return vmx_get_guest_faulttype();
> - else if (vmm_softc->mode == VMM_MODE_RVI)
> - return vmx_get_guest_faulttype();
> - else
> - panic("%s: unknown vmm mode: %d", __func__, vmm_softc->mode);
> }
>
> /*
>
Remove unused code from vmm
Hi
While working on a patch, i noticed that vmm_get_guest_faulttype was
incorrect for amd (VMM_MODE_RVI) cpus, apon further inspection realised
it was unused. Please see the patch below to remove it.
cheers
Adam
? div
Index: sys/arch/amd64/amd64/vmm.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
retrieving revision 1.257
diff -u -p -u -p -r1.257 vmm.c
--- sys/arch/amd64/amd64/vmm.c 13 Dec 2019 03:38:15 - 1.257
+++ sys/arch/amd64/amd64/vmm.c 30 Jan 2020 06:47:41 -
@@ -177,7 +177,6 @@ void vmx_handle_intr(struct vcpu *);
void vmx_handle_intwin(struct vcpu *);
void vmx_handle_misc_enable_msr(struct vcpu *);
int vmm_get_guest_memtype(struct vm *, paddr_t);
-int vmm_get_guest_faulttype(void);
int vmx_get_guest_faulttype(void);
int svm_get_guest_faulttype(struct vmcb *);
int vmx_get_exit_qualification(uint64_t *);
@@ -5073,23 +5072,6 @@ vmm_get_guest_memtype(struct vm *vm, pad
DPRINTF("guest memtype @ 0x%llx unknown\n", (uint64_t)gpa);
return (VMM_MEM_TYPE_UNKNOWN);
-}
-
-/*
- * vmm_get_guest_faulttype
- *
- * Determines the type (R/W/X) of the last fault on the VCPU last run on
- * this PCPU. Calls the appropriate architecture-specific subroutine.
- */
-int
-vmm_get_guest_faulttype(void)
-{
- if (vmm_softc->mode == VMM_MODE_EPT)
- return vmx_get_guest_faulttype();
- else if (vmm_softc->mode == VMM_MODE_RVI)
- return vmx_get_guest_faulttype();
- else
- panic("%s: unknown vmm mode: %d", __func__, vmm_softc->mode);
}
/*
Re: waitpid vs ptrace
On Thu, 30 Jan 2020, Marc Espie wrote: > So, basically, if we start arbitrary commands, then > the classic loop > /* Wait for the child to exit. */ > while (waitpid(cpid, &status, 0) == -1 && errno == EINTR) > continue; > > is not quite enough. > > See the small note in manpages (not only us, but everyone): > WIFSTOPPED(status) > True if the process has not terminated, but has stopped and can > be restarted. This macro can be true only if the wait call > specified the WUNTRACED option or if the child process is being > traced (see ptrace(2)). > > this means that somebody could run a command that forks, and then its child > (our grand-child) could use ptrace on its parent, and then we would get > a notification with WIFSTOPPED (assuming the current kernel bug is fixed). No, what you describe would not cause waitpid(2) to return in the 'make' process: when ptrace(PT_ATTACH) is used, then target is effectively reparented to the tracing process such that the tracing process is the one which sees the wait() status changes, including the "stopped for tracing" state. Only when it is detached (and thus either continued or killed!) will the make process see any wait statuses; at that point they will be normal wait statuses. The case you describe _can_ happen if make's direct child simply calls ptrace(PT_TRACE_ME) and then takes a signal or execs, but a process doing that without providing a tracer process as well is simply buggy and misdesigned. (The kernel bug is that wait calls in the "original but not currently the parent" process do not act like the traced process is still there and running: the fact that the child has been attached to and is being stopped and started by its tracer should be completely invisible to the original parent.) Philip Guenther
Re: ntpd and 2036
On Mon, Jan 20, 2020 at 07:08:26AM +0100, Otto Moerbeek wrote:
> On Fri, Jan 10, 2020 at 03:14:42PM +0100, Otto Moerbeek wrote:
>
> > Hi,
> >
> > THe ntp protocol uses 32-bit unsigned timestamps counting seconds
> > since 1900. That means that in 2036 the timestamp field will wrap.
> > This difff makes sure ntpd handles that correctly by assuming we are
> > in era 0 unless we see "small" timestamps.
> >
> > tested in the future (incuding wrapping form era 0 to 1) on a couple
> > of machines including one running xntpd for interoperability.
> >
> > ok?
>
> ping...
Firts post on Jan 10th, zero feedback. I think I'll commit and let the
community do the testing. We'll have 16 years to fix the bugs.
-Otto
>
> >
> > Index: client.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ntpd/client.c,v
> > retrieving revision 1.112
> > diff -u -p -r1.112 client.c
> > --- client.c10 Nov 2019 19:24:47 - 1.112
> > +++ client.c10 Jan 2020 14:06:14 -
> > @@ -324,12 +324,6 @@ client_dispatch(struct ntp_peer *p, u_in
> > }
> > }
> >
> > - if (T4 < JAN_1970) {
> > - client_log_error(p, "recvmsg control format", EBADF);
> > - set_next(p, error_interval());
> > - return (0);
> > - }
> > -
> > ntp_getmsg((struct sockaddr *)&p->addr->ss, buf, size, &msg);
> >
> > if (msg.orgtime.int_partl != p->query->msg.xmttime.int_partl ||
> > @@ -374,16 +368,6 @@ client_dispatch(struct ntp_peer *p, u_in
> > T1 = p->query->xmttime;
> > T2 = lfp_to_d(msg.rectime);
> > T3 = lfp_to_d(msg.xmttime);
> > -
> > - /*
> > -* XXX workaround: time_t / tv_sec must never wrap.
> > -* around 2020 we will need a solution (64bit time_t / tv_sec).
> > -* consider every answer with a timestamp beyond january 2030 bogus.
> > -*/
> > - if (T2 > JAN_2030 || T3 > JAN_2030) {
> > - set_next(p, error_interval());
> > - return (0);
> > - }
> >
> > /* Detect liars */
> > if (!p->trusted && conf->constraint_median != 0 &&
> > Index: ntp.h
> > ===
> > RCS file: /cvs/src/usr.sbin/ntpd/ntp.h,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 ntp.h
> > --- ntp.h 22 Apr 2009 07:42:17 - 1.13
> > +++ ntp.h 10 Jan 2020 14:06:14 -
> > @@ -141,7 +141,19 @@ struct ntp_query {
> > #defineMODE_RES2 7 /* reserved for private use */
> >
> > #defineJAN_19702208988800UL/* 1970 - 1900 in seconds */
> > -#defineJAN_20301893456000UL + JAN_1970 /* 1. 1. 2030 00:00:00
> > */
> > +
> > +/*
> > + * The era we're in if we have no reason to assume otherwise.
> > + * If lfp_to_d() sees an offset <= INT32_MAX the era is is assumed to be
> > + * NTP_ERA + 1.
> > + * Once the actual year is well into era 1, (after 2036) define NTP_ERA to
> > 1
> > + * and adapt (remove) the test in lfp_to_d().
> > + * Once more than half of era 1 has elapsed (after 2104), re-inroduce the
> > test
> > + * to move to era 2 if offset <= INT32_MAX, repeat for each half era.
> > + */
> > +#define NTP_ERA0
> > +
> > +#define SECS_IN_ERA(UINT32_MAX + 1ULL)
> >
> > #defineNTP_VERSION 4
> > #defineNTP_MAXSTRATUM 15
> > Index: util.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ntpd/util.c,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 util.c
> > --- util.c 1 Mar 2017 00:56:30 - 1.24
> > +++ util.c 10 Jan 2020 14:06:14 -
> > @@ -86,12 +86,17 @@ d_to_tv(double d, struct timeval *tv)
> > double
> > lfp_to_d(struct l_fixedpt lfp)
> > {
> > - double ret;
> > + double base, ret;
> >
> > lfp.int_partl = ntohl(lfp.int_partl);
> > lfp.fractionl = ntohl(lfp.fractionl);
> >
> > - ret = (double)(lfp.int_partl) + ((double)lfp.fractionl / UINT_MAX);
> > + /* see comment in ntp.h */
> > + base = NTP_ERA;
> > + if (lfp.int_partl <= INT32_MAX)
> > + base++;
> > + ret = base * SECS_IN_ERA;
> > + ret += (double)(lfp.int_partl) + ((double)lfp.fractionl / UINT_MAX);
> >
> > return (ret);
> > }
> > @@ -101,6 +106,8 @@ d_to_lfp(double d)
> > {
> > struct l_fixedptlfp;
> >
> > + while (d > SECS_IN_ERA)
> > + d -= SECS_IN_ERA;
> > lfp.int_partl = htonl((u_int32_t)d);
> > lfp.fractionl = htonl((u_int32_t)((d - (u_int32_t)d) * UINT_MAX));
> >
> >
> >
>
Re: piixpm(4) on ATI SBx00
On 1/22/20 5:25 AM, Ted Unangst wrote: Karel Gardas wrote: On 1/21/20 2:33 AM, Claudio Jeker wrote: Please test this since I can't test this properly at the moment. Sorry for delay with testing. Used today current to update and dmesg and diff of last fix and current dmesg are attached. Looks nice. Besides this it looks like someone also plays with acpi related output but nothing to complain about. Thanks! OpenBSD 6.6-current (GENERIC.MP) #624: Wed Jan 29 09:11:58 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4009230336 (3823MB) avail mem = 3875233792 (3695MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (69 entries) bios0: vendor American Megatrends Inc. version "1701" date 09/08/2010 bios0: ASUSTeK Computer INC. M4A88TD-M EVO acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) SBAZ(S4) P0PC(S4) GEC_(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) II X2 265 Processor, 3315.15 MHz, 10-06-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) II X2 265 Processor, 3314.79 MHz, 10-06-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE5) acpiprt5 at acpi0: bus 2 (PCE6) acpiprt6 at acpi0: bus 3 (PCE7) acpiprt7 at acpi0: bus 4 (PCE9) acpiprt8 at acpi0: bus 5 (PCEA) acpiprt9 at acpi0: bus 6 (P0PC) acpiec0 at acpi0 acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 extent `acpipci0 pcibus' (0x0 - 0xff), flags=0 extent `acpipci0 pciio' (0x0 - 0x), flags=0 0xcf8 - 0xcff 0x1 - 0x extent `acpipci0 pcimem' (0x0 - 0x), flags=0 0x0 - 0x9 0xc - 0xc 0xe - 0xcfff 0xe000 - 0xefff 0xfec0 - 0x acpicmos0 at acpi0 aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM acpibtn0 at acpi0: PWRB "PNP0C14" at acpi0 not configured cpu0: 3315 MHz: speeds: 3300 2600 1900 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 vendor "Asustek", unknown product 0x9602 rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 4250" rev 0x00 drm0 at radeondrm0 radeondrm0: apic 2 int 18 azalia0 at pci1 dev 5 function 1 "ATI Radeon HD 4200 HD Audio" rev 0x00: msi azalia0: no supported codecs ppb1 at pci0 dev 6 function 0 "AMD RS780 PCIE" rev 0x00: msi pci2 at ppb1 bus 2 xhci0 at pci2 dev 0 function 0 "NEC xHCI" rev 0x03: msi, xHCI 0.96 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "NEC xHCI root hub" rev 3.00/1.00 addr 1 ppb2 at pci0 dev 7 function 0 "AMD RS780 PCIE" rev 0x00: msi pci3 at ppb2 bus 3 vendor "VIA", unknown product 0x3403 (class serial bus subclass Firewire, rev 0x01) at pci3 dev 0 function 0 not configured ppb3 at pci0 dev 9 function 0 "AMD RS780 PCIE" rev 0x00: msi pci4 at ppb3 bus 4 pciide0 at pci4 dev 0 function 0 "VIA VT6415 IDE" rev 0x00: ATA133, channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 2 int 17 for native-PCI interrupt
Re: bump smtpd version?
yes ok January 30, 2020 2:02 PM, "Solene Rapenne" wrote: > on https://opensmtpd.org the OpenBSD version file says 6.6.2 while we > currently have 6.6.1 in CVS. > > Should we bump to 6.6.2? > > Index: smtpd.h > === > RCS file: /data/cvs/src/usr.sbin/smtpd/smtpd.h,v > retrieving revision 1.650 > diff -u -p -r1.650 smtpd.h > --- smtpd.h 8 Jan 2020 01:41:11 - 1.650 > +++ smtpd.h 30 Jan 2020 13:00:21 - > @@ -51,7 +51,7 @@ > #define SMTPD_QUEUE_EXPIRY (4 * 24 * 60 * 60) > #define SMTPD_SOCKET "/var/run/smtpd.sock" > #define SMTPD_NAME "OpenSMTPD" > -#define SMTPD_VERSION "6.6.1" > +#define SMTPD_VERSION "6.6.2" > #define SMTPD_SESSION_TIMEOUT 300 > #define SMTPD_BACKLOG 5
bump smtpd version?
on https://opensmtpd.org/ the OpenBSD version file says 6.6.2 while we currently have 6.6.1 in CVS. Should we bump to 6.6.2? Index: smtpd.h === RCS file: /data/cvs/src/usr.sbin/smtpd/smtpd.h,v retrieving revision 1.650 diff -u -p -r1.650 smtpd.h --- smtpd.h 8 Jan 2020 01:41:11 - 1.650 +++ smtpd.h 30 Jan 2020 13:00:21 - @@ -51,7 +51,7 @@ #define SMTPD_QUEUE_EXPIRY (4 * 24 * 60 * 60) #define SMTPD_SOCKET"/var/run/smtpd.sock" #defineSMTPD_NAME "OpenSMTPD" -#defineSMTPD_VERSION"6.6.1" +#defineSMTPD_VERSION"6.6.2" #define SMTPD_SESSION_TIMEOUT 300 #define SMTPD_BACKLOG 5
Re: sysupgrade should check for downgrades
On Thu, Jan 30, 2020 at 11:14:37AM +, Stuart Henderson wrote:
> Putting this here for discussion... good idea? bad idea? does it need
> more checks for expected file contents?
>
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.37
> diff -u -p -r1.37 sysupgrade.sh
> --- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
> +++ sysupgrade.sh 30 Jan 2020 10:56:52 -
> @@ -131,6 +131,7 @@ cd ${SETSDIR}
>
> echo "Fetching from ${URL}"
> unpriv -f SHA256.sig ftp -N sysupgrade -Vmo SHA256.sig ${URL}SHA256.sig
> +unpriv -f BUILDINFO ftp -N sysupgrade -Vmo BUILDINFO ${URL}BUILDINFO
>
> _KEY=openbsd-${_KERNV[0]%.*}${_KERNV[0]#*.}-base.pub
> _NEXTKEY=openbsd-${NEXT_VERSION%.*}${NEXT_VERSION#*.}-base.pub
> @@ -147,11 +148,26 @@ esac
> unpriv -f SHA256 signify -Ve -p "${SIGNIFY_KEY}" -x SHA256.sig -m SHA256
> rm SHA256.sig
>
> +unpriv cksum -qC SHA256 BUILDINFO
> +
> if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
> echo "Already on latest snapshot."
> exit 0
> fi
>
> +if [[ -r /var/db/installed.BUILDINFO ]] && ! $FORCE; then
> + read _skip _skip _oldbuildtime _skip < /var/db/installed.BUILDINFO
> + read _skip _skip _newbuildtime _skip < BUILDINFO
> + if [[ $_newbuildtime -lt $_oldbuildtime ]]; then
> + echo "Snapshot on mirror is older than installed version!"
> + exit 1
> + fi
> + if [[ $_newbuildtime -eq $_oldbuildtime ]]; then
> + echo "Already on latest snapshot? Mismatch between BUILDINFO
> and SHA256?"
> + exit 1
> + fi
> +fi
> +
> # INSTALL.*, bsd*, *.tgz
> SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
> -e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
> @@ -187,9 +203,14 @@ Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> __EOT
>
> +# XXX should be done in bsd.rd so that this is present for a clean install
> too
> +cat <<__EOT > /etc/rc.firsttime
> +cp /home/_sysupgrade/BUILDINFO /var/db/installed.BUILDINFO
> +__EOT
> +
> if ! ${KEEP}; then
> CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
> - cat <<__EOT > /etc/rc.firsttime
> + cat <<__EOT >> /etc/rc.firsttime
> rm -f /home/_sysupgrade/{${CLEAN}}
> __EOT
> fi
>
>
I think it's a good idea. A "bad" mirror could intentionally keep
snapshots around waiting for a critical bug to hit us, and then swap back
to an older snapshot that would be vulnerable. It would probably get
noticed reasonably quick, but not before it could make some damage.
sysupgrade should check for downgrades
Putting this here for discussion... good idea? bad idea? does it need
more checks for expected file contents?
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.37
diff -u -p -r1.37 sysupgrade.sh
--- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
+++ sysupgrade.sh 30 Jan 2020 10:56:52 -
@@ -131,6 +131,7 @@ cd ${SETSDIR}
echo "Fetching from ${URL}"
unpriv -f SHA256.sig ftp -N sysupgrade -Vmo SHA256.sig ${URL}SHA256.sig
+unpriv -f BUILDINFO ftp -N sysupgrade -Vmo BUILDINFO ${URL}BUILDINFO
_KEY=openbsd-${_KERNV[0]%.*}${_KERNV[0]#*.}-base.pub
_NEXTKEY=openbsd-${NEXT_VERSION%.*}${NEXT_VERSION#*.}-base.pub
@@ -147,11 +148,26 @@ esac
unpriv -f SHA256 signify -Ve -p "${SIGNIFY_KEY}" -x SHA256.sig -m SHA256
rm SHA256.sig
+unpriv cksum -qC SHA256 BUILDINFO
+
if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
echo "Already on latest snapshot."
exit 0
fi
+if [[ -r /var/db/installed.BUILDINFO ]] && ! $FORCE; then
+ read _skip _skip _oldbuildtime _skip < /var/db/installed.BUILDINFO
+ read _skip _skip _newbuildtime _skip < BUILDINFO
+ if [[ $_newbuildtime -lt $_oldbuildtime ]]; then
+ echo "Snapshot on mirror is older than installed version!"
+ exit 1
+ fi
+ if [[ $_newbuildtime -eq $_oldbuildtime ]]; then
+ echo "Already on latest snapshot? Mismatch between BUILDINFO
and SHA256?"
+ exit 1
+ fi
+fi
+
# INSTALL.*, bsd*, *.tgz
SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
-e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
@@ -187,9 +203,14 @@ Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes
__EOT
+# XXX should be done in bsd.rd so that this is present for a clean install too
+cat <<__EOT > /etc/rc.firsttime
+cp /home/_sysupgrade/BUILDINFO /var/db/installed.BUILDINFO
+__EOT
+
if ! ${KEEP}; then
CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
- cat <<__EOT > /etc/rc.firsttime
+ cat <<__EOT >> /etc/rc.firsttime
rm -f /home/_sysupgrade/{${CLEAN}}
__EOT
fi
waitpid vs ptrace
So, basically, if we start arbitrary commands, then
the classic loop
/* Wait for the child to exit. */
while (waitpid(cpid, &status, 0) == -1 && errno == EINTR)
continue;
is not quite enough.
See the small note in manpages (not only us, but everyone):
WIFSTOPPED(status)
True if the process has not terminated, but has stopped and can
be restarted. This macro can be true only if the wait call
specified the WUNTRACED option or if the child process is being
traced (see ptrace(2)).
this means that somebody could run a command that forks, and then its child
(our grand-child) could use ptrace on its parent, and then we would get
a notification with WIFSTOPPED (assuming the current kernel bug is fixed).
e.g., something like that:
while (1) {
if (waitpid(cpid, &status, 0) == -1) {
if (errno == EINTR)
continue;
} else {
if (WIFSTOPPED(status))
continue;
}
break;
}
or should we just assume no-one will be nasty enough to do that ?
Re: em(4) diff to test
On 21/01/20(Tue) 12:31, Martin Pieuchot wrote:
> On 20/01/20(Mon) 16:42, Martin Pieuchot wrote:
> > Diff below is a refactoring of the actual em(4) code and defines that
> > will allows me to present a shorter diff to interrupt multiple CPUs and
> > make use of multiple queues.
> >
> > It contains the following items:
> >
> > - Abstract the allocation/freeing of TX/RX ring into em_dma_malloc().
> > This will ease the introduction of multiple rings.
> >
> > - Split the 82576 variant out of 82575. The distinction is necessary
> > when it comes to setting multiple queues.
> >
> > - Change multiple TX/RX related macro to take an index argument
> > corresponding to a ring. Currently only the index 0 and 1 are used.
> >
> > - Gather and print more stats counters
> >
> > - Switch to using a function, like FreeBSD, to translate 82542
> > registers and get rid of a set of defines.
> >
> > It has been tested one the models below, I'd like to be sure there isn't
> > any fallout with this part before continuing the effort.
>
> New diff that works with 82576, previous breakage reported by Hrvoje
> Popovski. So far the following models have been tested, I'm looking for
> more tests :o)
So far this has been tested on the following, I'm confident enough and
would like to move forward, ok?
em2 at pci0 dev 4 function 0 "Intel 82540EM" rev 0x02: apic 9 int 14
em1 at pci3 dev 1 function 0 "Intel 82545GM" rev 0x04: apic 4 int 0
em0 at pci3 dev 1 function 0 "Intel 82546GB" rev 0x03: apic 3 int 0
em3 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 0 int 16
em0 at pci1 dev 0 function 0 "Intel 82572EI" rev 0x06: apic 0 int 16
em2 at pci5 dev 0 function 0 "Intel 82573E" rev 0x03: msi
em3 at pci6 dev 0 function 0 "Intel 82573L" rev 0x00: msi
em0 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi
em0 at pci0 dev 2 function 0 "Intel 82575GB" rev 0x02: msi
em0 at pci1 dev 0 function 0 "Intel 82576" rev 0x01: msi
em0 at pci0 dev 25 function 0 "Intel 82577LM" rev 0x06: msi
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi
em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi
em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi
em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: msi
em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi
em0 at pci0 dev 25 function 0 "Intel I218-V" rev 0x03: msi
em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x04: msi
em0 at pci0 dev 31 function 6 "Intel I219-V" rev 0x21: msi
em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi
Index: pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.343
diff -u -p -r1.343 if_em.c
--- pci/if_em.c 20 Jan 2020 23:45:02 - 1.343
+++ pci/if_em.c 21 Jan 2020 11:27:14 -
@@ -260,6 +260,7 @@ void em_disable_aspm(struct em_softc *);
void em_txeof(struct em_softc *);
int em_allocate_receive_structures(struct em_softc *);
int em_allocate_transmit_structures(struct em_softc *);
+int em_allocate_desc_rings(struct em_softc *);
int em_rxfill(struct em_softc *);
void em_rxrefill(void *);
int em_rxeof(struct em_softc *);
@@ -344,11 +345,6 @@ em_defer_attach(struct device *self)
em_free_pci_resources(sc);
- sc->sc_rx_desc_ring = NULL;
- em_dma_free(sc, &sc->sc_rx_dma);
- sc->sc_tx_desc_ring = NULL;
- em_dma_free(sc, &sc->sc_tx_dma);
-
return;
}
@@ -464,6 +460,7 @@ em_attach(struct device *parent, struct
case em_82572:
case em_82574:
case em_82575:
+ case em_82576:
case em_82580:
case em_i210:
case em_i350:
@@ -494,23 +491,11 @@ em_attach(struct device *parent, struct
sc->hw.min_frame_size =
ETHER_MIN_LEN + ETHER_CRC_LEN;
- /* Allocate Transmit Descriptor ring */
- if (em_dma_malloc(sc, sc->sc_tx_slots * sizeof(struct em_tx_desc),
- &sc->sc_tx_dma) != 0) {
- printf("%s: Unable to allocate tx_desc memory\n",
- DEVNAME(sc));
- goto err_tx_desc;
- }
- sc->sc_tx_desc_ring = (struct em_tx_desc *)sc->sc_tx_dma.dma_vaddr;
-
- /* Allocate Receive Descriptor ring */
- if (em_dma_malloc(sc, sc->sc_rx_slots * sizeof(struct em_rx_desc),
- &sc->sc_rx_dma) != 0) {
- printf("%s: Unable to allocate rx_desc memory\n",
- DEVNAME(sc));
- goto err_rx_desc;
+ if (em_allocate_desc_rings(sc) != 0) {
+ printf("%s: Unable to allocate descriptor ring memory\n",
+ DEVNAME(sc));
+ goto err_pci;
}
- sc->sc_rx_desc_ri
