Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] connector: remove redundant input callback from cn_dev
From: David Miller @ 2019-07-21 20:31 UTC (permalink / raw)
  To: vvs; +Cc: linux-kernel, zbr, stanislav.kinsburskiy, netdev
In-Reply-To: <1f53c1fb-c42e-fb78-7b2b-ad6c4712fe72@virtuozzo.com>

From: Vasily Averin <vvs@virtuozzo.com>
Date: Thu, 18 Jul 2019 07:26:46 +0300

> A small cleanup: this callback is never used.
> Originally fixed by Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
> for OpenVZ7 bug OVZ-6877
> 
> cc: stanislav.kinsburskiy@gmail.com
> Signed-off-by: Vasily Averin <vvs@virtuozzo.com>

Applied.

^ permalink raw reply

* Re: [PATCH] qed: Prefer pcie_capability_read_word()
From: David Miller @ 2019-07-21 20:30 UTC (permalink / raw)
  To: fred; +Cc: aelior, GR-everest-linux-l2, netdev, linux-kernel, bhelgaas
In-Reply-To: <20190718020745.8867-7-fred@fredlawl.com>

From: Frederick Lawler <fred@fredlawl.com>
Date: Wed, 17 Jul 2019 21:07:42 -0500

> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
> 
> Replace pci_read_config_word() and pci_write_config_word() calls with
> pcie_capability_read_word() and pcie_capability_write_word().
> 
> Signed-off-by: Frederick Lawler <fred@fredlawl.com>

Applied.

^ permalink raw reply

* Re: [PATCH] igc: Prefer pcie_capability_read_word()
From: David Miller @ 2019-07-21 20:30 UTC (permalink / raw)
  To: fred; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel,
	bhelgaas
In-Reply-To: <20190718020745.8867-4-fred@fredlawl.com>

From: Frederick Lawler <fred@fredlawl.com>
Date: Wed, 17 Jul 2019 21:07:39 -0500

> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
> 
> Replace pci_read_config_word() and pci_write_config_word() calls with
> pcie_capability_read_word() and pcie_capability_write_word().
> 
> Signed-off-by: Frederick Lawler <fred@fredlawl.com>

Applied.

^ permalink raw reply

* Re: [PATCH] cxgb4: Prefer pcie_capability_read_word()
From: David Miller @ 2019-07-21 20:30 UTC (permalink / raw)
  To: fred; +Cc: vishal, netdev, linux-kernel, bhelgaas
In-Reply-To: <20190718020745.8867-1-fred@fredlawl.com>

From: Frederick Lawler <fred@fredlawl.com>
Date: Wed, 17 Jul 2019 21:07:36 -0500

> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
> 
> Replace pci_read_config_word() and pci_write_config_word() calls with
> pcie_capability_read_word() and pcie_capability_write_word().
> 
> Signed-off-by: Frederick Lawler <fred@fredlawl.com>

Applied.

^ permalink raw reply

* Re: [PATCH net] be2net: Synchronize be_update_queues with dev_watchdog
From: David Miller @ 2019-07-21 20:22 UTC (permalink / raw)
  To: bpoirier
  Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
	fyang, saeedm, netdev
In-Reply-To: <20190718014218.16610-1-bpoirier@suse.com>

From: Benjamin Poirier <bpoirier@suse.com>
Date: Thu, 18 Jul 2019 10:42:18 +0900

> As pointed out by Firo Yang, a netdev tx timeout may trigger just before an
> ethtool set_channels operation is started. be_tx_timeout(), which dumps
> some queue structures, is not written to run concurrently with
> be_update_queues(), which frees/allocates those queues structures. Add some
> synchronization between the two.
> 
> Message-id: <CH2PR18MB31898E033896F9760D36BFF288C90@CH2PR18MB3189.namprd18.prod.outlook.com>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH] bnx2x: Prevent load reordering in tx completion processing
From: David Miller @ 2019-07-21 19:29 UTC (permalink / raw)
  To: brking; +Cc: GR-everest-linux-l2, skalluru, aelior, netdev
In-Reply-To: <1563226910-21660-1-git-send-email-brking@linux.vnet.ibm.com>

From: Brian King <brking@linux.vnet.ibm.com>
Date: Mon, 15 Jul 2019 16:41:50 -0500

> This patch fixes an issue seen on Power systems with bnx2x which results
> in the skb is NULL WARN_ON in bnx2x_free_tx_pkt firing due to the skb
> pointer getting loaded in bnx2x_free_tx_pkt prior to the hw_cons
> load in bnx2x_tx_int. Adding a read memory barrier resolves the issue.
> 
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [PATCH] netfilter: ebtables: compat: fix a memory leak bug
From: Pablo Neira Ayuso @ 2019-07-21 18:59 UTC (permalink / raw)
  To: Wenwen Wang
  Cc: Wenwen Wang, Jozsef Kadlecsik, Florian Westphal, Roopa Prabhu,
	Nikolay Aleksandrov, David S. Miller, open list:NETFILTER,
	open list:NETFILTER, moderated list:ETHERNET BRIDGE,
	open list:ETHERNET BRIDGE, open list
In-Reply-To: <1563625366-3602-1-git-send-email-wang6495@umn.edu>

On Sat, Jul 20, 2019 at 07:22:45AM -0500, Wenwen Wang wrote:
> From: Wenwen Wang <wenwen@cs.uga.edu>
> 
> In compat_do_replace(), a temporary buffer is allocated through vmalloc()
> to hold entries copied from the user space. The buffer address is firstly
> saved to 'newinfo->entries', and later on assigned to 'entries_tmp'. Then
> the entries in this temporary buffer is copied to the internal kernel
> structure through compat_copy_entries(). If this copy process fails,
> compat_do_replace() should be terminated. However, the allocated temporary
> buffer is not freed on this path, leading to a memory leak.
> 
> To fix the bug, free the buffer before returning from compat_do_replace().

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net] net: phy: sfp: hwmon: Fix scaling of RX power
From: David Miller @ 2019-07-21 18:52 UTC (permalink / raw)
  To: andrew; +Cc: netdev, rmk+kernel, Chris.Healy
