* Re: [PATCH net 6/7] net: hns3: fix VF reset fail issue
From: Paolo Abeni @ 2023-11-02 10:45 UTC (permalink / raw)
To: Jijie Shao, yisen.zhuang, salil.mehta, davem, edumazet, kuba
Cc: shenjian15, wangjie125, liuyonglong, netdev, linux-kernel
In-Reply-To: <20231028025917.314305-7-shaojijie@huawei.com>
On Sat, 2023-10-28 at 10:59 +0800, Jijie Shao wrote:
> Currently the reset process in hns3 and firmware watchdog init process is
> asynchronous. We think firmware watchdog initialization is completed
> before VF clear the interrupt source. However, firmware initialization
> may not complete early. So VF will receive multiple reset interrupts
> and fail to reset.
>
> So we add delay before VF interrupt source and 5 ms delay
> is enough to avoid second reset interrupt.
>
> Fixes: 427900d27d86 ("net: hns3: fix the timing issue of VF clearing interrupt sources")
> Signed-off-by: Jijie Shao <shaojijie@huawei.com>
> ---
> .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
> index 1c62e58ff6d8..7b87da031be6 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
> @@ -1924,8 +1924,14 @@ static void hclgevf_service_task(struct work_struct *work)
> hclgevf_mailbox_service_task(hdev);
> }
>
> -static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr)
> +static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr,
> + bool need_dalay)
> {
> +#define HCLGEVF_RESET_DELAY 5
> +
> + if (need_dalay)
> + mdelay(HCLGEVF_RESET_DELAY);
5ms delay in an interrupt handler is quite a lot. What about scheduling
a timer from the IH to clear the register when such delay is needed?
Thanks!
Paolo
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
From: Vladimir Oltean @ 2023-11-02 10:45 UTC (permalink / raw)
To: Linus Walleij
Cc: Luiz Angelo Daros de Luca, Andrew Lunn, Florian Fainelli,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <CACRpkdaoBo0S0RgLhacObd3pbjtWAfr6s3oizQAHqdB76gaG5A@mail.gmail.com>
On Wed, Nov 01, 2023 at 09:26:50PM +0100, Linus Walleij wrote:
> On Wed, Nov 1, 2023 at 1:35 PM Luiz Angelo Daros de Luca <luizluca@gmail.com> wrote:
>
> > Sorry but I noticed no issues:
>
> Don't be sorry about that, it's good news because now I know
> where to look, i.e. in the ethernet controller.
Don't look too deeply into the code just yet, just try to see what
happens with dsa_loop on an identical Ethernet controller that isn't
physically attached to a switch.
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net:dsa:microchip: add property to select
From: Vladimir Oltean @ 2023-11-02 10:44 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Andrew Lunn, Ante Knezic, conor+dt, UNGLinuxDriver, davem,
devicetree, edumazet, f.fainelli, krzysztof.kozlowski+dt, kuba,
linux-kernel, marex, netdev, pabeni, robh+dt, woojung.huh
In-Reply-To: <20231031072847.GP3803936@pengutronix.de>
On Tue, Oct 31, 2023 at 08:28:47AM +0100, Oleksij Rempel wrote:
> Transferring these issues to KSZ8863, we might face difficulties configuring
> STMMAC if KSZ8863, acting as the clock provider, isn't enabled early before MAC
> driver probing, a tricky scenario in the DSA framework.
So for each driver, there are 2 components to using CCF for MAC/PHY
interface clocks, one is providing what you have, and the other is
requesting what you need.
To avoid circular dependencies, we should make the clock provider per
DSA port be independent of the DSA driver itself. That is because, as
you point out in your example, the conduit interface (stmmac) may depend
on a clock provided by the switch, but the switch also depends on the
conduit being fully probed.
Stronger separation / more granular dependencies was one reason why I
wanted for more DSA drivers to follow Colin Foster's suit, but I stopped
working on that too:
https://lore.kernel.org/lkml/20221222134844.lbzyx5hz7z5n763n@skbuf/
but in the case of interface clocks, the separation is not so clear.
I would expect that for most if not all switches, the interface clock is
implicitly provided by enabling and configuring the respective MAC, the
same MAC that is intrinsically controlled through phylink by the main
DSA (switching IP) driver. So we have 2 APIs for controlling the same
piece of hardware, I'm not sure how conflicting requests are supposed to
be resolved.
This piece of the puzzle is quite complicated to fit into the larger
architecture in a coherent way, although I'm not arguing that there will
also be benefits.
^ permalink raw reply
* [PATCH bpf] selftests/bpf: Fix broken build where char is unsigned
From: Björn Töpel @ 2023-11-02 10:35 UTC (permalink / raw)
To: Andrii Nakryiko, Mykola Lysenko, bpf, Daniel Borkmann, netdev
Cc: Björn Töpel, Alexei Starovoitov, linux-kselftest,
linux-kernel, Larysa Zaremba
From: Björn Töpel <bjorn@rivosinc.com>
There are architectures where char is not signed. If so, the following
error is triggered:
| xdp_hw_metadata.c:435:42: error: result of comparison of constant -1 \
| with expression of type 'char' is always true \
| [-Werror,-Wtautological-constant-out-of-range-compare]
| 435 | while ((opt = getopt(argc, argv, "mh")) != -1) {
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~
| 1 error generated.
Correct by changing the char to int.
Fixes: bb6a88885fde ("selftests/bpf: Add options and frags to xdp_hw_metadata")
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
---
tools/testing/selftests/bpf/xdp_hw_metadata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/xdp_hw_metadata.c b/tools/testing/selftests/bpf/xdp_hw_metadata.c
index 17c0f92ff160..c3ba40d0b9de 100644
--- a/tools/testing/selftests/bpf/xdp_hw_metadata.c
+++ b/tools/testing/selftests/bpf/xdp_hw_metadata.c
@@ -430,7 +430,7 @@ static void print_usage(void)
static void read_args(int argc, char *argv[])
{
- char opt;
+ int opt;
while ((opt = getopt(argc, argv, "mh")) != -1) {
switch (opt) {
base-commit: cb3c6a58be50c65014296aa3455cae0fa1e82eac
--
2.40.1
^ permalink raw reply related
* Re: [PATCH net v1 1/3] net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT
From: Wenjia Zhang @ 2023-11-02 10:34 UTC (permalink / raw)
To: D. Wythe, kgraul, jaka, wintera
Cc: kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <1698904324-33238-2-git-send-email-alibuda@linux.alibaba.com>
On 02.11.23 06:52, D. Wythe wrote:
> From: "D. Wythe" <alibuda@linux.alibaba.com>
>
> Considering scenario:
>
> smc_cdc_rx_handler
> __smc_release
> sock_set_flag
> smc_close_active()
> sock_set_flag
>
> __set_bit(DEAD) __set_bit(DONE)
>
> Dues to __set_bit is not atomic, the DEAD or DONE might be lost.
> if the DEAD flag lost, the state SMC_CLOSED will be never be reached
> in smc_close_passive_work:
>
> if (sock_flag(sk, SOCK_DEAD) &&
> smc_close_sent_any_close(conn)) {
> sk->sk_state = SMC_CLOSED;
> } else {
> /* just shutdown, but not yet closed locally */
> sk->sk_state = SMC_APPFINCLOSEWAIT;
> }
>
> Replace sock_set_flags or __set_bit to set_bit will fix this problem.
> Since set_bit is atomic.
>
> Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
> Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Fixes tag?
^ permalink raw reply
* Re: [PATCH net 1/7] net: hns3: fix add VLAN fail issue
From: Paolo Abeni @ 2023-11-02 10:31 UTC (permalink / raw)
To: Jijie Shao, yisen.zhuang, salil.mehta, davem, edumazet, kuba
Cc: shenjian15, wangjie125, liuyonglong, netdev, linux-kernel
In-Reply-To: <20231028025917.314305-2-shaojijie@huawei.com>
On Sat, 2023-10-28 at 10:59 +0800, Jijie Shao wrote:
> From: Jian Shen <shenjian15@huawei.com>
>
> The hclge_sync_vlan_filter is called in periodic task,
> trying to remove VLAN from vlan_del_fail_bmap. It can
> be concurrence with VLAN adding operation from user.
> So once user failed to delete a VLAN id, and add it
> again soon, it may be removed by the periodic task,
> which may cause the software configuration being
> inconsistent with hardware. So add mutex handling
> to avoid this.
>
> user hns3 driver
>
> periodic task
> │
> add vlan 10 ───── hns3_vlan_rx_add_vid │
> │ (suppose success) │
> │ │
> del vlan 10 ───── hns3_vlan_rx_kill_vid │
> │ (suppose fail,add to │
> │ vlan_del_fail_bmap) │
> │ │
> add vlan 10 ───── hns3_vlan_rx_add_vid │
> (suppose success) │
> foreach vlan_del_fail_bmp
> del vlan 10
>
> Fixes: fe4144d47eef ("net: hns3: sync VLAN filter entries when kill VLAN ID failed")
> Signed-off-by: Jian Shen <shenjian15@huawei.com>
> Signed-off-by: Jijie Shao <shaojijie@huawei.com>
> ---
> .../hisilicon/hns3/hns3pf/hclge_main.c | 21 +++++++++++++------
> .../hisilicon/hns3/hns3vf/hclgevf_main.c | 11 ++++++++--
> 2 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index c42574e29747..a3230ac928a9 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -10026,8 +10026,6 @@ static void hclge_rm_vport_vlan_table(struct hclge_vport *vport, u16 vlan_id,
> struct hclge_vport_vlan_cfg *vlan, *tmp;
> struct hclge_dev *hdev = vport->back;
>
> - mutex_lock(&hdev->vport_lock);
> -
> list_for_each_entry_safe(vlan, tmp, &vport->vlan_list, node) {
> if (vlan->vlan_id == vlan_id) {
> if (is_write_tbl && vlan->hd_tbl_status)
> @@ -10042,8 +10040,6 @@ static void hclge_rm_vport_vlan_table(struct hclge_vport *vport, u16 vlan_id,
> break;
> }
> }
> -
> - mutex_unlock(&hdev->vport_lock);
> }
>
> void hclge_rm_vport_all_vlan_table(struct hclge_vport *vport, bool is_del_list)
> @@ -10452,11 +10448,16 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,
> * handle mailbox. Just record the vlan id, and remove it after
> * reset finished.
> */
> + mutex_lock(&hdev->vport_lock);
> if ((test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state) ||
> test_bit(HCLGE_STATE_RST_FAIL, &hdev->state)) && is_kill) {
> set_bit(vlan_id, vport->vlan_del_fail_bmap);
> + mutex_unlock(&hdev->vport_lock);
> return -EBUSY;
> + } else if (!is_kill && test_bit(vlan_id, vport->vlan_del_fail_bmap)) {
> + clear_bit(vlan_id, vport->vlan_del_fail_bmap);
> }
> + mutex_unlock(&hdev->vport_lock);
>
> /* when port base vlan enabled, we use port base vlan as the vlan
> * filter entry. In this case, we don't update vlan filter table
> @@ -10481,7 +10482,9 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,
> * and try to remove it from hw later, to be consistence
> * with stack
> */
> + mutex_lock(&hdev->vport_lock);
> set_bit(vlan_id, vport->vlan_del_fail_bmap);
> + mutex_unlock(&hdev->vport_lock);
It looks like that the 'hclge_rm_vport_vlan_table()' call a few lines
above will now happen with the vport_lock unlocked.
That looks racy and would deserve at least a comment explaining why
it's safe.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
From: Vladimir Oltean @ 2023-11-02 10:31 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Linus Walleij, Andrew Lunn, Florian Fainelli, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <CAJq09z6QwLNEc5rEGvE3jujZ-vb+vtUQLS-fkOnrdnYqk5KvxA@mail.gmail.com>
Hi Luiz,
On Wed, Nov 01, 2023 at 09:35:30AM -0300, Luiz Angelo Daros de Luca wrote:
> Hi Linus,
>
> Sorry but I noticed no issues:
>
> From the router:
>
> No. Time Source Destination Protocol Length Info
> 1 0.000000000 192.168.1.1 192.168.1.2 ICMP 1514 Echo (ping) request id=0x0789, seq=23/5888, ttl=64 (reply in 2)
> 2 0.000040094 192.168.1.2 192.168.1.1 ICMP 1514 Echo (ping) reply id=0x0789, seq=23/5888, ttl=64 (request in 1)
>
> From the host:
>
> No. Time Source Destination Protocol Length Info
> 1 0.000000000 192.168.1.2 192.168.1.1 ICMP 1514 Echo (ping) request id=0x0002, seq=8/2048, ttl=64 (reply in 2)
> 2 0.000391800 192.168.1.1 192.168.1.2 ICMP 1514 Echo (ping) reply id=0x0002, seq=8/2048, ttl=64 (request in 1)
>
> If I go over that limit, it fragments the packet as expected.
Could you run the shell command that sweeps over the entire range, fromhere?
https://lore.kernel.org/netdev/20231030222035.oqos7v7sdq5u6mti@skbuf/
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
From: Florian Westphal @ 2023-11-02 10:28 UTC (permalink / raw)
To: Dan Carpenter
Cc: Thadeu Lima de Souza Cascardo, netfilter-devel, netdev,
Pablo Neira Ayuso, Florian Westphal, Harshit Mogalapalli
In-Reply-To: <d7e42ffd-aabf-46d7-b02a-a7337708a29a@moroto.mountain>
Dan Carpenter <dan.carpenter@linaro.org> wrote:
> This patch is correct, but shouldn't we fix the code for 64 bit writes
> as well?
Care to send a patch?
> net/netfilter/nft_byteorder.c
> 26 void nft_byteorder_eval(const struct nft_expr *expr,
> 27 struct nft_regs *regs,
> 28 const struct nft_pktinfo *pkt)
> 29 {
> 30 const struct nft_byteorder *priv = nft_expr_priv(expr);
> 31 u32 *src = ®s->data[priv->sreg];
> 32 u32 *dst = ®s->data[priv->dreg];
> 33 u16 *s16, *d16;
> 34 unsigned int i;
> 35
> 36 s16 = (void *)src;
> 37 d16 = (void *)dst;
> 38
> 39 switch (priv->size) {
> 40 case 8: {
> 41 u64 src64;
> 42
> 43 switch (priv->op) {
> 44 case NFT_BYTEORDER_NTOH:
> 45 for (i = 0; i < priv->len / 8; i++) {
> 46 src64 = nft_reg_load64(&src[i]);
> 47 nft_reg_store64(&dst[i],
> 48 be64_to_cpu((__force __be64)src64));
>
> We're writing 8 bytes, then moving forward 4 bytes and writing 8 bytes
> again. Each subsequent write over-writes 4 bytes from the previous
> write.
Yes. I can't think if a case where we'd do two swaps back-to-back,
which is probably the reason noone noticed this so far.
^ permalink raw reply
* Re: [PATCH bpf-next v9 09/12] bpf, net: switch to dynamic registration
From: kernel test robot @ 2023-11-02 10:23 UTC (permalink / raw)
To: thinker.li, bpf, ast, martin.lau, song, kernel-team, andrii,
drosen
Cc: oe-kbuild-all, sinquersw, kuifeng, Kui-Feng Lee, netdev
In-Reply-To: <20231101204519.677870-10-thinker.li@gmail.com>
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/thinker-li-gmail-com/bpf-refactory-struct_ops-type-initialization-to-a-function/20231102-044820
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/20231101204519.677870-10-thinker.li%40gmail.com
patch subject: [PATCH bpf-next v9 09/12] bpf, net: switch to dynamic registration
config: x86_64-randconfig-013-20231102 (https://download.01.org/0day-ci/archive/20231102/202311021810.n3qVl5OS-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231102/202311021810.n3qVl5OS-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311021810.n3qVl5OS-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: kernel/bpf/btf.o: in function `btf_add_struct_ops':
>> kernel/bpf/btf.c:8662: undefined reference to `bpf_struct_ops_desc_init'
vim +8662 kernel/bpf/btf.c
8619
8620 static int
8621 btf_add_struct_ops(struct btf *btf, struct bpf_struct_ops *st_ops,
8622 struct bpf_verifier_log *log)
8623 {
8624 struct btf_struct_ops_tab *tab, *new_tab;
8625 int i, err;
8626
8627 if (!btf)
8628 return -ENOENT;
8629
8630 /* Assume this function is called for a module when the module is
8631 * loading.
8632 */
8633
8634 tab = btf->struct_ops_tab;
8635 if (!tab) {
8636 tab = kzalloc(offsetof(struct btf_struct_ops_tab, ops[4]),
8637 GFP_KERNEL);
8638 if (!tab)
8639 return -ENOMEM;
8640 tab->capacity = 4;
8641 btf->struct_ops_tab = tab;
8642 }
8643
8644 for (i = 0; i < tab->cnt; i++)
8645 if (tab->ops[i].st_ops == st_ops)
8646 return -EEXIST;
8647
8648 if (tab->cnt == tab->capacity) {
8649 new_tab = krealloc(tab,
8650 offsetof(struct btf_struct_ops_tab,
8651 ops[tab->capacity * 2]),
8652 GFP_KERNEL);
8653 if (!new_tab)
8654 return -ENOMEM;
8655 tab = new_tab;
8656 tab->capacity *= 2;
8657 btf->struct_ops_tab = tab;
8658 }
8659
8660 tab->ops[btf->struct_ops_tab->cnt].st_ops = st_ops;
8661
> 8662 err = bpf_struct_ops_desc_init(&tab->ops[btf->struct_ops_tab->cnt], btf, log);
8663 if (err)
8664 return err;
8665
8666 btf->struct_ops_tab->cnt++;
8667
8668 return 0;
8669 }
8670
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] net: dsa: lan9303: consequently nested-lock physical MDIO
From: patchwork-bot+netdevbpf @ 2023-11-02 10:20 UTC (permalink / raw)
To: A. Sverdlin
Cc: netdev, andrew, f.fainelli, olteanv, davem, edumazet, kuba,
pabeni, jbe, jerry.ray, mans, stable
In-Reply-To: <20231027065741.534971-1-alexander.sverdlin@siemens.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Oct 2023 08:57:38 +0200 you wrote:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
>
> When LAN9303 is MDIO-connected two callchains exist into
> mdio->bus->write():
>
> 1. switch ports 1&2 ("physical" PHYs):
>
> [...]
Here is the summary with links:
- net: dsa: lan9303: consequently nested-lock physical MDIO
https://git.kernel.org/netdev/net/c/5a22fbcc10f3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net, sched: Fix SKB_NOT_DROPPED_YET splat under debug config
From: Paolo Abeni @ 2023-11-02 10:17 UTC (permalink / raw)
To: Daniel Borkmann, Jamal Hadi Salim; +Cc: kuba, idosch, netdev, bpf
In-Reply-To: <5ab182b6-6ac7-16f7-7eae-7001be2b6da7@iogearbox.net>
On Fri, 2023-10-27 at 20:21 +0200, Daniel Borkmann wrote:
> On 10/27/23 7:24 PM, Jamal Hadi Salim wrote:
> > On Fri, Oct 27, 2023 at 9:51 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > >
> > > Ido reported:
> > >
> > > [...] getting the following splat [1] with CONFIG_DEBUG_NET=y and this
> > > reproducer [2]. Problem seems to be that classifiers clear 'struct
> > > tcf_result::drop_reason', thereby triggering the warning in
> > > __kfree_skb_reason() due to reason being 'SKB_NOT_DROPPED_YET' (0). [...]
> > >
> > > [1]
> > > WARNING: CPU: 0 PID: 181 at net/core/skbuff.c:1082 kfree_skb_reason+0x38/0x130
> > > Modules linked in:
> > > CPU: 0 PID: 181 Comm: mausezahn Not tainted 6.6.0-rc6-custom-ge43e6d9582e0 #682
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
> > > RIP: 0010:kfree_skb_reason+0x38/0x130
> > > [...]
> > > Call Trace:
> > > <IRQ>
> > > __netif_receive_skb_core.constprop.0+0x837/0xdb0
> > > __netif_receive_skb_one_core+0x3c/0x70
> > > process_backlog+0x95/0x130
> > > __napi_poll+0x25/0x1b0
> > > net_rx_action+0x29b/0x310
> > > __do_softirq+0xc0/0x29b
> > > do_softirq+0x43/0x60
> > > </IRQ>
> > >
> > > [2]
> > > #!/bin/bash
> > >
> > > ip link add name veth0 type veth peer name veth1
> > > ip link set dev veth0 up
> > > ip link set dev veth1 up
> > > tc qdisc add dev veth1 clsact
> > > tc filter add dev veth1 ingress pref 1 proto all flower dst_mac 00:11:22:33:44:55 action drop
> > > mausezahn veth0 -a own -b 00:11:22:33:44:55 -q -c 1
> > >
> > > What happens is that inside most classifiers the tcf_result is copied over
> > > from a filter template e.g. *res = f->res which then implicitly overrides
> > > the prior SKB_DROP_REASON_TC_{INGRESS,EGRESS} default drop code which was
> > > set via sch_handle_{ingress,egress}() for kfree_skb_reason().
> > >
> > > Add a small helper tcf_set_result() and convert classifiers over to it.
> > > The latter leaves the drop code intact and classifiers, actions as well
> > > as the action engine in tcf_exts_exec() can then in future make use of
> > > tcf_set_drop_reason(), too.
> > >
> > > Tested that the splat is fixed under CONFIG_DEBUG_NET=y with the repro.
> > >
> > > Fixes: 54a59aed395c ("net, sched: Make tc-related drop reason more flexible")
> > > Reported-by: Ido Schimmel <idosch@idosch.org>
> > > Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> > > Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> > > Cc: Jakub Kicinski <kuba@kernel.org>
> > > Link: https://lore.kernel.org/netdev/ZTjY959R+AFXf3Xy@shredder
> > > ---
> > > include/net/pkt_cls.h | 12 ++++++++++++
> > > net/sched/cls_basic.c | 2 +-
> > > net/sched/cls_bpf.c | 2 +-
> > > net/sched/cls_flower.c | 2 +-
> > > net/sched/cls_fw.c | 2 +-
> > > net/sched/cls_matchall.c | 2 +-
> > > net/sched/cls_route.c | 4 ++--
> > > net/sched/cls_u32.c | 2 +-
> > > 8 files changed, 20 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> > > index a76c9171db0e..31d8e8587824 100644
> > > --- a/include/net/pkt_cls.h
> > > +++ b/include/net/pkt_cls.h
> > > @@ -160,6 +160,18 @@ static inline void tcf_set_drop_reason(struct tcf_result *res,
> > > res->drop_reason = reason;
> > > }
> > >
> > > +static inline void tcf_set_result(struct tcf_result *to,
> > > + const struct tcf_result *from)
> > > +{
> > > + /* tcf_result's drop_reason which is the last member must be
> > > + * preserved and cannot be copied from the cls'es tcf_result
> > > + * template given this is carried all the way and potentially
> > > + * set to a concrete tc drop reason upon error or intentional
> > > + * drop. See tcf_set_drop_reason() locations.
> > > + */
> > > + memcpy(to, from, offsetof(typeof(*to), drop_reason));
> > > +}
> >
> > I believe our bigger issue here is we are using this struct now for
> > both policy set by the control plane and for runtime decisions
>
> Hm, but that was also either way in the original rfc.
>
> > (drop_reason) - whereas the original assumption was this struct only
> > held set policy. In retrospect we should have put the verdict(which is
> > policy) here and return the error code (as was in the first patch). I
> > am also not sure humans would not make a mistake on "this field must
> > be at the end of the struct". Can we put some assert (or big comment
> > on the struct) to make sure someone does not overwrite this field?
>
> Yeah that can be done.
FTR, I agree the comment or even better a build_bug_on() somewhere
should be better.
Thanks!
Paolo
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
From: Dan Carpenter @ 2023-11-02 10:16 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: netfilter-devel, netdev, Pablo Neira Ayuso, Florian Westphal,
Harshit Mogalapalli
In-Reply-To: <20230705210535.943194-1-cascardo@canonical.com>
On Wed, Jul 05, 2023 at 06:05:35PM -0300, Thadeu Lima de Souza Cascardo wrote:
> diff --git a/net/netfilter/nft_byteorder.c b/net/netfilter/nft_byteorder.c
> index 9a85e797ed58..e596d1a842f7 100644
> --- a/net/netfilter/nft_byteorder.c
> +++ b/net/netfilter/nft_byteorder.c
> @@ -30,11 +30,11 @@ void nft_byteorder_eval(const struct nft_expr *expr,
> const struct nft_byteorder *priv = nft_expr_priv(expr);
> u32 *src = ®s->data[priv->sreg];
> u32 *dst = ®s->data[priv->dreg];
> - union { u32 u32; u16 u16; } *s, *d;
> + u16 *s16, *d16;
> unsigned int i;
>
> - s = (void *)src;
> - d = (void *)dst;
> + s16 = (void *)src;
> + d16 = (void *)dst;
>
> switch (priv->size) {
> case 8: {
This patch is correct, but shouldn't we fix the code for 64 bit writes
as well?
net/netfilter/nft_byteorder.c
26 void nft_byteorder_eval(const struct nft_expr *expr,
27 struct nft_regs *regs,
28 const struct nft_pktinfo *pkt)
29 {
30 const struct nft_byteorder *priv = nft_expr_priv(expr);
31 u32 *src = ®s->data[priv->sreg];
32 u32 *dst = ®s->data[priv->dreg];
33 u16 *s16, *d16;
34 unsigned int i;
35
36 s16 = (void *)src;
37 d16 = (void *)dst;
38
39 switch (priv->size) {
40 case 8: {
41 u64 src64;
42
43 switch (priv->op) {
44 case NFT_BYTEORDER_NTOH:
45 for (i = 0; i < priv->len / 8; i++) {
46 src64 = nft_reg_load64(&src[i]);
47 nft_reg_store64(&dst[i],
48 be64_to_cpu((__force __be64)src64));
We're writing 8 bytes, then moving forward 4 bytes and writing 8 bytes
again. Each subsequent write over-writes 4 bytes from the previous
write.
49 }
50 break;
51 case NFT_BYTEORDER_HTON:
52 for (i = 0; i < priv->len / 8; i++) {
53 src64 = (__force __u64)
54 cpu_to_be64(nft_reg_load64(&src[i]));
55 nft_reg_store64(&dst[i], src64);
Same.
56 }
57 break;
58 }
59 break;
60 }
61 case 4:
62 switch (priv->op) {
63 case NFT_BYTEORDER_NTOH:
64 for (i = 0; i < priv->len / 4; i++)
65 dst[i] = ntohl((__force __be32)src[i]);
66 break;
67 case NFT_BYTEORDER_HTON:
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 2/2] net: mwifiex: add support for the SD8777 chipset
From: Ulf Hansson @ 2023-11-02 10:13 UTC (permalink / raw)
To: Karel Balej
Cc: Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brian Norris, linux-wireless, netdev, devicetree, linux-kernel,
linux-mmc, Duje Mihanović, ~postmarketos/upstreaming,
phone-devel
In-Reply-To: <20231029111807.19261-3-balejk@matfyz.cz>
On Sun, 29 Oct 2023 at 12:19, Karel Balej <balejk@matfyz.cz> wrote:
>
> Marvell SD8777 is a wireless chipset used for instance in the PXA1908
> SoC found for example in the samsung,coreprimevelte smartphone, with
> which this was tested. The driver seems to be compatible with this
> chipset so enable this support by adding the necessary information based
> on the downstream code.
>
> Signed-off-by: Karel Balej <balejk@matfyz.cz>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Kind regards
Uffe
> ---
> drivers/net/wireless/marvell/mwifiex/Kconfig | 4 ++--
> drivers/net/wireless/marvell/mwifiex/sdio.c | 19 +++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
> include/linux/mmc/sdio_ids.h | 1 +
> 4 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/Kconfig b/drivers/net/wireless/marvell/mwifiex/Kconfig
> index b182f7155d66..a7bd2c5735f6 100644
> --- a/drivers/net/wireless/marvell/mwifiex/Kconfig
> +++ b/drivers/net/wireless/marvell/mwifiex/Kconfig
> @@ -10,13 +10,13 @@ config MWIFIEX
> mwifiex.
>
> config MWIFIEX_SDIO
> - tristate "Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897/SD8977/SD8978/SD8987/SD8997"
> + tristate "Marvell WiFi-Ex Driver for SD8777/SD8786/SD8787/SD8797/SD8887/SD8897/SD8977/SD8978/SD8987/SD8997"
> depends on MWIFIEX && MMC
> select FW_LOADER
> select WANT_DEV_COREDUMP
> help
> This adds support for wireless adapters based on Marvell
> - 8786/8787/8797/8887/8897/8977/8978/8987/8997 chipsets with
> + 8777/8786/8787/8797/8887/8897/8977/8978/8987/8997 chipsets with
> SDIO interface. SD8978 is also known as NXP IW416.
>
> If you choose to build it as a module, it will be called
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index 774858cfe86f..c55f1f5669cb 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -318,6 +318,21 @@ static const struct mwifiex_sdio_card_reg mwifiex_reg_sd89xx = {
> 0x68, 0x69, 0x6a},
> };
>
> +static const struct mwifiex_sdio_device mwifiex_sdio_sd8777 = {
> + .firmware = SD8777_DEFAULT_FW_NAME,
> + .reg = &mwifiex_reg_sd87xx,
> + .max_ports = 16,
> + .mp_agg_pkt_limit = 8,
> + .tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K,
> + .mp_tx_agg_buf_size = MWIFIEX_MP_AGGR_BUF_SIZE_16K,
> + .mp_rx_agg_buf_size = MWIFIEX_MP_AGGR_BUF_SIZE_16K,
> + .supports_sdio_new_mode = false,
> + .has_control_mask = true,
> + .can_dump_fw = false,
> + .can_auto_tdls = false,
> + .can_ext_scan = true,
> +};
> +
> static const struct mwifiex_sdio_device mwifiex_sdio_sd8786 = {
> .firmware = SD8786_DEFAULT_FW_NAME,
> .reg = &mwifiex_reg_sd87xx,
> @@ -496,6 +511,7 @@ static struct memory_type_mapping mem_type_mapping_tbl[] = {
> };
>
> static const struct of_device_id mwifiex_sdio_of_match_table[] __maybe_unused = {
> + { .compatible = "marvell,sd8777" },
> { .compatible = "marvell,sd8787" },
> { .compatible = "marvell,sd8897" },
> { .compatible = "marvell,sd8978" },
> @@ -924,6 +940,8 @@ static void mwifiex_sdio_coredump(struct device *dev)
>
> /* WLAN IDs */
> static const struct sdio_device_id mwifiex_ids[] = {
> + {SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8777_WLAN),
> + .driver_data = (unsigned long)&mwifiex_sdio_sd8777},
> {SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8786_WLAN),
> .driver_data = (unsigned long) &mwifiex_sdio_sd8786},
> {SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8787_WLAN),
> @@ -3180,6 +3198,7 @@ MODULE_AUTHOR("Marvell International Ltd.");
> MODULE_DESCRIPTION("Marvell WiFi-Ex SDIO Driver version " SDIO_VERSION);
> MODULE_VERSION(SDIO_VERSION);
> MODULE_LICENSE("GPL v2");
> +MODULE_FIRMWARE(SD8777_DEFAULT_FW_NAME);
> MODULE_FIRMWARE(SD8786_DEFAULT_FW_NAME);
> MODULE_FIRMWARE(SD8787_DEFAULT_FW_NAME);
> MODULE_FIRMWARE(SD8797_DEFAULT_FW_NAME);
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index ae94c172310f..ed92256b2302 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -18,6 +18,7 @@
>
> #include "main.h"
>
> +#define SD8777_DEFAULT_FW_NAME "mrvl/sd8777_uapsta.bin"
> #define SD8786_DEFAULT_FW_NAME "mrvl/sd8786_uapsta.bin"
> #define SD8787_DEFAULT_FW_NAME "mrvl/sd8787_uapsta.bin"
> #define SD8797_DEFAULT_FW_NAME "mrvl/sd8797_uapsta.bin"
> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
> index 7fada7a714fe..c46ab35ceb20 100644
> --- a/include/linux/mmc/sdio_ids.h
> +++ b/include/linux/mmc/sdio_ids.h
> @@ -94,6 +94,7 @@
> #define SDIO_DEVICE_ID_MARVELL_8797_BT 0x912a
> #define SDIO_DEVICE_ID_MARVELL_8897_WLAN 0x912d
> #define SDIO_DEVICE_ID_MARVELL_8897_BT 0x912e
> +#define SDIO_DEVICE_ID_MARVELL_8777_WLAN 0x9131
> #define SDIO_DEVICE_ID_MARVELL_8887_F0 0x9134
> #define SDIO_DEVICE_ID_MARVELL_8887_WLAN 0x9135
> #define SDIO_DEVICE_ID_MARVELL_8887_BT 0x9136
> --
> 2.42.0
>
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
From: Vladimir Oltean @ 2023-11-02 10:04 UTC (permalink / raw)
To: Linus Walleij
Cc: Luiz Angelo Daros de Luca, Andrew Lunn, Florian Fainelli,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <CACRpkdaoBo0S0RgLhacObd3pbjtWAfr6s3oizQAHqdB76gaG5A@mail.gmail.com>
On Wed, Nov 01, 2023 at 09:26:50PM +0100, Linus Walleij wrote:
> > [ 3.967086] realtek-smi switch: set MAC: 42:E4:F5:XX:XX:XX
>
> Unrelated: I have seen other DSA switches "inherit" the MAC of the
> conduit interface (BRCM). I wonder if we could do that too instead
> of this random MAC number. Usually the conduit interface has a
> properly configured MAC.
We need to know what is the MAC address from the RTL8366RB_SMAR
registers used for.
What you know about is that DSA user interfaces have their own MAC
address for packet termination (send/receive to/from the CPU). MAC
addresses for switch ports are an abstract concept, of course (switches
normally just forward packets, nothing is addressed *to* them), and so,
these addresses are not programmed per se to hardware unless the
prerequisites of dsa_switch_supports_uc_filtering() are implemented.
If they are, the MAC addresses of user ports are programmed as host FDB
entries (FDB entries towards the CPU port).
The rule for establishing the MAC address of each user port is as
follows: if of_get_mac_address() finds something valid for that port's
OF node - provided by the bootloader - ("address", "mac-address",
"local-mac-address", a nvmem provider etc), then that value is used.
Otherwise, the MAC address is inherited from the conduit interface.
Some switches also have a global MAC address register (used for all
ports) of their own, but it is switch-specific what this does. We look
at the functionality it offers when deciding what to program it to,
since it's of course not possible to sync a single hardware register to
the value of the MAC addresses of multiple user ports.
For KSZ switches - see ksz_switch_macaddr_get() - the global MAC address
register is used for HSR self-address filtering and for Wake on LAN.
We sync the value of this hardware register with the MAC address of the
first user port on which these optional features are enabled. Then, we
allow these optional features only on the other user ports which have
the same MAC address as the original one which enabled that feature.
On KSZ, the same switch MAC address is also used as MAC SA in generated
pause frames, but to our knowledge, that MAC address could be any
address (even 00:00:00:00:00:00), so we don't really care too much about
that and we let it fall to whatever value it may.
^ permalink raw reply
* Re: [RFC 0/7] vdpa: Add support for iommufd
From: Michael S. Tsirkin @ 2023-11-02 10:02 UTC (permalink / raw)
To: Cindy Lu; +Cc: jasowang, yi.l.liu, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <CACLfguXstNSC20x=acDx20CXU3UksURDY04Z89DM_sNbGeTELQ@mail.gmail.com>
On Thu, Oct 26, 2023 at 02:48:07PM +0800, Cindy Lu wrote:
> On Thu, Oct 26, 2023 at 2:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Sun, Sep 24, 2023 at 01:05:33AM +0800, Cindy Lu wrote:
> > > Hi All
> > > Really apologize for the delay, this is the draft RFC for
> > > iommufd support for vdpa, This code provides the basic function
> > > for iommufd support
> > >
> > > The code was tested and passed in device vdpa_sim_net
> > > The qemu code is
> > > https://gitlab.com/lulu6/gitlabqemutmp/-/tree/iommufdRFC
> > > The kernel code is
> > > https://gitlab.com/lulu6/vhost/-/tree/iommufdRFC
> > >
> > > ToDo
> > > 1. this code is out of date and needs to clean and rebase on the latest code
> > > 2. this code has some workaround, I Skip the check for
> > > iommu_group and CACHE_COHERENCY, also some misc issues like need to add
> > > mutex for iommfd operations
> > > 3. only test in emulated device, other modes not tested yet
> > >
> > > After addressed these problems I will send out a new version for RFC. I will
> > > provide the code in 3 weeks
> >
> > What's the status here?
> >
> Hi Michael
> The code is finished, but I found some bug after adding the support for ASID,
> will post the new version after this bug is fixed, should be next week
> Thanks
> Cindy
The week is almost gone, what's going on?
> > --
> > MST
> >
^ permalink raw reply
* Re: [PATCH] net: ipmr_base: Check iif when returning a (*, G) MFC
From: Ido Schimmel @ 2023-11-02 9:52 UTC (permalink / raw)
To: Yang Sun; +Cc: davem, dsahern, edumazet, kuba, pabeni, netdev, nicolas.dichtel
In-Reply-To: <20231031015756.1843599-1-sunytt@google.com>
+ Nicolas
On Tue, Oct 31, 2023 at 09:57:56AM +0800, Yang Sun wrote:
> Looking for a (*, G) MFC returns the first match without checking
> the iif. This can return a MFC not intended for a packet's iif and
> forwarding the packet with this MFC will not work correctly.
>
> When looking up for a (*, G) MFC, check that the MFC's iif is
> the same as the packet's iif.
Is this a regression (doesn't seem that way)? If not, the change should
be targeted at net-next which is closed right now:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> Signed-off-by: Yang Sun <sunytt@google.com>
> ---
> net/ipv4/ipmr_base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
> index 271dc03fc6db..5cf7c7088dfe 100644
> --- a/net/ipv4/ipmr_base.c
> +++ b/net/ipv4/ipmr_base.c
> @@ -97,7 +97,7 @@ void *mr_mfc_find_any(struct mr_table *mrt, int vifi, void *hasharg)
>
> list = rhltable_lookup(&mrt->mfc_hash, hasharg, *mrt->ops.rht_params);
> rhl_for_each_entry_rcu(c, tmp, list, mnode) {
> - if (c->mfc_un.res.ttls[vifi] < 255)
> + if (c->mfc_parent == vifi && c->mfc_un.res.ttls[vifi] < 255)
What happens if the route doesn't have an iif (-1)? It won't match
anymore?
> return c;
>
> /* It's ok if the vifi is part of the static tree */
> --
> 2.42.0.820.g83a721a137-goog
>
>
^ permalink raw reply
* Re: [PATCH net v1 1/2] octeontx2-pf: Fix error codes
From: patchwork-bot+netdevbpf @ 2023-11-02 9:50 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: netdev, linux-kernel, sgoutham, gakula, sbhatta, hkelam, davem,
edumazet, kuba, pabeni, wojciech.drewek
In-Reply-To: <20231027021953.1819959-1-rkannoth@marvell.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Oct 2023 07:49:52 +0530 you wrote:
> Some of error codes were wrong. Fix the same.
>
> Fixes: 51afe9026d0c ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]")
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
>
> ---
>
> [...]
Here is the summary with links:
- [net,v1,1/2] octeontx2-pf: Fix error codes
https://git.kernel.org/netdev/net/c/96b9a68d1a6e
- [net,v1,2/2] octeontx2-pf: Fix holes in error code
https://git.kernel.org/netdev/net/c/7aeeb2cb7a25
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] inet: shrink struct flowi_common
From: patchwork-bot+netdevbpf @ 2023-11-02 9:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, netdev, eric.dumazet, wenxu
In-Reply-To: <20231025141037.3448203-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 25 Oct 2023 14:10:37 +0000 you wrote:
> I am looking at syzbot reports triggering kernel stack overflows
> involving a cascade of ipvlan devices.
>
> We can save 8 bytes in struct flowi_common.
>
> This patch alone will not fix the issue, but is a start.
>
> [...]
Here is the summary with links:
- [net] inet: shrink struct flowi_common
https://git.kernel.org/netdev/net/c/1726483b79a7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] net/smc: avoid atomic_set and smp_wmb in the tx path when possible
From: Li RongQing @ 2023-11-02 9:27 UTC (permalink / raw)
To: linux-s390, netdev
these is less opportunity that conn->tx_pushing is not 1, since
tx_pushing is just checked with 1, so move the setting tx_pushing
to 1 after atomic_dec_and_test() return false, to avoid atomic_set
and smp_wmb in tx path when possible
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/smc/smc_tx.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/smc/smc_tx.c b/net/smc/smc_tx.c
index 3b0ff3b..72dbdee 100644
--- a/net/smc/smc_tx.c
+++ b/net/smc/smc_tx.c
@@ -667,8 +667,6 @@ int smc_tx_sndbuf_nonempty(struct smc_connection *conn)
return 0;
again:
- atomic_set(&conn->tx_pushing, 1);
- smp_wmb(); /* Make sure tx_pushing is 1 before real send */
rc = __smc_tx_sndbuf_nonempty(conn);
/* We need to check whether someone else have added some data into
@@ -677,8 +675,11 @@ int smc_tx_sndbuf_nonempty(struct smc_connection *conn)
* If so, we need to push again to prevent those data hang in the send
* queue.
*/
- if (unlikely(!atomic_dec_and_test(&conn->tx_pushing)))
+ if (unlikely(!atomic_dec_and_test(&conn->tx_pushing))) {
+ atomic_set(&conn->tx_pushing, 1);
+ smp_wmb(); /* Make sure tx_pushing is 1 before real send */
goto again;
+ }
return rc;
}
--
2.9.4
^ permalink raw reply related
* Re: [PATCH] net: usbnet: Fix potential NULL pointer dereference
From: Ren Mingshuai @ 2023-11-02 9:06 UTC (permalink / raw)
To: kuba
Cc: caowangbao, davem, khlebnikov, liaichun, linux-kernel, netdev,
oneukum, renmingshuai, yanan
In-Reply-To: <20231101213832.77bd657b@kernel.org>
>> >23ba07991dad said SKB can be NULL without describing the triggering
>> >scenario. Always Check it before dereference to void potential NULL
>> >pointer dereference.
>> I've tried to find out the scenarios where SKB is NULL, but failed.
>> It seems impossible for SKB to be NULL. If SKB can be NULL, please
>> tell me the reason and I'd be very grateful.
>
>What do you mean? Grepping the function name shows call sites with NULL getting passed as skb.
Yes And I just learned that during the cdc_ncm_driver.probe, it is possible to pass a NULL SKB to usbnet_start_xmit().
^ permalink raw reply
* Re: [PATCH] rfkill: return ENOTTY on invalid ioctl
From: Przemek Kitszel @ 2023-11-02 8:57 UTC (permalink / raw)
To: Thomas Weißschuh, Johannes Berg, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20231101-rfkill-ioctl-enosys-v1-1-5bf374fabffe@weissschuh.net>
On 11/1/23 20:41, Thomas Weißschuh wrote:
> For unknown ioctls the correct error is
> ENOTTY "Inappropriate ioctl for device".
For sure!
I would like to learn more of why this is not an UAPI breaking change?
>
> ENOSYS as returned before should only be used to indicate that a syscall
> is not available at all.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> net/rfkill/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index 14cc8fe8584b..c3feb4f49d09 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -1351,11 +1351,11 @@ static long rfkill_fop_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> struct rfkill_data *data = file->private_data;
> - int ret = -ENOSYS;
> + int ret = -ENOTTY;
> u32 size;
>
> if (_IOC_TYPE(cmd) != RFKILL_IOC_MAGIC)
> - return -ENOSYS;
> + return -ENOTTY;
>
> mutex_lock(&data->mtx);
> switch (_IOC_NR(cmd)) {
>
> ---
> base-commit: 7d461b291e65938f15f56fe58da2303b07578a76
> change-id: 20231101-rfkill-ioctl-enosys-00a2bb0a4ab1
>
> Best regards,
^ permalink raw reply
* Re: Does anyone use Appletalk?
From: John Paul Adrian Glaubitz @ 2023-11-02 8:55 UTC (permalink / raw)
To: Finn Thain, Arnd Bergmann
Cc: Dan Williams, Geert Uytterhoeven, linux-m68k, Jakub Kicinski,
Netdev, linuxppc-dev
In-Reply-To: <973278b8-c9e5-b1cf-2e08-2ff8fd8e9aa4@linux-m68k.org>
On Thu, 2023-11-02 at 13:13 +1100, Finn Thain wrote:
> So I can't object to the removal of the localtalk code. But I do object to
> the underhand manner in which it is done.
I agree. I have the impression that the actual users of the affected code are
never asked. It's usually a question posed on a mailing list where 99% of the
affected users don't hang around.
Naturally, there won't be any objections to the removal because affected users
didn't receive a heads-up in the first place.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [REGRESSION] Userland interface breaks due to hard HFSC_FSC requirement
From: Linux regression tracking #update (Thorsten Leemhuis) @ 2023-11-02 8:05 UTC (permalink / raw)
To: stable, netdev; +Cc: regressions
In-Reply-To: <78f59b5f-33d7-4b5b-9b7c-ee7a4647b35f@leemhuis.info>
On 01.11.23 20:05, Linux regression tracking #update (Thorsten Leemhuis)
wrote:
> [TLDR: This mail in primarily relevant for Linux kernel regression
> tracking. See link in footer if these mails annoy you.]
>
> On 06.10.23 10:37, Christian Theune wrote:
>>
>> I upgraded from 6.1.38 to 6.1.55 this morning and it broke my traffic shaping script, leaving me with a non-functional uplink on a remote router.
>> [...]
>> #regzbot introduced: a1e820fc7808e42b990d224f40e9b4895503ac40
>
> #regzbot fix: net/sched: sch_hfsc: upgrade rt to sc when it becomes a
> inner curve
> #regzbot ignore-activity
Sorry, that had a typo:
#regzbot fix: d80bc191420a2edecb555b
#regzbot ignore-activity
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
^ permalink raw reply
* Missing a write memory barrier in tls_init()
From: Dae R. Jeong @ 2023-11-02 7:11 UTC (permalink / raw)
To: borisp, john.fastabend, kuba, davem, edumazet, pabeni, netdev,
linux-kernel
Cc: ywchoi
Hello,
It seems a write memory barrier is missing in tls_init() (or
tls_ctx_create()). In the following execution, NULL dereference may
happen in {tls_setsockopt, tls_getsockopt}.
CPU0 CPU1
----- -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx->sk_proto = READ_ONCE(sk->sk_prot) - (1)
// In update_sk_prot()
WRITE_ONCE(sk->sk_prot, tls_prots) - (2)
// In sock_common_setsockopt()
READ_ONCE(sk->sk_prot)->setsockopt()
// In tls_{setsockopt,getsockopt}()
ctx->sk_proto->setsockopt() - (3)
In the above concurrent execution, nothing prevents store-store
reordering in CPU0, so it is possible that CPU0 completes (2) before
(1). If it happens, CPU1 may crash at (3).
To prevent such out-of-order execution, I think we need something like
this (although I don't like smp_wmb(). smp_store_release() should be
better):
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 1c2c6800949d..5dccde91f9b1 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -819,6 +819,7 @@ struct tls_context *tls_ctx_create(struct sock *sk)
rcu_assign_pointer(icsk->icsk_ulp_data, ctx);
ctx->sk_proto = READ_ONCE(sk->sk_prot);
ctx->sk = sk;
+ smp_wmb();
return ctx;
}
In addition, I believe the {tls_setsockopt, tls_getsockopt}
implementation is fine because of the address dependency. I think
load-load reordering is prohibited in this case so we don't need a
read barrier.
Could you check this?
Best regards,
Dae R. Jeong
^ permalink raw reply related
* Re: [PATCH] [PATCH net] tg3: power down device only on SYSTEM_POWER_OFF
From: Pavan Chebbi @ 2023-11-02 7:04 UTC (permalink / raw)
To: George Shuklin; +Cc: netdev, Andrew Gospodarek, Michael Chan
In-Reply-To: <31a5cfe8-133d-4548-9814-cf3e61d89307@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
On Thu, Nov 2, 2023 at 1:28 AM George Shuklin <george.shuklin@gmail.com> wrote:
>
> On 01/11/2023 17:20, Pavan Chebbi wrote:
> > On Wed, Nov 1, 2023 at 6:34 PM George Shuklin <george.shuklin@gmail.com> wrote:
> >> Dell R650xs servers hangs if tg3 driver calls tg3_power_down.
> >>
> >> This happens only if network adapters (BCM5720 for R650xs) were
> >> initialized using SNP (e.g. by booting ipxe.efi).
> >>
> >> This is partial revert of commit 2ca1c94ce0b.
> >>
> >> The actual problem is on Dell side, but this fix allow servers
> >> to come back alive after reboot.
> > How are you sure that the problem solved by 2ca1c94ce0b is not
> > reintroduced with this change?
>
> I contacted the author of original patch, no reply yet (1st day). Also,
> I tested it on few generations of available Dell servers (R330, R340,
> R350 and R650sx, for which this fix should help). It does produce log
> message from
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917471, but, at
> least, it reboots without issues.
>
> Actually, original patch is regression: 5.19 rebooting just fine, 6.0
> start to hang. I also reported it to dell support forum, but I'm not
> sure if they pick it up or not.
>
> What would be the proper course of actions for such problem (outside of
> fixing UEFI SNP, for which I don't have access to sources)?
>
Thanks for the explanation. I am not sure if we should make this
change unless we are 100pc sure that this patch won't cause
regression.
I feel Dell is in the best position to debug this and they can even
contact Broadcom if they see any problem in UEFI.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4209 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox