Upgrading buildbot and switching to Debian 11
Hi, FYI, just started moving master buildbot server to a new hardware and will move snapshot builds there first to iron out any remaining issues. While at it I'm updating it to the latest buildbot 3.8.0 release and switching base container images from Debian 10 to Debian 11[1]: "Debian 10 LTS support ends on 6/2024, so it makes no sense to use it as a base for 23.05 release, so lets switch to Debian 11 which should've LTS support till 6/2026." I'll try to keep you updated during transition. 1. https://github.com/openwrt/buildbot/pull/3/commits/f2c27d0084c9450e86e6534cc9ea2fcc92aa0828 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH iwinfo] lib: report byte counters as 64 bit values
The 32bit counter can only count to 4GiB before wrapping.
Switching to the 64bit variant avoids this issue.
In practice some users are interpreting the counter values as signed
integer bringing down the usable range for 32bit values down to only
2GiB.
Signed-off-by: Thomas Weißschuh
---
include/iwinfo.h | 4 ++--
iwinfo_nl80211.c | 12 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index eae99302704a..b50de69f49ca 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -240,8 +240,8 @@ struct iwinfo_assoclist_entry {
uint64_t rx_drop_misc;
struct iwinfo_rate_entry rx_rate;
struct iwinfo_rate_entry tx_rate;
- uint32_t rx_bytes;
- uint32_t tx_bytes;
+ uint64_t rx_bytes;
+ uint64_t tx_bytes;
uint32_t tx_retries;
uint32_t tx_failed;
uint64_t t_offset;
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 50bb8f03c2fd..1e0a0c77dc39 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -1554,6 +1554,8 @@ static int nl80211_fill_signal_cb(struct nl_msg *msg,
void *arg)
[NL80211_STA_INFO_INACTIVE_TIME] = { .type = NLA_U32},
[NL80211_STA_INFO_RX_BYTES] = { .type = NLA_U32},
[NL80211_STA_INFO_TX_BYTES] = { .type = NLA_U32},
+ [NL80211_STA_INFO_RX_BYTES64]= { .type = NLA_U64},
+ [NL80211_STA_INFO_TX_BYTES64]= { .type = NLA_U64},
[NL80211_STA_INFO_RX_PACKETS]= { .type = NLA_U32},
[NL80211_STA_INFO_TX_PACKETS]= { .type = NLA_U32},
[NL80211_STA_INFO_SIGNAL]= { .type = NLA_U8 },
@@ -2214,6 +2216,8 @@ static int nl80211_get_assoclist_cb(struct nl_msg *msg,
void *arg)
[NL80211_STA_INFO_SIGNAL_AVG]= { .type = NLA_U8 },
[NL80211_STA_INFO_RX_BYTES] = { .type = NLA_U32},
[NL80211_STA_INFO_TX_BYTES] = { .type = NLA_U32},
+ [NL80211_STA_INFO_RX_BYTES64]= { .type = NLA_U64},
+ [NL80211_STA_INFO_TX_BYTES64]= { .type = NLA_U64},
[NL80211_STA_INFO_TX_RETRIES]= { .type = NLA_U32},
[NL80211_STA_INFO_TX_FAILED] = { .type = NLA_U32},
[NL80211_STA_INFO_CONNECTED_TIME]= { .type = NLA_U32},
@@ -2277,10 +2281,14 @@ static int nl80211_get_assoclist_cb(struct nl_msg *msg,
void *arg)
sinfo[NL80211_STA_INFO_TX_BITRATE],
rate_policy))
nl80211_parse_rateinfo(rinfo, >tx_rate);
- if (sinfo[NL80211_STA_INFO_RX_BYTES])
+ if (sinfo[NL80211_STA_INFO_RX_BYTES64])
+ e->rx_bytes =
nla_get_u64(sinfo[NL80211_STA_INFO_RX_BYTES64]);
+ else if (sinfo[NL80211_STA_INFO_RX_BYTES])
e->rx_bytes =
nla_get_u32(sinfo[NL80211_STA_INFO_RX_BYTES]);
- if (sinfo[NL80211_STA_INFO_TX_BYTES])
+ if (sinfo[NL80211_STA_INFO_TX_BYTES64])
+ e->tx_bytes =
nla_get_u64(sinfo[NL80211_STA_INFO_TX_BYTES64]);
+ else if (sinfo[NL80211_STA_INFO_TX_BYTES])
e->tx_bytes =
nla_get_u32(sinfo[NL80211_STA_INFO_TX_BYTES]);
if (sinfo[NL80211_STA_INFO_TX_RETRIES])
base-commit: b3888b29535a92584524e14aadf25fcb85e7fed2
--
2.40.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH iwinfo] nl80211: constify a few arrays
Signed-off-by: Thomas Weißschuh
---
iwinfo_nl80211.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 50bb8f03c2fd..2a5e461e8d90 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -1249,7 +1249,7 @@ static int nl80211_get_ssid_bssid_cb(struct nl_msg *msg,
void *arg)
struct nlattr **tb = nl80211_parse(msg);
struct nlattr *bss[NL80211_BSS_MAX + 1];
- static struct nla_policy bss_policy[NL80211_BSS_MAX + 1] = {
+ static const struct nla_policy bss_policy[NL80211_BSS_MAX + 1] = {
[NL80211_BSS_INFORMATION_ELEMENTS] = { 0 },
[NL80211_BSS_STATUS] = { .type = NLA_U32 },
};
@@ -1373,7 +1373,7 @@ static int nl80211_get_frequency_scan_cb(struct nl_msg
*msg, void *arg)
struct nlattr **attr = nl80211_parse(msg);
struct nlattr *binfo[NL80211_BSS_MAX + 1];
- static struct nla_policy bss_policy[NL80211_BSS_MAX + 1] = {
+ static const struct nla_policy bss_policy[NL80211_BSS_MAX + 1] = {
[NL80211_BSS_FREQUENCY] = { .type = NLA_U32 },
[NL80211_BSS_STATUS]= { .type = NLA_U32 },
};
@@ -1550,7 +1550,7 @@ static int nl80211_fill_signal_cb(struct nl_msg *msg,
void *arg)
struct nlattr *sinfo[NL80211_STA_INFO_MAX + 1];
struct nlattr *rinfo[NL80211_RATE_INFO_MAX + 1];
- static struct nla_policy stats_policy[NL80211_STA_INFO_MAX + 1] = {
+ static const struct nla_policy stats_policy[NL80211_STA_INFO_MAX + 1] =
{
[NL80211_STA_INFO_INACTIVE_TIME] = { .type = NLA_U32},
[NL80211_STA_INFO_RX_BYTES] = { .type = NLA_U32},
[NL80211_STA_INFO_TX_BYTES] = { .type = NLA_U32},
@@ -1563,7 +1563,7 @@ static int nl80211_fill_signal_cb(struct nl_msg *msg,
void *arg)
[NL80211_STA_INFO_PLINK_STATE] = { .type = NLA_U8 },
};
- static struct nla_policy rate_policy[NL80211_RATE_INFO_MAX + 1] = {
+ static const struct nla_policy rate_policy[NL80211_RATE_INFO_MAX + 1] =
{
[NL80211_RATE_INFO_BITRATE] = { .type = NLA_U16 },
[NL80211_RATE_INFO_MCS] = { .type = NLA_U8 },
[NL80211_RATE_INFO_40_MHZ_WIDTH] = { .type = NLA_FLAG },
@@ -1662,7 +1662,7 @@ static int nl80211_get_noise_cb(struct nl_msg *msg, void
*arg)
struct nlattr **tb = nl80211_parse(msg);
struct nlattr *si[NL80211_SURVEY_INFO_MAX + 1];
- static struct nla_policy sp[NL80211_SURVEY_INFO_MAX + 1] = {
+ static const struct nla_policy sp[NL80211_SURVEY_INFO_MAX + 1] = {
[NL80211_SURVEY_INFO_FREQUENCY] = { .type = NLA_U32 },
[NL80211_SURVEY_INFO_NOISE] = { .type = NLA_U8 },
};
@@ -1760,7 +1760,7 @@ static int nl80211_check_wepkey(const char *key)
return 0;
}
-static struct {
+static const struct {
const char *match;
int version;
int suite;
@@ -1817,7 +1817,7 @@ static void parse_wpa_suites(const char *str, int
defversion,
}
}
-static struct {
+static const struct {
const char *match;
int cipher;
} wpa_cipher_strings[] = {
@@ -2099,7 +2099,7 @@ static int nl80211_get_survey_cb(struct nl_msg *msg, void
*arg)
struct nlattr *sinfo[NL80211_SURVEY_INFO_MAX + 1];
int rc;
- static struct nla_policy survey_policy[NL80211_SURVEY_INFO_MAX + 1] = {
+ static const struct nla_policy survey_policy[NL80211_SURVEY_INFO_MAX +
1] = {
[NL80211_SURVEY_INFO_FREQUENCY] = { .type = NLA_U32 },
[NL80211_SURVEY_INFO_NOISE] = { .type = NLA_U8 },
[NL80211_SURVEY_INFO_TIME] = { .type = NLA_U64 },
@@ -2204,7 +2204,7 @@ static int nl80211_get_assoclist_cb(struct nl_msg *msg,
void *arg)
struct nlattr *rinfo[NL80211_RATE_INFO_MAX + 1];
struct nl80211_sta_flag_update *sta_flags;
- static struct nla_policy stats_policy[NL80211_STA_INFO_MAX + 1] = {
+ static const struct nla_policy stats_policy[NL80211_STA_INFO_MAX + 1] =
{
[NL80211_STA_INFO_INACTIVE_TIME] = { .type = NLA_U32},
[NL80211_STA_INFO_RX_PACKETS]= { .type = NLA_U32},
[NL80211_STA_INFO_TX_PACKETS]= { .type = NLA_U32},
@@ -2231,7 +2231,7 @@ static int nl80211_get_assoclist_cb(struct nl_msg *msg,
void *arg)
[NL80211_STA_INFO_NONPEER_PM]= { .type = NLA_U32},
};
- static struct nla_policy rate_policy[NL80211_RATE_INFO_MAX + 1] = {
+ static const struct nla_policy rate_policy[NL80211_RATE_INFO_MAX + 1] =
{
[NL80211_RATE_INFO_BITRATE] = { .type = NLA_U16},
[NL80211_RATE_INFO_MCS] = { .type = NLA_U8 },
[NL80211_RATE_INFO_40_MHZ_WIDTH] = { .type = NLA_FLAG },
@@ -2413,7 +2413,7 @@ static
Re: OpenWrt vs Defense positions
On 5/7/23 13:19, Hauke Mehrtens wrote: I check from time to time which companies in the US are looking for OpenWrt experts [0] to get an overview who is using it. About 10% to 30% of these job offers require clearance. It looks like the US military and US intelligence community is using OpenWrt. Once I saw a job offer where someone was looking for a person who has experience in writing exploits for OpenWrt and DD-WRT in the Washington, D.C. area, this scared me a bit, normally I do not have the NSA in my thread model. Someone from BAE Systems (largest defence contractor in Europe) was also contacting us at OpenWrt some years ago with questions about the license. I hope that these companies use OpenWrt mostly to provide Internet access for their soldiers and it is not part of any real weapon system. As OpenWrt is now used by many vendors I think the intelligence agencies around the world are interested in exploits fro OpenWrt. I'm now getting at least two queries a week from recruiters regarding (non-OpenWrt) but embedded Linux positions building weapons systems. My usual reply is that "firing missiles at people doesn't improve the world". That's hippy idealism of course, but it's still my stance. (My current involvement in OpenWrt is providing cell/internet access to first responders; my knowledge of military internet or whatever is zero apart from the the obvious history). I heard a rumor some years ago that one of the biggest OpenWrt installation was at the fence between the US and Mexico, but I have no prove that this is true. Yes, and regarding security as we usually mean in the software stance, and whether the rumor is true or not, OpenWrt is widely deployed. It doesn't take very much paranoia at all to think that there are government departments in various countries keeping track of issues with embedded Linux in general and OpenWrt in particular. It also doesn't take much of a stretch to image they have at least some info on major OpenWrt contributors such as yourself or people who have long expressed interest in embedded Linux security, although certainly in my case, it would be short and boring. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/4] bcm53xx: Add network configuration for DIR-890L
On Mon, May 15, 2023 at 10:41 AM Rafał Miłecki wrote:
> On 2023-05-13 23:21, Linus Walleij wrote:
> > This adds the lan/wan default bridge config and also the MAC
> > NVRAM read-out for et2.
> >
> > DIR-885L was missing a default bridge config so I just added
> > that too while I was at it.
>
> It seems that D-Link DIR-890L in its DTS file already has "et0macaddr"
> specified and "gmac2" referencing it. So I think bgmac should read MAC
> on its own and no user space extra code should be needed.
>
> That should work starting with the commit 4ab27bc6efee ("kernel:
> backport NVMEM patch for Broadcom's NVRAM MAC cells").
>
> Can you test that, please?
Yup you're right, that works on its own.
Can you drop the oneliner when applying or do you want me to
send a revised patch?
Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] kernel: fix scheduling while atomic in bridge offload
From: Qingfang DENG
br_offload_port_state is in a spinlock's critical section (>lock),
but rhashtable_init/rhashtable_free_and_destroy/flush_work may sleep,
causing scheduling while atomic bug.
To fix this, use workqueues to defer the init/destroy operations. To
synchronize between rhashtable insert/destroy, synchronize_rcu is used
to ensure all writers have left the RCU critical section before calling
rhashtable_free_and_destroy.
While at it, check for null pointers at the flow allocation.
Fixes: 94b4da9b4aad ("kernel: add a fast path for the bridge code")
Signed-off-by: Qingfang DENG
---
v3: fix race conditions and optimize code
.../hack-5.15/600-bridge_offload.patch| 97 +--
1 file changed, 69 insertions(+), 28 deletions(-)
diff --git a/target/linux/generic/hack-5.15/600-bridge_offload.patch
b/target/linux/generic/hack-5.15/600-bridge_offload.patch
index 9d71a741b2..87396611bd 100644
--- a/target/linux/generic/hack-5.15/600-bridge_offload.patch
+++ b/target/linux/generic/hack-5.15/600-bridge_offload.patch
@@ -150,16 +150,25 @@ Subject: [PATCH] net/bridge: add bridge offload
/*
* Determine initial path cost based on speed.
-@@ -428,7 +429,7 @@ static struct net_bridge_port *new_nbp(s
+@@ -362,6 +363,7 @@ static void del_nbp(struct net_bridge_po
+ kobject_del(>kobj);
+
+ br_netpoll_disable(p);
++ flush_work(>offload.deferred_work);
+
+ call_rcu(>rcu, destroy_nbp_rcu);
+ }
+@@ -428,7 +430,8 @@ static struct net_bridge_port *new_nbp(s
p->path_cost = port_cost(dev);
p->priority = 0x8000 >> BR_PORT_BITS;
p->port_no = index;
- p->flags = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
+ p->flags = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD |
BR_OFFLOAD;
++ br_offload_init_work(p);
br_init_port(p);
br_set_state(p, BR_STATE_DISABLED);
br_stp_port_timer_init(p);
-@@ -771,6 +772,9 @@ void br_port_flags_change(struct net_bri
+@@ -771,6 +774,9 @@ void br_port_flags_change(struct net_bri
if (mask & BR_NEIGH_SUPPRESS)
br_recalculate_neigh_suppress_enabled(br);
@@ -199,7 +208,7 @@ Subject: [PATCH] net/bridge: add bridge offload
--- /dev/null
+++ b/net/bridge/br_offload.c
-@@ -0,0 +1,438 @@
+@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
@@ -306,7 +315,7 @@ Subject: [PATCH] net/bridge: add bridge offload
+ p->br->offload_cache_reserved) >= p->br->offload_cache_size;
+}
+
-+static void
++void
+br_offload_gc_work(struct work_struct *work)
+{
+ struct rhashtable_iter hti;
@@ -354,36 +363,53 @@ Subject: [PATCH] net/bridge: add bridge offload
+
+}
+
-+void br_offload_port_state(struct net_bridge_port *p)
++void br_offload_deferred_work(struct work_struct *work)
+{
-+ struct net_bridge_port_offload *o = >offload;
-+ bool enabled = true;
-+ bool flush = false;
++ struct net_bridge_port_offload *o;
++ struct net_bridge_port *p;
++ bool enabling, enabled;
+
-+ if (p->state != BR_STATE_FORWARDING ||
-+ !(p->flags & BR_OFFLOAD))
-+ enabled = false;
++ p = container_of(work, struct net_bridge_port, offload.deferred_work);
++ o = >offload;
+
-+ spin_lock_bh(_lock);
-+ if (o->enabled == enabled)
-+ goto out;
++ spin_lock_bh(>br->lock);
++ enabling = o->enabling;
++ enabled = o->enabled;
++ spin_unlock_bh(>br->lock);
++
++ if (enabling == enabled)
++ return;
+
-+ if (enabled) {
-+ if (!o->gc_work.func)
-+ INIT_WORK(>gc_work, br_offload_gc_work);
++ if (enabling) {
+ rhashtable_init(>rht, _params);
++ spin_lock_bh(_lock);
++ o->enabled = true;
++ spin_unlock_bh(_lock);
+ } else {
-+ flush = true;
++ spin_lock_bh(_lock);
++ o->enabled = false;
++ spin_unlock_bh(_lock);
++ /* Ensure all rht users have finished */
++ synchronize_rcu();
++ cancel_work_sync(>gc_work);
+ rhashtable_free_and_destroy(>rht, br_offload_destroy_cb, o);
+ }
++}
+
-+ o->enabled = enabled;
++void br_offload_port_state(struct net_bridge_port *p)
++{
++ struct net_bridge_port_offload *o = >offload;
++ bool enabling = true;
+
-+out:
-+ spin_unlock_bh(_lock);
++ if (p->state != BR_STATE_FORWARDING ||
++ !(p->flags & BR_OFFLOAD))
++ enabling = false;
++
++ if (o->enabling == enabling)
++ return;
+
-+ if (flush)
-+ flush_work(>gc_work);
++ o->enabling = enabling;
++ schedule_work(>deferred_work);
+}
+
+void br_offload_fdb_update(const struct net_bridge_fdb_entry *fdb)
@@ -475,6 +501,9 @@ Subject: [PATCH] net/bridge: add bridge offload
+#endif
+
+ flow =
Re: [PATCH 4/4] bcm53xx: Add network configuration for DIR-890L
On 2023-05-13 23:21, Linus Walleij wrote:
This adds the lan/wan default bridge config and also the MAC
NVRAM read-out for et2.
DIR-885L was missing a default bridge config so I just added
that too while I was at it.
It seems that D-Link DIR-890L in its DTS file already has "et0macaddr"
specified and "gmac2" referencing it. So I think bgmac should read MAC
on its own and no user space extra code should be needed.
That should work starting with the commit 4ab27bc6efee ("kernel:
backport NVMEM patch for Broadcom's NVRAM MAC cells").
Can you test that, please?
Signed-off-by: Linus Walleij
---
target/linux/bcm53xx/base-files/etc/board.d/02_network | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/linux/bcm53xx/base-files/etc/board.d/02_network
b/target/linux/bcm53xx/base-files/etc/board.d/02_network
index 6bec600540ea..35b1efc91323 100644
--- a/target/linux/bcm53xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm53xx/base-files/etc/board.d/02_network
@@ -16,6 +16,10 @@ bcm53xx_setup_interfaces()
asus,rt-ac88u)
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 extsw" "wan"
;;
+ dlink,dir-885l | \
+ dlink,dir-890l)
+ ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"
+ ;;
dlink,dwl-8610ap)
ucidef_set_interface_lan "eth0 eth1" "dhcp"
;;
@@ -50,6 +54,7 @@ bcm53xx_setup_macs()
offset=1
;;
dlink,dir-885l | \
+ dlink,dir-890l | \
linksys,panamera | \
netgear,r7900 | \
netgear,r8000 | \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