In-Reply-To: <20190721165008.26597-1-andrew@lunn.ch>

From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 21 Jul 2019 18:50:08 +0200

> The RX power read from the SFP uses units of 0.1uW. This must be
> scaled to units of uW for HWMON. This requires a divide by 10, not the
> current 100.
> 
> With this change in place, sensors(1) and ethtool -m agree:
> 
> sff2-isa-0000
> Adapter: ISA adapter
> in0:          +3.23 V
> temp1:        +33.1 C
> power1:      270.00 uW
> power2:      200.00 uW
> curr1:        +0.01 A
> 
>         Laser output power                        : 0.2743 mW / -5.62 dBm
>         Receiver signal average optical power     : 0.2014 mW / -6.96 dBm
> 
> Reported-by: chris.healy@zii.aero
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")

Applied and queued up for -stable, thanks Andrew.

^ permalink raw reply

* Re: [PATCH net-next] net: sched: verify that q!=NULL before setting q->flags
From: David Miller @ 2019-07-21 18:50 UTC (permalink / raw)
  To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190721144412.2783-1-vladbu@mellanox.com>

From: Vlad Buslov <vladbu@mellanox.com>
Date: Sun, 21 Jul 2019 17:44:12 +0300

> In function int tc_new_tfilter() q pointer can be NULL when adding filter
> on a shared block. With recent change that resets TCQ_F_CAN_BYPASS after
> filter creation, following NULL pointer dereference happens in case parent
> block is shared:
 ...
> Verify that q pointer is not NULL before setting the 'flags' field.
> 
> Fixes: 3f05e6886a59 ("net_sched: unset TCQ_F_CAN_BYPASS when adding filters")
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>

Applied.

^ permalink raw reply

* Re: [PATCH] chelsio: Fix a typo in a function name
From: David Miller @ 2019-07-21 18:48 UTC (permalink / raw)
  To: christophe.jaillet; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190721131605.16603-1-christophe.jaillet@wanadoo.fr>

From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun, 21 Jul 2019 15:16:05 +0200

> It is likely that 'my3216_poll()' should be 'my3126_poll()'. (1 and 2
> switched in 3126.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Applied.

^ permalink raw reply

* Re: [PATCH] allocate_flower_entry: should check for null deref
From: David Miller @ 2019-07-21 18:47 UTC (permalink / raw)
  To: navid.emamdoost
  Cc: kjlu, smccaman, secalert, emamd001, vishal, netdev, linux-kernel
In-Reply-To: <20190721063731.7772-1-navid.emamdoost@gmail.com>

From: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Sun, 21 Jul 2019 01:37:31 -0500

> allocate_flower_entry does not check for allocation success, but tries
> to deref the result. I only moved the spin_lock under null check, because
>  the caller is checking allocation's status at line 652.
> 
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH] net: hns3: typo in the name of a constant
From: David Miller @ 2019-07-21 18:46 UTC (permalink / raw)
  To: christophe.jaillet
  Cc: yisen.zhuang, salil.mehta, tanhuazhong, lipeng321, shenjian15,
	liuzhongzhu, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190721130831.16330-1-christophe.jaillet@wanadoo.fr>

From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun, 21 Jul 2019 15:08:31 +0200

> All constant in 'enum HCLGE_MBX_OPCODE' start with HCLGE, except
> 'HLCGE_MBX_PUSH_VLAN_INFO' (C and L switched)
> 
> s/HLC/HCL/
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Applied.

^ permalink raw reply

* Re: [PATCHv2 0/2] forcedeth: recv cache to make NIC work steadily
From: David Miller @ 2019-07-21 18:45 UTC (permalink / raw)
  To: yanjun.zhu; +Cc: netdev
In-Reply-To: <1563713633-25528-1-git-send-email-yanjun.zhu@oracle.com>


I made it abundantly clear that I am completely not supportive of
changes like this.

If anything, we need to improve the behavior of the core kernel
allocators, and the mid-level networking interfaces which use them,
to fix problems like this.

It is absolutely not sustainable to have every driver implement
a cache of some sort to "improve" allocation behavior.

Sorry, there is no way in the world I'm applying changes like
these.

^ permalink raw reply

* Re: [PATCH net] kbuild: add net/netfilter/nf_tables_offload.h to header-test blacklist.
From: David Miller @ 2019-07-21 18:44 UTC (permalink / raw)
  To: jeremy; +Cc: netdev, pablo, jakub.kicinski
In-Reply-To: <20190721113105.19301-1-jeremy@azazel.net>

From: Jeremy Sowden <jeremy@azazel.net>
Date: Sun, 21 Jul 2019 12:31:05 +0100

> net/netfilter/nf_tables_offload.h includes net/netfilter/nf_tables.h
> which is itself on the blacklist.
> 
> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Jeremy Sowden <jeremy@azazel.net>

Applied.

^ permalink raw reply

* Re: [PATCH] tipc: Fix a typo
From: David Miller @ 2019-07-21 18:42 UTC (permalink / raw)
  To: christophe.jaillet
  Cc: jon.maloy, ying.xue, netdev, tipc-discussion, linux-kernel,
	kernel-janitors
In-Reply-To: <20190721103811.29724-1-christophe.jaillet@wanadoo.fr>

From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun, 21 Jul 2019 12:38:11 +0200

> s/tipc_toprsv_listener_data_ready/tipc_topsrv_listener_data_ready/
> (r and s switched in topsrv)
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> The function name could also be removed from the comment. It does not
> bring any useful information IMHO.

Applied, thanks Christophe.

^ permalink raw reply

* Re: pull-request: mac80211 2019-07-20
From: David Miller @ 2019-07-21 18:39 UTC (permalink / raw)
  To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190720202456.8444-1-johannes@sipsolutions.net>

