Re: pf log drop default rule
Hello, I'm fine with it. OK sashan On Wed, Oct 11, 2023 at 12:28:20AM +0200, Alexander Bluhm wrote: > Hi, > > If a packet is malformed, it is dropped by pf(4). The rule referenced > in pflog(4) is the default rule. As the default rule is a pass > rule, tcpdump prints "pass" although the packet is actually dropped. > I have reports from genua and OPNsense users who are confused by > the output. > > With the diff below we see pass or blocked when the packet is matched > or dropped due to bad fragment respectively. > > 19:29:17.314991 rule def/(match) [uid 0, pid 0] pass in on em1: 10.188.81.21 > > 10.188.81.22: (frag 43955:8@8+) (ttl 64, len 28) > 19:29:31.321728 rule def/(fragment) [uid 0, pid 0] block in on em1: > 10.188.81.21 > 10.188.81.22: (frag 27096:64@4032+) (ttl 64, len 84) > > ok? > > bluhm > > Index: net/if_pflog.c > === > RCS file: /cvs/src/sys/net/if_pflog.c,v > retrieving revision 1.97 > diff -u -p -r1.97 if_pflog.c > --- net/if_pflog.c20 Jan 2021 23:25:19 - 1.97 > +++ net/if_pflog.c10 Oct 2023 17:20:00 - > @@ -204,7 +204,9 @@ pflog_packet(struct pf_pdesc *pd, u_int8 > > bzero(, sizeof(hdr)); > hdr.length = PFLOG_REAL_HDRLEN; > - hdr.action = rm->action; > + /* Default rule does not pass packets dropped for other reasons. */ > + hdr.action = (rm->nr == (u_int32_t)-1 && reason != PFRES_MATCH) ? > + PF_DROP : rm->action; > hdr.reason = reason; > memcpy(hdr.ifname, pd->kif->pfik_name, sizeof(hdr.ifname)); > >
pf log drop default rule
Hi, If a packet is malformed, it is dropped by pf(4). The rule referenced in pflog(4) is the default rule. As the default rule is a pass rule, tcpdump prints "pass" although the packet is actually dropped. I have reports from genua and OPNsense users who are confused by the output. With the diff below we see pass or blocked when the packet is matched or dropped due to bad fragment respectively. 19:29:17.314991 rule def/(match) [uid 0, pid 0] pass in on em1: 10.188.81.21 > 10.188.81.22: (frag 43955:8@8+) (ttl 64, len 28) 19:29:31.321728 rule def/(fragment) [uid 0, pid 0] block in on em1: 10.188.81.21 > 10.188.81.22: (frag 27096:64@4032+) (ttl 64, len 84) ok? bluhm Index: net/if_pflog.c === RCS file: /cvs/src/sys/net/if_pflog.c,v retrieving revision 1.97 diff -u -p -r1.97 if_pflog.c --- net/if_pflog.c 20 Jan 2021 23:25:19 - 1.97 +++ net/if_pflog.c 10 Oct 2023 17:20:00 - @@ -204,7 +204,9 @@ pflog_packet(struct pf_pdesc *pd, u_int8 bzero(, sizeof(hdr)); hdr.length = PFLOG_REAL_HDRLEN; - hdr.action = rm->action; + /* Default rule does not pass packets dropped for other reasons. */ + hdr.action = (rm->nr == (u_int32_t)-1 && reason != PFRES_MATCH) ? + PF_DROP : rm->action; hdr.reason = reason; memcpy(hdr.ifname, pd->kif->pfik_name, sizeof(hdr.ifname));
bwfm(4): support scan v3
The firmware for the BCM4388 has yet another version of the "escan"
command. But we can treat it the same as v2 since it just added a new
parameter in place of some padding. We just set that new parameter to
zero, which doesn't change anything.
As a bonus this adds some missing htole16() calls.
This is the equivalent of:
https://github.com/AsahiLinux/linux/commit/399ef7b1cb9094c1c64e0f9ad6caa5c4d114009f
ok?
Index: dev/ic/bwfm.c
===
RCS file: /cvs/src/sys/dev/ic/bwfm.c,v
retrieving revision 1.110
diff -u -p -r1.110 bwfm.c
--- dev/ic/bwfm.c 9 Oct 2023 21:49:34 - 1.110
+++ dev/ic/bwfm.c 10 Oct 2023 21:36:44 -
@@ -249,6 +249,7 @@ bwfm_preinit(struct bwfm_softc *sc)
struct ifnet *ifp = >ic_if;
int i, j, nbands, nmode, vhtmode;
uint32_t bandlist[3], tmp;
+ struct bwfm_scan_version scan_ver;
if (sc->sc_initialized)
return 0;
@@ -274,8 +275,10 @@ bwfm_preinit(struct bwfm_softc *sc)
nmode = 0;
if (bwfm_fwvar_var_get_int(sc, "vhtmode", ))
vhtmode = 0;
- if (bwfm_fwvar_var_get_int(sc, "scan_ver", >sc_scan_ver))
- sc->sc_scan_ver = 0;
+ if (bwfm_fwvar_var_get_data(sc, "scan_ver", _ver,
+ sizeof(scan_ver)))
+ scan_ver.scan_ver_major = 0;
+ sc->sc_scan_ver = letoh16(scan_ver.scan_ver_major);
if (bwfm_fwvar_cmd_get_data(sc, BWFM_C_GET_BANDLIST, bandlist,
sizeof(bandlist))) {
printf("%s: couldn't get supported band list\n", DEVNAME(sc));
@@ -2201,17 +2204,21 @@ bwfm_scan_v2(struct bwfm_softc *sc)
ssid = (struct bwfm_ssid *)
(((uint8_t *)params) + sizeof(*params) + chan_size);
- params->scan_params.version = 2;
- params->scan_params.length = params_size;
+ params->scan_params.version = htole16(sc->sc_scan_ver);
+ params->scan_params.length = htole16(params_size);
memset(params->scan_params.bssid, 0xff,
sizeof(params->scan_params.bssid));
params->scan_params.bss_type = 2;
+ params->scan_params.ssid_type = 0;
params->scan_params.scan_type = BWFM_SCANTYPE_PASSIVE;
params->scan_params.nprobes = htole32(-1);
params->scan_params.active_time = htole32(-1);
params->scan_params.passive_time = htole32(-1);
params->scan_params.home_time = htole32(-1);
- params->version = htole32(BWFM_ESCAN_REQ_VERSION_V2);
+ if (sc->sc_scan_ver == 3)
+ params->version = htole32(BWFM_ESCAN_REQ_VERSION_V3);
+ else
+ params->version = htole32(BWFM_ESCAN_REQ_VERSION_V2);
params->action = htole16(WL_ESCAN_ACTION_START);
params->sync_id = htole16(0x1234);
@@ -2282,17 +2289,21 @@ bwfm_scan_abort_v2(struct bwfm_softc *sc
params_size = sizeof(*params) + sizeof(uint16_t);
params = malloc(params_size, M_TEMP, M_WAITOK | M_ZERO);
- params->scan_params.version = 2;
- params->scan_params.length = params_size;
+ params->scan_params.version = htole16(sc->sc_scan_ver);
+ params->scan_params.length = htole16(params_size);
memset(params->scan_params.bssid, 0xff,
sizeof(params->scan_params.bssid));
params->scan_params.bss_type = 2;
+ params->scan_params.ssid_type = 0;
params->scan_params.scan_type = BWFM_SCANTYPE_PASSIVE;
params->scan_params.nprobes = htole32(-1);
params->scan_params.active_time = htole32(-1);
params->scan_params.passive_time = htole32(-1);
params->scan_params.home_time = htole32(-1);
- params->version = htole32(BWFM_ESCAN_REQ_VERSION_V2);
+ if (sc->sc_scan_ver == 3)
+ params->version = htole32(BWFM_ESCAN_REQ_VERSION_V3);
+ else
+ params->version = htole32(BWFM_ESCAN_REQ_VERSION_V2);
params->action = htole16(WL_ESCAN_ACTION_START);
params->sync_id = htole16(0x1234);
params->scan_params.channel_num = htole32(1);
Index: dev/ic/bwfmreg.h
===
RCS file: /cvs/src/sys/dev/ic/bwfmreg.h,v
retrieving revision 1.26
diff -u -p -r1.26 bwfmreg.h
--- dev/ic/bwfmreg.h4 Mar 2022 22:34:41 - 1.26
+++ dev/ic/bwfmreg.h10 Oct 2023 21:36:44 -
@@ -511,6 +511,12 @@ struct bwfm_ssid {
uint8_t ssid[BWFM_MAX_SSID_LEN];
};
+struct bwfm_scan_version {
+ uint16_t version;
+ uint16_t len;
+ uint16_t scan_ver_major;
+};
+
struct bwfm_scan_params_v0 {
struct bwfm_ssid ssid;
uint8_t bssid[ETHER_ADDR_LEN];
@@ -538,7 +544,7 @@ struct bwfm_scan_params_v2 {
struct bwfm_ssid ssid;
uint8_t bssid[ETHER_ADDR_LEN];
uint8_t bss_type;
- uint8_t pad;
+ uint8_t ssid_type;
uint32_t scan_type;
uint32_t nprobes;
uint32_t active_time;
@@ -569,6 +575,7 @@ struct
Re: initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci
> Date: Tue, 10 Oct 2023 20:49:46 +0200
> From: Stefan Sperling
>
> On Tue, Oct 10, 2023 at 08:41:37PM +0200, Mark Kettenis wrote:
> > So the GMAC_VERSION #define is simply wrong. We should commit the
> > diff attached and drop the sc_core stuff you added below.
>
> That means all our supported chips are GMAC4 and later? Good to know.
Yes, earlier generations are handled by dwge(4).
> > > + switch (PCI_PRODUCT(pa->pa_id)) {
> > > + case PCI_PRODUCT_INTEL_EHL_PSE0_RGMII_1G:
> > > + sc->sc_phy_mode = DWQE_PHY_MODE_RGMII;
> >
> > This suggests that the PHY must be programmed to disable its internal
> > delays. Our eephy(4) driver doesn't do this. That may explain the
> > poor performance. See how MIIF_SETDELAY, MIIF_RXID and MIIF_TXID are
> > used in rgephy(4).
> >
> > Anyway, that is a different driver, so a separate diff that can go in
> > after this one.
>
> Thanks for the hint. I will take a look.
>
> > > + sc->sc_txfifo_size = 4096 * 8;
> > > + sc->sc_rxfifo_size = 4096 * 8;
> >
> > Makes more sense to simply use 32768 here. Intel's data sheet says 32KB.
>
> I will fix this and send a follow-up version soon.
>
> OK for your diff. Please put it in and I'll rebase on top.
done
> > Index: dev/ic/dwqereg.h
> > ===
> > RCS file: /cvs/src/sys/dev/ic/dwqereg.h,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 dwqereg.h
> > --- dev/ic/dwqereg.h16 Feb 2023 14:43:53 - 1.2
> > +++ dev/ic/dwqereg.h10 Oct 2023 18:40:19 -
> > @@ -39,8 +39,6 @@
> > #define GMAC_MAC_PACKET_FILTER_PR (1 << 0)
> > #define GMAC_MAC_HASH_TAB_REG0 0x0010
> > #define GMAC_MAC_HASH_TAB_REG1 0x0014
> > -#define GMAC_VERSION 0x0020
> > -#define GMAC_VERSION_SNPS_MASK0xff
> > #define GMAC_INT_MASK 0x003c
> > #define GMAC_INT_MASK_LPIIM (1 << 10)
> > #define GMAC_INT_MASK_PIM (1 << 3)
> > @@ -60,6 +58,8 @@
> > #define GMAC_INT_STATUS0x00b0
> > #define GMAC_INT_EN0x00b4
> > #define GMAC_MAC_1US_TIC_CTR 0x00dc
> > +#define GMAC_VERSION 0x0110
> > +#define GMAC_VERSION_SNPS_MASK0xff
> > #define GMAC_MAC_HW_FEATURE(x) (0x011c + (x) * 0x4)
> > #define GMAC_MAC_HW_FEATURE1_TXFIFOSIZE(x) (((x) >> 6) & 0x1f)
> > #define GMAC_MAC_HW_FEATURE1_RXFIFOSIZE(x) (((x) >> 0) & 0x3f)
> >
> >
>
Re: initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci
On Tue, Oct 10, 2023 at 08:41:37PM +0200, Mark Kettenis wrote:
> So the GMAC_VERSION #define is simply wrong. We should commit the
> diff attached and drop the sc_core stuff you added below.
That means all our supported chips are GMAC4 and later? Good to know.
> > + switch (PCI_PRODUCT(pa->pa_id)) {
> > + case PCI_PRODUCT_INTEL_EHL_PSE0_RGMII_1G:
> > + sc->sc_phy_mode = DWQE_PHY_MODE_RGMII;
>
> This suggests that the PHY must be programmed to disable its internal
> delays. Our eephy(4) driver doesn't do this. That may explain the
> poor performance. See how MIIF_SETDELAY, MIIF_RXID and MIIF_TXID are
> used in rgephy(4).
>
> Anyway, that is a different driver, so a separate diff that can go in
> after this one.
Thanks for the hint. I will take a look.
> > + sc->sc_txfifo_size = 4096 * 8;
> > + sc->sc_rxfifo_size = 4096 * 8;
>
> Makes more sense to simply use 32768 here. Intel's data sheet says 32KB.
I will fix this and send a follow-up version soon.
OK for your diff. Please put it in and I'll rebase on top.
> Index: dev/ic/dwqereg.h
> ===
> RCS file: /cvs/src/sys/dev/ic/dwqereg.h,v
> retrieving revision 1.2
> diff -u -p -r1.2 dwqereg.h
> --- dev/ic/dwqereg.h 16 Feb 2023 14:43:53 - 1.2
> +++ dev/ic/dwqereg.h 10 Oct 2023 18:40:19 -
> @@ -39,8 +39,6 @@
> #define GMAC_MAC_PACKET_FILTER_PR (1 << 0)
> #define GMAC_MAC_HASH_TAB_REG0 0x0010
> #define GMAC_MAC_HASH_TAB_REG1 0x0014
> -#define GMAC_VERSION 0x0020
> -#define GMAC_VERSION_SNPS_MASK 0xff
> #define GMAC_INT_MASK0x003c
> #define GMAC_INT_MASK_LPIIM (1 << 10)
> #define GMAC_INT_MASK_PIM (1 << 3)
> @@ -60,6 +58,8 @@
> #define GMAC_INT_STATUS 0x00b0
> #define GMAC_INT_EN 0x00b4
> #define GMAC_MAC_1US_TIC_CTR 0x00dc
> +#define GMAC_VERSION 0x0110
> +#define GMAC_VERSION_SNPS_MASK 0xff
> #define GMAC_MAC_HW_FEATURE(x) (0x011c + (x) * 0x4)
> #define GMAC_MAC_HW_FEATURE1_TXFIFOSIZE(x) (((x) >> 6) & 0x1f)
> #define GMAC_MAC_HW_FEATURE1_RXFIFOSIZE(x) (((x) >> 0) & 0x3f)
>
>
Re: initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci
> Date: Tue, 10 Oct 2023 19:40:31 +0200
> From: Stefan Sperling
>
> This patch adds enough code to get Elkart Lake devices with PCI
> Vendor ID 8086 and Product ID 4ba0 to attach and pass traffic.
>
> dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev
> 0x52, address xx:xx:xx:xx:xx:xx
> eephy0 at dwqe0 phy 1: 88E1512 10/100/1000 PHY, rev. 1
>
> # ifconfig dwqe0 media
> dwqe0: flags=8843 mtu 1500
> lladdr xx:xx:xx:xx:xx:xx
> index 5 priority 0 llprio 3
> media: Ethernet autoselect (1000baseT full-duplex,master)
> status: active
> supported media:
> media none
> media 10baseT
> media 10baseT mediaopt full-duplex
> media 100baseTX
> media 100baseTX mediaopt full-duplex
> media 1000baseT
> media 1000baseT mediaopt full-duplex
> media autoselect
>
> There is one issue though: Tx speed is currently capped to 64 Mbps in my
> testing, while Rx works at 300 Mbps. I will keep investigating this problem.
> But since 64 is better than 0 and the device seems to be working reliably
> in my testing I think it's worth getting this in and fixing remaining the
> issues in the tree.
>
> Various other PCI IDs could attach to this but would require more code.
> I don't have access to such hardware. So they remain commented for now.
> There is a second Elkhart Lake Ethernet device in the same box, with
> PCI id 4bb0. However, this interface has no physical Ethernet port
> exposed, and according to Linux there is no PHY attached to the MAC.
> Linux detects this device but fails to atach a PHY.
>
> ok?
So the GMAC_VERSION #define is simply wrong. We should commit the
diff attached and drop the sc_core stuff you added below.
A few more nits below...
> diff refs/heads/master refs/heads/dwqe
> commit - ef065493fb463fe122ab7b535932b871830b6de3
> commit + a82b4a31a1787b55291d125b3adfb40fe58779e4
> blob - c6094ca5a57d964784f56124b8d923393b1abb66
> blob + cf64e8ff2018fb0ee1e7e59b29b2bc2dd281aa99
> --- sys/arch/amd64/conf/GENERIC
> +++ sys/arch/amd64/conf/GENERIC
> @@ -556,6 +556,7 @@ lii* at pci? # Attansic L2
> Ethernet
> jme* at pci? # JMicron JMC250/JMC260 Ethernet
> bnxt*at pci? # Broadcom BCM573xx, BCM574xx
> ixl* at pci? # Intel Ethernet 700 Series
> +dwqe*at pci? # Intel Elkhart Lake Ethernet
> mcx* at pci? # Mellanox ConnectX-4
> iavf*at pci? # Intel Ethernet Adaptive VF
> aq* at pci? # Aquantia aQtion Ethernet
> blob - 7e6afaba34dd35e3bd180055a68741ee3b773486
> blob + 6a4cc88f048d63430ea9eb6080cd98741f7e1612
> --- sys/dev/fdt/if_dwqe_fdt.c
> +++ sys/dev/fdt/if_dwqe_fdt.c
> @@ -111,6 +111,8 @@ dwqe_fdt_attach(struct device *parent, struct device *
> }
> sc->sc_dmat = faa->fa_dmat;
>
> + sc->sc_core = DWQE_CORE_GMAC;
> +
> /* Decide GMAC id through address */
> switch (faa->fa_reg[0].addr) {
> case 0xfe2a:/* RK3568 */
> blob - 7d260ef46054d6566ef2f81f6cf96dc8de5a5893
> blob + 7ae36ee6e804b7456c296a248d2b058ffe65f722
> --- sys/dev/ic/dwqe.c
> +++ sys/dev/ic/dwqe.c
> @@ -100,7 +100,14 @@ dwqe_attach(struct dwqe_softc *sc)
> uint32_t version, mode;
> int i;
>
> - version = dwqe_read(sc, GMAC_VERSION);
> + switch (sc->sc_core) {
> + case DWQE_CORE_GMAC:
> + version = dwqe_read(sc, GMAC_VERSION);
> + break;
> + case DWQE_CORE_GMAC4:
> + version = dwqe_read(sc, GMAC4_VERSION);
> + break;
> + }
> printf(": rev 0x%02x, address %s\n", version & GMAC_VERSION_SNPS_MASK,
> ether_sprintf(sc->sc_lladdr));
>
> @@ -705,7 +712,7 @@ dwqe_up(struct dwqe_softc *sc)
> {
> struct ifnet *ifp = >sc_ac.ac_if;
> struct dwqe_buf *txb, *rxb;
> - uint32_t mode, reg, tqs, rqs;
> + uint32_t mode, reg, fifosz, tqs, rqs;
> int i;
>
> /* Allocate Tx descriptor ring. */
> @@ -793,9 +800,21 @@ dwqe_up(struct dwqe_softc *sc)
> mode |= GMAC_MTL_CHAN_RX_OP_MODE_RSF;
> }
> mode &= ~GMAC_MTL_CHAN_RX_OP_MODE_RQS_MASK;
> - rqs = (128 << GMAC_MAC_HW_FEATURE1_RXFIFOSIZE(sc->sc_hw_feature[1]) /
> - 256) - 1;
> - mode |= rqs << GMAC_MTL_CHAN_RX_OP_MODE_RQS_SHIFT;
> + if (sc->sc_rxfifo_size)
> + fifosz = sc->sc_rxfifo_size;
> + else
> + fifosz = (128 <<
> + GMAC_MAC_HW_FEATURE1_RXFIFOSIZE(sc->sc_hw_feature[1]));
> + rqs = fifosz / 256 - 1;
> + mode |= (rqs << GMAC_MTL_CHAN_RX_OP_MODE_RQS_SHIFT) &
> +GMAC_MTL_CHAN_RX_OP_MODE_RQS_MASK;
> + if (fifosz >= 4096) {
> + mode |= GMAC_MTL_CHAN_RX_OP_MODE_EHFC;
> + mode &=
initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci
This patch adds enough code to get Elkart Lake devices with PCI
Vendor ID 8086 and Product ID 4ba0 to attach and pass traffic.
dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev
0x52, address xx:xx:xx:xx:xx:xx
eephy0 at dwqe0 phy 1: 88E1512 10/100/1000 PHY, rev. 1
# ifconfig dwqe0 media
dwqe0: flags=8843 mtu 1500
lladdr xx:xx:xx:xx:xx:xx
index 5 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
supported media:
media none
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect
There is one issue though: Tx speed is currently capped to 64 Mbps in my
testing, while Rx works at 300 Mbps. I will keep investigating this problem.
But since 64 is better than 0 and the device seems to be working reliably
in my testing I think it's worth getting this in and fixing remaining the
issues in the tree.
Various other PCI IDs could attach to this but would require more code.
I don't have access to such hardware. So they remain commented for now.
There is a second Elkhart Lake Ethernet device in the same box, with
PCI id 4bb0. However, this interface has no physical Ethernet port
exposed, and according to Linux there is no PHY attached to the MAC.
Linux detects this device but fails to atach a PHY.
ok?
diff refs/heads/master refs/heads/dwqe
commit - ef065493fb463fe122ab7b535932b871830b6de3
commit + a82b4a31a1787b55291d125b3adfb40fe58779e4
blob - c6094ca5a57d964784f56124b8d923393b1abb66
blob + cf64e8ff2018fb0ee1e7e59b29b2bc2dd281aa99
--- sys/arch/amd64/conf/GENERIC
+++ sys/arch/amd64/conf/GENERIC
@@ -556,6 +556,7 @@ lii*at pci? # Attansic L2
Ethernet
jme* at pci? # JMicron JMC250/JMC260 Ethernet
bnxt* at pci? # Broadcom BCM573xx, BCM574xx
ixl* at pci? # Intel Ethernet 700 Series
+dwqe* at pci? # Intel Elkhart Lake Ethernet
mcx* at pci? # Mellanox ConnectX-4
iavf* at pci? # Intel Ethernet Adaptive VF
aq*at pci? # Aquantia aQtion Ethernet
blob - 7e6afaba34dd35e3bd180055a68741ee3b773486
blob + 6a4cc88f048d63430ea9eb6080cd98741f7e1612
--- sys/dev/fdt/if_dwqe_fdt.c
+++ sys/dev/fdt/if_dwqe_fdt.c
@@ -111,6 +111,8 @@ dwqe_fdt_attach(struct device *parent, struct device *
}
sc->sc_dmat = faa->fa_dmat;
+ sc->sc_core = DWQE_CORE_GMAC;
+
/* Decide GMAC id through address */
switch (faa->fa_reg[0].addr) {
case 0xfe2a:/* RK3568 */
blob - 7d260ef46054d6566ef2f81f6cf96dc8de5a5893
blob + 7ae36ee6e804b7456c296a248d2b058ffe65f722
--- sys/dev/ic/dwqe.c
+++ sys/dev/ic/dwqe.c
@@ -100,7 +100,14 @@ dwqe_attach(struct dwqe_softc *sc)
uint32_t version, mode;
int i;
- version = dwqe_read(sc, GMAC_VERSION);
+ switch (sc->sc_core) {
+ case DWQE_CORE_GMAC:
+ version = dwqe_read(sc, GMAC_VERSION);
+ break;
+ case DWQE_CORE_GMAC4:
+ version = dwqe_read(sc, GMAC4_VERSION);
+ break;
+ }
printf(": rev 0x%02x, address %s\n", version & GMAC_VERSION_SNPS_MASK,
ether_sprintf(sc->sc_lladdr));
@@ -705,7 +712,7 @@ dwqe_up(struct dwqe_softc *sc)
{
struct ifnet *ifp = >sc_ac.ac_if;
struct dwqe_buf *txb, *rxb;
- uint32_t mode, reg, tqs, rqs;
+ uint32_t mode, reg, fifosz, tqs, rqs;
int i;
/* Allocate Tx descriptor ring. */
@@ -793,9 +800,21 @@ dwqe_up(struct dwqe_softc *sc)
mode |= GMAC_MTL_CHAN_RX_OP_MODE_RSF;
}
mode &= ~GMAC_MTL_CHAN_RX_OP_MODE_RQS_MASK;
- rqs = (128 << GMAC_MAC_HW_FEATURE1_RXFIFOSIZE(sc->sc_hw_feature[1]) /
- 256) - 1;
- mode |= rqs << GMAC_MTL_CHAN_RX_OP_MODE_RQS_SHIFT;
+ if (sc->sc_rxfifo_size)
+ fifosz = sc->sc_rxfifo_size;
+ else
+ fifosz = (128 <<
+ GMAC_MAC_HW_FEATURE1_RXFIFOSIZE(sc->sc_hw_feature[1]));
+ rqs = fifosz / 256 - 1;
+ mode |= (rqs << GMAC_MTL_CHAN_RX_OP_MODE_RQS_SHIFT) &
+ GMAC_MTL_CHAN_RX_OP_MODE_RQS_MASK;
+ if (fifosz >= 4096) {
+ mode |= GMAC_MTL_CHAN_RX_OP_MODE_EHFC;
+ mode &= ~GMAC_MTL_CHAN_RX_OP_MODE_RFD_MASK;
+ mode |= 0x3 << GMAC_MTL_CHAN_RX_OP_MODE_RFD_SHIFT;
+ mode &= ~GMAC_MTL_CHAN_RX_OP_MODE_RFA_MASK;
+ mode |= 0x1 << GMAC_MTL_CHAN_RX_OP_MODE_RFA_SHIFT;
+ }
dwqe_write(sc, GMAC_MTL_CHAN_RX_OP_MODE(0), mode);
mode = dwqe_read(sc, GMAC_MTL_CHAN_TX_OP_MODE(0));
@@ -809,9 +828,14 @@
Re: CVS: cvs.openbsd.org: src
On Tue, 10 Oct 2023 10:14:10 -0700, Chris Cappuccio wrote: > The Message-ID should be added to any message that doesn't have one. > An existing Message-ID should not be removed or changed. > > The RFC says it "MAY be applied when necessary by an originating SMTP server" > so the port numbers aren't a terrible idea, but it leaves open plenty > of room to not add one if someone isn't following the 465/587 scheme. But smtpd may not be the originating SMTP server. For "local" messages (that originated on the server) it knows to add the Message-ID if missing. I don't think it should be adding it to relayed messages. Messages received on the submission port are special, they need to be treated as local even though they originated elsewhere. - todd
Re: CVS: cvs.openbsd.org: src
Todd C. Miller [mill...@openbsd.org] wrote: > On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote: > > > Presumably 465 should be treated the same, though the hardcoded ports > > don't feel entirely right here - this is presumably something that would > > want adding for any connection which is allowed to relay .. > > Yes, I think so. Hard-coding ports is not great but there isn't a > way in the config file to indicate that explicitly. > The Message-ID should be added to any message that doesn't have one. An existing Message-ID should not be removed or changed. The RFC says it "MAY be applied when necessary by an originating SMTP server" so the port numbers aren't a terrible idea, but it leaves open plenty of room to not add one if someone isn't following the 465/587 scheme. If the smtp_tx_dataline or a subset could be called when we know the message isn't being delivered locally, that would be ideal and avoid the need to lookup port numbers. Chris
Re: mail(1) MIME support [PATCH]
Added random number to Message-ID to get more unique string.
Index: cmd3.c
===
RCS file: /cvs/src/usr.bin/mail/cmd3.c,v
retrieving revision 1.30
diff -u -p -r1.30 cmd3.c
--- cmd3.c 8 Mar 2023 04:43:11 - 1.30
+++ cmd3.c 10 Oct 2023 16:58:19 -
@@ -238,6 +238,7 @@ _respond(int *msgvec)
head.h_cc = np;
} else
head.h_cc = NULL;
+ head.h_msgid = hfield("message-id", mp);
head.h_bcc = NULL;
head.h_smopts = NULL;
mail1(, 1);
@@ -617,6 +618,7 @@ _Respond(int *msgvec)
if ((head.h_subject = hfield("subject", mp)) == NULL)
head.h_subject = hfield("subj", mp);
head.h_subject = reedit(head.h_subject);
+ head.h_msgid = hfield("message-id", mp);
head.h_from = NULL;
head.h_cc = NULL;
head.h_bcc = NULL;
Index: collect.c
===
RCS file: /cvs/src/usr.bin/mail/collect.c,v
retrieving revision 1.34
diff -u -p -r1.34 collect.c
--- collect.c 17 Jan 2014 18:42:30 - 1.34
+++ collect.c 10 Oct 2023 16:58:19 -
@@ -87,7 +87,7 @@ collect(struct header *hp, int printhead
* refrain from printing a newline after
* the headers (since some people mind).
*/
- t = GTO|GSUBJECT|GCC|GNL;
+ t = GTO|GSUBJECT|GMID|GCC|GNL;
getsub = 0;
if (hp->h_subject == NULL && value("interactive") != NULL &&
(value("ask") != NULL || value("asksub") != NULL))
@@ -208,7 +208,7 @@ cont:
/*
* Grab a bunch of headers.
*/
- grabh(hp, GTO|GSUBJECT|GCC|GBCC);
+ grabh(hp, GTO|GSUBJECT|GMID|GCC|GBCC);
goto cont;
case 't':
/*
@@ -328,7 +328,7 @@ cont:
*/
rewind(collf);
puts("---\nMessage contains:");
- puthead(hp, stdout, GTO|GSUBJECT|GCC|GBCC|GNL);
+ puthead(hp, stdout, GTO|GSUBJECT|GMID|GCC|GBCC|GNL);
while ((t = getc(collf)) != EOF)
(void)putchar(t);
goto cont;
Index: def.h
===
RCS file: /cvs/src/usr.bin/mail/def.h,v
retrieving revision 1.17
diff -u -p -r1.17 def.h
--- def.h 28 Jan 2022 06:18:41 - 1.17
+++ def.h 10 Oct 2023 16:58:19 -
@@ -156,14 +156,15 @@ struct headline {
#defineGTO 1 /* Grab To: line */
#defineGSUBJECT 2 /* Likewise, Subject: line */
-#defineGCC 4 /* And the Cc: line */
-#defineGBCC8 /* And also the Bcc: line */
-#defineGMASK (GTO|GSUBJECT|GCC|GBCC)
+#defineGMID4 /* Message-ID: line */
+#defineGCC 8 /* And the Cc: line */
+#defineGBCC16 /* And also the Bcc: line */
+#defineGMASK (GTO|GSUBJECT|GMID|GCC|GBCC)
/* Mask of places from whence */
-#defineGNL 16 /* Print blank line after */
-#defineGDEL32 /* Entity removed from list */
-#defineGCOMMA 64 /* detract puts in commas */
+#defineGNL 32 /* Print blank line after */
+#defineGDEL64 /* Entity removed from list */
+#defineGCOMMA 128 /* detract puts in commas */
/*
* Structure used to pass about the current
@@ -173,6 +174,7 @@ struct header {
struct name *h_to; /* Dynamic "To:" string */
char *h_from; /* User-specified "From:" string */
char *h_subject;/* Subject string */
+ char *h_msgid; /* Message-ID string */
struct name *h_cc; /* Carbon copies string */
struct name *h_bcc; /* Blind carbon copies */
struct name *h_smopts; /* Sendmail options */
Index: extern.h
===
RCS file: /cvs/src/usr.bin/mail/extern.h,v
retrieving revision 1.29
diff -u -p -r1.29 extern.h
--- extern.h16 Sep 2018 02:38:57 - 1.29
+++ extern.h10 Oct 2023 16:58:19 -
@@ -163,7 +163,7 @@ void load(char *);
struct var *
lookup(char *);
int mail(struct name *, struct name *, struct name *, struct name *,
- char *, char *);
+ char *, char *, char *);
voidmail1(struct header *, int);
voidmakemessage(FILE *, int);
voidmark(int);
Index: main.c
===
RCS file:
bt(5), btrace(8): support modulo operator ('%')
This adds support for the modulo operator to btrace(8).
I was trying to use it like this:
$start = nsecs;
/* ... */
$elapsed = nsecs - $start;
printf("%d.%09d seconds\n",
$elapsed / 10, $elapsed % 10);
and noticed it was missing.
ok?
Index: bt_parse.y
===
RCS file: /cvs/src/usr.sbin/btrace/bt_parse.y,v
retrieving revision 1.53
diff -u -p -r1.53 bt_parse.y
--- bt_parse.y 11 Sep 2023 19:01:26 - 1.53
+++ bt_parse.y 10 Oct 2023 16:07:45 -
@@ -184,7 +184,7 @@ filter : /* empty */ { $$ = NULL; }
* Give higher precedence to:
* 1. && and ||
* 2. ==, !=, <<, <, >=, >, +, =, &, ^, |
- * 3. * and /
+ * 3. * , / , %
*/
expr : expr OP_LAND term { $$ = ba_op(B_AT_OP_LAND, $1, $3); }
| expr OP_LOR term { $$ = ba_op(B_AT_OP_LOR, $1, $3); }
@@ -207,6 +207,7 @@ term: term OP_EQ fterm { $$ = ba_op(B_A
fterm : fterm '*' factor { $$ = ba_op(B_AT_OP_MULT, $1, $3); }
| fterm '/' factor { $$ = ba_op(B_AT_OP_DIVIDE, $1, $3); }
+ | fterm '%' factor { $$ = ba_op(B_AT_OP_MODULO, $1, $3); }
| factor
;
Index: bt_parser.h
===
RCS file: /cvs/src/usr.sbin/btrace/bt_parser.h,v
retrieving revision 1.24
diff -u -p -r1.24 bt_parser.h
--- bt_parser.h 11 Sep 2023 19:01:26 - 1.24
+++ bt_parser.h 10 Oct 2023 16:07:45 -
@@ -163,6 +163,7 @@ struct bt_arg {
B_AT_OP_MINUS,
B_AT_OP_MULT,
B_AT_OP_DIVIDE,
+ B_AT_OP_MODULO,
B_AT_OP_BAND,
B_AT_OP_XOR,
B_AT_OP_BOR,
Index: btrace.c
===
RCS file: /cvs/src/usr.sbin/btrace/btrace.c,v
retrieving revision 1.78
diff -u -p -r1.78 btrace.c
--- btrace.c15 Sep 2023 10:59:02 - 1.78
+++ btrace.c10 Oct 2023 16:07:45 -
@@ -1416,6 +1416,9 @@ baexpr2long(struct bt_arg *ba, struct dt
case B_AT_OP_DIVIDE:
result = lval / rval;
break;
+ case B_AT_OP_MODULO:
+ result = lval % rval;
+ break;
case B_AT_OP_BAND:
result = lval & rval;
break;
@@ -1526,6 +1529,8 @@ ba_name(struct bt_arg *ba)
return "*";
case B_AT_OP_DIVIDE:
return "/";
+ case B_AT_OP_MODULO:
+ return "%";
case B_AT_OP_BAND:
return "&";
case B_AT_OP_XOR:
Re: pf passes packet if limit reached
On Tue, Oct 10, 2023 at 02:53:15PM +0200, Alexander Bluhm wrote: > Hi, > > The behaviour of the PFRULE_SRCTRACK and max_states check was > unintentionally changed by this commit. > > > revision 1.964 > date: 2016/01/25 18:49:57; author: sashan; state: Exp; lines: +18 -10; > commitid: KeemoLxcm7FS1oYy; > - plugging massive pf_state_key leak > > OK mpi@ dlg@ sthen@ > > > If we do not create a state after some limit was reached, pf still > passes the packet. We can restore the old behavior by setting > action later, after the checks. > > ok? > oh dear... thanks for finding that bug out and killing it OK sashan
Re: CVS: cvs.openbsd.org: src
On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote: > Presumably 465 should be treated the same, though the hardcoded ports > don't feel entirely right here - this is presumably something that would > want adding for any connection which is allowed to relay .. Yes, I think so. Hard-coding ports is not great but there isn't a way in the config file to indicate that explicitly. - todd
Can you help our opensource project (file formats)?
We want the unreal map file types. http://sf.net/p/chaosesqueanthology /tickets/2/ .t3d and .unr file formats
Re: I can't get contributors for my C project. Can you help?
Bruce Perens; Thank's for responding. I mean that. No one else ever does :( *Message Main Body: Where am I supposed to send it? Every opensource forum I go to is basically shut down now: even slashdot (they don't even allow new registrations). No one seems to use C anymore: even though it's not /that/ much harder than any of the new programming languages: you just got to say where you want to store your data. Everyone is afraid of that now for some reason. I've found C to be very similar to PERL, and QuakeC, it's just easy to use as one or the other. And C is alot faster. I don't know why people trash it. So I send it to the few C programs I know still are kicking. I really don't have any other solution for communication: everywhere else is a complete ghost town. Things changed alot in these last 10 years. I remeber when all one had to do was post in any random article on slashdot, in the comments section, and one would have like 12 people the next day interested in the opensource project. Now everything's shuttered, silo'd, and dead :( And I don't want to attempt to communicate on ... X? a walled garden and a firehose put together. *Message Addendum: --- *Long story short; *We want the unreal map file types. *sf.net/p/chaosesqueanthology /tickets/2/ *.t3d and .unr file formats t3d format is nice; but requires more math grinding. .unr format is ... less nice... but requires less math (ie format more complex; but less processing is required) On Sunday, October 8, 2023 at 08:25:38 PM EDT, Bruce Perens wrote: Mikey, This is why nobody wants to help you. On Sat, Oct 7, 2023 at 7:29 AM chaosesquet...@yahoo.com wrote: > Bagas; > There is no other place that C projects are talked about. In the past I could > get help and contributors just asking; now you are all silo'd in your own > little worlds and seethe with extreme anger or some castrated-drug-stupor in > "irony" and smugness against anyone that asks for some contributors. Every > single place bans anyone that asks for contributors to free-software projects. > > You feel you are superior because you "did code" 10 years ago and "support > trans rights". > When asked to even allow a message to be seen that asks for contributors, in > this case a file format, to a fellow C project: you seethe or pretend you are > superior. > As if I didn't know where I was sending the message? > I sent it to: RMS, ESR, Bruce Perens, redhat, OpenBSD, NetBSD, and Line-Unix. > All C projects. Just like this engine. > I'm just asking for contributors. Not promoting "outrecehery" (some feminist > BS), Not "master vs main", not "noo can't call things whitelist/blacklist", > and not Codes Of Conducts for free contributors. I'm just asking for C > programming help for 3d file formats I'd like to add to this free-software > project. > > sourceforge.net/p/chaosesqueanthology/tickets/2/ > > > > > > > > On Saturday, October 7, 2023 at 04:56:51 AM EDT, Bagas Sanjaya > wrote: > > > > > > On Fri, Oct 06, 2023 at 07:18:20PM +, chaosesquet...@yahoo.com wrote: >> Dear RMS; >> >> I've read that you are both a lisp and C developer. I cannot get any >> contributors for the longstanding C 3d engine I work on as part of my >> fully-free-software (including media) 3d game/architecture project. I've >> been working on it alone for 10 years but now have branched into supporting >> more 3d file types and can't do that alone. >> >> I've gone to "opensource" forums and gotten banned every single time for >> asking for help. Every single time. The message gets deleted. This is >> extremely difficult: it's not like 20 years ago when communication was free. >> Obvs the "opensource" community is no longer interested in any collaboration >> or development. >> >> The reason I wanted to find more contributors, is that I recently (last 2 >> years) programmed more file format support myself >> (wolfenstine:enemyterritory bsp support) and extended and fixed support for >> existing formats (obj file support for use as maps, and support for minetest >> and minecraft object exports as maps directly into the game, and BZFlag >> exported obj as maps (these didn't work at all before: now they do (bzflag >> and the engine previously had different opinions on what an obj file was >> mathmatically))). That opened up 600 3d maps with the bsp work, and then >> 1000s of obj files with the obj_to_mc work. So I felt I was on a roll. >> Sketchfab was "opened up" and lots of free-software-licensed terrain and >> such were easily used from there. It was nice. I wanted to keep going. >> >> I thought it might be possible to get unreal 97 and unreal tournament 99 3d >> map formats working: as there are tons of maps there and I used to make >> little 3d worlds using that format. The two main formats here are .t3d ; an >> ascii format (like obj) but which requires CSG math, and .unr : a binary >> format which pre-compiles the csg math down
Re: tcp syn cache unlock
On Tue, Oct 10, 2023 at 09:06:23AM -0500, Scott Cheloha wrote:
> On Fri, Oct 06, 2023 at 03:41:39PM +0200, Alexander Bluhm wrote:
> > On Fri, Oct 06, 2023 at 03:47:31PM +0300, Vitaliy Makkoveev wrote:
> > > On Fri, Oct 06, 2023 at 02:14:52PM +0200, Alexander Bluhm wrote:
> > > > > @@ -718,11 +743,13 @@ softclock(void *arg)
> > > > > softclock_process_tick_timeout(to, new);
> > > > > }
> > > > > tostat.tos_softclocks++;
> > > > > - needsproc = !CIRCQ_EMPTY(_proc);
> > > > > - mtx_leave(_mutex);
> > > > > -
> > > > > - if (needsproc)
> > > > > + if (!CIRCQ_EMPTY(_proc))
> > > > > wakeup(_proc);
> > > > > +#ifdef MULTIPROCESSOR
> > > > > + if(!CIRCQ_EMPTY(_proc_mpsafe))
> > > > > + wakeup(_proc_mpsafe);
> > > > > +#endif
> > > > > + mtx_leave(_mutex);
> > > > > }
> > > > >
> > > > > void
> > > >
> > > > Was there a good reason that wakeup() did run without mutex?
> > > > Do we really want to change this?
> > > >
> > >
> > > I dont understand you. Original code does wakeup() outside mutex. I
> > > moved wakeup() under mutex. You want to move it back?
> >
> > I just wanted to know why you moved it.
> >
> > Now I see. You use msleep_nsec() with timeout_mutex. Putting
> > wakeup in mutex ensures that you don't miss it.
>
> Do we actually need to move the softclock() wakeup calls into the
> mutex? As long as CIRCQ_EMPTY(...) is evaluated within timeout_mutex,
> the thread can't get stuck waiting for a wakeup that isn't coming.
> Both threads now sleep via msleep_nsec(), so there is no "gap" between
> evaluation and unlock.
>
> Am I missing something else?
>
In other hand, why to not move them under the `timeout_mutex' mutex(9)?
Does this unlocked call provides something significant?
> > Nitpick: timeoutmp_proc should be timeout_procmp. timeout_ is the
> > prefix in this file. mp suffix is easier to see at the end.
> >
> > >+ if (kthread_create(softclockmp_thread, NULL, NULL, "softclockm"))
> > "softclockm" -> "softclockmp"
> >
> > OK bluhm@, but let's wait for cheloha@ and see what he thinks
>
> Revised patch:
>
> - Add TIMEOUT_MPSAFE support to timeout_barrier(). This is crucial.
> - Keep the names in the existing namespaces where possible.
> - Keep the wakeup(9) calls in softclock() outside of timeout_mutex.
> ... unless I have made an error, they can stay where they are.
> - Trim the processing loops in the threads.
> - Tweak the ddb(4) printing code to distinguish the locked and
> unlocked thread circqs.
>
> mvs/bluhm: try this with your favorite process-context timeout and
> make sure the timeouts still run.
>
> Assuming everything works, ok?
>
ok by me, with the one nit:
> + msleep_nsec(_proc, _mutex, PSWP, "bored",
> + INFSLP);
"bored" is used by tasks. Can you use another ident?
> Index: share/man/man9/timeout.9
> ===
> RCS file: /cvs/src/share/man/man9/timeout.9,v
> retrieving revision 1.56
> diff -u -p -r1.56 timeout.9
> --- share/man/man9/timeout.9 1 Jan 2023 01:19:18 - 1.56
> +++ share/man/man9/timeout.9 10 Oct 2023 13:44:02 -
> @@ -193,11 +193,16 @@ Counts the time elapsed since the system
> The timeout's behavior may be configured with the bitwise OR of
> zero or more of the following
> .Fa flags :
> -.Bl -tag -width TIMEOUT_PROC
> +.Bl -tag -width TIMEOUT_MPSAFE
> .It Dv TIMEOUT_PROC
> Execute the timeout in a process context instead of the default
> .Dv IPL_SOFTCLOCK
> interrupt context.
> +.It Dv TIMEOUT_MPSAFE
> +Execute the timeout without the kernel lock.
> +Requires the
> +.Dv TIMEOUT_PROC
> +flag.
> .El
> .El
> .Pp
> @@ -367,8 +372,9 @@ The function
> .Fa fn
> must not block and must be safe to execute on any CPU in the system.
> .Pp
> -Currently,
> -all timeouts are executed under the kernel lock.
> +Timeouts without the
> +.Dv TIMEOUT_MPSAFE
> +flag are executed under the kernel lock.
> .Sh RETURN VALUES
> .Fn timeout_add ,
> .Fn timeout_add_sec ,
> Index: sys/sys/timeout.h
> ===
> RCS file: /cvs/src/sys/sys/timeout.h,v
> retrieving revision 1.47
> diff -u -p -r1.47 timeout.h
> --- sys/sys/timeout.h 31 Dec 2022 16:06:24 - 1.47
> +++ sys/sys/timeout.h 10 Oct 2023 13:44:02 -
> @@ -54,6 +54,7 @@ struct timeout {
> #define TIMEOUT_ONQUEUE 0x02/* on any timeout queue */
> #define TIMEOUT_INITIALIZED 0x04/* initialized */
> #define TIMEOUT_TRIGGERED0x08/* running or ran */
> +#define TIMEOUT_MPSAFE 0x10/* run without kernel lock */
>
> struct timeoutstat {
> uint64_t tos_added; /* timeout_add*(9) calls */
> Index: sys/kern/kern_timeout.c
> ===
> RCS file: /cvs/src/sys/kern/kern_timeout.c,v
> retrieving revision 1.95
> diff -u -p -r1.95
Re: tcp syn cache unlock
On Fri, Oct 06, 2023 at 03:41:39PM +0200, Alexander Bluhm wrote:
> On Fri, Oct 06, 2023 at 03:47:31PM +0300, Vitaliy Makkoveev wrote:
> > On Fri, Oct 06, 2023 at 02:14:52PM +0200, Alexander Bluhm wrote:
> > > > @@ -718,11 +743,13 @@ softclock(void *arg)
> > > > softclock_process_tick_timeout(to, new);
> > > > }
> > > > tostat.tos_softclocks++;
> > > > - needsproc = !CIRCQ_EMPTY(_proc);
> > > > - mtx_leave(_mutex);
> > > > -
> > > > - if (needsproc)
> > > > + if (!CIRCQ_EMPTY(_proc))
> > > > wakeup(_proc);
> > > > +#ifdef MULTIPROCESSOR
> > > > + if(!CIRCQ_EMPTY(_proc_mpsafe))
> > > > + wakeup(_proc_mpsafe);
> > > > +#endif
> > > > + mtx_leave(_mutex);
> > > > }
> > > >
> > > > void
> > >
> > > Was there a good reason that wakeup() did run without mutex?
> > > Do we really want to change this?
> > >
> >
> > I dont understand you. Original code does wakeup() outside mutex. I
> > moved wakeup() under mutex. You want to move it back?
>
> I just wanted to know why you moved it.
>
> Now I see. You use msleep_nsec() with timeout_mutex. Putting
> wakeup in mutex ensures that you don't miss it.
Do we actually need to move the softclock() wakeup calls into the
mutex? As long as CIRCQ_EMPTY(...) is evaluated within timeout_mutex,
the thread can't get stuck waiting for a wakeup that isn't coming.
Both threads now sleep via msleep_nsec(), so there is no "gap" between
evaluation and unlock.
Am I missing something else?
> Nitpick: timeoutmp_proc should be timeout_procmp. timeout_ is the
> prefix in this file. mp suffix is easier to see at the end.
>
> >+ if (kthread_create(softclockmp_thread, NULL, NULL, "softclockm"))
> "softclockm" -> "softclockmp"
>
> OK bluhm@, but let's wait for cheloha@ and see what he thinks
Revised patch:
- Add TIMEOUT_MPSAFE support to timeout_barrier(). This is crucial.
- Keep the names in the existing namespaces where possible.
- Keep the wakeup(9) calls in softclock() outside of timeout_mutex.
... unless I have made an error, they can stay where they are.
- Trim the processing loops in the threads.
- Tweak the ddb(4) printing code to distinguish the locked and
unlocked thread circqs.
mvs/bluhm: try this with your favorite process-context timeout and
make sure the timeouts still run.
Assuming everything works, ok?
Index: share/man/man9/timeout.9
===
RCS file: /cvs/src/share/man/man9/timeout.9,v
retrieving revision 1.56
diff -u -p -r1.56 timeout.9
--- share/man/man9/timeout.91 Jan 2023 01:19:18 - 1.56
+++ share/man/man9/timeout.910 Oct 2023 13:44:02 -
@@ -193,11 +193,16 @@ Counts the time elapsed since the system
The timeout's behavior may be configured with the bitwise OR of
zero or more of the following
.Fa flags :
-.Bl -tag -width TIMEOUT_PROC
+.Bl -tag -width TIMEOUT_MPSAFE
.It Dv TIMEOUT_PROC
Execute the timeout in a process context instead of the default
.Dv IPL_SOFTCLOCK
interrupt context.
+.It Dv TIMEOUT_MPSAFE
+Execute the timeout without the kernel lock.
+Requires the
+.Dv TIMEOUT_PROC
+flag.
.El
.El
.Pp
@@ -367,8 +372,9 @@ The function
.Fa fn
must not block and must be safe to execute on any CPU in the system.
.Pp
-Currently,
-all timeouts are executed under the kernel lock.
+Timeouts without the
+.Dv TIMEOUT_MPSAFE
+flag are executed under the kernel lock.
.Sh RETURN VALUES
.Fn timeout_add ,
.Fn timeout_add_sec ,
Index: sys/sys/timeout.h
===
RCS file: /cvs/src/sys/sys/timeout.h,v
retrieving revision 1.47
diff -u -p -r1.47 timeout.h
--- sys/sys/timeout.h 31 Dec 2022 16:06:24 - 1.47
+++ sys/sys/timeout.h 10 Oct 2023 13:44:02 -
@@ -54,6 +54,7 @@ struct timeout {
#define TIMEOUT_ONQUEUE0x02/* on any timeout queue */
#define TIMEOUT_INITIALIZED0x04/* initialized */
#define TIMEOUT_TRIGGERED 0x08/* running or ran */
+#define TIMEOUT_MPSAFE 0x10/* run without kernel lock */
struct timeoutstat {
uint64_t tos_added; /* timeout_add*(9) calls */
Index: sys/kern/kern_timeout.c
===
RCS file: /cvs/src/sys/kern/kern_timeout.c,v
retrieving revision 1.95
diff -u -p -r1.95 kern_timeout.c
--- sys/kern/kern_timeout.c 29 Jul 2023 06:52:08 - 1.95
+++ sys/kern/kern_timeout.c 10 Oct 2023 13:44:02 -
@@ -75,6 +75,9 @@ struct circq timeout_wheel_kc[BUCKETS];
struct circq timeout_new; /* [T] New, unscheduled timeouts */
struct circq timeout_todo; /* [T] Due or needs rescheduling */
struct circq timeout_proc; /* [T] Due + needs process context */
+#ifdef MULTIPROCESSOR
+struct circq timeout_proc_mp; /* [T] Process ctx + no kernel lock */
+#endif
time_t
bgpd: fix handling of non-transitive ext communities
See https://github.com/openbgpd-portable/openbgpd-portable/issues/64
The handling of non-transitive ext communities causes encoding errors in
for regular communities. The problem is that the start and end points of
the loop are calculated like this:
for (l = 0; l < comm->nentries; l++) {
cp = >communities[l];
if (ebgp && non_transitive_ext_community(cp))
continue;
if ((uint8_t)cp->flags == t) {
num++;
if (start == -1)
start = l;
}
if ((uint8_t)cp->flags > t)
break;
}
end = l;
But in the write out loop the non_transitive_ext_community() check
is only done inside the ext-community block. As a result
COMMUNITY_TYPE_BASIC communities can walk over their respective end of the
list into the COMMUNITY_TYPE_EXT communities (if the non-transitive
ext-comm is the first ext-community).
The fix is to move the non_transitive_ext_community() check into
if ((uint8_t)cp->flags == t) { } block. Since then we know the type is
correct.
--
:wq Claudio
Index: rde_community.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_community.c,v
retrieving revision 1.13
diff -u -p -r1.13 rde_community.c
--- rde_community.c 12 Jul 2023 14:45:43 - 1.13
+++ rde_community.c 10 Oct 2023 13:43:03 -
@@ -556,10 +556,9 @@ community_writebuf(struct rde_community
start = -1;
for (l = 0; l < comm->nentries; l++) {
cp = >communities[l];
-
- if (ebgp && non_transitive_ext_community(cp))
- continue;
if ((uint8_t)cp->flags == t) {
+ if (ebgp && non_transitive_ext_community(cp))
+ continue;
num++;
if (start == -1)
start = l;
pf passes packet if limit reached
Hi,
The behaviour of the PFRULE_SRCTRACK and max_states check was
unintentionally changed by this commit.
revision 1.964
date: 2016/01/25 18:49:57; author: sashan; state: Exp; lines: +18 -10;
commitid: KeemoLxcm7FS1oYy;
- plugging massive pf_state_key leak
OK mpi@ dlg@ sthen@
If we do not create a state after some limit was reached, pf still
passes the packet. We can restore the old behavior by setting
action later, after the checks.
ok?
bluhm
Index: net/pf.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
retrieving revision 1.1186
diff -u -p -r1.1186 pf.c
--- net/pf.c8 Sep 2023 13:40:52 - 1.1186
+++ net/pf.c9 Oct 2023 22:37:14 -
@@ -4467,8 +4467,6 @@ pf_test_rule(struct pf_pdesc *pd, struct
goto cleanup;
}
- action = PF_PASS;
-
if (pd->virtual_proto != PF_VPROTO_FRAGMENT
&& !ctx.state_icmp && r->keep_state) {
@@ -4511,6 +4509,8 @@ pf_test_rule(struct pf_pdesc *pd, struct
#endif /* INET6 */
} else {
+ action = PF_PASS;
+
while ((ctx.ri = SLIST_FIRST())) {
SLIST_REMOVE_HEAD(, entry);
pool_put(_rule_item_pl, ctx.ri);
malloc: more info in error message for write-after-free with option D
Hi,
This diff adds better error reporting for write-after-free or the more
general write of free memory if malloc option D is active. Knowing the
place where allocations were done often helps to find out where the
overwrite happened.
If option D is active malloc now saves caller info in a separate page
instead of only doing that for chunk index 0. It also reports about
the preceding chunk if applicable. A report looks like this:
X(12489) in calloc(): write to free chunk 0x851ec6066d0[0..7]@16
allocated at /usr/X11R6/lib/modules/dri/radeonsi_dri.so 0x88c949
(preceding chunk 0x851ec6066c0 allocated at /usr/X11R6/bin/X 0x177374 (now
free))
You can use addr2line -e to get the file and linenumber the allocation
was done (if the object was compiled with debug info).
If D is not used only the first part is printed, as no caller info is
saved. So no extra overhead if D is not useed.
Also: the leak report now do not contain unknown locations anymore, as
each allocation gets its caller recorded if D is active.
-Otto
Index: stdlib/malloc.3
===
RCS file: /home/cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.137
diff -u -p -r1.137 malloc.3
--- stdlib/malloc.3 1 Jul 2023 18:35:14 - 1.137
+++ stdlib/malloc.3 10 Oct 2023 10:23:19 -
@@ -307,7 +307,7 @@ These malloc options imply
.Cm D .
.It Cm F
.Dq Freecheck .
-Enable more extensive double free and use after free detection.
+Enable more extensive double free and write after free detection.
All chunks in the delayed free list will be checked for double frees and
write after frees.
Unused pages on the freelist are read and write protected to
@@ -641,18 +641,34 @@ or
reallocate an unallocated pointer was made.
.It Dq double free
There was an attempt to free an allocation that had already been freed.
-.It Dq write after free
-An allocation has been modified after it was freed.
+.It Dq write of free mem Va address Ns [ Va start Ns .. Ns Va end Ns ]@ Ns Va
size
+An allocation has been modified after it was freed,
+or a chunk that was never allocated was written to.
+The
+.Va range
+at which corruption was detected is printed between [ and ].
+.Pp
+Enabling option
+.Cm D
+allows malloc to print information about where the allocation
+was done.
.It Dq modified chunk-pointer
The pointer passed to
.Fn free
or a reallocation function has been modified.
-.It Dq canary corrupted address offset@length
-A byte after the requested size has been overwritten,
+.It Dq canary corrupted Va address Ns [ Va offset Ns ]@ Ns Va length Ns / Ns
Va size
+A byte after the requested
+.Va length has been overwritten,
indicating a heap overflow.
-The offset at which corruption was detected is printed before the @,
-and the requested length of the allocation after the @.
-.It Dq recorded size oldsize inconsistent with size
+The
+.Va offset
+at which corruption was detected is printed between [ and ],
+the requested
+.Va length
+of the allocation is printed before the / and the
+.Va size
+of the allocation after the /.
+.It Dq recorded size Va oldsize No inconsistent with Va size
.Fn recallocarray
or
.Fn freezero
@@ -676,7 +692,7 @@ functions nor utilize any other function
(e.g.,
.Xr stdio 3
routines).
-.It Dq unknown char in MALLOC_OPTIONS
+.It Dq unknown char in Ev MALLOC_OPTIONS
We found something we didn't understand.
.It any other error
.Fn malloc
Index: stdlib/malloc.c
===
RCS file: /home/cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.290
diff -u -p -r1.290 malloc.c
--- stdlib/malloc.c 9 Sep 2023 06:52:40 - 1.290
+++ stdlib/malloc.c 10 Oct 2023 10:23:19 -
@@ -112,7 +112,7 @@ struct region_info {
void *p;/* page; low bits used to mark chunks */
uintptr_t size; /* size for pages, or chunk_info pointer */
#ifdef MALLOC_STATS
- void *f;/* where allocated from */
+ void **f; /* where allocated from */
#endif
};
@@ -146,7 +146,7 @@ struct dir_info {
size_t regions_total; /* number of region slots */
size_t regions_free;/* number of free slots */
size_t rbytesused; /* random bytes used */
- char *func; /* current function */
+ const char *func; /* current function */
int malloc_junk;/* junk fill? */
int mmap_flag; /* extra flag for mmap */
int mutex;
@@ -166,6 +166,7 @@ struct dir_info {
void *chunk_pages;
size_t chunk_pages_used;
#ifdef MALLOC_STATS
+ void *caller;
size_t inserts;
size_t insert_collisions;
size_t finds;
@@ -183,12 +184,16 @@ struct dir_info {
#define STATS_INC(x) ((x)++)
#define STATS_ZERO(x) ((x) = 0)
#define STATS_SETF(x,y)((x)->f = (y))
+#define
Re: CVS: cvs.openbsd.org: src
On 2023/10/09 14:55, Todd C. Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: mill...@cvs.openbsd.org 2023/10/09 14:55:33
>
> Modified files:
> usr.sbin/smtpd : smtp_session.c
>
> Log message:
> Add Message-Id as needed for messages received on the submission port.
>
> Since listener->port is in network byte order we need to compare
> against htons(587). The fix for this got dropped in the rewrite
> in revision 1.335.
Presumably 465 should be treated the same, though the hardcoded ports
don't feel entirely right here - this is presumably something that would
want adding for any connection which is allowed to relay ..
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.436
diff -u -p -r1.436 smtp_session.c
--- smtp_session.c 9 Oct 2023 20:55:32 - 1.436
+++ smtp_session.c 10 Oct 2023 09:41:05 -
@@ -2624,6 +2624,7 @@ smtp_tx_dataline(struct smtp_tx *tx, con
case RFC5322_END_OF_HEADERS:
if (tx->session->listener->local ||
+ tx->session->listener->port == htons(465) ||
tx->session->listener->port == htons(587)) {
if (!tx->has_date) {
Re: pf_pull_hdr useless action pointer and fragment logic
Hello, On Mon, Oct 09, 2023 at 08:07:35PM +0200, Alexander Bluhm wrote: > Hi, > > pf_pull_hdr() allows to pass an action pointer parameter as output > value. This is never used, all callers pass a NULL argument. Remove > ACTION_SET() entirely. > > The logic if (fragoff >= len) in pf_pull_hdr() looks odd. One is > the offset in the IP packet, the latter the length of some header > within the fragment. In revision 1.1 the logic was used to drop > short TCP or UDP fragments that contained only part of the header. > This does not work since pf_pull_hdr() supports offsets. > > > revision 1.4 > date: 2001/06/24 20:54:55; author: itojun; state: Exp; lines: +18 -16; > pull_hdr() now takes header offset explicitly, to help header chain parsing > (v6, ipsec) > > > The code drops the packets anyway, so always set reason PFRES_FRAG. > > ok? > yes, please. looks good to me. OK sashan
