Re: cwm: add fvwm and tvm as default wm entries
On Mon, May 15, 2023 at 09:42:47AM -0400, Bryan Steele wrote: > On Mon, May 15, 2023 at 09:17:00AM -0400, Okan Demirmen wrote: > > On Mon 2023.05.15 at 10:41 +0200, Matthieu Herrb wrote: > > > On Mon, May 15, 2023 at 06:26:41AM +, Klemens Nanni wrote: > > > > Both fvwm(1) and twm(1) have a restart menu that contains other window > > > > managers by default, which is useful if you want to switch around > > > > without restarting X and/or custom window manager config. > > > > > > > > cwm(1) only offers to restart into itself by deafult. > > > > Add the other two we ship by default so users can round trip between > > > > them. > > > > > > > > Feedback? OK? > > > > > > Last year I mentionned that I think we should retire twm. It's really > > > too old and missing support for the modern window managers hints. > > > > > > People still using it should switch to cwm or maybe ctwm from ports > > > (to keep the same configurarion system), or someone should step up to > > > maintain it and enhance it with exwmh support. (but this is somehow > > > just wasting time imho). I don't know anything about twm, so I'll leave that to others. > > > > > > Otherwise ok to add this and fix the other WM menus for other window > > > managers (those parts of the configs are already local changes in > > > Xenocara) > > > > I might argue the opposite, to remove cwm from fvwm and twm restart menus, > > if > > this inconsistency is a real concern. The entries in fvwm/twm are in the > > (shipped) example config files, where-as below it is, well, there for good > > with > > no user choice. Heck, how often to do people even use this restart wm to > > another WM outside of playing around? Most window managers handle restarts > > differently, regardless of what ICCCM/EWMH says) and even then, crossing > > window > > managers like this introduces inconsistencies. It's fine for playing around > > I > > suppose, but is it really a demanded "workflow"? It is convenient for testing because you keep all your windows and don't have to login out and in again; that's about it for me. > > > > PS: fwvm and twm menus more programs we don't ship, e.g. "wm2", and > > > > twm dies when failing to execute them (fvwm and cwm keeps running); > > > > do we want to keep those default-broken entries around? > > > > I'd support removing them. > > +1 > > I don't think hardcoding window managers into cwm makes sense. I don't > think anyone is actually switching around WMs at runtime like this. Except for cwm itself, since that's how you reload the cwmrc(5). No idea how fvwm(1) handles config reload and/or state across restart. > If the point is for new users to have an example that provides a list > of alternative WMs, perhaps this is a man page issue and they should > be added to "SEE ALSO" sections. Sure, these can't hurt. > > -Bryan. > I prefer consistency across base window managers, so if we don't want users to hop around by default, here's a tentative diff to remove foreign window managers from fvwm. Lef click -> Root Menu -> (Re)Start no lists xterm and fvm itself, the latter results in an appearent restart and a new FvwmPager process whilst 'fvwm -s' remains on the same PID (I don't use fvwm). There are multiple configs, I changed all containing cwm or twm. So something like this? Not touching twm (assuming it goes away) or cwm (needs itself for reload). Index: sample.fvwmrc/system.fvwm2rc === RCS file: /cvs/xenocara/app/fvwm/sample.fvwmrc/system.fvwm2rc,v retrieving revision 1.2 diff -u -p -r1.2 system.fvwm2rc --- sample.fvwmrc/system.fvwm2rc15 Aug 2019 16:15:04 - 1.2 +++ sample.fvwmrc/system.fvwm2rc16 May 2023 02:31:40 - @@ -196,13 +196,6 @@ AddToMenu Quit-Verify "Really Quit Fvwm + "Restart Fvwm2" Restart fvwm2 + "Restart Fvwm" Restart fvwm + "" Nop -+ "Start twm" Restart twm -+ "Start ctwm"Restart ctwm -+ "Start tvtwm" Restart tvtwm -+ "Start vtwm"Restart vtwm -+ "Start mwm" Restart mwm -+ "Start olwm"Restart /usr/openwin/bin/olwm -+ "" Nop + "Start dummy" Restart xterm + "" Nop + "No, Don't Quit"Nop Index: sample.fvwmrc/system.fvwm2rc-sample-1 === RCS file: /cvs/xenocara/app/fvwm/sample.fvwmrc/system.fvwm2rc-sample-1,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 system.fvwm2rc-sample-1 --- sample.fvwmrc/system.fvwm2rc-sample-1 26 Nov 2006 10:53:57 - 1.1.1.1 +++ sample.fvwmrc/system.fvwm2rc-sample-1 16 May 2023 02:21:06 - @@
Re: seperate LRO/TSO flags
On Mon, May 15, 2023 at 11:16:59PM +0200, Jan Klemkow wrote: > - updated the diff to the current source state > - improved the vlan(4) capability handling > > ok? OK bluhm@ > - "\11CSUM_UDPv6\17TSO\20WOL" > + "\11CSUM_UDPv6\15TSOv4\16TSOv6\17LSO\20WOL" typo s/LSO/LRO/
Re: Status of Virtual Function driver for Intel 82599 series port?
Hi.
Paul notified me that my previous patch was broken. I changed my mailer
to Mew on Emacs that sends a plain text mail without any modification.
I re-send my patch by Mew. Please try following patch. Thank you!
diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
index c8e4ec8284e..2ad357f9c1b 100644
--- a/sys/arch/amd64/conf/GENERIC
+++ b/sys/arch/amd64/conf/GENERIC
@@ -524,6 +524,7 @@ msk*at mskc?# each port of
above
em*at pci? # Intel Pro/1000 ethernet
ixgb* at pci? # Intel Pro/10Gb ethernet
ix*at pci? # Intel 82598EB 10Gb ethernet
+ixv* at pci? # Virtual Function of Intel 82598EB
myx* at pci? # Myricom Myri-10G 10Gb ethernet
oce* at pci? # Emulex OneConnect 10Gb ethernet
txp* at pci? # 3com 3CR990
diff --git a/sys/dev/pci/files.pci b/sys/dev/pci/files.pci
index 101ed502e76..72c8b485938 100644
--- a/sys/dev/pci/files.pci
+++ b/sys/dev/pci/files.pci
@@ -350,13 +350,19 @@ file dev/pci/ixgb_hw.c ixgb
# Intel 82598 10GbE
device ix: ether, ifnet, ifmedia, intrmap, stoeplitz
attach ix at pci
-file dev/pci/if_ix.c ix
-file dev/pci/ixgbe.c ix
-file dev/pci/ixgbe_82598.c ix
-file dev/pci/ixgbe_82599.c ix
-file dev/pci/ixgbe_x540.cix
-file dev/pci/ixgbe_x550.cix
-file dev/pci/ixgbe_phy.c ix
+file dev/pci/if_ix.c ix | ixv
+file dev/pci/ixgbe.c ix | ixv
+file dev/pci/ixgbe_82598.c ix | ixv
+file dev/pci/ixgbe_82599.c ix | ixv
+file dev/pci/ixgbe_x540.cix | ixv
+file dev/pci/ixgbe_x550.cix | ixv
+file dev/pci/ixgbe_phy.c ix | ixv
+
+# Virtual Function of i82599.
+device ixv: ether, ifnet, ifmedia, intrmap, stoeplitz
+attach ixv at pci
+file dev/pci/if_ixv.cixv
+file dev/pci/ixgbe_vf.c ixv
# Intel Ethernet 700 Series
device ixl: ether, ifnet, ifmedia, intrmap, stoeplitz
diff --git a/sys/dev/pci/if_ix.c b/sys/dev/pci/if_ix.c
index 870c3349fb3..24397a01a9d 100644
--- a/sys/dev/pci/if_ix.c
+++ b/sys/dev/pci/if_ix.c
@@ -507,7 +507,7 @@ ixgbe_start(struct ifqueue *ifq)
* hardware that this frame is available to transmit.
*/
if (post)
- IXGBE_WRITE_REG(>hw, IXGBE_TDT(txr->me),
+ IXGBE_WRITE_REG(>hw, txr->tail,
txr->next_avail_desc);
}
@@ -705,7 +705,7 @@ ixgbe_watchdog(struct ifnet * ifp)
for (i = 0; i < sc->num_queues; i++, txr++) {
printf("%s: Queue(%d) tdh = %d, hw tdt = %d\n", ifp->if_xname,
i,
IXGBE_READ_REG(hw, IXGBE_TDH(i)),
- IXGBE_READ_REG(hw, IXGBE_TDT(i)));
+ IXGBE_READ_REG(hw, sc->tx_rings[i].tail));
printf("%s: TX(%d) Next TX to Clean = %d\n", ifp->if_xname,
i, txr->next_to_clean);
}
@@ -825,7 +825,7 @@ ixgbe_init(void *arg)
msec_delay(1);
}
IXGBE_WRITE_FLUSH(>hw);
- IXGBE_WRITE_REG(>hw, IXGBE_RDT(i), rxr->last_desc_filled);
+ IXGBE_WRITE_REG(>hw, rxr[i].tail, rxr->last_desc_filled);
}
/* Set up VLAN support and filter */
@@ -2358,9 +2358,12 @@ ixgbe_initialize_transmit_units(struct ix_softc *sc)
IXGBE_WRITE_REG(hw, IXGBE_TDLEN(i),
sc->num_tx_desc * sizeof(struct ixgbe_legacy_tx_desc));
+ /* Set Tx Tail register */
+ txr->tail = IXGBE_TDT(i);
+
/* Setup the HW Tx Head and Tail descriptor pointers */
IXGBE_WRITE_REG(hw, IXGBE_TDH(i), 0);
- IXGBE_WRITE_REG(hw, IXGBE_TDT(i), 0);
+ IXGBE_WRITE_REG(hw, txr->tail, 0);
/* Setup Transmit Descriptor Cmd Settings */
txr->txd_cmd = IXGBE_TXD_CMD_IFCS;
@@ -2808,7 +2811,7 @@ ixgbe_rxrefill(void *xrxr)
if (ixgbe_rxfill(rxr)) {
/* Advance the Rx Queue "Tail Pointer" */
- IXGBE_WRITE_REG(>hw, IXGBE_RDT(rxr->me),
+ IXGBE_WRITE_REG(>hw, rxr->tail,
rxr->last_desc_filled);
} else if (if_rxr_inuse(>rx_ring) == 0)
timeout_add(>rx_refill, 1);
@@ -2902,6 +2905,9 @@ ixgbe_initialize_receive_units(struct ix_softc *sc)
srrctl = bufsz | IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl);
+ /* Capture Rx Tail index */
+ rxr->tail = IXGBE_RDT(i);
+
if (ISSET(ifp->if_xflags, IFXF_TSO)) {
rdrxctl = IXGBE_READ_REG(>hw, IXGBE_RSCCTL(i));
@@ -2914,7 +2920,7 @@ ixgbe_initialize_receive_units(struct
Re: seperate LRO/TSO flags
On Mon, May 15, 2023 at 11:40:20AM +0200, Alexander Bluhm wrote:
> On Mon, May 15, 2023 at 09:34:21AM +0200, Jan Klemkow wrote:
> > @@ -251,12 +251,16 @@ struct if_status_description {
> > #defineIFCAP_VLAN_HWTAGGING0x0020 /* hardware VLAN tag
> > support */
> > #defineIFCAP_CSUM_TCPv60x0080 /* can do IPv6/TCP
> > checksums */
> > #defineIFCAP_CSUM_UDPv60x0100 /* can do IPv6/UDP
> > checksums */
> > -#defineIFCAP_TSO 0x4000 /* TCP segment
> > offloading */
> > +#defineIFCAP_LRO 0x1000 /* TCP large recv
> > offload */
> > +#defineIFCAP_TSOv4 0x2000 /* TCP segmentation
> > offload */
> > +#defineIFCAP_TSOv6 0x4000 /* TCP segmentation
> > offload */
> > #defineIFCAP_WOL 0x8000 /* can do wake on lan */
>
> I would prefer to keep the numbers of IFCAP_TSO/IFCAP_LRO as this
> is just a naming error. Then we have less confusion during the
> ifconfig transition phase.
>
> +#define IFCAP_TSOv4 0x1000
> +#define IFCAP_TSOv6 0x2000
> -#define IFCAP_TSO0x4000
> +#define IFCAP_LRO0x4000
>
> > +#define IFCAP_TSO (IFCAP_TSOv4 | IFCAP_TSOv6)
> > +
>
> Could you please remove this chunk and expand it, where is used?
> This one more define does not make the code clearer. And this flag
> IFCAP_TSO had a different meaning before renaming. When it is not
> introduced again, the compiler makes sure that no renaming was
> forgotten.
done
Also:
- updated the diff to the current source state
- improved the vlan(4) capability handling
@dlg: Whats your opinion about this diff?
ok?
Thanks,
Jan
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.394
diff -u -p -r1.394 ifconfig.8
--- sbin/ifconfig/ifconfig.826 Apr 2023 02:38:08 - 1.394
+++ sbin/ifconfig/ifconfig.815 May 2023 18:46:48 -
@@ -282,8 +282,18 @@ tag.
As CSUM_TCPv4, but supports IPv6 datagrams.
.It Sy CSUM_UDPv6
As above, for UDP.
-.It Sy TSO
-The device supports TCP segment offloading (TSO).
+.It Sy LRO
+The device supports TCP large receive offload (LRO).
+.It Sy TSOv4
+The device supports IPv4 TCP segmentation offload (TSO).
+TSO is used by default.
+Use the
+.Xr sysctl 8
+variable
+.Va net.inet.tcp.tso
+to disable this feature.
+.It Sy TSOv6
+As above, for IPv6.
.It Sy WOL
The device supports Wake on LAN (WoL).
.It Sy hardmtu
@@ -491,25 +501,25 @@ Query and display information and diagno
modules installed in an interface.
It is only supported by drivers implementing the necessary functionality
on hardware which supports it.
-.It Cm tso
-Enable TCP segmentation offloading (TSO) if it's supported by the hardware; see
+.It Cm tcprecvoffload
+Enable TCP large receive offload (LRO) if it's supported by the hardware; see
.Cm hwfeatures .
-TSO enabled NICs modify received TCP/IP packets.
+LRO enabled network interfaces modify received TCP/IP packets.
This will also affect traffic of upper layer interfaces,
such as
.Xr vlan 4 ,
.Xr aggr 4 ,
and
.Xr carp 4 .
-It is not possible to use TSO with interfaces attached to a
+It is not possible to use LRO with interfaces attached to a
.Xr bridge 4 ,
.Xr veb 4 ,
or
.Xr tpmr 4 .
Changing this option will re-initialize the network interface.
-.It Cm -tso
-Disable TSO.
-TSO is disabled by default.
+.It Cm -tcprecvoffload
+Disable LRO.
+LRO is disabled by default.
.It Cm up
Mark an interface
.Dq up .
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.463
diff -u -p -r1.463 ifconfig.c
--- sbin/ifconfig/ifconfig.c12 May 2023 18:24:13 - 1.463
+++ sbin/ifconfig/ifconfig.c15 May 2023 20:27:51 -
@@ -126,7 +126,7 @@
#define HWFEATURESBITS \
"\024\1CSUM_IPv4\2CSUM_TCPv4\3CSUM_UDPv4" \
"\5VLAN_MTU\6VLAN_HWTAGGING\10CSUM_TCPv6" \
- "\11CSUM_UDPv6\17TSO\20WOL"
+ "\11CSUM_UDPv6\15TSOv4\16TSOv6\17LSO\20WOL"
struct ifencap {
unsigned int ife_flags;
@@ -469,8 +469,8 @@ const structcmd {
{ "-soii", IFXF_INET6_NOSOII, 0, setifxflags },
{ "monitor",IFXF_MONITOR, 0, setifxflags },
{ "-monitor", -IFXF_MONITOR, 0, setifxflags },
- { "tso",IFXF_TSO, 0, setifxflags },
- { "-tso", -IFXF_TSO, 0, setifxflags },
+ { "tcprecvoffload", IFXF_LRO, 0, setifxflags },
+ { "-tcprecvoffload", -IFXF_LRO, 0, setifxflags },
#ifndef SMALL
{ "hwfeatures", NEXTARG0, 0, printifhwfeatures },
{ "metric",
Re: ix hardware tso
On Sun, May 14, 2023 at 11:39:01PM +0200, Hrvoje Popovski wrote:
> I've tested this on openbsd box with 4 iperf3's. 2 for ip4 and 2 for ip6
> and with 16 tcp streams per iperf. When testing over ix(4) there is big
> differences in output performance. When testing ix/veb/vport there is
> differences in output performance but not that big.
Thanks a lot for testing. I have also created some numbers which
can be seen here.
http://bluhm.genua.de/perform/results/2023-05-14T09:14:59Z/perform.html
Sending TCP to Linux host and socket splicing gets faster.
> When testing over vport I'm getting "software chopped" which should be
> expected.
Yes, we cannot do hardware TSO in a bridge. Maybe we could if all
bridge members support it.
Next diff that should go in is where jan@ renames flags, cleans up
ifconfig(8), and fixes pseudo interface devices.
Updated ix(4) driver diff after TCP/IP commit is below.
bluhm
Index: dev/pci/if_ix.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.193
diff -u -p -r1.193 if_ix.c
--- dev/pci/if_ix.c 28 Apr 2023 10:18:57 - 1.193
+++ dev/pci/if_ix.c 15 May 2023 17:27:09 -
@@ -1924,8 +1924,9 @@ ixgbe_setup_interface(struct ix_softc *s
ifp->if_capabilities |= IFCAP_CSUM_TCPv6 | IFCAP_CSUM_UDPv6;
ifp->if_capabilities |= IFCAP_CSUM_IPv4;
+ ifp->if_capabilities |= IFCAP_TSOv4 | IFCAP_TSOv6;
if (sc->hw.mac.type != ixgbe_mac_82598EB)
- ifp->if_capabilities |= IFCAP_TSO;
+ ifp->if_capabilities |= IFCAP_LRO;
/*
* Specify the media types supported by this sc and register
@@ -2344,6 +2345,7 @@ ixgbe_initialize_transmit_units(struct i
int i;
uint64_t tdba;
uint32_t txctrl;
+ uint32_t hlreg;
/* Setup the Base and Length of the Tx Descriptor Ring */
@@ -2405,6 +2407,11 @@ ixgbe_initialize_transmit_units(struct i
rttdcs &= ~IXGBE_RTTDCS_ARBDIS;
IXGBE_WRITE_REG(hw, IXGBE_RTTDCS, rttdcs);
}
+
+ /* Enable TCP/UDP padding when using TSO */
+ hlreg = IXGBE_READ_REG(hw, IXGBE_HLREG0);
+ hlreg |= IXGBE_HLREG0_TXPADEN;
+ IXGBE_WRITE_REG(hw, IXGBE_HLREG0, hlreg);
}
/*
@@ -2473,16 +2480,18 @@ ixgbe_free_transmit_buffers(struct tx_ri
**/
static inline int
-ixgbe_csum_offload(struct mbuf *mp, uint32_t *vlan_macip_lens,
-uint32_t *type_tucmd_mlhl, uint32_t *olinfo_status)
+ixgbe_tx_offload(struct mbuf *mp, uint32_t *vlan_macip_lens,
+uint32_t *type_tucmd_mlhl, uint32_t *olinfo_status, uint32_t *cmd_type_len,
+uint32_t *mss_l4len_idx)
{
struct ether_extracted ext;
int offload = 0;
- uint32_t iphlen;
+ uint32_t ethlen, iphlen;
ether_extract_headers(mp, );
+ ethlen = sizeof(*ext.eh);
- *vlan_macip_lens |= (sizeof(*ext.eh) << IXGBE_ADVTXD_MACLEN_SHIFT);
+ *vlan_macip_lens |= (ethlen << IXGBE_ADVTXD_MACLEN_SHIFT);
if (ext.ip4) {
iphlen = ext.ip4->ip_hl << 2;
@@ -2500,6 +2509,8 @@ ixgbe_csum_offload(struct mbuf *mp, uint
*type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV6;
#endif
} else {
+ if (mp->m_pkthdr.csum_flags & M_TCP_TSO)
+ tcpstat_inc(tcps_outbadtso);
return offload;
}
@@ -2519,6 +2530,32 @@ ixgbe_csum_offload(struct mbuf *mp, uint
}
}
+ if (mp->m_pkthdr.csum_flags & M_TCP_TSO) {
+ if (ext.tcp) {
+ uint32_t pktlen, hdrlen, thlen, outlen;
+
+ thlen = ext.tcp->th_off << 2;
+
+ *mss_l4len_idx |= (uint32_t)(mp->m_pkthdr.ph_mss
+ << IXGBE_ADVTXD_MSS_SHIFT);
+ *mss_l4len_idx |= thlen << IXGBE_ADVTXD_L4LEN_SHIFT;
+
+ hdrlen = ethlen + iphlen + thlen;
+ pktlen = mp->m_pkthdr.len - hdrlen;
+ CLR(*olinfo_status, IXGBE_ADVTXD_PAYLEN_MASK
+ << IXGBE_ADVTXD_PAYLEN_SHIFT);
+ *olinfo_status |= pktlen << IXGBE_ADVTXD_PAYLEN_SHIFT;
+
+ *cmd_type_len |= IXGBE_ADVTXD_DCMD_TSE;
+ offload = 1;
+
+ outlen = hdrlen + mp->m_pkthdr.ph_mss;
+ tcpstat_add(tcps_outpkttso,
+ (pktlen + outlen - 1) / outlen);
+ } else
+ tcpstat_inc(tcps_outbadtso);
+ }
+
return offload;
}
@@ -2529,6 +2566,7 @@ ixgbe_tx_ctx_setup(struct tx_ring *txr,
struct ixgbe_adv_tx_context_desc *TXD;
struct ixgbe_tx_buf *tx_buffer;
uint32_t
OpenBSD Errata: Mai 16, 2023 (bgpd)
An errata patch for bgpd and bgpctl has been released for OpenBSD 7.3. Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata73.html
user: simplify memsave() to strsave()
All the callers of memsave() pass strlen(s) as the size argument.
We can eliminate the size argument and just use strdup(3) instead.
OK?
- todd
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.128
diff -u -p -u -r1.128 user.c
--- user.c 17 Oct 2019 21:54:29 - 1.128
+++ user.c 15 May 2023 16:05:40 -
@@ -200,20 +200,18 @@ static size_t expand_len(const char *, c
static struct group *find_group_info(const char *);
static struct passwd *find_user_info(const char *);
static void checkeuid(void);
-static void memsave(char **, const char *, size_t);
+static void strsave(char **, const char *);
static void read_defaults(user_t *);
static int verbose;
-/* if *cpp is non-null, free it, then assign `n' chars of `s' to it */
+/* free *cpp, then strdup `s' to it */
static void
-memsave(char **cpp, const char *s, size_t n)
+strsave(char **cpp, const char *s)
{
free(*cpp);
- if ((*cpp = calloc (n + 1, sizeof(char))) == NULL)
+ if ((*cpp = strdup(s)) == NULL)
err(1, NULL);
- memcpy(*cpp, s, n);
- (*cpp)[n] = '\0';
}
/* a replacement for system(3) */
@@ -788,12 +786,12 @@ read_defaults(user_t *up)
unsigned char *cp;
unsigned char *s;
- memsave(>u_primgrp, DEF_GROUP, strlen(DEF_GROUP));
- memsave(>u_basedir, DEF_BASEDIR, strlen(DEF_BASEDIR));
- memsave(>u_skeldir, DEF_SKELDIR, strlen(DEF_SKELDIR));
- memsave(>u_shell, DEF_SHELL, strlen(DEF_SHELL));
- memsave(>u_comment, DEF_COMMENT, strlen(DEF_COMMENT));
- memsave(>u_class, DEF_CLASS, strlen(DEF_CLASS));
+ strsave(>u_primgrp, DEF_GROUP);
+ strsave(>u_basedir, DEF_BASEDIR);
+ strsave(>u_skeldir, DEF_SKELDIR);
+ strsave(>u_shell, DEF_SHELL);
+ strsave(>u_comment, DEF_COMMENT);
+ strsave(>u_class, DEF_CLASS);
up->u_rsize = 16;
up->u_defrc = 0;
if ((up->u_rv = calloc(up->u_rsize, sizeof(range_t))) == NULL)
@@ -811,27 +809,27 @@ read_defaults(user_t *up)
if (strncmp(s, "group", 5) == 0) {
for (cp = s + 5 ; isspace((unsigned char)*cp);
cp++) {
}
- memsave(>u_primgrp, cp, strlen(cp));
+ strsave(>u_primgrp, cp);
} else if (strncmp(s, "base_dir", 8) == 0) {
for (cp = s + 8 ; isspace((unsigned char)*cp);
cp++) {
}
- memsave(>u_basedir, cp, strlen(cp));
+ strsave(>u_basedir, cp);
} else if (strncmp(s, "skel_dir", 8) == 0) {
for (cp = s + 8 ; isspace((unsigned char)*cp);
cp++) {
}
- memsave(>u_skeldir, cp, strlen(cp));
+ strsave(>u_skeldir, cp);
} else if (strncmp(s, "shell", 5) == 0) {
for (cp = s + 5 ; isspace((unsigned char)*cp);
cp++) {
}
- memsave(>u_shell, cp, strlen(cp));
+ strsave(>u_shell, cp);
} else if (strncmp(s, "password", 8) == 0) {
for (cp = s + 8 ; isspace((unsigned char)*cp);
cp++) {
}
- memsave(>u_password, cp, strlen(cp));
+ strsave(>u_password, cp);
} else if (strncmp(s, "class", 5) == 0) {
for (cp = s + 5 ; isspace((unsigned char)*cp);
cp++) {
}
- memsave(>u_class, cp, strlen(cp));
+ strsave(>u_class, cp);
} else if (strncmp(s, "inactive", 8) == 0) {
for (cp = s + 8 ; isspace((unsigned char)*cp);
cp++) {
}
@@ -839,7 +837,7 @@ read_defaults(user_t *up)
free(up->u_inactive);
up->u_inactive = NULL;
} else {
- memsave(>u_inactive, cp,
strlen(cp));
+ strsave(>u_inactive, cp);
}
} else if (strncmp(s, "range", 5) == 0) {
for (cp = s + 5 ; isspace((unsigned char)*cp);
cp++) {
@@ -858,7 +856,7 @@ read_defaults(user_t *up)
free(up->u_expire);
up->u_expire = NULL;
} else {
-
Re: cwm: add fvwm and tvm as default wm entries
On Mon, May 15, 2023 at 09:17:00AM -0400, Okan Demirmen wrote: > On Mon 2023.05.15 at 10:41 +0200, Matthieu Herrb wrote: > > On Mon, May 15, 2023 at 06:26:41AM +, Klemens Nanni wrote: > > > Both fvwm(1) and twm(1) have a restart menu that contains other window > > > managers by default, which is useful if you want to switch around > > > without restarting X and/or custom window manager config. > > > > > > cwm(1) only offers to restart into itself by deafult. > > > Add the other two we ship by default so users can round trip between > > > them. > > > > > > Feedback? OK? > > > > Last year I mentionned that I think we should retire twm. It's really > > too old and missing support for the modern window managers hints. > > > > People still using it should switch to cwm or maybe ctwm from ports > > (to keep the same configurarion system), or someone should step up to > > maintain it and enhance it with exwmh support. (but this is somehow > > just wasting time imho). > > > > Otherwise ok to add this and fix the other WM menus for other window > > managers (those parts of the configs are already local changes in > > Xenocara) > > I might argue the opposite, to remove cwm from fvwm and twm restart menus, if > this inconsistency is a real concern. The entries in fvwm/twm are in the > (shipped) example config files, where-as below it is, well, there for good > with > no user choice. Heck, how often to do people even use this restart wm to > another WM outside of playing around? Most window managers handle restarts > differently, regardless of what ICCCM/EWMH says) and even then, crossing > window > managers like this introduces inconsistencies. It's fine for playing around I > suppose, but is it really a demanded "workflow"? > > > > > > > PS: fwvm and twm menus more programs we don't ship, e.g. "wm2", and > > > twm dies when failing to execute them (fvwm and cwm keeps running); > > > do we want to keep those default-broken entries around? > > I'd support removing them. +1 I don't think hardcoding window managers into cwm makes sense. I don't think anyone is actually switching around WMs at runtime like this. If the point is for new users to have an example that provides a list of alternative WMs, perhaps this is a man page issue and they should be added to "SEE ALSO" sections. -Bryan.
Re: smtpd: nits to reduce the diff with -portable
On 2023/05/15 07:34:03 -0600, "Todd C. Miller" wrote: > On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote: > > > almost always (cast)var. I've adjusted the spacing in the line I was > > touching, grepping for common types I could only find one instance of > > a '(long long) src' in envelope.c which I'm not addressing here. > > OK millert@. Sorry, as soon as I got an ok offlist from tb@ I went ahead since it was just cosmetic. I noticed I'm too in a hurry recently when committing diffs, so i'll make sure to wait more in the future. > It would be nice to get these changes in portable > as well to avoid gratuitous differences. I'll take care of sync'ing with -portable. Thanks,
Re: smtpd: nits to reduce the diff with -portable
May 15, 2023 3:34 PM, "Todd C. Miller" wrote: > On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote: > >> almost always (cast)var. I've adjusted the spacing in the line I was >> touching, grepping for common types I could only find one instance of >> a '(long long) src' in envelope.c which I'm not addressing here. > > OK millert@. It would be nice to get these changes in portable > as well to avoid gratuitous differences. > FYI, I've granted Omar commit access to the portable repo so he can make syncs on his own and limit differences with OpenBSD.
Re: smtpd: nits to reduce the diff with -portable
On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote: > almost always (cast)var. I've adjusted the spacing in the line I was > touching, grepping for common types I could only find one instance of > a '(long long) src' in envelope.c which I'm not addressing here. OK millert@. It would be nice to get these changes in portable as well to avoid gratuitous differences. - todd
Re: cwm: add fvwm and tvm as default wm entries
On Mon 2023.05.15 at 10:41 +0200, Matthieu Herrb wrote: > On Mon, May 15, 2023 at 06:26:41AM +, Klemens Nanni wrote: > > Both fvwm(1) and twm(1) have a restart menu that contains other window > > managers by default, which is useful if you want to switch around > > without restarting X and/or custom window manager config. > > > > cwm(1) only offers to restart into itself by deafult. > > Add the other two we ship by default so users can round trip between > > them. > > > > Feedback? OK? > > Last year I mentionned that I think we should retire twm. It's really > too old and missing support for the modern window managers hints. > > People still using it should switch to cwm or maybe ctwm from ports > (to keep the same configurarion system), or someone should step up to > maintain it and enhance it with exwmh support. (but this is somehow > just wasting time imho). > > Otherwise ok to add this and fix the other WM menus for other window > managers (those parts of the configs are already local changes in > Xenocara) I might argue the opposite, to remove cwm from fvwm and twm restart menus, if this inconsistency is a real concern. The entries in fvwm/twm are in the (shipped) example config files, where-as below it is, well, there for good with no user choice. Heck, how often to do people even use this restart wm to another WM outside of playing around? Most window managers handle restarts differently, regardless of what ICCCM/EWMH says) and even then, crossing window managers like this introduces inconsistencies. It's fine for playing around I suppose, but is it really a demanded "workflow"? > > > > PS: fwvm and twm menus more programs we don't ship, e.g. "wm2", and > > twm dies when failing to execute them (fvwm and cwm keeps running); > > do we want to keep those default-broken entries around? I'd support removing them.
Re: smtpd: nits to reduce the diff with -portable
On 2023/05/15 09:40:50 +0200, theo Buehler wrote:
> Do we care that sometimes we (cast)var and sometimes we (cast) var?
> Is this at least consistent per-file?
almost always (cast)var. I've adjusted the spacing in the line I was
touching, grepping for common types I could only find one instance of
a '(long long) src' in envelope.c which I'm not addressing here.
Index: libexec/mail.local/mail.local.c
===
RCS file: /cvs/src/libexec/mail.local/mail.local.c,v
retrieving revision 1.40
diff -u -p -r1.40 mail.local.c
--- libexec/mail.local/mail.local.c 10 May 2023 08:03:49 - 1.40
+++ libexec/mail.local/mail.local.c 15 May 2023 06:59:09 -
@@ -244,7 +244,7 @@ retry:
curoff = lseek(mbfd, 0, SEEK_END);
(void)snprintf(biffmsg, sizeof biffmsg, "%s@%lld\n", name,
- (long long int)curoff);
+ (long long)curoff);
if (lseek(fd, 0, SEEK_SET) == (off_t)-1) {
mwarn("temporary file: %s", strerror(errno));
goto bad;
Index: usr.sbin/smtpd/bounce.c
===
RCS file: /cvs/src/usr.sbin/smtpd/bounce.c,v
retrieving revision 1.88
diff -u -p -r1.88 bounce.c
--- usr.sbin/smtpd/bounce.c 4 May 2023 12:43:44 - 1.88
+++ usr.sbin/smtpd/bounce.c 15 May 2023 06:59:29 -
@@ -305,7 +305,7 @@ bounce_send(struct bounce_session *s, co
}
static const char *
-bounce_duration(long long int d)
+bounce_duration(long long d)
{
static char buf[32];
Index: usr.sbin/smtpd/lka_filter.c
===
RCS file: /cvs/src/usr.sbin/smtpd/lka_filter.c,v
retrieving revision 1.69
diff -u -p -r1.69 lka_filter.c
--- usr.sbin/smtpd/lka_filter.c 10 May 2023 07:20:20 - 1.69
+++ usr.sbin/smtpd/lka_filter.c 15 May 2023 06:59:29 -
@@ -933,13 +933,13 @@ filter_protocol_query(struct filter *fil
n = io_printf(lka_proc_get_io(filter->proc),
"filter|%s|%lld.%06ld|smtp-in|%s|%016"PRIx64"|%016"PRIx64"|%s|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
phase, reqid, token, fs->rdns, param);
else
n = io_printf(lka_proc_get_io(filter->proc),
"filter|%s|%lld.%06ld|smtp-in|%s|%016"PRIx64"|%016"PRIx64"|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
phase, reqid, token, param);
if (n == -1)
fatalx("failed to write to processor");
@@ -957,7 +957,7 @@ filter_data_query(struct filter *filter,
"filter|%s|%lld.%06ld|smtp-in|data-line|"
"%016"PRIx64"|%016"PRIx64"|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
reqid, token, line);
if (n == -1)
fatalx("failed to write to processor");
@@ -1374,7 +1374,7 @@ report_smtp_broadcast(uint64_t reqid, co
va_start(ap, format);
if (io_printf(lka_proc_get_io(rp->name),
"report|%s|%lld.%06ld|%s|%s|%016"PRIx64"%s",
- PROTOCOL_VERSION, (long long int)tv->tv_sec, tv->tv_usec,
+ PROTOCOL_VERSION, (long long)tv->tv_sec, tv->tv_usec,
direction, event, reqid,
format[0] != '\n' ? "|" : "") == -1 ||
io_vprintf(lka_proc_get_io(rp->name), format, ap) == -1)
Index: usr.sbin/smtpd/mail.maildir.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mail.maildir.c,v
retrieving revision 1.16
diff -u -p -r1.16 mail.maildir.c
--- usr.sbin/smtpd/mail.maildir.c 10 May 2023 07:19:49 - 1.16
+++ usr.sbin/smtpd/mail.maildir.c 15 May 2023 11:46:03 -
@@ -171,7 +171,7 @@ maildir_engine(const char *dirname, int
(void)strlcpy(hostname, "localhost", sizeof hostname);
(void)snprintf(filename, sizeof filename, "%lld.%08x.%s",
- (long long int) time(NULL),
+ (long long)time(NULL),
arc4random(),
hostname);
Index: usr.sbin/smtpd/mta_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mta_session.c,v
retrieving revision 1.147
diff -u -p -r1.147 mta_session.c
--- usr.sbin/smtpd/mta_session.c26 Sep 2022 08:48:52 - 1.147
+++ usr.sbin/smtpd/mta_session.c15 May 2023 06:59:30 -
@@ -1157,7 +1157,7 @@ mta_response(struct mta_session *s, char
s->rcptcount = 0;
if (s->relay->limits->sessdelay_transaction) {
pfsync(4) must protect state with mutex
Hello,
diff below has been posted to bugs@ ~week [1] ago. Diff fixes long lasting
issue I was scratching my head around for several months.
Recently I've shared my itch with bluhm@ who pointed out that `sc_st_mtx`
mutex is not sufficient protection. We also need to grab pf_state::mtx
when inserting/removing/moving particular state on sync queues.
diff below makes sure pfsync always grab a pf_state::mtx when it
moves state around its queues.
Hrvoje confirms diff fixes panic he was able to induce on his
test bed under stress load.
OK to commit?
thanks and
regards
sashan
[1] https://marc.info/?l=openbsd-bugs=168367101726447=2
8<---8<---8<--8<
diff --git a/sys/net/if_pfsync.c b/sys/net/if_pfsync.c
index 822b4211d0f..811d9d59666 100644
--- a/sys/net/if_pfsync.c
+++ b/sys/net/if_pfsync.c
@@ -1362,14 +1362,17 @@ pfsync_grab_snapshot(struct pfsync_snapshot *sn, struct
pfsync_softc *sc)
while ((st = TAILQ_FIRST(>sc_qs[q])) != NULL) {
TAILQ_REMOVE(>sc_qs[q], st, sync_list);
+ mtx_enter(>mtx);
if (st->snapped == 0) {
TAILQ_INSERT_TAIL(>sn_qs[q], st, sync_snap);
st->snapped = 1;
+ mtx_leave(>mtx);
} else {
/*
* item is on snapshot list already, so we can
* skip it now.
*/
+ mtx_leave(>mtx);
pf_state_unref(st);
}
}
@@ -1422,11 +1425,13 @@ pfsync_drop_snapshot(struct pfsync_snapshot *sn)
continue;
while ((st = TAILQ_FIRST(>sn_qs[q])) != NULL) {
+ mtx_enter(>mtx);
KASSERT(st->sync_state == q);
KASSERT(st->snapped == 1);
TAILQ_REMOVE(>sn_qs[q], st, sync_snap);
st->sync_state = PFSYNC_S_NONE;
st->snapped = 0;
+ mtx_leave(>mtx);
pf_state_unref(st);
}
}
@@ -1665,6 +1670,7 @@ pfsync_sendout(void)
count = 0;
while ((st = TAILQ_FIRST(_qs[q])) != NULL) {
+ mtx_enter(>mtx);
TAILQ_REMOVE(_qs[q], st, sync_snap);
KASSERT(st->sync_state == q);
KASSERT(st->snapped == 1);
@@ -1672,6 +1678,7 @@ pfsync_sendout(void)
st->snapped = 0;
pfsync_qs[q].write(st, m->m_data + offset);
offset += pfsync_qs[q].len;
+ mtx_leave(>mtx);
pf_state_unref(st);
count++;
@@ -1725,8 +1732,6 @@ pfsync_insert_state(struct pf_state *st)
ISSET(st->state_flags, PFSTATE_NOSYNC))
return;
- KASSERT(st->sync_state == PFSYNC_S_NONE);
-
if (sc->sc_len == PFSYNC_MINPKT)
timeout_add_sec(>sc_tmo, 1);
@@ -2221,6 +2226,7 @@ pfsync_q_ins(struct pf_state *st, int q)
panic("pfsync pkt len is too low %zd", sc->sc_len);
do {
mtx_enter(>sc_st_mtx);
+ mtx_enter(>mtx);
/*
* There are either two threads trying to update the
@@ -2228,6 +2234,7 @@ pfsync_q_ins(struct pf_state *st, int q)
* (is on snapshot queue).
*/
if (st->sync_state != PFSYNC_S_NONE) {
+ mtx_leave(>mtx);
mtx_leave(>sc_st_mtx);
break;
}
@@ -2240,6 +2247,7 @@ pfsync_q_ins(struct pf_state *st, int q)
sclen = atomic_add_long_nv(>sc_len, nlen);
if (sclen > sc->sc_if.if_mtu) {
atomic_sub_long(>sc_len, nlen);
+ mtx_leave(>mtx);
mtx_leave(>sc_st_mtx);
pfsync_sendout();
continue;
@@ -2249,6 +2257,7 @@ pfsync_q_ins(struct pf_state *st, int q)
TAILQ_INSERT_TAIL(>sc_qs[q], st, sync_list);
st->sync_state = q;
+ mtx_leave(>mtx);
mtx_leave(>sc_st_mtx);
} while (0);
}
@@ -2260,6 +2269,7 @@ pfsync_q_del(struct pf_state *st)
int q;
mtx_enter(>sc_st_mtx);
+ mtx_enter(>mtx);
q = st->sync_state;
/*
* re-check under mutex
@@ -2267,6 +2277,7 @@ pfsync_q_del(struct pf_state *st)
* too late, the state is being just processed/dispatched to peer.
*/
if ((q == PFSYNC_S_NONE) || (st->snapped)) {
+ mtx_leave(>mtx);
Re: calendar.usholiday: add Juneteenth
ok. jmc On 15 May 2023 09:58:29 BST, "Anthony J. Bentley" wrote: >A federal holiday since 2021. > >ok? > >Index: usr.bin/calendar/calendars/calendar.usholiday >=== >RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.usholiday,v >retrieving revision 1.9 >diff -u -p -r1.9 calendar.usholiday >--- usr.bin/calendar/calendars/calendar.usholiday 19 Jan 2015 18:07:47 >- 1.9 >+++ usr.bin/calendar/calendars/calendar.usholiday 15 May 2023 08:51:58 >- >@@ -22,6 +22,7 @@ > 05/SatThird Armed Forces Day (3rd Saturday of May) > 05/MonLastMemorial Day (Last Monday of May) > 06/SunThird Father's Day (3rd Sunday of June) >+06/19 Juneteenth > 06/21*Summer Solstice > 07/04 Independence Day > 09/MonFirst Labor Day (1st Monday of September) >
Re: seperate LRO/TSO flags
On Mon, May 15, 2023 at 09:34:21AM +0200, Jan Klemkow wrote:
> @@ -251,12 +251,16 @@ struct if_status_description {
> #define IFCAP_VLAN_HWTAGGING0x0020 /* hardware VLAN tag
> support */
> #define IFCAP_CSUM_TCPv60x0080 /* can do IPv6/TCP
> checksums */
> #define IFCAP_CSUM_UDPv60x0100 /* can do IPv6/UDP
> checksums */
> -#define IFCAP_TSO 0x4000 /* TCP segment
> offloading */
> +#define IFCAP_LRO 0x1000 /* TCP large recv
> offload */
> +#define IFCAP_TSOv4 0x2000 /* TCP segmentation
> offload */
> +#define IFCAP_TSOv6 0x4000 /* TCP segmentation
> offload */
> #define IFCAP_WOL 0x8000 /* can do wake on lan */
I would prefer to keep the numbers of IFCAP_TSO/IFCAP_LRO as this
is just a naming error. Then we have less confusion during the
ifconfig transition phase.
+#define IFCAP_TSOv40x1000
+#define IFCAP_TSOv60x2000
-#define IFCAP_TSO 0x4000
+#define IFCAP_LRO 0x4000
> +#define IFCAP_TSO(IFCAP_TSOv4 | IFCAP_TSOv6)
> +
Could you please remove this chunk and expand it, where is used?
This one more define does not make the code clearer. And this flag
IFCAP_TSO had a different meaning before renaming. When it is not
introduced again, the compiler makes sure that no renaming was
forgotten.
bluhm
Re: hardware TSO TCP/IP layer
Hello, I see tcp_dochopper() got committed already... anyway changes here look good. I have no objection. OK sashan
calendar.usholiday: add Juneteenth
A federal holiday since 2021. ok? Index: usr.bin/calendar/calendars/calendar.usholiday === RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.usholiday,v retrieving revision 1.9 diff -u -p -r1.9 calendar.usholiday --- usr.bin/calendar/calendars/calendar.usholiday 19 Jan 2015 18:07:47 - 1.9 +++ usr.bin/calendar/calendars/calendar.usholiday 15 May 2023 08:51:58 - @@ -22,6 +22,7 @@ 05/SatThirdArmed Forces Day (3rd Saturday of May) 05/MonLast Memorial Day (Last Monday of May) 06/SunThirdFather's Day (3rd Sunday of June) +06/19 Juneteenth 06/21* Summer Solstice 07/04 Independence Day 09/MonFirstLabor Day (1st Monday of September)
Re: ix hardware tso
Claudio Jeker wrote: > > > Do not set ifconfig ix tso, this flag does not work correctly. > > > > Are there plans for that flag? Remove it? Use it? Only document as > > deprecated? Also print a deprecation message if used? > > It will be removed. No need to overcomplicate it with deprecation message. Perfect - thanks! I just found the removal in Jan's patch. //Peter
Re: ix hardware tso
On Mon, May 15, 2023 at 08:42:20AM +, Peter Stuge wrote: > Alexander Bluhm wrote: > > Do not set ifconfig ix tso, this flag does not work correctly. > > Are there plans for that flag? Remove it? Use it? Only document as > deprecated? Also print a deprecation message if used? It will be removed. No need to overcomplicate it with deprecation message. -- :wq Claudio
Re: ix hardware tso
Alexander Bluhm wrote: > Do not set ifconfig ix tso, this flag does not work correctly. Are there plans for that flag? Remove it? Use it? Only document as deprecated? Also print a deprecation message if used? Thanks //Peter
Re: cwm: add fvwm and tvm as default wm entries
On Mon, May 15, 2023 at 06:26:41AM +, Klemens Nanni wrote:
> Both fvwm(1) and twm(1) have a restart menu that contains other window
> managers by default, which is useful if you want to switch around
> without restarting X and/or custom window manager config.
>
> cwm(1) only offers to restart into itself by deafult.
> Add the other two we ship by default so users can round trip between
> them.
>
> Feedback? OK?
Last year I mentionned that I think we should retire twm. It's really
too old and missing support for the modern window managers hints.
People still using it should switch to cwm or maybe ctwm from ports
(to keep the same configurarion system), or someone should step up to
maintain it and enhance it with exwmh support. (but this is somehow
just wasting time imho).
Otherwise ok to add this and fix the other WM menus for other window
managers (those parts of the configs are already local changes in
Xenocara)
>
> PS: fwvm and twm menus more programs we don't ship, e.g. "wm2", and
> twm dies when failing to execute them (fvwm and cwm keeps running);
> do we want to keep those default-broken entries around?
>
> Index: conf.c
> ===
> RCS file: /cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.255
> diff -u -p -r1.255 conf.c
> --- conf.c26 Feb 2022 15:19:18 - 1.255
> +++ conf.c15 May 2023 06:11:01 -
> @@ -307,6 +307,8 @@ conf_init(struct conf *c)
> conf_cmd_add(c, "lock", "xlock");
> conf_cmd_add(c, "term", "xterm");
> conf_wm_add(c, "cwm", "cwm");
> + conf_wm_add(c, "fvwm", "fvwm");
> + conf_wm_add(c, "twm", "twm");
>
> c->font = xstrdup("sans-serif:pixelsize=14:bold");
> c->wmname = xstrdup("CWM");
>
--
Matthieu Herrb
Re: ifconfig description for wireguard peers
On 15.5.2023. 9:47, Hrvoje Popovski wrote: > On 12.1.2023. 5:49, Mikolaj Kucharski wrote: >> Hi, >> >> Is there anything else which I can do, to help this diff reviwed and >> increase the chance of getting in? >> >> Thread at https://marc.info/?t=16347829861=1=2 >> >> Last version of the diff at >> https://marc.info/?l=openbsd-tech=167185582521873=mbox > > Hi, > > I've applied this diff and it's works as expected. wgdesc would be nice > features to have when having remote access server with wireguard. Hi, With this diff when executing wg in shell or wg showconf I'm getting core dump. maybe I did something wrong? Mikolaj did you get core dump with diff? "wg show" without this diff r620-1# wg show interface: wg0 public key: 123= private key: (hidden) listening port: 12345 peer: 111= preshared key: (hidden) allowed ips: 10.123.123.2/32 "wg show" with this diff smc4# wg show Segmentation fault (core dumped) smc4# gdb wg wg.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd7.3"...(no debugging symbols found) Core was generated by `wg'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found) Loaded symbols for /usr/local/bin/wg Reading symbols from /usr/lib/libc.so.97.0...done. Loaded symbols for /usr/lib/libc.so.97.0 Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] #0 0x0ec9a681649d in ipc_get_device () from /usr/local/bin/wg (gdb) bt #0 0x0ec9a681649d in ipc_get_device () from /usr/local/bin/wg #1 0x0ec9a6817ac2 in show_main () from /usr/local/bin/wg #2 0x0ec9a6808822 in _start () from /usr/local/bin/wg #3 0x in ?? () (gdb)
Re: ifconfig description for wireguard peers
On 12.1.2023. 5:49, Mikolaj Kucharski wrote: > Hi, > > Is there anything else which I can do, to help this diff reviwed and > increase the chance of getting in? > > Thread at https://marc.info/?t=16347829861=1=2 > > Last version of the diff at > https://marc.info/?l=openbsd-tech=167185582521873=mbox Hi, I've applied this diff and it's works as expected. wgdesc would be nice features to have when having remote access server with wireguard. old ifconfig wg0 wg0: flags=80c3 mtu 1420 index 15 priority 0 llprio 3 wgport 12345 wgpubkey 123= wgpeer 111= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.2/32 wgpeer 222= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.3/32 wgpeer 33= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.4/32 wgpeer 44= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.5/32 wgpeer 55= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.6/32 wgpeer 66= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.7/32 wgpeer 777= wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.8/32 groups: wg inet 10.123.123.1 netmask 0xff00 broadcast 10.123.123.255 new ifconfig wg0 wg0: flags=80c3 mtu 1420 index 15 priority 0 llprio 3 wgport 12345 wgpubkey 123= wgpeer 111= wgdesc Hrvoje Popovski 1 wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.2/32 wgpeer 222= wgdesc Hrvoje Popovski 2 wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.3/32 wgpeer 333= wgdesc Hrvoje Popovski 3 wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.4/32 wgpeer 444= wgdesc Hrvoje Popovski 4 wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.5/32 wgpeer 555= wgdesc Hrvoje Popovski 5 wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.6/32 wgpeer 666= wgdesc Hrvoje Popovski 6 wgpsk (present) tx: 0, rx: 0 wgaip 10.123.123.7/32 groups: wg inet 10.123.123.1 netmask 0xff00 broadcast 10.123.123.255 cat /etc/hostname.wg0 inet 10.123.123.1 255.255.255.0 wgport 12345 wgkey 456= # old desc - Hrvoje Popovski 1 wgpeer 111= wgdesc "Hrvoje Popovski 1" \ wgpsk 111= \ wgaip 10.123.123.2/32 # old desc - Hrvoje Popovski 2 wgpeer 222= wgdesc "Hrvoje Popovski 2" \ wgpsk 222= \ wgaip 10.123.123.3/32 # old desc - Hrvoje Popovski 3 wgpeer 3= wgdesc "Hrvoje Popovski 3" \ wgpsk 3= \ wgaip 10.123.123.4/32 # old desc - Hrvoje Popovski 4 wgpeer 44= wgdesc "Hrvoje Popovski 4" \ wgpsk 44= \ wgaip 10.123.123.5/32 # old desc .- Hrvoje Popovski 5 wgpeer 555= wgdesc "Hrvoje Popovski 5" \ wgpsk 555= \ wgaip 10.123.123.6/32 # old desc - Hrvoje Popovski 6 wgpeer = wgdesc "Hrvoje Popovski 6" \ wgpsk = \ wgaip 10.123.123.7/32
Re: smtpd: nits to reduce the diff with -portable
On Mon, May 15, 2023 at 09:22:47AM +0200, Omar Polo wrote: > On 2023/05/15 09:03:47 +0200, Omar Polo wrote: > > On 2023/05/14 18:03:17 -0600, "Theo de Raadt" wrote: > > > Omar Polo wrote: > > > > On 2023/05/10 09:30:12 +0200, Theo Buehler wrote: > > > > > > I forgot to include one off_t cast since it was in a different > > > > > > directory and -even if off topic because it's not in portable- > > > > > > instead > > > > > > of "const"-ify only tz why don't mark as const also the two arrays > > > > > > day > > > > > > and month? > > > > > > > > > > ok. > > > > > > > > > > The previous diff used (long long int) and this one now uses (long > > > > > long). > > > > > Would be nice to be consistent. > > > > > > > > Yes, indeed. smtpd uses `long long int', while for mail.local doesn't > > > > have any. I'll go with `long long int' for consistency, typed `long > > > > long' out of muscular memory. > > > > > > I think it is wrong for smtpd to use "long long int". It is pointless > > > silliness, and there is more value in being idiomatically identical with > > > the greater body of code. > > > > ack (fwiw I prefer long long too). Here's s/long long int/long long/g, > > ok? > > let's fix the indentation in smtpctl.c since I have to touch that line > anyway... I am ok with this. Do we care that sometimes we (cast)var and sometimes we (cast) var? Is this at least consistent per-file?
Re: seperate LRO/TSO flags
On Sat, May 13, 2023 at 04:44:18PM +0200, Christian Weisgerber wrote:
> Jan Klemkow:
>
> > This diff introduces separate flags for TCP offloading. We split this
> > into LRO (large receive offloading) and TSO (TCP segmentation
> > offloading). Thus, we are able to turn it on/off separately.
>
> Wait, why do we even have a knob for TSO?
>
> We specifically decided not to have a knob for checksum offloading,
> because it should just work out of the box, and if it doesn't, then
> it should be disabled by the driver. It should not be the admin's
> task to figure out if the implementation is broken and to fiddle
> with the knobs (hi, FreeBSD!).
>
> I would assume that line of thinking extends to TSO.
You are right. This is reflected in the current state of the diff
below.
We just need a knob for TCP Large Receive Offload (LRO) because it
changes the TCP segments. You may want to avoid this on a forwarding
router.
ok?
Thanks,
Jan
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.394
diff -u -p -r1.394 ifconfig.8
--- sbin/ifconfig/ifconfig.826 Apr 2023 02:38:08 - 1.394
+++ sbin/ifconfig/ifconfig.812 May 2023 06:22:35 -
@@ -282,8 +282,18 @@ tag.
As CSUM_TCPv4, but supports IPv6 datagrams.
.It Sy CSUM_UDPv6
As above, for UDP.
-.It Sy TSO
-The device supports TCP segment offloading (TSO).
+.It Sy LRO
+The device supports TCP large receive offload (LRO).
+.It Sy TSOv4
+The device supports IPv4 TCP segmentation offload (TSO).
+TSO is used by default.
+Use the
+.Xr sysctl 8
+variable
+.Va net.inet.tcp.tso
+to disable this feature.
+.It Sy TSOv6
+As above, for IPv6.
.It Sy WOL
The device supports Wake on LAN (WoL).
.It Sy hardmtu
@@ -491,25 +501,25 @@ Query and display information and diagno
modules installed in an interface.
It is only supported by drivers implementing the necessary functionality
on hardware which supports it.
-.It Cm tso
-Enable TCP segmentation offloading (TSO) if it's supported by the hardware; see
+.It Cm tcprecvoffload
+Enable TCP large receive offload (LRO) if it's supported by the hardware; see
.Cm hwfeatures .
-TSO enabled NICs modify received TCP/IP packets.
+LRO enabled network interfaces modify received TCP/IP packets.
This will also affect traffic of upper layer interfaces,
such as
.Xr vlan 4 ,
.Xr aggr 4 ,
and
.Xr carp 4 .
-It is not possible to use TSO with interfaces attached to a
+It is not possible to use LRO with interfaces attached to a
.Xr bridge 4 ,
.Xr veb 4 ,
or
.Xr tpmr 4 .
Changing this option will re-initialize the network interface.
-.It Cm -tso
-Disable TSO.
-TSO is disabled by default.
+.It Cm -tcprecvoffload
+Disable LRO.
+LRO is disabled by default.
.It Cm up
Mark an interface
.Dq up .
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.462
diff -u -p -r1.462 ifconfig.c
--- sbin/ifconfig/ifconfig.c8 Mar 2023 04:43:06 - 1.462
+++ sbin/ifconfig/ifconfig.c11 May 2023 17:33:55 -
@@ -126,7 +126,7 @@
#define HWFEATURESBITS \
"\024\1CSUM_IPv4\2CSUM_TCPv4\3CSUM_UDPv4" \
"\5VLAN_MTU\6VLAN_HWTAGGING\10CSUM_TCPv6" \
- "\11CSUM_UDPv6\17TSO\20WOL"
+ "\11CSUM_UDPv6\15LRO\16TSOv4\17TSOv6\20WOL"
struct ifencap {
unsigned int ife_flags;
@@ -469,8 +469,8 @@ const structcmd {
{ "-soii", IFXF_INET6_NOSOII, 0, setifxflags },
{ "monitor",IFXF_MONITOR, 0, setifxflags },
{ "-monitor", -IFXF_MONITOR, 0, setifxflags },
- { "tso",IFXF_TSO, 0, setifxflags },
- { "-tso", -IFXF_TSO, 0, setifxflags },
+ { "tcprecvoffload", IFXF_LRO, 0, setifxflags },
+ { "-tcprecvoffload", -IFXF_LRO, 0, setifxflags },
#ifndef SMALL
{ "hwfeatures", NEXTARG0, 0, printifhwfeatures },
{ "metric", NEXTARG,0, setifmetric },
@@ -674,7 +674,7 @@ const structcmd {
"\7RUNNING\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX"\
"\15LINK0\16LINK1\17LINK2\20MULTICAST" \
"\23AUTOCONF6TEMP\24MPLS\25WOL\26AUTOCONF6\27INET6_NOSOII" \
- "\30AUTOCONF4" "\31MONITOR" "\32TSO"
+ "\30AUTOCONF4" "\31MONITOR" "\32LRO"
intgetinfo(struct ifreq *, int);
void getsock(int);
Index: sys/dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.193
diff -u -p -r1.193 if_ix.c
--- sys/dev/pci/if_ix.c 28 Apr 2023 10:18:57 - 1.193
+++ sys/dev/pci/if_ix.c 12 May 2023 06:37:44 -
@@
Re: smtpd: nits to reduce the diff with -portable
On 2023/05/15 09:03:47 +0200, Omar Polo wrote:
> On 2023/05/14 18:03:17 -0600, "Theo de Raadt" wrote:
> > Omar Polo wrote:
> > > On 2023/05/10 09:30:12 +0200, Theo Buehler wrote:
> > > > > I forgot to include one off_t cast since it was in a different
> > > > > directory and -even if off topic because it's not in portable- instead
> > > > > of "const"-ify only tz why don't mark as const also the two arrays day
> > > > > and month?
> > > >
> > > > ok.
> > > >
> > > > The previous diff used (long long int) and this one now uses (long
> > > > long).
> > > > Would be nice to be consistent.
> > >
> > > Yes, indeed. smtpd uses `long long int', while for mail.local doesn't
> > > have any. I'll go with `long long int' for consistency, typed `long
> > > long' out of muscular memory.
> >
> > I think it is wrong for smtpd to use "long long int". It is pointless
> > silliness, and there is more value in being idiomatically identical with
> > the greater body of code.
>
> ack (fwiw I prefer long long too). Here's s/long long int/long long/g,
> ok?
let's fix the indentation in smtpctl.c since I have to touch that line
anyway...
Index: libexec/mail.local/mail.local.c
===
RCS file: /cvs/src/libexec/mail.local/mail.local.c,v
retrieving revision 1.40
diff -u -p -r1.40 mail.local.c
--- libexec/mail.local/mail.local.c 10 May 2023 08:03:49 - 1.40
+++ libexec/mail.local/mail.local.c 15 May 2023 06:59:09 -
@@ -244,7 +244,7 @@ retry:
curoff = lseek(mbfd, 0, SEEK_END);
(void)snprintf(biffmsg, sizeof biffmsg, "%s@%lld\n", name,
- (long long int)curoff);
+ (long long)curoff);
if (lseek(fd, 0, SEEK_SET) == (off_t)-1) {
mwarn("temporary file: %s", strerror(errno));
goto bad;
Index: usr.sbin/smtpd/bounce.c
===
RCS file: /cvs/src/usr.sbin/smtpd/bounce.c,v
retrieving revision 1.88
diff -u -p -r1.88 bounce.c
--- usr.sbin/smtpd/bounce.c 4 May 2023 12:43:44 - 1.88
+++ usr.sbin/smtpd/bounce.c 15 May 2023 06:59:29 -
@@ -305,7 +305,7 @@ bounce_send(struct bounce_session *s, co
}
static const char *
-bounce_duration(long long int d)
+bounce_duration(long long d)
{
static char buf[32];
Index: usr.sbin/smtpd/lka_filter.c
===
RCS file: /cvs/src/usr.sbin/smtpd/lka_filter.c,v
retrieving revision 1.69
diff -u -p -r1.69 lka_filter.c
--- usr.sbin/smtpd/lka_filter.c 10 May 2023 07:20:20 - 1.69
+++ usr.sbin/smtpd/lka_filter.c 15 May 2023 06:59:29 -
@@ -933,13 +933,13 @@ filter_protocol_query(struct filter *fil
n = io_printf(lka_proc_get_io(filter->proc),
"filter|%s|%lld.%06ld|smtp-in|%s|%016"PRIx64"|%016"PRIx64"|%s|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
phase, reqid, token, fs->rdns, param);
else
n = io_printf(lka_proc_get_io(filter->proc),
"filter|%s|%lld.%06ld|smtp-in|%s|%016"PRIx64"|%016"PRIx64"|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
phase, reqid, token, param);
if (n == -1)
fatalx("failed to write to processor");
@@ -957,7 +957,7 @@ filter_data_query(struct filter *filter,
"filter|%s|%lld.%06ld|smtp-in|data-line|"
"%016"PRIx64"|%016"PRIx64"|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
reqid, token, line);
if (n == -1)
fatalx("failed to write to processor");
@@ -1374,7 +1374,7 @@ report_smtp_broadcast(uint64_t reqid, co
va_start(ap, format);
if (io_printf(lka_proc_get_io(rp->name),
"report|%s|%lld.%06ld|%s|%s|%016"PRIx64"%s",
- PROTOCOL_VERSION, (long long int)tv->tv_sec, tv->tv_usec,
+ PROTOCOL_VERSION, (long long)tv->tv_sec, tv->tv_usec,
direction, event, reqid,
format[0] != '\n' ? "|" : "") == -1 ||
io_vprintf(lka_proc_get_io(rp->name), format, ap) == -1)
Index: usr.sbin/smtpd/mail.maildir.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mail.maildir.c,v
retrieving revision 1.16
diff -u -p -r1.16 mail.maildir.c
--- usr.sbin/smtpd/mail.maildir.c 10 May 2023 07:19:49 - 1.16
+++ usr.sbin/smtpd/mail.maildir.c 15 May 2023 06:59:29 -
@@ -171,7 +171,7 @@ maildir_engine(const char *dirname, int
(void)strlcpy(hostname, "localhost", sizeof
Re: smtpd: nits to reduce the diff with -portable
On 2023/05/14 18:03:17 -0600, "Theo de Raadt" wrote:
> Omar Polo wrote:
> > On 2023/05/10 09:30:12 +0200, Theo Buehler wrote:
> > > > I forgot to include one off_t cast since it was in a different
> > > > directory and -even if off topic because it's not in portable- instead
> > > > of "const"-ify only tz why don't mark as const also the two arrays day
> > > > and month?
> > >
> > > ok.
> > >
> > > The previous diff used (long long int) and this one now uses (long long).
> > > Would be nice to be consistent.
> >
> > Yes, indeed. smtpd uses `long long int', while for mail.local doesn't
> > have any. I'll go with `long long int' for consistency, typed `long
> > long' out of muscular memory.
>
> I think it is wrong for smtpd to use "long long int". It is pointless
> silliness, and there is more value in being idiomatically identical with
> the greater body of code.
ack (fwiw I prefer long long too). Here's s/long long int/long long/g,
ok?
Index: libexec/mail.local/mail.local.c
===
RCS file: /cvs/src/libexec/mail.local/mail.local.c,v
retrieving revision 1.40
diff -u -p -r1.40 mail.local.c
--- libexec/mail.local/mail.local.c 10 May 2023 08:03:49 - 1.40
+++ libexec/mail.local/mail.local.c 15 May 2023 06:59:09 -
@@ -244,7 +244,7 @@ retry:
curoff = lseek(mbfd, 0, SEEK_END);
(void)snprintf(biffmsg, sizeof biffmsg, "%s@%lld\n", name,
- (long long int)curoff);
+ (long long)curoff);
if (lseek(fd, 0, SEEK_SET) == (off_t)-1) {
mwarn("temporary file: %s", strerror(errno));
goto bad;
Index: usr.sbin/smtpd/bounce.c
===
RCS file: /cvs/src/usr.sbin/smtpd/bounce.c,v
retrieving revision 1.88
diff -u -p -r1.88 bounce.c
--- usr.sbin/smtpd/bounce.c 4 May 2023 12:43:44 - 1.88
+++ usr.sbin/smtpd/bounce.c 15 May 2023 06:59:29 -
@@ -305,7 +305,7 @@ bounce_send(struct bounce_session *s, co
}
static const char *
-bounce_duration(long long int d)
+bounce_duration(long long d)
{
static char buf[32];
Index: usr.sbin/smtpd/lka_filter.c
===
RCS file: /cvs/src/usr.sbin/smtpd/lka_filter.c,v
retrieving revision 1.69
diff -u -p -r1.69 lka_filter.c
--- usr.sbin/smtpd/lka_filter.c 10 May 2023 07:20:20 - 1.69
+++ usr.sbin/smtpd/lka_filter.c 15 May 2023 06:59:29 -
@@ -933,13 +933,13 @@ filter_protocol_query(struct filter *fil
n = io_printf(lka_proc_get_io(filter->proc),
"filter|%s|%lld.%06ld|smtp-in|%s|%016"PRIx64"|%016"PRIx64"|%s|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
phase, reqid, token, fs->rdns, param);
else
n = io_printf(lka_proc_get_io(filter->proc),
"filter|%s|%lld.%06ld|smtp-in|%s|%016"PRIx64"|%016"PRIx64"|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
phase, reqid, token, param);
if (n == -1)
fatalx("failed to write to processor");
@@ -957,7 +957,7 @@ filter_data_query(struct filter *filter,
"filter|%s|%lld.%06ld|smtp-in|data-line|"
"%016"PRIx64"|%016"PRIx64"|%s\n",
PROTOCOL_VERSION,
- (long long int)tv.tv_sec, tv.tv_usec,
+ (long long)tv.tv_sec, tv.tv_usec,
reqid, token, line);
if (n == -1)
fatalx("failed to write to processor");
@@ -1374,7 +1374,7 @@ report_smtp_broadcast(uint64_t reqid, co
va_start(ap, format);
if (io_printf(lka_proc_get_io(rp->name),
"report|%s|%lld.%06ld|%s|%s|%016"PRIx64"%s",
- PROTOCOL_VERSION, (long long int)tv->tv_sec, tv->tv_usec,
+ PROTOCOL_VERSION, (long long)tv->tv_sec, tv->tv_usec,
direction, event, reqid,
format[0] != '\n' ? "|" : "") == -1 ||
io_vprintf(lka_proc_get_io(rp->name), format, ap) == -1)
Index: usr.sbin/smtpd/mail.maildir.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mail.maildir.c,v
retrieving revision 1.16
diff -u -p -r1.16 mail.maildir.c
--- usr.sbin/smtpd/mail.maildir.c 10 May 2023 07:19:49 - 1.16
+++ usr.sbin/smtpd/mail.maildir.c 15 May 2023 06:59:29 -
@@ -171,7 +171,7 @@ maildir_engine(const char *dirname, int
(void)strlcpy(hostname, "localhost", sizeof hostname);
(void)snprintf(filename, sizeof filename, "%lld.%08x.%s",
- (long long int) time(NULL),
+ (long long) time(NULL),
arc4random(),
cwm: add fvwm and tvm as default wm entries
Both fvwm(1) and twm(1) have a restart menu that contains other window
managers by default, which is useful if you want to switch around
without restarting X and/or custom window manager config.
cwm(1) only offers to restart into itself by deafult.
Add the other two we ship by default so users can round trip between
them.
Feedback? OK?
PS: fwvm and twm menus more programs we don't ship, e.g. "wm2", and
twm dies when failing to execute them (fvwm and cwm keeps running);
do we want to keep those default-broken entries around?
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.255
diff -u -p -r1.255 conf.c
--- conf.c 26 Feb 2022 15:19:18 - 1.255
+++ conf.c 15 May 2023 06:11:01 -
@@ -307,6 +307,8 @@ conf_init(struct conf *c)
conf_cmd_add(c, "lock", "xlock");
conf_cmd_add(c, "term", "xterm");
conf_wm_add(c, "cwm", "cwm");
+ conf_wm_add(c, "fvwm", "fvwm");
+ conf_wm_add(c, "twm", "twm");
c->font = xstrdup("sans-serif:pixelsize=14:bold");
c->wmname = xstrdup("CWM");