From: Johannes Berg <johannes@sipsolutions.net>
Date: Sat, 20 Jul 2019 22:24:55 +0200

> Sorry, this really should've gone out much earlier, in partilar
> the vendor command fixes. Not much for now, more -next material
> will come later.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

^ permalink raw reply

* Re: [PATCH net] kbuild: add net/netfilter/nf_tables_offload.h to header-test blacklist.
From: Pablo Neira Ayuso @ 2019-07-21 18:26 UTC (permalink / raw)
  To: Jeremy Sowden; +Cc: Netdev, Jakub Kicinski
In-Reply-To: <20190721113105.19301-1-jeremy@azazel.net>

On Sun, Jul 21, 2019 at 12:31:05PM +0100, Jeremy Sowden wrote:
> net/netfilter/nf_tables_offload.h includes net/netfilter/nf_tables.h
> which is itself on the blacklist.
> 
> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Jeremy Sowden <jeremy@azazel.net>

Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>

Thanks, I think it would be good later on to review all of the
netfilter headers and make them compile via this new
CONFIG_HEADER_TEST Kconfig knob.

^ permalink raw reply

* [PATCH net] net: phy: sfp: hwmon: Fix scaling of RX power
From: Andrew Lunn @ 2019-07-21 16:50 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Russell King, Chris Healy, Andrew Lunn

The RX power read from the SFP uses units of 0.1uW. This must be
scaled to units of uW for HWMON. This requires a divide by 10, not the
current 100.

With this change in place, sensors(1) and ethtool -m agree:

sff2-isa-0000
Adapter: ISA adapter
in0:          +3.23 V
temp1:        +33.1 C
power1:      270.00 uW
power2:      200.00 uW
curr1:        +0.01 A

        Laser output power                        : 0.2743 mW / -5.62 dBm
        Receiver signal average optical power     : 0.2014 mW / -6.96 dBm

Reported-by: chris.healy@zii.aero
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
---
 drivers/net/phy/sfp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 2d816aadea79..e36c04c26866 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -517,7 +517,7 @@ static int sfp_hwmon_read_sensor(struct sfp *sfp, int reg, long *value)
 
 static void sfp_hwmon_to_rx_power(long *value)
 {
-	*value = DIV_ROUND_CLOSEST(*value, 100);
+	*value = DIV_ROUND_CLOSEST(*value, 10);
 }
 
 static void sfp_hwmon_calibrate(struct sfp *sfp, unsigned int slope, int offset,
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH net-next] net: sched: verify that q!=NULL before setting q->flags
From: Jiri Pirko @ 2019-07-21 15:24 UTC (permalink / raw)
  To: Vlad Buslov; +Cc: netdev, jhs, xiyou.wangcong, davem
In-Reply-To: <20190721144412.2783-1-vladbu@mellanox.com>

