Re: remove rise detection from i386
On Sun, Jul 24, 2022 at 02:16:23AM -0400, Daniel Dickman wrote: >http://datasheets.chipdb.org/Rise/ > >Quoting the data sheet from this link: > >“The CMPXCHG8B instruction is supported and always enabled on the Rise >mP6 processor; however, the default CPUID function bit is set to 0 to >circumvent a reported bug in Windows NT” > >I don’t think we have a workaround for this quirk so I’m not sure >there’s value in keeping the cpu ID code. The kernel shows if the CX8 bit is set, but doesn't use it otherwise. The toolchain assumes it exists as we default to -march=i586 since 2020. I'd expect a mP6 to boot just not be as recognised after the diff. Still ok with the original diff.
Re: remove rise detection from i386
On Sun, Jul 24, 2022 at 02:25:02PM +1000, Jonathan Gray wrote: > On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote: > > The Rise mp6 was a short lived processor that was announced around 20+ > > years and didn't make it to market. > > > > I think we can delete the cpu identification for this cpu at this point. > > > > ok? > > I am ok with removing it, but I think it did ship. > > https://github.com/InstLatx64/InstLatx64/tree/master/RiseRiseRise > http://datasheets.chipdb.org/Rise/ > > BIOS Writer's Guide: iDRAGON mP6 MICROPROCESSOR > family 5 model 0 RiSE iDragon (0.25 um) > family 5 model 2 RiSE iDragon (0.18 um) > family 5 model 8 RiSE iDragon II (0.25 um) > family 5 model 9 RiSE iDragon II (0.18 um) > > https://www.pcengines.ch/platform.htm > SIS 55x > CPU: Rise MP6 "Pentium class", 200 to 250 MHz, 8K I-Cache + 8K D-Cache > > STPC Vega > CPU: Rise MP6 "Pentium II class" core, up to 250 MHz, 8K I-Cache + 8K D-Cache > > both SiS 55x and DM&P Vortex86 appear to use "SiS SiS SiS ". > not sure what the STPC Vega would show as later Vortex86 have "Vortex86 SoC" for cpuid 0
Re: remove rise detection from i386
On Jul 24, 2022, at 12:25 AM, Jonathan Gray wrote:On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:The Rise mp6 was a short lived processor that was announced around 20+ years and didn't make it to market.I think we can delete the cpu identification for this cpu at this point.ok?I am ok with removing it, but I think it did ship.Sure I believe “Kirin” did but “Lynx” only made it as engineering samples.https://github.com/InstLatx64/InstLatx64/tree/master/RiseRiseRisehttp://datasheets.chipdb.org/Rise/Quoting the data sheet from this link:“The CMPXCHG8B instruction is supported and always enabled on the Rise mP6 processor; however, the default CPUID function bit is set to 0 to circumvent a reported bug in Windows NT”I don’t think we have a workaround for this quirk so I’m not sure there’s value in keeping the cpu ID code.BIOS Writer's Guide: iDRAGON mP6 MICROPROCESSORfamily 5 model 0 RiSE iDragon (0.25 um)family 5 model 2 RiSE iDragon (0.18 um)family 5 model 8 RiSE iDragon II (0.25 um)family 5 model 9 RiSE iDragon II (0.18 um)https://www.pcengines.ch/platform.htmSIS 55xCPU: Rise MP6 "Pentium class", 200 to 250 MHz, 8K I-Cache + 8K D-CacheThe SiS 55x was a licensed Rise core but I believe the cpuid is “SiS SiS SiS”STPC VegaCPU: Rise MP6 "Pentium II class" core, up to 250 MHz, 8K I-Cache + 8K D-Cacheboth SiS 55x and DM&P Vortex86 appear to use "SiS SiS SiS ".I think only the early vortex CPUs which used the SiS core. I don’t own one myself but I think current versions do not have this cpuid and might use “Vortex86 SoC” See:Information on DM&P Vortex86DX3 SoCtortoiseit.blogspot.comnot sure what the STPC Vega would show asNor do I.Index: i386/machdep.c===RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,vretrieving revision 1.650diff -u -p -u -r1.650 machdep.c--- i386/machdep.c 12 Jul 2022 05:45:49 - 1.650+++ i386/machdep.c 23 Jul 2022 18:02:05 -@@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp } } }, {- "RiseRiseRise",- CPUVENDOR_RISE,- "Rise",- /* Family 4, not available from Rise */- { {- CPUCLASS_486,- {- 0, 0, 0, 0, 0, 0, 0, 0,- 0, 0, 0, 0, 0, 0, 0, 0,- "486 class" /* Default */- },- NULL- },- /* Family 5 */- {- CPUCLASS_586,- {- "mP6", 0, "mP6", 0, 0, 0, 0, 0,- 0, 0, 0, 0, 0, 0, 0, 0,- "mP6" /* Default */- },- NULL- },- /* Family 6, not yet available from Rise */- {- CPUCLASS_686,- {- 0, 0, 0, 0, 0, 0, 0, 0,- 0, 0, 0, 0, 0, 0, 0, 0,- "686 class" /* Default */- },- NULL- } }- },- { "GenuineTMx86", CPUVENDOR_TRANSMETA, "Transmeta",Index: include/cputypes.h===RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,vretrieving revision 1.11diff -u -p -u -r1.11 cputypes.h--- include/cputypes.h 7 Jul 2022 00:56:46 - 1.11+++ include/cputypes.h 23 Jul 2022 18:02:05 -@@ -63,7 +63,6 @@ #define CPUVENDOR_CYRIX 1 #define CPUVENDOR_AMD 3 #define CPUVENDOR_IDT 4-#define CPUVENDOR_RISE 5 #define CPUVENDOR_TRANSMETA 6 #define CPUVENDOR_NS 7 #define CPUVENDOR_VIA 8
include cpuid 0 string in dmesg for fw_update
include cpuid 0 string in dmesg for fw_update
Intel CPUs used to have brand strings such as
cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20
GHz
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
recent CPUs use
cpu0: 11th Gen Intel(R) Core(TM) i5-1130G7 @ 1.10GHz, 30009.37 MHz, 06-8c-01
cpu0: 12th Gen Intel(R) Core(TM) i5-12400, 4390.71 MHz, 06-97-02
cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
after the diff:
amd64:
cpu0: GenuineIntel, 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
cpu0: AuthenticAMD, AMD Ryzen 5 2600X Six-Core Processor, 3593.83 MHz, 17-08-02
i386:
cpu0: GenuineIntel, Intel(R) Pentium(R) M processor 1.60GHz (686-class) 1.60
GHz, 06-0d-06
changes the output of hw.model on i386 to not include the cpuid 0 string
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.125
diff -u -p -r1.125 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 12 Jul 2022 04:46:00 - 1.125
+++ sys/arch/amd64/amd64/identcpu.c 24 Jul 2022 05:14:07 -
@@ -516,6 +516,11 @@ identifycpu(struct cpu_info *ci)
int i;
char *brandstr_from, *brandstr_to;
int skipspace;
+ uint32_t vendor_regs[3];
+ char vendor[13];
+
+ CPUID(0, dummy, vendor_regs[0], vendor_regs[2], vendor_regs[1]);
+ strlcpy(vendor, (char *)vendor_regs, sizeof(vendor));
CPUID(1, ci->ci_signature, val, dummy, ci->ci_feature_flags);
CPUID(0x8000, ci->ci_pnfeatset, dummy, dummy, dummy);
@@ -605,7 +610,7 @@ identifycpu(struct cpu_info *ci)
freq = cpu_freq(ci);
- printf("%s: %s", ci->ci_dev->dv_xname, mycpu_model);
+ printf("%s: %s, %s", ci->ci_dev->dv_xname, vendor, mycpu_model);
if (freq != 0)
printf(", %llu.%02llu MHz", (freq + 4999) / 100,
Index: sys/arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.650
diff -u -p -r1.650 machdep.c
--- sys/arch/i386/i386/machdep.c12 Jul 2022 05:45:49 - 1.650
+++ sys/arch/i386/i386/machdep.c24 Jul 2022 04:45:20 -
@@ -1891,19 +1891,18 @@ identifycpu(struct cpu_info *ci)
if (cachesize > -1) {
snprintf(cpu_model, sizeof(cpu_model),
- "%s (%s%s%s%s-class, %dKB L2 cache)",
- cpu_brandstr,
- ((*token) ? "\"" : ""), ((*token) ? token : ""),
- ((*token) ? "\" " : ""), classnames[class], cachesize);
+ "%s (%s-class, %dKB L2 cache)",
+ cpu_brandstr, classnames[class], cachesize);
} else {
snprintf(cpu_model, sizeof(cpu_model),
- "%s (%s%s%s%s-class)",
- cpu_brandstr,
- ((*token) ? "\"" : ""), ((*token) ? token : ""),
- ((*token) ? "\" " : ""), classnames[class]);
+ "%s (%s-class)",
+ cpu_brandstr, classnames[class]);
}
- printf("%s: %s", cpu_device, cpu_model);
+ if (*token)
+ printf("%s: %s, %s", cpu_device, token, cpu_model);
+ else
+ printf("%s: %s", cpu_device, cpu_model);
if (ci->ci_feature_flags && (ci->ci_feature_flags & CPUID_TSC)) {
/* Has TSC, check if it's constant */
Index: usr.sbin/fw_update/patterns.c
===
RCS file: /cvs/src/usr.sbin/fw_update/patterns.c,v
retrieving revision 1.3
diff -u -p -r1.3 patterns.c
--- usr.sbin/fw_update/patterns.c 10 Mar 2022 07:12:13 - 1.3
+++ usr.sbin/fw_update/patterns.c 24 Jul 2022 05:36:11 -
@@ -94,7 +94,7 @@ main(void)
printf("%s\n", "bwfm");
printf("%s\n", "bwi");
printf("%s\n", "intel");
- printf("%s\n", "intel ^cpu0: Intel");
+ printf("%s\n", "intel ^cpu0: GenuineIntel");
printf("%s\n", "inteldrm");
print_devices("inteldrm", i915_devices, nitems(i915_devices));
printf("%s\n", "ipw");
Re: remove rise detection from i386
On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
I am ok with removing it, but I think it did ship.
https://github.com/InstLatx64/InstLatx64/tree/master/RiseRiseRise
http://datasheets.chipdb.org/Rise/
BIOS Writer's Guide: iDRAGON mP6 MICROPROCESSOR
family 5 model 0RiSE iDragon (0.25 um)
family 5 model 2RiSE iDragon (0.18 um)
family 5 model 8RiSE iDragon II (0.25 um)
family 5 model 9RiSE iDragon II (0.18 um)
https://www.pcengines.ch/platform.htm
SIS 55x
CPU: Rise MP6 "Pentium class", 200 to 250 MHz, 8K I-Cache + 8K D-Cache
STPC Vega
CPU: Rise MP6 "Pentium II class" core, up to 250 MHz, 8K I-Cache + 8K D-Cache
both SiS 55x and DM&P Vortex86 appear to use "SiS SiS SiS ".
not sure what the STPC Vega would show as
>
> Index: i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.650
> diff -u -p -u -r1.650 machdep.c
> --- i386/machdep.c12 Jul 2022 05:45:49 - 1.650
> +++ i386/machdep.c23 Jul 2022 18:02:05 -
> @@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp
> } }
> },
> {
> - "RiseRiseRise",
> - CPUVENDOR_RISE,
> - "Rise",
> - /* Family 4, not available from Rise */
> - { {
> - CPUCLASS_486,
> - {
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "486 class" /* Default */
> - },
> - NULL
> - },
> - /* Family 5 */
> - {
> - CPUCLASS_586,
> - {
> - "mP6", 0, "mP6", 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "mP6" /* Default */
> - },
> - NULL
> - },
> - /* Family 6, not yet available from Rise */
> - {
> - CPUCLASS_686,
> - {
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "686 class" /* Default */
> - },
> - NULL
> - } }
> - },
> - {
> "GenuineTMx86",
> CPUVENDOR_TRANSMETA,
> "Transmeta",
> Index: include/cputypes.h
> ===
> RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 cputypes.h
> --- include/cputypes.h7 Jul 2022 00:56:46 - 1.11
> +++ include/cputypes.h23 Jul 2022 18:02:05 -
> @@ -63,7 +63,6 @@
> #define CPUVENDOR_CYRIX 1
> #define CPUVENDOR_AMD3
> #define CPUVENDOR_IDT4
> -#define CPUVENDOR_RISE 5
> #define CPUVENDOR_TRANSMETA 6
> #define CPUVENDOR_NS 7
> #define CPUVENDOR_VIA8
>
>
powerpc64: retrigger deferred DEC interrupts from splx(9)
Okay, we did this for powerpc/macppc, on to powerpc64.
It's roughly the same problem as before:
- On powerpc64 we need to leave the DEC unmasked at or above
IPL_CLOCK.
- Currently we defer clock interrupt work to the next tick if a DEC
interrupt arrives when the CPU's priority level is at or above
IPL_CLOCK.
- This is a problem because the MD code needs to know about
when the next clock interrupt event is scheduled and I intend
to make that information machine-independent and handle it
in machine-independent code in the future.
- This patch instead defers clock interrupt work to the next splx(9)
call where the CPU's priority level is dropping below IPL_CLOCK.
This requires no knowledge of when the next clock interrupt
event is scheduled.
The code is almost identical to what we did for powerpc/macppc,
except that:
- We can do the ci_dec_deferred handling in trap(), which is a
bit cleaner.
- There is only one splx() function that needs modifying.
Unless I'm missing something, we no longer need the struct member
cpu_info.ci_statspending.
I don't have a powerpc64 machine, so this is untested. I would
appreciate tests and review. If you're copied on this, I'm under the
impression you have a powerpc64 machine or know someone who might.
Thoughts? Test results?
I'm really sorry if this doesn't work out of the box and your machine
hangs.
Index: include/cpu.h
===
RCS file: /cvs/src/sys/arch/powerpc64/include/cpu.h,v
retrieving revision 1.31
diff -u -p -r1.31 cpu.h
--- include/cpu.h 6 Jul 2021 09:34:07 - 1.31
+++ include/cpu.h 24 Jul 2022 01:08:22 -
@@ -74,9 +74,9 @@ struct cpu_info {
uint64_tci_lasttb;
uint64_tci_nexttimerevent;
uint64_tci_nextstatevent;
- int ci_statspending;
volatile intci_cpl;
+ volatile intci_dec_deferred;
uint32_tci_ipending;
uint32_tci_idepth;
#ifdef DIAGNOSTIC
Index: powerpc64/clock.c
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/clock.c,v
retrieving revision 1.3
diff -u -p -r1.3 clock.c
--- powerpc64/clock.c 23 Feb 2021 04:44:31 - 1.3
+++ powerpc64/clock.c 24 Jul 2022 01:08:22 -
@@ -130,30 +130,23 @@ decr_intr(struct trapframe *frame)
mtdec(nextevent - tb);
mtdec(nextevent - mftb());
- if (ci->ci_cpl >= IPL_CLOCK) {
- ci->ci_statspending += nstats;
- } else {
- nstats += ci->ci_statspending;
- ci->ci_statspending = 0;
+ s = splclock();
+ intr_enable();
- s = splclock();
- intr_enable();
-
- /*
-* Do standard timer interrupt stuff.
-*/
- while (ci->ci_lasttb < prevtb) {
- ci->ci_lasttb += tick_increment;
- clock_count.ec_count++;
- hardclock((struct clockframe *)frame);
- }
+ /*
+* Do standard timer interrupt stuff.
+*/
+ while (ci->ci_lasttb < prevtb) {
+ ci->ci_lasttb += tick_increment;
+ clock_count.ec_count++;
+ hardclock((struct clockframe *)frame);
+ }
- while (nstats-- > 0)
- statclock((struct clockframe *)frame);
+ while (nstats-- > 0)
+ statclock((struct clockframe *)frame);
- intr_disable();
- splx(s);
- }
+ intr_disable();
+ splx(s);
}
void
Index: powerpc64/intr.c
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/intr.c,v
retrieving revision 1.9
diff -u -p -r1.9 intr.c
--- powerpc64/intr.c26 Sep 2020 17:56:54 - 1.9
+++ powerpc64/intr.c24 Jul 2022 01:08:22 -
@@ -139,6 +139,11 @@ splx(int new)
{
struct cpu_info *ci = curcpu();
+ if (ci->ci_dec_deferred && new < IPL_CLOCK) {
+ mtdec(0);
+ mtdec(UINT32_MAX); /* raise DEC exception */
+ }
+
if (ci->ci_ipending & intr_smask[new])
intr_do_pending(new);
Index: powerpc64/trap.c
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/trap.c,v
retrieving revision 1.51
diff -u -p -r1.51 trap.c
--- powerpc64/trap.c11 May 2021 18:21:12 - 1.51
+++ powerpc64/trap.c24 Jul 2022 01:08:22 -
@@ -65,9 +65,15 @@ trap(struct trapframe *frame)
switch (type) {
case EXC_DECR:
uvmexp.intrs++;
- ci->ci_idepth++;
- decr_intr(frame);
- ci->ci_idepth--;
+ if (ci->ci_cpl < IPL_CLOCK) {
+ ci->ci_decr_deferred = 0;
+ ci->ci
Re: remove rise detection from i386
fine
Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
>
> Index: i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.650
> diff -u -p -u -r1.650 machdep.c
> --- i386/machdep.c12 Jul 2022 05:45:49 - 1.650
> +++ i386/machdep.c23 Jul 2022 18:02:05 -
> @@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp
> } }
> },
> {
> - "RiseRiseRise",
> - CPUVENDOR_RISE,
> - "Rise",
> - /* Family 4, not available from Rise */
> - { {
> - CPUCLASS_486,
> - {
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "486 class" /* Default */
> - },
> - NULL
> - },
> - /* Family 5 */
> - {
> - CPUCLASS_586,
> - {
> - "mP6", 0, "mP6", 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "mP6" /* Default */
> - },
> - NULL
> - },
> - /* Family 6, not yet available from Rise */
> - {
> - CPUCLASS_686,
> - {
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "686 class" /* Default */
> - },
> - NULL
> - } }
> - },
> - {
> "GenuineTMx86",
> CPUVENDOR_TRANSMETA,
> "Transmeta",
> Index: include/cputypes.h
> ===
> RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 cputypes.h
> --- include/cputypes.h7 Jul 2022 00:56:46 - 1.11
> +++ include/cputypes.h23 Jul 2022 18:02:05 -
> @@ -63,7 +63,6 @@
> #define CPUVENDOR_CYRIX 1
> #define CPUVENDOR_AMD3
> #define CPUVENDOR_IDT4
> -#define CPUVENDOR_RISE 5
> #define CPUVENDOR_TRANSMETA 6
> #define CPUVENDOR_NS 7
> #define CPUVENDOR_VIA8
>
Re: remove rise detection from i386
On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
ok mlarkin
>
> Index: i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.650
> diff -u -p -u -r1.650 machdep.c
> --- i386/machdep.c12 Jul 2022 05:45:49 - 1.650
> +++ i386/machdep.c23 Jul 2022 18:02:05 -
> @@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp
> } }
> },
> {
> - "RiseRiseRise",
> - CPUVENDOR_RISE,
> - "Rise",
> - /* Family 4, not available from Rise */
> - { {
> - CPUCLASS_486,
> - {
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "486 class" /* Default */
> - },
> - NULL
> - },
> - /* Family 5 */
> - {
> - CPUCLASS_586,
> - {
> - "mP6", 0, "mP6", 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "mP6" /* Default */
> - },
> - NULL
> - },
> - /* Family 6, not yet available from Rise */
> - {
> - CPUCLASS_686,
> - {
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0, 0, 0, 0,
> - "686 class" /* Default */
> - },
> - NULL
> - } }
> - },
> - {
> "GenuineTMx86",
> CPUVENDOR_TRANSMETA,
> "Transmeta",
> Index: include/cputypes.h
> ===
> RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 cputypes.h
> --- include/cputypes.h7 Jul 2022 00:56:46 - 1.11
> +++ include/cputypes.h23 Jul 2022 18:02:05 -
> @@ -63,7 +63,6 @@
> #define CPUVENDOR_CYRIX 1
> #define CPUVENDOR_AMD3
> #define CPUVENDOR_IDT4
> -#define CPUVENDOR_RISE 5
> #define CPUVENDOR_TRANSMETA 6
> #define CPUVENDOR_NS 7
> #define CPUVENDOR_VIA8
>
remove rise detection from i386
The Rise mp6 was a short lived processor that was announced around 20+
years and didn't make it to market.
I think we can delete the cpu identification for this cpu at this point.
ok?
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.650
diff -u -p -u -r1.650 machdep.c
--- i386/machdep.c 12 Jul 2022 05:45:49 - 1.650
+++ i386/machdep.c 23 Jul 2022 18:02:05 -
@@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp
} }
},
{
- "RiseRiseRise",
- CPUVENDOR_RISE,
- "Rise",
- /* Family 4, not available from Rise */
- { {
- CPUCLASS_486,
- {
- 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0,
- "486 class" /* Default */
- },
- NULL
- },
- /* Family 5 */
- {
- CPUCLASS_586,
- {
- "mP6", 0, "mP6", 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0,
- "mP6" /* Default */
- },
- NULL
- },
- /* Family 6, not yet available from Rise */
- {
- CPUCLASS_686,
- {
- 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0,
- "686 class" /* Default */
- },
- NULL
- } }
- },
- {
"GenuineTMx86",
CPUVENDOR_TRANSMETA,
"Transmeta",
Index: include/cputypes.h
===
RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
retrieving revision 1.11
diff -u -p -u -r1.11 cputypes.h
--- include/cputypes.h 7 Jul 2022 00:56:46 - 1.11
+++ include/cputypes.h 23 Jul 2022 18:02:05 -
@@ -63,7 +63,6 @@
#define CPUVENDOR_CYRIX1
#define CPUVENDOR_AMD 3
#define CPUVENDOR_IDT 4
-#define CPUVENDOR_RISE 5
#define CPUVENDOR_TRANSMETA6
#define CPUVENDOR_NS 7
#define CPUVENDOR_VIA 8
Re: ipv4 reassemble in parallel
ok mvs@
> On 23 Jul 2022, at 03:15, Alexander Bluhm wrote:
>
> Hi,
>
> The IPv6 reassembly code looks MP safe. So we can run it in parallel.
> Note that ip_ours() runs with shared netlock, while ip_local() has
> exclusive netlock after queuing.
>
> ok?
>
> bluhm
>
> Index: netinet/ip_input.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_input.c,v
> retrieving revision 1.372
> diff -u -p -r1.372 ip_input.c
> --- netinet/ip_input.c29 Jun 2022 09:01:48 - 1.372
> +++ netinet/ip_input.c22 Jul 2022 21:59:38 -
> @@ -142,6 +142,11 @@ int ip_local(struct mbuf **, int *, int,
> int ip_dooptions(struct mbuf *, struct ifnet *);
> int in_ouraddr(struct mbuf *, struct ifnet *, struct rtentry **);
>
> +int ip_fragcheck(struct mbuf **, int *);
> +struct mbuf *ip_reass(struct ipqent *, struct ipq *);
> +void ip_freef(struct ipq *);
> +void ip_flush(void);
> +
> static void ip_send_dispatch(void *);
> static void ip_sendraw_dispatch(void *);
> static struct task ipsend_task = TASK_INITIALIZER(ip_send_dispatch,
> &ipsend_mq);
> @@ -234,6 +239,10 @@ ip_init(void)
> int
> ip_ours(struct mbuf **mp, int *offp, int nxt, int af)
> {
> + nxt = ip_fragcheck(mp, offp);
> + if (nxt == IPPROTO_DONE)
> + return IPPROTO_DONE;
> +
> /* We are already in a IPv4/IPv6 local deliver loop. */
> if (af != AF_UNSPEC)
> return ip_local(mp, offp, nxt, af);
> @@ -550,14 +559,29 @@ ip_input_if(struct mbuf **mp, int *offp,
> int
> ip_local(struct mbuf **mp, int *offp, int nxt, int af)
> {
> - struct mbuf *m = *mp;
> - struct ip *ip = mtod(m, struct ip *);
> + struct ip *ip;
> +
> + NET_ASSERT_WLOCKED();
> +
> + ip = mtod(*mp, struct ip *);
> + *offp = ip->ip_hl << 2;
> + nxt = ip->ip_p;
> +
> + /* Check whether we are already in a IPv4/IPv6 local deliver loop. */
> + if (af == AF_UNSPEC)
> + nxt = ip_deliver(mp, offp, nxt, AF_INET);
> + return nxt;
> +}
> +
> +int
> +ip_fragcheck(struct mbuf **mp, int *offp)
> +{
> + struct ip *ip;
> struct ipq *fp;
> struct ipqent *ipqe;
> int mff, hlen;
>
> - NET_ASSERT_WLOCKED();
> -
> + ip = mtod(*mp, struct ip *);
> hlen = ip->ip_hl << 2;
>
> /*
> @@ -568,12 +592,12 @@ ip_local(struct mbuf **mp, int *offp, in
>* but it's not worth the time; just let them time out.)
>*/
> if (ip->ip_off &~ htons(IP_DF | IP_RF)) {
> - if (m->m_flags & M_EXT) { /* XXX */
> - if ((m = *mp = m_pullup(m, hlen)) == NULL) {
> + if ((*mp)->m_flags & M_EXT) { /* XXX */
> + if ((*mp = m_pullup(*mp, hlen)) == NULL) {
> ipstat_inc(ips_toosmall);
> return IPPROTO_DONE;
> }
> - ip = mtod(m, struct ip *);
> + ip = mtod(*mp, struct ip *);
> }
>
> mtx_enter(&ipq_mutex);
> @@ -630,28 +654,26 @@ ip_local(struct mbuf **mp, int *offp, in
> }
> ip_frags++;
> ipqe->ipqe_mff = mff;
> - ipqe->ipqe_m = m;
> + ipqe->ipqe_m = *mp;
> ipqe->ipqe_ip = ip;
> - m = *mp = ip_reass(ipqe, fp);
> - if (m == NULL)
> + *mp = ip_reass(ipqe, fp);
> + if (*mp == NULL)
> goto bad;
> ipstat_inc(ips_reassembled);
> - ip = mtod(m, struct ip *);
> + ip = mtod(*mp, struct ip *);
> hlen = ip->ip_hl << 2;
> ip->ip_len = htons(ntohs(ip->ip_len) + hlen);
> - } else
> - if (fp)
> + } else {
> + if (fp != NULL)
> ip_freef(fp);
> + }
>
> mtx_leave(&ipq_mutex);
> }
>
> *offp = hlen;
> - nxt = ip->ip_p;
> - /* Check whether we are already in a IPv4/IPv6 local deliver loop. */
> - if (af == AF_UNSPEC)
> - nxt = ip_deliver(mp, offp, nxt, AF_INET);
> - return nxt;
> + return ip->ip_p;
> +
> bad:
> mtx_leave(&ipq_mutex);
> m_freemp(mp);
> Index: netinet/ip_var.h
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_var.h,v
> retrieving revision 1.93
> diff -u -p -r1.93 ip_var.h
> --- netinet/ip_var.h 5 May 2022 13:57:40 - 1.93
> +++ netinet/ip_var.h 22 Jul 2022 21:39:01 -
> @@ -223,9 +223,7 @@ struct route;
> struct inpcb;
>
> intip_ctloutput(int, struct socket *, int, int, struct mbuf *);
> -void ip_flush(void);
> intip_fragme
Re: ipv6 local deliver net lock
ok mvs@
> On 22 Jul 2022, at 22:43, Alexander Bluhm wrote:
>
> Hi,
>
> During regress testing I found this bug.
>
> splassert: rip6_input: want 1 have 2
> Starting stack trace...
> rip6_input(1,2,d0c6b7ad,f57ff9fc) at rip6_input+0x166
> rip6_input(f57ffbfc,f57ffbe8,3a,18) at rip6_input+0x166
> icmp6_input(f57ffbfc,f57ffbe8,3a,18) at icmp6_input+0x66d
> ip_deliver(f57ffbfc,f57ffbe8,3a,18) at ip_deliver+0xf4
> ip6_input_if(f57ffbfc,f57ffbe8,29,0,d7066830) at ip6_input_if+0x88a
> ipv6_input(d7066830,dafe5400) at ipv6_input+0x2b
> ether_input(d7066830,dafe5400) at ether_input+0x3a9
> if_input_process(d7066830,f57ffc54) at if_input_process+0x5d
> ifiq_process(d7066ae0) at ifiq_process+0x57
> taskq_thread(d6ff1040) at taskq_thread+0x69
> End of stack trace.
>
> ip6_input() has shared net lock. ip_deliver() needs exclusive net
> lock. Use ip6_ours() to queue the packet. Move the write lock
> assertion into ip_deliver() to catch such bugs earlier.
>
> The assertion is only triggered with IPv6 multicast forwarding or
> router alert hop by hop option. So nobody noticed it.
>
> ok?
>
> bluhm
>
> Index: netinet/ip_input.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_input.c,v
> retrieving revision 1.372
> diff -u -p -r1.372 ip_input.c
> --- netinet/ip_input.c29 Jun 2022 09:01:48 - 1.372
> +++ netinet/ip_input.c22 Jul 2022 19:23:47 -
> @@ -556,8 +556,6 @@ ip_local(struct mbuf **mp, int *offp, in
> struct ipqent *ipqe;
> int mff, hlen;
>
> - NET_ASSERT_WLOCKED();
> -
> hlen = ip->ip_hl << 2;
>
> /*
> @@ -673,6 +671,8 @@ ip_deliver(struct mbuf **mp, int *offp,
> #ifdef INET6
> int nest = 0;
> #endif /* INET6 */
> +
> + NET_ASSERT_WLOCKED();
>
> /* pf might have modified stuff, might have to chksum */
> switch (af) {
> Index: netinet6/ip6_input.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/ip6_input.c,v
> retrieving revision 1.248
> diff -u -p -r1.248 ip6_input.c
> --- netinet6/ip6_input.c 29 Jun 2022 22:45:24 - 1.248
> +++ netinet6/ip6_input.c 22 Jul 2022 19:23:17 -
> @@ -448,8 +448,7 @@ ip6_input_if(struct mbuf **mp, int *offp
>
> if (ours) {
> if (af == AF_UNSPEC)
> - nxt = ip_deliver(mp, offp, nxt,
> - AF_INET6);
> + nxt = ip6_ours(mp, offp, nxt, af);
> goto out;
> }
> goto bad;
> @@ -550,7 +549,7 @@ ip6_input_if(struct mbuf **mp, int *offp
>
> if (ours) {
> if (af == AF_UNSPEC)
> - nxt = ip_deliver(mp, offp, nxt, AF_INET6);
> + nxt = ip6_ours(mp, offp, nxt, af);
> goto out;
> }
>
> @@ -584,8 +583,6 @@ ip6_input_if(struct mbuf **mp, int *offp
> int
> ip6_local(struct mbuf **mp, int *offp, int nxt, int af)
> {
> - NET_ASSERT_WLOCKED();
> -
> nxt = ip6_hbhchcheck(mp, offp, NULL);
> if (nxt == IPPROTO_DONE)
> return IPPROTO_DONE;
>
Re: pf.conf(5): document new anchors limit
On Sat, Jul 23, 2022 at 02:16:16PM +0200, Moritz Buhl wrote:
> On Thu, Jul 21, 2022 at 10:25:09PM +0100, Jason McIntyre wrote:
> ...
> > it looks like the "set limit" text in pf.conf(5) might need some small
> > adjustments:
> >
> > - as well as the "anchors" limit, it does not document "pktdelay-pkts"
> >
> > - for entries where defaults are not documented, it is not clear whether
> > this is an omission or they are just not limited by default (in the
> > same way that things like table numbers are limited). those affected
> > seem to be src-nodes and pktdelay-pkts
>
> All of these limits have defaults that are sometimes set in the
> kernel or with the first pfctl invocation during boot:
>
> /usr/src/sbin/pfctl.c:
> 1726 pf->limit[PF_LIMIT_SRC_NODES] = PFSNODE_HIWAT;
> ...
> 1729 pf->limit[PF_LIMIT_PKTDELAY_PKTS] = PF_PKTDELAY_MAXPKTS;
>
> /usr/include/net/pfvar.h:
> #define PFSNODE_HIWAT 1 /* default source node table
> size */
> ...
> #define PF_PKTDELAY_MAXPKTS 1 /* max # of pkts held in delay
> queue */
>
>
> > - the two entries for "table-entries" are confusing. it seems to be that
> > machines with less than a specific amount of memory have their entries
> > limited to the value of _SMALL. but the way it's documented makes that
> > unclear. i'm not sure whether the reader needs the names such as
> > PFSTATE_HIWAT. i think it's just confusing to list it this way. we
> > should probably have one item, table-entries, and say what the default
> > is normally, and what it is for lesser memory setups.
>
> /usr/src/sbin/pfctl.c:
> 1737 if (mem <= 100*1024*1024)
> 1738 pf->limit[PF_LIMIT_TABLE_ENTRIES] =
> PFR_KENTRY_HIWAT_SMALL;
>
> If the machine has less than 100MB physical memory, ..._SMALL is set for
> PF_LIMIT_TABLE_ENTRIES.
>
thanks, i've managed to fill in the blanks with your help/ looking for
oks now.
jmc
Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.596
diff -u -p -r1.596 pf.conf.5
--- pf.conf.5 27 May 2022 15:45:02 - 1.596
+++ pf.conf.5 23 Jul 2022 12:31:28 -
@@ -1236,65 +1236,55 @@ See
.Xr pool 9
for an explanation of memory pools.
.Pp
-For example,
-to set the maximum number of entries in the memory pool used by state table
-entries (generated by
+Limits can be set on the following:
+.Bl -tag -width pktdelay_pkts
+.It Cm states
+Set the maximum number of entries in the memory pool used by state table
+entries (those generated by
.Ic pass
rules which do not specify
-.Cm no state )
-to 2:
-.Pp
-.Dl set limit states 2
-.Pp
-To set the maximum number of entries in the memory pool used for fragment
-reassembly to 2000:
-.Pp
-.Dl set limit frags 2000
-.Pp
-This maximum may not exceed, and should be well below, the maximum number
-of mbuf clusters
-.Pq sysctl kern.maxclusters
-in the system.
-.Pp
-To set the maximum number of entries in the memory pool used for tracking
+.Cm no state ) .
+The default is 10.
+.It Cm src-nodes
+Set the maximum number of entries in the memory pool used for tracking
source IP addresses (generated by the
.Cm sticky-address
and
.Cm src.track
-options) to 2000:
-.Pp
-.Dl set limit src-nodes 2000
-.Pp
-To set limits on the memory pools used by tables:
-.Bd -literal -offset indent
-set limit tables 1000
-set limit table-entries 10
-.Ed
-.Pp
-The first limits the number of tables that can exist to 1000.
-The second limits the overall number of addresses that can be stored
-in tables to 10.
-.Pp
-Various limits can be combined on a single line:
-.Bd -literal -offset indent
-set limit { states 2, frags 2000, src-nodes 2000 }
-.Ed
-.Pp
-.Xr pf 4
-has the following defaults:
-.Bl -column table-entries PFR_KENTRY_HIWAT_SMALL platform_dependent
-.It states Ta Dv PFSTATE_HIWAT Ta Pq 10
-.It tables Ta Dv PFR_KTABLE_HIWAT Ta Pq 1000
-.It table-entries Ta Dv PFR_KENTRY_HIWAT Ta Pq 20
-.It table-entries Ta Dv PFR_KENTRY_HIWAT_SMALL Ta Pq 10
-.It frags Ta Dv NMBCLUSTERS Ns /32 Ta Pq platform dependent
-.El
-.Pp
+options).
+The default is 1.
+.It Cm frags
+Set the maximum number of entries in the memory pool used for fragment
+reassembly.
+The maximum may not exceed, and should be well below,
+the maximum number of mbuf clusters
+.Pq sysctl kern.maxclusters
+in the system.
+The default is NMBCLUSTERS/32.
.Dv NMBCLUSTERS
defines the total number of packets which can exist in-system at any one time.
Refer to
.In machine/param.h
for the platform-specific value.
+.It Cm tables
+Set the number of tables that can exist.
+The default is 1000.
+.It Cm table-entries
+Set the number of addresses that can be stored in tables.
+The default is 20, or 10 on machines with
+less than 100MB of physical memory.
+.It Cm pktdelay_pkts
+Set the maximum number of packets that can be held in the delay queue.
+The defaul
Re: pf.conf(5): document new anchors limit
On Thu, Jul 21, 2022 at 10:25:09PM +0100, Jason McIntyre wrote:
...
> it looks like the "set limit" text in pf.conf(5) might need some small
> adjustments:
>
> - as well as the "anchors" limit, it does not document "pktdelay-pkts"
>
> - for entries where defaults are not documented, it is not clear whether
> this is an omission or they are just not limited by default (in the
> same way that things like table numbers are limited). those affected
> seem to be src-nodes and pktdelay-pkts
All of these limits have defaults that are sometimes set in the
kernel or with the first pfctl invocation during boot:
/usr/src/sbin/pfctl.c:
1726 pf->limit[PF_LIMIT_SRC_NODES] = PFSNODE_HIWAT;
...
1729 pf->limit[PF_LIMIT_PKTDELAY_PKTS] = PF_PKTDELAY_MAXPKTS;
/usr/include/net/pfvar.h:
#define PFSNODE_HIWAT 1 /* default source node table size */
...
#define PF_PKTDELAY_MAXPKTS 1 /* max # of pkts held in delay queue */
> - the two entries for "table-entries" are confusing. it seems to be that
> machines with less than a specific amount of memory have their entries
> limited to the value of _SMALL. but the way it's documented makes that
> unclear. i'm not sure whether the reader needs the names such as
> PFSTATE_HIWAT. i think it's just confusing to list it this way. we
> should probably have one item, table-entries, and say what the default
> is normally, and what it is for lesser memory setups.
/usr/src/sbin/pfctl.c:
1737 if (mem <= 100*1024*1024)
1738 pf->limit[PF_LIMIT_TABLE_ENTRIES] = PFR_KENTRY_HIWAT_SMALL;
If the machine has less than 100MB physical memory, ..._SMALL is set for
PF_LIMIT_TABLE_ENTRIES.
> - i think the whole section should just be reduced to a simple list of
> what can be set, and any default values.
>
> here's a stab at tidying up. i've inserted a couple of XXX for where i
> came unstuck.
>
> thoughts? help?
I appreciate where this is going.
mbuhl
> jmc
>
> Index: pf.conf.5
> ===
> RCS file: /cvs/src/share/man/man5/pf.conf.5,v
> retrieving revision 1.596
> diff -u -p -r1.596 pf.conf.5
> --- pf.conf.5 27 May 2022 15:45:02 - 1.596
> +++ pf.conf.5 21 Jul 2022 21:22:08 -
> @@ -1236,65 +1236,56 @@ See
> .Xr pool 9
> for an explanation of memory pools.
> .Pp
> -For example,
> -to set the maximum number of entries in the memory pool used by state table
> -entries (generated by
> +Limits can be set on the following:
> +.Bl -tag -width pktdelay_pkts
> +.It Cm states
> +Set the maximum number of entries in the memory pool used by state table
> +entries (those generated by
> .Ic pass
> rules which do not specify
> -.Cm no state )
> -to 2:
> -.Pp
> -.Dl set limit states 2
> -.Pp
> -To set the maximum number of entries in the memory pool used for fragment
> -reassembly to 2000:
> -.Pp
> -.Dl set limit frags 2000
> -.Pp
> -This maximum may not exceed, and should be well below, the maximum number
> -of mbuf clusters
> -.Pq sysctl kern.maxclusters
> -in the system.
> -.Pp
> -To set the maximum number of entries in the memory pool used for tracking
> +.Cm no state ) .
> +The default is 10.
> +.It Cm src-nodes
> +Set the maximum number of entries in the memory pool used for tracking
> source IP addresses (generated by the
> .Cm sticky-address
> and
> .Cm src.track
> -options) to 2000:
> -.Pp
> -.Dl set limit src-nodes 2000
> -.Pp
> -To set limits on the memory pools used by tables:
> -.Bd -literal -offset indent
> -set limit tables 1000
> -set limit table-entries 10
> -.Ed
> -.Pp
> -The first limits the number of tables that can exist to 1000.
> -The second limits the overall number of addresses that can be stored
> -in tables to 10.
> -.Pp
> -Various limits can be combined on a single line:
> -.Bd -literal -offset indent
> -set limit { states 2, frags 2000, src-nodes 2000 }
> -.Ed
> -.Pp
> -.Xr pf 4
> -has the following defaults:
> -.Bl -column table-entries PFR_KENTRY_HIWAT_SMALL platform_dependent
> -.It states Ta Dv PFSTATE_HIWAT Ta Pq 10
> -.It tables Ta Dv PFR_KTABLE_HIWAT Ta Pq 1000
> -.It table-entries Ta Dv PFR_KENTRY_HIWAT Ta Pq 20
> -.It table-entries Ta Dv PFR_KENTRY_HIWAT_SMALL Ta Pq 10
> -.It frags Ta Dv NMBCLUSTERS Ns /32 Ta Pq platform dependent
> -.El
> -.Pp
> +options).
> +The default is
> +.\" XXX
> +.It Cm frags
> +Set the maximum number of entries in the memory pool used for fragment
> +reassembly.
> +The maximum may not exceed, and should be well below,
> +the maximum number of mbuf clusters
> +.Pq sysctl kern.maxclusters
> +in the system.
> +The default is NMBCLUSTERS/32.
> .Dv NMBCLUSTERS
> defines the total number of packets which can exist in-system at any one
> time.
> Refer to
> .In machine/param.h
> for the platform-specific value.
> +.It Cm tables
> +Set the number of tables that can exist.
> +The default is 1000.
> +.It Cm table-entries
> +Set the number of addresses
Re: ipv6 local deliver net lock
On Fri, Jul 22, 2022 at 09:43:02PM +0200, Alexander Bluhm wrote: > Hi, > > During regress testing I found this bug. > > splassert: rip6_input: want 1 have 2 > Starting stack trace... > rip6_input(1,2,d0c6b7ad,f57ff9fc) at rip6_input+0x166 > rip6_input(f57ffbfc,f57ffbe8,3a,18) at rip6_input+0x166 > icmp6_input(f57ffbfc,f57ffbe8,3a,18) at icmp6_input+0x66d > ip_deliver(f57ffbfc,f57ffbe8,3a,18) at ip_deliver+0xf4 > ip6_input_if(f57ffbfc,f57ffbe8,29,0,d7066830) at ip6_input_if+0x88a > ipv6_input(d7066830,dafe5400) at ipv6_input+0x2b > ether_input(d7066830,dafe5400) at ether_input+0x3a9 > if_input_process(d7066830,f57ffc54) at if_input_process+0x5d > ifiq_process(d7066ae0) at ifiq_process+0x57 > taskq_thread(d6ff1040) at taskq_thread+0x69 > End of stack trace. > > ip6_input() has shared net lock. ip_deliver() needs exclusive net > lock. Use ip6_ours() to queue the packet. Move the write lock > assertion into ip_deliver() to catch such bugs earlier. > > The assertion is only triggered with IPv6 multicast forwarding or > router alert hop by hop option. So nobody noticed it. OK kn
Re: slaacd(8): delete autoconf or temporary address on interface flag removal
On Sat, Jul 23, 2022 at 11:06:13AM +0200, Florian Obser wrote: > I just fixed the case where autoconf and temporary addresses stayed > behind when the interface no longer has inet6 autoconf and inet6 > temporary. > This deletes addresses when one removes the temporary or autoconf flag > but the other one is still set. OK kn
Re: bgpd nexthop check
On Sat, Jul 23, 2022 at 11:14:35AM +0200, Claudio Jeker wrote:
> Change the logic and name of bgpd_filternexthop(). This function applies
> the 'nexthop qualify via' config setting. Instead of telling if the route
> is filtered (true) or not (false) flip the logic around and rename the
> function to bgpd_oknexthop(). Also flip the internal logic around to
> simplify the logic in bgpd_oknexthop().
>
> Adjust the kroute_match() code accordingly (which makes that code easier
> to understand).
>
> This is just a refactor and should not change behaviour.
> --
> :wq Claudio
>
> Index: bgpd.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
> retrieving revision 1.251
> diff -u -p -r1.251 bgpd.c
> --- bgpd.c22 Jul 2022 17:26:58 - 1.251
> +++ bgpd.c23 Jul 2022 08:53:58 -
> @@ -1115,23 +1115,27 @@ send_network(int type, struct network_co
> return (0);
> }
>
> +/*
> + * Return true if a route can be used for nexthop resolution.
> + */
> int
> -bgpd_filternexthop(struct kroute_full *kf)
> +bgpd_oknexthop(struct kroute_full *kf)
> {
> - /* kernel routes are never filtered */
> - if (kf->flags & F_KERNEL && kf->prefixlen != 0)
> - return (0);
> -
> - if (cflags & BGPD_FLAG_NEXTHOP_BGP) {
> - if (kf->flags & F_BGPD)
> + if (kf->flags & F_BGPD) {
> + if (cflags & BGPD_FLAG_NEXTHOP_BGP)
> + return (1);
> + else
> return (0);
> }
>
> - if (cflags & BGPD_FLAG_NEXTHOP_DEFAULT) {
> - if (kf->prefixlen == 0)
> + if (kf->prefixlen == 0) {
> + if (cflags & BGPD_FLAG_NEXTHOP_DEFAULT)
> + return (1);
> + else
> return (0);
> }
Your version is ok. I'd do away with the inner ifs and write this as:
if (kf->flags & F_BGPD)
return ((cflags & BGPD_FLAG_NEXTHOP_BGP) != 0);
if (kf->prefixlen == 0)
return ((cflags & BGPD_FLAG_NEXTHOP_DEFAULT) != 0);
>
> + /* any other route is fine */
> return (1);
> }
>
> Index: bgpd.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.444
> diff -u -p -r1.444 bgpd.h
> --- bgpd.h22 Jul 2022 17:26:58 - 1.444
> +++ bgpd.h23 Jul 2022 08:54:09 -
> @@ -1265,7 +1265,7 @@ void send_nexthop_update(struct kroute
> void send_imsg_session(int, pid_t, void *, uint16_t);
> int send_network(int, struct network_config *,
>struct filter_set_head *);
> -int bgpd_filternexthop(struct kroute_full *);
> +int bgpd_oknexthop(struct kroute_full *);
> void set_pollfd(struct pollfd *, struct imsgbuf *);
> int handle_pollfd(struct pollfd *, struct imsgbuf *);
>
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
> retrieving revision 1.278
> diff -u -p -r1.278 kroute.c
> --- kroute.c 22 Jul 2022 17:26:58 - 1.278
> +++ kroute.c 23 Jul 2022 08:55:27 -
> @@ -2444,7 +2444,7 @@ knexthop_send_update(struct knexthop *kn
> }
>
> struct kroute *
> -kroute_match(struct ktable *kt, struct bgpd_addr *key, int matchall)
> +kroute_match(struct ktable *kt, struct bgpd_addr *key, int matchany)
> {
> int i;
> struct kroute *kr;
> @@ -2453,8 +2453,7 @@ kroute_match(struct ktable *kt, struct b
> for (i = 32; i >= 0; i--) {
> applymask(&masked, key, i);
> if ((kr = kroute_find(kt, &masked, i, RTP_ANY)) != NULL)
> - if (matchall ||
> - bgpd_filternexthop(kr_tofull(kr)) == 0)
> + if (matchany || bgpd_oknexthop(kr_tofull(kr)))
> return (kr);
> }
>
> @@ -2462,7 +2461,7 @@ kroute_match(struct ktable *kt, struct b
> }
>
> struct kroute6 *
> -kroute6_match(struct ktable *kt, struct bgpd_addr *key, int matchall)
> +kroute6_match(struct ktable *kt, struct bgpd_addr *key, int matchany)
> {
> int i;
> struct kroute6 *kr6;
> @@ -2471,8 +2470,7 @@ kroute6_match(struct ktable *kt, struct
> for (i = 128; i >= 0; i--) {
> applymask(&masked, key, i);
> if ((kr6 = kroute6_find(kt, &masked, i, RTP_ANY)) != NULL)
> - if (matchall ||
> - bgpd_filternexthop(kr6_tofull(kr6)) == 0)
> + if (matchany || bgpd_oknexthop(kr6_tofull(kr6)))
> return (kr6);
> }
>
>
bgpd nexthop check
Change the logic and name of bgpd_filternexthop(). This function applies
the 'nexthop qualify via' config setting. Instead of telling if the route
is filtered (true) or not (false) flip the logic around and rename the
function to bgpd_oknexthop(). Also flip the internal logic around to
simplify the logic in bgpd_oknexthop().
Adjust the kroute_match() code accordingly (which makes that code easier
to understand).
This is just a refactor and should not change behaviour.
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.251
diff -u -p -r1.251 bgpd.c
--- bgpd.c 22 Jul 2022 17:26:58 - 1.251
+++ bgpd.c 23 Jul 2022 08:53:58 -
@@ -1115,23 +1115,27 @@ send_network(int type, struct network_co
return (0);
}
+/*
+ * Return true if a route can be used for nexthop resolution.
+ */
int
-bgpd_filternexthop(struct kroute_full *kf)
+bgpd_oknexthop(struct kroute_full *kf)
{
- /* kernel routes are never filtered */
- if (kf->flags & F_KERNEL && kf->prefixlen != 0)
- return (0);
-
- if (cflags & BGPD_FLAG_NEXTHOP_BGP) {
- if (kf->flags & F_BGPD)
+ if (kf->flags & F_BGPD) {
+ if (cflags & BGPD_FLAG_NEXTHOP_BGP)
+ return (1);
+ else
return (0);
}
- if (cflags & BGPD_FLAG_NEXTHOP_DEFAULT) {
- if (kf->prefixlen == 0)
+ if (kf->prefixlen == 0) {
+ if (cflags & BGPD_FLAG_NEXTHOP_DEFAULT)
+ return (1);
+ else
return (0);
}
+ /* any other route is fine */
return (1);
}
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.444
diff -u -p -r1.444 bgpd.h
--- bgpd.h 22 Jul 2022 17:26:58 - 1.444
+++ bgpd.h 23 Jul 2022 08:54:09 -
@@ -1265,7 +1265,7 @@ void send_nexthop_update(struct kroute
voidsend_imsg_session(int, pid_t, void *, uint16_t);
int send_network(int, struct network_config *,
struct filter_set_head *);
-int bgpd_filternexthop(struct kroute_full *);
+int bgpd_oknexthop(struct kroute_full *);
voidset_pollfd(struct pollfd *, struct imsgbuf *);
int handle_pollfd(struct pollfd *, struct imsgbuf *);
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.278
diff -u -p -r1.278 kroute.c
--- kroute.c22 Jul 2022 17:26:58 - 1.278
+++ kroute.c23 Jul 2022 08:55:27 -
@@ -2444,7 +2444,7 @@ knexthop_send_update(struct knexthop *kn
}
struct kroute *
-kroute_match(struct ktable *kt, struct bgpd_addr *key, int matchall)
+kroute_match(struct ktable *kt, struct bgpd_addr *key, int matchany)
{
int i;
struct kroute *kr;
@@ -2453,8 +2453,7 @@ kroute_match(struct ktable *kt, struct b
for (i = 32; i >= 0; i--) {
applymask(&masked, key, i);
if ((kr = kroute_find(kt, &masked, i, RTP_ANY)) != NULL)
- if (matchall ||
- bgpd_filternexthop(kr_tofull(kr)) == 0)
+ if (matchany || bgpd_oknexthop(kr_tofull(kr)))
return (kr);
}
@@ -2462,7 +2461,7 @@ kroute_match(struct ktable *kt, struct b
}
struct kroute6 *
-kroute6_match(struct ktable *kt, struct bgpd_addr *key, int matchall)
+kroute6_match(struct ktable *kt, struct bgpd_addr *key, int matchany)
{
int i;
struct kroute6 *kr6;
@@ -2471,8 +2470,7 @@ kroute6_match(struct ktable *kt, struct
for (i = 128; i >= 0; i--) {
applymask(&masked, key, i);
if ((kr6 = kroute6_find(kt, &masked, i, RTP_ANY)) != NULL)
- if (matchall ||
- bgpd_filternexthop(kr6_tofull(kr6)) == 0)
+ if (matchany || bgpd_oknexthop(kr6_tofull(kr6)))
return (kr6);
}
slaacd(8): delete autoconf or temporary address on interface flag removal
I just fixed the case where autoconf and temporary addresses stayed
behind when the interface no longer has inet6 autoconf and inet6
temporary.
This deletes addresses when one removes the temporary or autoconf flag
but the other one is still set.
OK?
(This needs rev 1.82 of engine.c to work correctly)
diff --git engine.c engine.c
index 226342364e6..1e67ab11a45 100644
--- engine.c
+++ engine.c
@@ -1930,6 +1930,20 @@ update_iface_ra_prefix(struct slaacd_iface *iface,
struct radv *ra,
found = found_temporary = duplicate_found = 0;
+ if (!!iface->autoconf != !!iface->temporary) {
+ struct address_proposal *tmp;
+ /*
+* if only the autoconf or temporary flag is set check if we
+* have the "other kind" of address configured at delete it
+*/
+ LIST_FOREACH_SAFE (addr_proposal, &iface->addr_proposals,
+ entries, tmp) {
+ if ((!addr_proposal->temporary && !iface->autoconf) ||
+ (addr_proposal->temporary && !iface->temporary))
+ free_address_proposal(addr_proposal);
+ }
+ }
+
LIST_FOREACH(addr_proposal, &iface->addr_proposals, entries) {
if (prefix->prefix_len == addr_proposal-> prefix_len &&
memcmp(&prefix->prefix, &addr_proposal->prefix,
--
I'm not entirely sure you are real.