Sun, Jul 21, 2019 at 04:44:12PM CEST, vladbu@mellanox.com wrote:
>In function int tc_new_tfilter() q pointer can be NULL when adding filter
>on a shared block. With recent change that resets TCQ_F_CAN_BYPASS after
>filter creation, following NULL pointer dereference happens in case parent
>block is shared:
>
>[  212.925060] BUG: kernel NULL pointer dereference, address: 0000000000000010
>[  212.925445] #PF: supervisor write access in kernel mode
>[  212.925709] #PF: error_code(0x0002) - not-present page
>[  212.925965] PGD 8000000827923067 P4D 8000000827923067 PUD 827924067 PMD 0
>[  212.926302] Oops: 0002 [#1] SMP KASAN PTI
>[  212.926539] CPU: 18 PID: 2617 Comm: tc Tainted: G    B             5.2.0+ #512
>[  212.926938] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
>[  212.927364] RIP: 0010:tc_new_tfilter+0x698/0xd40
>[  212.927633] Code: 74 0d 48 85 c0 74 08 48 89 ef e8 03 aa 62 00 48 8b 84 24 a0 00 00 00 48 8d 78 10 48 89 44 24 18 e8 4d 0c 6b ff 48 8b 44 24 18 <83> 60 10 f
>b 48 85 ed 0f 85 3d fe ff ff e9 4f fe ff ff e8 81 26 f8
>[  212.928607] RSP: 0018:ffff88884fd5f5d8 EFLAGS: 00010296
>[  212.928905] RAX: 0000000000000000 RBX: 0000000000000000 RCX: dffffc0000000000
>[  212.929201] RDX: 0000000000000007 RSI: 0000000000000004 RDI: 0000000000000297
>[  212.929402] RBP: ffff88886bedd600 R08: ffffffffb91d4b51 R09: fffffbfff7616e4d
>[  212.929609] R10: fffffbfff7616e4c R11: ffffffffbb0b7263 R12: ffff88886bc61040
>[  212.929803] R13: ffff88884fd5f950 R14: ffffc900039c5000 R15: ffff88835e927680
>[  212.929999] FS:  00007fe7c50b6480(0000) GS:ffff88886f980000(0000) knlGS:0000000000000000
>[  212.930235] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[  212.930394] CR2: 0000000000000010 CR3: 000000085bd04002 CR4: 00000000001606e0
>[  212.930588] Call Trace:
>[  212.930682]  ? tc_del_tfilter+0xa40/0xa40
>[  212.930811]  ? __lock_acquire+0x5b5/0x2460
>[  212.930948]  ? find_held_lock+0x85/0xa0
>[  212.931081]  ? tc_del_tfilter+0xa40/0xa40
>[  212.931201]  rtnetlink_rcv_msg+0x4ab/0x5f0
>[  212.931332]  ? rtnl_dellink+0x490/0x490
>[  212.931454]  ? lockdep_hardirqs_on+0x260/0x260
>[  212.931589]  ? netlink_deliver_tap+0xab/0x5a0
>[  212.931717]  ? match_held_lock+0x1b/0x240
>[  212.931844]  netlink_rcv_skb+0xd0/0x200
>[  212.931958]  ? rtnl_dellink+0x490/0x490
>[  212.932079]  ? netlink_ack+0x440/0x440
>[  212.932205]  ? netlink_deliver_tap+0x161/0x5a0
>[  212.932335]  ? lock_downgrade+0x360/0x360
>[  212.932457]  ? lock_acquire+0xe5/0x210
>[  212.932579]  netlink_unicast+0x296/0x350
>[  212.932705]  ? netlink_attachskb+0x390/0x390
>[  212.932834]  ? _copy_from_iter_full+0xe0/0x3a0
>[  212.932976]  netlink_sendmsg+0x394/0x600
>[  212.937998]  ? netlink_unicast+0x350/0x350
>[  212.943033]  ? move_addr_to_kernel.part.0+0x90/0x90
>[  212.948115]  ? netlink_unicast+0x350/0x350
>[  212.953185]  sock_sendmsg+0x96/0xa0
>[  212.958099]  ___sys_sendmsg+0x482/0x520
>[  212.962881]  ? match_held_lock+0x1b/0x240
>[  212.967618]  ? copy_msghdr_from_user+0x250/0x250
>[  212.972337]  ? lock_downgrade+0x360/0x360
>[  212.976973]  ? rwlock_bug.part.0+0x60/0x60
>[  212.981548]  ? __mod_node_page_state+0x1f/0xa0
>[  212.986060]  ? match_held_lock+0x1b/0x240
>[  212.990567]  ? find_held_lock+0x85/0xa0
>[  212.994989]  ? do_user_addr_fault+0x349/0x5b0
>[  212.999387]  ? lock_downgrade+0x360/0x360
>[  213.003713]  ? find_held_lock+0x85/0xa0
>[  213.007972]  ? __fget_light+0xa1/0xf0
>[  213.012143]  ? sockfd_lookup_light+0x91/0xb0
>[  213.016165]  __sys_sendmsg+0xba/0x130
>[  213.020040]  ? __sys_sendmsg_sock+0xb0/0xb0
>[  213.023870]  ? handle_mm_fault+0x337/0x470
>[  213.027592]  ? page_fault+0x8/0x30
>[  213.031316]  ? lockdep_hardirqs_off+0xbe/0x100
>[  213.034999]  ? mark_held_locks+0x24/0x90
>[  213.038671]  ? do_syscall_64+0x1e/0xe0
>[  213.042297]  do_syscall_64+0x74/0xe0
>[  213.045828]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>[  213.049354] RIP: 0033:0x7fe7c527c7b8
>[  213.052792] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 8f 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f
>0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54
>[  213.060269] RSP: 002b:00007ffc3f7908a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
>[  213.064144] RAX: ffffffffffffffda RBX: 000000005d34716f RCX: 00007fe7c527c7b8
>[  213.068094] RDX: 0000000000000000 RSI: 00007ffc3f790910 RDI: 0000000000000003
>[  213.072109] RBP: 0000000000000000 R08: 0000000000000001 R09: 00007fe7c5340cc0
>[  213.076113] R10: 0000000000404ec2 R11: 0000000000000246 R12: 0000000000000080
>[  213.080146] R13: 0000000000480640 R14: 0000000000000080 R15: 0000000000000000
>[  213.084147] Modules linked in: act_gact cls_flower sch_ingress nfsv3 nfs_acl nfs lockd grace fscache bridge stp llc sunrpc intel_rapl_msr intel_rapl_common
>^[[<1;69;32Msb_edac rdma_ucm rdma_cm x86_pkg_temp_thermal iw_cm intel_powerclamp ib_cm coretemp kvm_intel kvm irqbypass mlx5_ib ib_uverbs ib_core crct10dif_pclmul crc32_pc
>lmul crc32c_intel ghash_clmulni_intel mlx5_core intel_cstate intel_uncore iTCO_wdt igb iTCO_vendor_support mlxfw mei_me ptp ses intel_rapl_perf mei pcspkr ipmi
>_ssif i2c_i801 joydev enclosure pps_core lpc_ich ioatdma wmi dca ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad ast i2c_algo_bit drm_vram_helpe
>r ttm drm_kms_helper drm mpt3sas raid_class scsi_transport_sas
>[  213.112326] CR2: 0000000000000010
>[  213.117429] ---[ end trace adb58eb0a4ee6283 ]---
>
>Verify that q pointer is not NULL before setting the 'flags' field.
>
>Fixes: 3f05e6886a59 ("net_sched: unset TCQ_F_CAN_BYPASS when adding filters")
>Signed-off-by: Vlad Buslov <vladbu@mellanox.com>

Acked-by: Jiri Pirko <jiri@mellanox.com>

Thanks!

^ permalink raw reply

* Re: [PATCH net-next 00/12] mlx5 TLS TX HW offload support
From: Tariq Toukan @ 2019-07-21 15:19 UTC (permalink / raw)
  To: David Miller, jakub.kicinski@netronome.com
  Cc: Tariq Toukan, netdev@vger.kernel.org, Eran Ben Elisha,
	Saeed Mahameed, Moshe Shemesh
In-Reply-To: <20190718.120910.1323935732125670131.davem@davemloft.net>



On 7/18/2019 10:09 PM, David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Thu, 18 Jul 2019 10:08:47 -0700
> 
>> Yes, certainly. It's documentation and renaming a stat before it makes
>> it into an official release.
> 
> Agreed.
> 

Ack.
I'll prepare and send this week.

Tariq

^ permalink raw reply

* Re: [PATCHv2 0/2] forcedeth: recv cache to make NIC work steadily
From: Andrew Lunn @ 2019-07-21 14:53 UTC (permalink / raw)
  To: Zhu Yanjun; +Cc: davem, netdev
In-Reply-To: <1563713633-25528-1-git-send-email-yanjun.zhu@oracle.com>

On Sun, Jul 21, 2019 at 08:53:51AM -0400, Zhu Yanjun wrote:
> These patches are to this scenario:
> 
> "
> When the host run for long time, there are a lot of memory fragments in
> the hosts. And it is possible that kernel will compact memory fragments.
> But normally it is difficult for NIC driver to allocate a memory from
> kernel. From this variable stat_rx_dropped, we can confirm that NIC driver
> can not allocate skb very frequently.
> "
> 
> Since NIC driver can not allocate skb in time, this makes some important
> tasks not be completed in time.
> To avoid it, a recv cache is created to pre-allocate skb for NIC driver.
> This can make the important tasks be completed in time.
> >From Nan's tests in LAB, these patches can make NIC driver work steadily.
> Now in production hosts, these patches are applied.
> 
> With these patches, one NIC port needs 125MiB reserved. This 125MiB memory
> can not be used by others. To a host on which the communications are not
> mandatory, it is not necessary to reserve so much memory. So this recv cache
> is disabled by default.
> 
> V1->V2:
> 1. ndelay is replaced with GFP_KERNEL function __netdev_alloc_skb.
> 2. skb_queue_purge is used when recv cache is destroyed.
> 3. RECV_LIST_ALLOCATE bit is removed.
> 4. schedule_delayed_work is moved out of while loop.

Hi Zhu

You don't appear to of address David's comment that this is probably
the wrong way to do this, it should be a generic solution.

Also, that there should be enough atomic memory in the system
anyway. Have you looked at what other drivers are using atomic memory?
It could actually be you need to debug some other driver, rather than
add hacks to forcedeth.

    Andrew

^ permalink raw reply

* Re: [PATCHv2 2/2] forcedeth: disable recv cache by default
From: Andrew Lunn @ 2019-07-21 14:48 UTC (permalink / raw)
  To: Zhu Yanjun; +Cc: davem, netdev
In-Reply-To: <1563713633-25528-3-git-send-email-yanjun.zhu@oracle.com>

On Sun, Jul 21, 2019 at 08:53:53AM -0400, Zhu Yanjun wrote:
> The recv cache is to allocate 125MiB memory to reserve for NIC.
> In the past time, this recv cache works very well. When the memory
> is not enough, this recv cache reserves memory for NIC.
> And the communications through this NIC is not affected by the
> memory shortage. And the performance of NIC is better because of
> this recv cache.
> But this recv cache reserves 125MiB memory for one NIC port. Normally
> there are 2 NIC ports in one card. So in a host, there are about 250
> MiB memory reserved for NIC ports. To a host on which communications
> are not mandatory, it is not necessary to reserve memory.
> So this recv cache is disabled by default.
> 
> CC: Joe Jin <joe.jin@oracle.com>
> CC: Junxiao Bi <junxiao.bi@oracle.com>
> Tested-by: Nan san <nan.1986san@gmail.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
>  drivers/net/ethernet/nvidia/Kconfig     | 11 ++++++++
>  drivers/net/ethernet/nvidia/Makefile    |  1 +
>  drivers/net/ethernet/nvidia/forcedeth.c | 46 ++++++++++++++++++++++++++-------
>  3 files changed, 48 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/nvidia/Kconfig b/drivers/net/ethernet/nvidia/Kconfig
> index faacbd1..9a9f42a 100644
> --- a/drivers/net/ethernet/nvidia/Kconfig
> +++ b/drivers/net/ethernet/nvidia/Kconfig
> @@ -26,4 +26,15 @@ config FORCEDETH
>  	  To compile this driver as a module, choose M here. The module
>  	  will be called forcedeth.
>  
> +config	FORCEDETH_RECV_CACHE
> +	bool "nForce Ethernet recv cache support"
> +	depends on FORCEDETH
> +	default n
> +	---help---
> +	  The recv cache can make nic work steadily when the system memory is
> +	  not enough. And it can also enhance nic performance. But to a host
> +	  on which the communications are not mandatory, it is not necessary
> +	  to reserve 125MiB memory for NIC.
> +	  So recv cache is disabled by default.
> +
>  endif # NET_VENDOR_NVIDIA
> diff --git a/drivers/net/ethernet/nvidia/Makefile b/drivers/net/ethernet/nvidia/Makefile
> index 8935699..40c055e 100644
> --- a/drivers/net/ethernet/nvidia/Makefile
> +++ b/drivers/net/ethernet/nvidia/Makefile
> @@ -4,3 +4,4 @@
>  #
>  
>  obj-$(CONFIG_FORCEDETH) += forcedeth.o
> +ccflags-$(CONFIG_FORCEDETH_RECV_CACHE)	:=	-DFORCEDETH_RECV_CACHE
> diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
> index f8e766f..deda276 100644
> --- a/drivers/net/ethernet/nvidia/forcedeth.c
> +++ b/drivers/net/ethernet/nvidia/forcedeth.c
> @@ -674,10 +674,12 @@ struct nv_ethtool_stats {
>  	u64 tx_broadcast;
>  };
>  
> +#ifdef FORCEDETH_RECV_CACHE
>  /* 1000Mb is 125M bytes, 125 * 1024 * 1024 bytes
>   * The length of recv cache is 125M / skb_length
>   */
>  #define RECV_CACHE_LIST_LENGTH		(125 * 1024 * 1024 / np->rx_buf_sz)
> +#endif
>  
>  #define NV_DEV_STATISTICS_V3_COUNT (sizeof(struct nv_ethtool_stats)/sizeof(u64))
>  #define NV_DEV_STATISTICS_V2_COUNT (NV_DEV_STATISTICS_V3_COUNT - 3)
> @@ -850,10 +852,12 @@ struct fe_priv {
>  	char name_tx[IFNAMSIZ + 3];       /* -tx    */
>  	char name_other[IFNAMSIZ + 6];    /* -other */
>  
> +#ifdef FORCEDETH_RECV_CACHE
>  	/* This is to schedule work */
>  	struct delayed_work     recv_cache_work;
>  	/* This list is to store skb queue for recv */
>  	struct sk_buff_head recv_list;
> +#endif
>  };
>  
>  /*
> @@ -1814,8 +1818,12 @@ static int nv_alloc_rx(struct net_device *dev)
>  		less_rx = np->last_rx.orig;
>  
>  	while (np->put_rx.orig != less_rx) {
> +#ifdef FORCEDETH_RECV_CACHE
>  		struct sk_buff *skb = skb_dequeue(&np->recv_list);
> -
> +#else
> +		struct sk_buff *skb = netdev_alloc_skb(np->dev,
> +					 np->rx_buf_sz + NV_RX_ALLOC_PAD);
> +#endif
>  		if (likely(skb)) {
>  			np->put_rx_ctx->skb = skb;
>  			np->put_rx_ctx->dma = dma_map_single(&np->pci_dev->dev,
> @@ -1840,15 +1848,15 @@ static int nv_alloc_rx(struct net_device *dev)
>  			u64_stats_update_begin(&np->swstats_rx_syncp);
>  			np->stat_rx_dropped++;
>  			u64_stats_update_end(&np->swstats_rx_syncp);
> -
> +#ifdef FORCEDETH_RECV_CACHE
>  			schedule_delayed_work(&np->recv_cache_work, 0);
> -
> +#endif

All these #ifdef are pretty ugly. It also makes for easy to break code
since most of the time this option will not be enabled. Please
refactor the code so that is uses

if (IS_ENABLED(FORCEDETH_RECV_CACHE))

so that the compiler at least compiles the code every time, and then
optimizing it out.

	   Andrew

^ permalink raw reply

* [PATCH net-next] net: sched: verify that q!=NULL before setting q->flags
From: Vlad Buslov @ 2019-07-21 14:44 UTC (permalink / raw)
  To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, Vlad Buslov

In function int tc_new_tfilter() q pointer can be NULL when adding filter
on a shared block. With recent change that resets TCQ_F_CAN_BYPASS after
filter creation, following NULL pointer dereference happens in case parent
block is shared:

[  212.925060] BUG: kernel NULL pointer dereference, address: 0000000000000010
[  212.925445] #PF: supervisor write access in kernel mode
[  212.925709] #PF: error_code(0x0002) - not-present page
[  212.925965] PGD 8000000827923067 P4D 8000000827923067 PUD 827924067 PMD 0
[  212.926302] Oops: 0002 [#1] SMP KASAN PTI
[  212.926539] CPU: 18 PID: 2617 Comm: tc Tainted: G    B             5.2.0+ #512
[  212.926938] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
[  212.927364] RIP: 0010:tc_new_tfilter+0x698/0xd40
[  212.927633] Code: 74 0d 48 85 c0 74 08 48 89 ef e8 03 aa 62 00 48 8b 84 24 a0 00 00 00 48 8d 78 10 48 89 44 24 18 e8 4d 0c 6b ff 48 8b 44 24 18 <83> 60 10 f
b 48 85 ed 0f 85 3d fe ff ff e9 4f fe ff ff e8 81 26 f8
[  212.928607] RSP: 0018:ffff88884fd5f5d8 EFLAGS: 00010296
[  212.928905] RAX: 0000000000000000 RBX: 0000000000000000 RCX: dffffc0000000000
[  212.929201] RDX: 0000000000000007 RSI: 0000000000000004 RDI: 0000000000000297
[  212.929402] RBP: ffff88886bedd600 R08: ffffffffb91d4b51 R09: fffffbfff7616e4d
[  212.929609] R10: fffffbfff7616e4c R11: ffffffffbb0b7263 R12: ffff88886bc61040
[  212.929803] R13: ffff88884fd5f950 R14: ffffc900039c5000 R15: ffff88835e927680
[  212.929999] FS:  00007fe7c50b6480(0000) GS:ffff88886f980000(0000) knlGS:0000000000000000
[  212.930235] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  212.930394] CR2: 0000000000000010 CR3: 000000085bd04002 CR4: 00000000001606e0
[  212.930588] Call Trace:
[  212.930682]  ? tc_del_tfilter+0xa40/0xa40
[  212.930811]  ? __lock_acquire+0x5b5/0x2460
[  212.930948]  ? find_held_lock+0x85/0xa0
[  212.931081]  ? tc_del_tfilter+0xa40/0xa40
[  212.931201]  rtnetlink_rcv_msg+0x4ab/0x5f0
[  212.931332]  ? rtnl_dellink+0x490/0x490
[  212.931454]  ? lockdep_hardirqs_on+0x260/0x260
[  212.931589]  ? netlink_deliver_tap+0xab/0x5a0
[  212.931717]  ? match_held_lock+0x1b/0x240
[  212.931844]  netlink_rcv_skb+0xd0/0x200
[  212.931958]  ? rtnl_dellink+0x490/0x490
[  212.932079]  ? netlink_ack+0x440/0x440
[  212.932205]  ? netlink_deliver_tap+0x161/0x5a0
[  212.932335]  ? lock_downgrade+0x360/0x360
[  212.932457]  ? lock_acquire+0xe5/0x210
[  212.932579]  netlink_unicast+0x296/0x350
[  212.932705]  ? netlink_attachskb+0x390/0x390
[  212.932834]  ? _copy_from_iter_full+0xe0/0x3a0
[  212.932976]  netlink_sendmsg+0x394/0x600
[  212.937998]  ? netlink_unicast+0x350/0x350
[  212.943033]  ? move_addr_to_kernel.part.0+0x90/0x90
[  212.948115]  ? netlink_unicast+0x350/0x350
[  212.953185]  sock_sendmsg+0x96/0xa0
[  212.958099]  ___sys_sendmsg+0x482/0x520
[  212.962881]  ? match_held_lock+0x1b/0x240
[  212.967618]  ? copy_msghdr_from_user+0x250/0x250
[  212.972337]  ? lock_downgrade+0x360/0x360
[  212.976973]  ? rwlock_bug.part.0+0x60/0x60
[  212.981548]  ? __mod_node_page_state+0x1f/0xa0
[  212.986060]  ? match_held_lock+0x1b/0x240
[  212.990567]  ? find_held_lock+0x85/0xa0
[  212.994989]  ? do_user_addr_fault+0x349/0x5b0
[  212.999387]  ? lock_downgrade+0x360/0x360
[  213.003713]  ? find_held_lock+0x85/0xa0
[  213.007972]  ? __fget_light+0xa1/0xf0
[  213.012143]  ? sockfd_lookup_light+0x91/0xb0
[  213.016165]  __sys_sendmsg+0xba/0x130
[  213.020040]  ? __sys_sendmsg_sock+0xb0/0xb0
[  213.023870]  ? handle_mm_fault+0x337/0x470
[  213.027592]  ? page_fault+0x8/0x30
[  213.031316]  ? lockdep_hardirqs_off+0xbe/0x100
[  213.034999]  ? mark_held_locks+0x24/0x90
[  213.038671]  ? do_syscall_64+0x1e/0xe0
[  213.042297]  do_syscall_64+0x74/0xe0
[  213.045828]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  213.049354] RIP: 0033:0x7fe7c527c7b8
[  213.052792] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 8f 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f
0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54
[  213.060269] RSP: 002b:00007ffc3f7908a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[  213.064144] RAX: ffffffffffffffda RBX: 000000005d34716f RCX: 00007fe7c527c7b8
[  213.068094] RDX: 0000000000000000 RSI: 00007ffc3f790910 RDI: 0000000000000003
[  213.072109] RBP: 0000000000000000 R08: 0000000000000001 R09: 00007fe7c5340cc0
[  213.076113] R10: 0000000000404ec2 R11: 0000000000000246 R12: 0000000000000080
[  213.080146] R13: 0000000000480640 R14: 0000000000000080 R15: 0000000000000000
[  213.084147] Modules linked in: act_gact cls_flower sch_ingress nfsv3 nfs_acl nfs lockd grace fscache bridge stp llc sunrpc intel_rapl_msr intel_rapl_common
^[[<1;69;32Msb_edac rdma_ucm rdma_cm x86_pkg_temp_thermal iw_cm intel_powerclamp ib_cm coretemp kvm_intel kvm irqbypass mlx5_ib ib_uverbs ib_core crct10dif_pclmul crc32_pc
lmul crc32c_intel ghash_clmulni_intel mlx5_core intel_cstate intel_uncore iTCO_wdt igb iTCO_vendor_support mlxfw mei_me ptp ses intel_rapl_perf mei pcspkr ipmi
_ssif i2c_i801 joydev enclosure pps_core lpc_ich ioatdma wmi dca ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad ast i2c_algo_bit drm_vram_helpe
r ttm drm_kms_helper drm mpt3sas raid_class scsi_transport_sas
[  213.112326] CR2: 0000000000000010
[  213.117429] ---[ end trace adb58eb0a4ee6283 ]---

Verify that q pointer is not NULL before setting the 'flags' field.

Fixes: 3f05e6886a59 ("net_sched: unset TCQ_F_CAN_BYPASS when adding filters")
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
---
 net/sched/cls_api.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index d144233423c5..0c5660bd0331 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -2152,7 +2152,9 @@ static int tc_new_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
 		tfilter_notify(net, skb, n, tp, block, q, parent, fh,
 			       RTM_NEWTFILTER, false, rtnl_held);
 		tfilter_put(tp, fh);
-		q->flags &= ~TCQ_F_CAN_BYPASS;
+		/* q pointer is NULL for shared blocks */
+		if (q)
+			q->flags &= ~TCQ_F_CAN_BYPASS;
 	}
 
 errout:
-- 
2.21.0


^ permalink raw reply related

* Re: [PATCH net v3] net: neigh: fix multiple neigh timer scheduling
From: Julian Anastasov @ 2019-07-21 13:46 UTC (permalink / raw)
  To: Lorenzo Bianconi; +Cc: davem, netdev, dsahern, marek
In-Reply-To: <552d7c8de6a07e12f7b76791da953e81478138cd.1563134704.git.lorenzo.bianconi@redhat.com>


	Hello,

On Sun, 14 Jul 2019, Lorenzo Bianconi wrote:

> Neigh timer can be scheduled multiple times from userspace adding

	If the garbage comes from ndm_state, why we should create
a patch that just covers the problem?:

State: INCOMPLETE, STALE, FAILED, 0x8400 (0x8425)

	User space is trying to create entry that is both
STALE (no timer) and INCOMPLETE (with timer). So, in the
2nd NL message __neigh_event_send() detects timer with NUD_STALE
bit. What if this 2nd message never comes? Such inconsistence
between nud_state and the timer can trigger other bugs in
other functions.

	May be we just need to restrict ndm_state and to drop
this patch, for example, by adding checks in __neigh_update():

        if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
            (old & (NUD_NOARP | NUD_PERMANENT)))
                goto out;
+	/* State must be single bit or 0 */
+	if (new & (new - 1))
+		goto out;
        if (neigh->dead) {

	If needed, this check can be moved only for ndm_state
in neigh_add().

> multiple neigh entries and forcing the neigh timer scheduling passing
> NTF_USE in the netlink requests.
> This will result in a refcount leak and in the following dump stack:

	It is a single create with multiple bits in state with following
__neigh_event_send(). And who knows, this bug may exist even in Linux 2.2 
and below...

> [   32.465295] NEIGH: BUG, double timer add, state is 8
> [   32.465308] CPU: 0 PID: 416 Comm: double_timer_ad Not tainted 5.2.0+ #65
> [   32.465311] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
> [   32.465313] Call Trace:
> [   32.465318]  dump_stack+0x7c/0xc0
> [   32.465323]  __neigh_event_send+0x20c/0x880
> [   32.465326]  ? ___neigh_create+0x846/0xfb0
> [   32.465329]  ? neigh_lookup+0x2a9/0x410
> [   32.465332]  ? neightbl_fill_info.constprop.0+0x800/0x800
> [   32.465334]  neigh_add+0x4f8/0x5e0
> [   32.465337]  ? neigh_xmit+0x620/0x620
> [   32.465341]  ? find_held_lock+0x85/0xa0
> [   32.465345]  rtnetlink_rcv_msg+0x204/0x570
> [   32.465348]  ? rtnl_dellink+0x450/0x450
> [   32.465351]  ? mark_held_locks+0x90/0x90
> [   32.465354]  ? match_held_lock+0x1b/0x230
> [   32.465357]  netlink_rcv_skb+0xc4/0x1d0
> [   32.465360]  ? rtnl_dellink+0x450/0x450
> [   32.465363]  ? netlink_ack+0x420/0x420
> [   32.465366]  ? netlink_deliver_tap+0x115/0x560
> [   32.465369]  ? __alloc_skb+0xc9/0x2f0
> [   32.465372]  netlink_unicast+0x270/0x330
> [   32.465375]  ? netlink_attachskb+0x2f0/0x2f0
> [   32.465378]  netlink_sendmsg+0x34f/0x5a0
> [   32.465381]  ? netlink_unicast+0x330/0x330
> [   32.465385]  ? move_addr_to_kernel.part.0+0x20/0x20
> [   32.465388]  ? netlink_unicast+0x330/0x330
> [   32.465391]  sock_sendmsg+0x91/0xa0
> [   32.465394]  ___sys_sendmsg+0x407/0x480
> [   32.465397]  ? copy_msghdr_from_user+0x200/0x200
> [   32.465401]  ? _raw_spin_unlock_irqrestore+0x37/0x40
> [   32.465404]  ? lockdep_hardirqs_on+0x17d/0x250
> [   32.465407]  ? __wake_up_common_lock+0xcb/0x110
> [   32.465410]  ? __wake_up_common+0x230/0x230
> [   32.465413]  ? netlink_bind+0x3e1/0x490
> [   32.465416]  ? netlink_setsockopt+0x540/0x540
> [   32.465420]  ? __fget_light+0x9c/0xf0
> [   32.465423]  ? sockfd_lookup_light+0x8c/0xb0
> [   32.465426]  __sys_sendmsg+0xa5/0x110
> [   32.465429]  ? __ia32_sys_shutdown+0x30/0x30
> [   32.465432]  ? __fd_install+0xe1/0x2c0
> [   32.465435]  ? lockdep_hardirqs_off+0xb5/0x100
> [   32.465438]  ? mark_held_locks+0x24/0x90
> [   32.465441]  ? do_syscall_64+0xf/0x270
> [   32.465444]  do_syscall_64+0x63/0x270
> [   32.465448]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> Fix the issue unscheduling neigh_timer if selected entry is in 'IN_TIMER'
> receiving a netlink request with NTF_USE flag set
> 
> Reported-by: Marek Majkowski <marek@cloudflare.com>
> Fixes: 0c5c2d308906 ("neigh: Allow for user space users of the neighbour table")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> ---
> Changes since v2:
> - remove check_timer flag and run neigh_del_timer directly
> Changes since v1:
> - fix compilation errors defining neigh_event_send_check_timer routine
> ---
>  net/core/neighbour.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 742cea4ce72e..0dfc97bc8760 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1124,6 +1124,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
>  
>  			atomic_set(&neigh->probes,
>  				   NEIGH_VAR(neigh->parms, UCAST_PROBES));
> +			neigh_del_timer(neigh);
>  			neigh->nud_state     = NUD_INCOMPLETE;
>  			neigh->updated = now;
>  			next = now + max(NEIGH_VAR(neigh->parms, RETRANS_TIME),
> @@ -1140,6 +1141,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
>  		}
>  	} else if (neigh->nud_state & NUD_STALE) {
>  		neigh_dbg(2, "neigh %p is delayed\n", neigh);
> +		neigh_del_timer(neigh);
>  		neigh->nud_state = NUD_DELAY;
>  		neigh->updated = jiffies;
>  		neigh_add_timer(neigh, jiffies +
> -- 
> 2.21.0

Regards

--
Julian Anastasov <ja@ssi.bg>

^ permalink raw reply

* [PATCH] chelsio: Fix a typo in a function name
From: Christophe JAILLET @ 2019-07-21 13:16 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET

It is likely that 'my3216_poll()' should be 'my3126_poll()'. (1 and 2
switched in 3126.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 drivers/net/ethernet/chelsio/cxgb/my3126.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb/my3126.c b/drivers/net/ethernet/chelsio/cxgb/my3126.c
index 20c09cc4b323..60aa45b375b6 100644
--- a/drivers/net/ethernet/chelsio/cxgb/my3126.c
+++ b/drivers/net/ethernet/chelsio/cxgb/my3126.c
@@ -94,7 +94,7 @@ static int my3126_interrupt_handler(struct cphy *cphy)
 	return cphy_cause_link_change;
 }
 
-static void my3216_poll(struct work_struct *work)
+static void my3126_poll(struct work_struct *work)
 {
 	struct cphy *cphy = container_of(work, struct cphy, phy_update.work);
 
@@ -177,7 +177,7 @@ static struct cphy *my3126_phy_create(struct net_device *dev,
 		return NULL;
 
 	cphy_init(cphy, dev, phy_addr, &my3126_ops, mdio_ops);
-	INIT_DELAYED_WORK(&cphy->phy_update, my3216_poll);
+	INIT_DELAYED_WORK(&cphy->phy_update, my3126_poll);
 	cphy->bmsr = 0;
 
 	return cphy;
-- 
2.20.1


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox