Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

On Sun, Jul 26, 2020 at 11:05 AM Cong Wang wrote: > > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote: > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, > > u32 spi) > > { > > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > > struct

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote: > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, > u32 spi) > { > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > struct xfrm6_tunnel_spi *x6spi; > - int index = xfrm6_tunnel_spi_

Re: [PATCH 0/4] Add Support for Marvell OcteonTX2 Cryptographic

Hi Srujana, On Fri, Jul 24, 2020 at 6:39 PM Srujana Challa wrote: > > The following series adds support for Marvell Cryptographic Acceleration > Unit(CPT) on OcteonTX2 CN96XX SoC. > This series is tested with CRYPTO_EXTRA_TESTS enabled and > CRYPTO_DISABLE_TESTS disabled. > > Srujana Challa (4):

Re: [PATCH v4 bpf-next 0/9] BPF XDP link

On Tue, Jul 21, 2020 at 11:46 PM Andrii Nakryiko wrote: > > Following cgroup and netns examples, implement bpf_link support for XDP. > > The semantics is described in patch #2. Program and link attachments are > mutually exclusive, in the sense that neither link can replace attached > program nor

Re: [RFT iproute2] iplink_bridge: scale all time values by USER_HZ

On Fri, 24 Jul 2020 17:31:12 -0700 (PDT) David Miller wrote: > From: niko...@cumulusnetworks.com > Date: Fri, 24 Jul 2020 19:24:35 +0300 > > > While I agree this should have been done from the start, it's too late to > > change. > > Agreed. Please fix the man page, the usage and add a war

[PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

__xfrm_tunnel_spi_check used xfrm6_tunnel_spi_has_byspi which returns spi % XFRM6_TUNNEL_SPI_BYSPI_HSIZE. whereas xfrm6_tunnel_spi_hash_byaddr makes a call to ipv6_addr_hash. netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim2: set [1, 0] type

Re: [PATCH bpf-next] udp: reduce merge conflict on udp[46]_lib_lookup2

On Sat, Jul 25, 2020 at 3:58 AM Kuniyuki Iwashima wrote: > > From: Willem de Bruijn > Date: Fri, 24 Jul 2020 22:54:57 -0400 > > From: Willem de Bruijn > > > > Commit efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") > > > > in net conflicts with > > > > Commit 72f7e9440e9b ("udp

Re: [PATCH net-next v2 6/6] smsc95xx: use PHY framework instead of MII library

Hi Andre, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Andre-Edich/Add-PAL-support-to-smsc95xx/20200723-195824 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 7fc3b978a8

Re: [PATCH] ipv6: Fix nexthop refcnt leak when creating ipv6 route info

On 7/25/20 2:02 AM, Xiyu Yang wrote: > ip6_route_info_create() invokes nexthop_get(), which increases the > refcount of the "nh". > > When ip6_route_info_create() returns, local variable "nh" becomes > invalid, so the refcount should be decreased to keep refcount balanced. I forgot to write the t

question about using UDP GSO in Linux kernel 4.19

My apologies if this is not the right place to ask this question. I'm trying to use UDP GSO to improve the throughput. My testing shows that UDP GSO works with the local server (i.e. loopback interface) but fails with a remote server (in WLAN, via wlan0 interface). My question is: do I need to ex

[Patch net] ipv6: fix memory leaks on IPV6_ADDRFORM path

IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket to IPv4, particularly struct ipv6_ac_socklist. Similar to struct ipv6_mc_socklist, we should just close it on this path. This bug can be easily reproduced with the following C program: #include #include #include #includ

Re: [GIT] Networking

The pull request you sent on Fri, 24 Jul 2020 22:12:04 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1b64b2e2444c11b8dd2b657f8538c05cb699ed25 Thank you! -- Deet-doot-dot, I am

Re: [PATCH net-next 3/3] docs: networking: timestamping: add a set of frequently asked questions

On Tue, Jul 21, 2020 at 08:25:53PM -0700, Richard Cochran wrote: > On Tue, Jul 21, 2020 at 10:51:27PM +0300, Vladimir Oltean wrote: > > So I think the position of "just don't have software timestamping code > > in DSA and you'll be fine" won't be getting us anywhere. Either you can > > or you can't

Re: [PATCH 0/6] rtlwifi: Convert RT_TRACE to rtl_dbg and neatening

On Sat, 2020-07-25 at 12:55 -0700, Joe Perches wrote: > RT_TRACE seems like it should be associated to tracing but it's not. > It's a generic debug logging mechanism. > Rename it to a more typical name. > Miscellaneous neatening around these changes. Patch 1/6 is over 1MB and is too large for some

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, 25 Jul 2020 20:48:46 +0200 Andrew Lunn wrote: > > > > +#if 0 > > > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */ > > > > + /* TODO: Support DUAL MODE */ > > > > + if (color == LED_COLOR_ID_MULTI) { > > > > + phydev_warn(phydev, "node %pOF: T

Re: [RESEND PATCH] ARM: dts: keystone-k2g-evm: fix rgmii phy-mode for ksz9031 phy

On 7/25/20 12:57 AM, Arnd Bergmann wrote: On Fri, Jul 24, 2020 at 11:57 PM santosh.shilim...@oracle.com wrote: On 7/24/20 2:42 PM, Grygorii Strashko wrote: Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") the networking is broken on keystone-k2g-evm boar

[Patch net-next] net_sched: initialize timer earlier in red_init()

When red_init() fails, red_destroy() is called to clean up. If the timer is not initialized yet, del_timer_sync() will complain. So we have to move timer_setup() before any failure. Reported-and-tested-by: syzbot+6e95a4fabf88dc217...@syzkaller.appspotmail.com Fixes: aee9caa03fc3 ("net: sched: sch_

Re: [PATCH net-next v2 5/6] smsc95xx: use PAL framework read/write functions

Hi Andre, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Andre-Edich/Add-PAL-support-to-smsc95xx/20200723-195824 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 7fc3b978a8

[PATCH 6/6] rtlwifi: Convert sleeped to slept in rtl_dbg uses

Use a more standard word. Signed-off-by: Joe Perches --- drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 2 +- drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 2 +- drivers/net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 2 +- drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 2

[PATCH 5/6] rtlwifi: Avoid multiline dereferences in rtl_dbg uses

Use a more typical kernel style in rtl_dbg uses. Signed-off-by: Joe Perches --- .../wireless/realtek/rtlwifi/rtl8188ee/phy.c | 3 +- .../realtek/rtlwifi/rtl8192c/phy_common.c | 48 +++ .../wireless/realtek/rtlwifi/rtl8192ce/phy.c | 3 +- .../wireless/realtek/rtlwifi/rtl81

[PATCH 4/6] rtlwifi: Convert rtl_dbg embedded function names to %s: ..., __func__

Use a more typical kernel style for embedded function names in debug logging statements. Signed-off-by: Joe Perches --- .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 +-- drivers/net/wireless/realtek/rtlwifi/cam.c | 14 ++ drivers/net/wireless/realtek/rtlwifi/core.c

[PATCH 0/6] rtlwifi: Convert RT_TRACE to rtl_dbg and neatening

RT_TRACE seems like it should be associated to tracing but it's not. It's a generic debug logging mechanism. Rename it to a more typical name. Miscellaneous neatening around these changes. Joe Perches (6): rtlwifi: Convert RT_TRACE to rtl_dbg rtlwifi: Remove unnecessary parenthese in rtl_dbg u

[PATCH 2/6] rtlwifi: Remove unnecessary parenthese in rtl_dbg uses

Make these statements a little simpler. Signed-off-by: Joe Perches --- drivers/net/wireless/realtek/rtlwifi/base.c | 14 +-- .../rtlwifi/btcoexist/halbtc8192e2ant.c | 23 ++- .../rtlwifi/btcoexist/halbtc8821a2ant.c | 12 +- .../realtek/rtlwifi/btcoex

[PATCH 3/6] rtlwifi: Better spacing around rtl_dbg uses

Use a more typical kernel style for rtl_dbg uses. Miscellanea: o Remove unnecessary braces and unindent a case statement o Realign or'd values and add parentheses Signed-off-by: Joe Perches --- drivers/net/wireless/realtek/rtlwifi/ps.c | 4 +- .../wireless/realtek/rtlwifi/rtl8188ee/hw.c

Re: [PATCH] net: ipv6: fix slab-out-of-bounds Read in __xfrm6_tunnel_spi_check

patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/B-K-Karthik/net-ipv6-fix-slab-out-of-bounds-Read-in-__xfrm6_tunnel_spi_check/20200725-213142 base: https://git.kernel.org/pub/scm/linux/kernel/gi

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

> > > +#if 0 > > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */ > > > + /* TODO: Support DUAL MODE */ > > > + if (color == LED_COLOR_ID_MULTI) { > > > + phydev_warn(phydev, "node %pOF: This driver does not yet > > > support multicolor LEDs\n", > > > + np)

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, Jul 25, 2020 at 08:02:24PM +0200, Marek Behun wrote: > On Sat, 25 Jul 2020 19:23:18 +0200 > Andrew Lunn wrote: > > > On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote: > > > This patch adds support for controlling the LEDs connected to several > > > families of Marvell PHYs via

KMSAN: uninit-value in strstr

Hello, syzbot found the following issue on: HEAD commit:93f54a72 instrumented.h: fix KMSAN support git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=118c345490 kernel config: https://syzkaller.appspot.com/x/.config?x=c534

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, 25 Jul 2020 19:23:18 +0200 Andrew Lunn wrote: > On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote: > > This patch adds support for controlling the LEDs connected to several > > families of Marvell PHYs via the PHY HW LED trigger API. These families > > are: 88E1112, 88E1121R, 88

Re: [RFC 0/7] Add support to process rx packets in thread

On 2020-07-25 10:16, Hillf Danton wrote: > Hi folks > > Below is a minimunm poc implementation I can imagine on top of workqueue > to make napi threaded. Thoughts are appreciated. Hi Hillf, For some reason I don't see your mails on linux-wireless/netdev. I've cleaned up your implementation a bit

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, Jul 25, 2020 at 07:39:50PM +0200, Marek Behun wrote: > On Sat, 25 Jul 2020 17:03:42 +0200 > Andrew Lunn wrote: > > > Does hi-z mean off? In the implementation i did, i did not list off > > and on as triggers. I instead used them for untriggered > > brightness. That allowed the software tr

Re: [RFC PATCH] net: dsa: microchip: delete dead code

On Thu, Jul 23, 2020 at 06:24:31AM +0200, Helmut Grohne wrote: > Hi Andrew, > > On Wed, Jul 22, 2020 at 04:39:53PM +0200, Andrew Lunn wrote: > > This patch probably is correct. But it is not obviously correct, > > because there are so many changes at once. Please could you break it > > up. > > >F

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, 25 Jul 2020 17:03:42 +0200 Andrew Lunn wrote: > Does hi-z mean off? In the implementation i did, i did not list off > and on as triggers. I instead used them for untriggered > brightness. That allowed the software triggers to work, so i had the > PHY blinking the heartbeat etc. But i had

Re: [RFC PATCH] net: dsa: qca8k: Add 802.1q VLAN support

On Thu, Jul 23, 2020 at 01:58:47AM +0300, Vladimir Oltean wrote: > On Wed, Jul 22, 2020 at 03:36:38PM -0700, Florian Fainelli wrote: > > On 7/22/20 12:38 PM, Jonathan McDowell wrote: > > > On Tue, Jul 21, 2020 at 10:26:07AM -0700, Florian Fainelli wrote: > > >> On 7/21/20 10:16 AM, Jonathan McDowel

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote: > This patch adds support for controlling the LEDs connected to several > families of Marvell PHYs via the PHY HW LED trigger API. These families > are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can > be added. > >

[PATCH] net/ipv4: add comment about connect() to INADDR_ANY

Copy comment from net/ipv6/tcp_ipv6.c to help future readers. Signed-off-by: Konstantin Khlebnikov --- net/ipv4/route.c |1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index a01efa062f6b..303fe706cbd2 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c

[PATCH v2] netfilter: Replace HTTP links with HTTPS ones

Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:

Re: [net-next 1/5] ice: add the virtchnl handler for AdminQ command

On Wed, Jul 22, 2020 at 6:07 PM Jakub Kicinski wrote: > > On Thu, 23 Jul 2020 00:37:29 + Venkataramanan, Anirudh wrote: > > Can you please clarify how you (and the community) define bifurcated > > driver? > > No amount of clarification from me will change the fact that you need > this for DPDK

Re: [PATCH net-next v2 3/6] smsc95xx: add PAL support to use external PHY drivers

Hi Andre, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Andre-Edich/Add-PAL-support-to-smsc95xx/20200723-195824 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 7fc3b978a8

Re: [PATCH RFC leds + net-next v3 1/2] net: phy: add API for LEDs controlled by PHY HW

On Fri, Jul 24, 2020 at 06:46:02PM +0200, Marek Behún wrote: > Many PHYs support various HW control modes for LEDs connected directly > to them. > > This code adds a new private LED trigger called phydev-hw-mode. When > this trigger is enabled for a LED, the various HW control modes which > the PH

Re: [RFC 0/7] Add support to process rx packets in thread

i agree. i just can say that i tested this patch recently due this discussion here. and it can be changed by sysfs. but it doesnt work for wifi drivers which are mainly using dummy netdev devices. for this i made a small patch to get them working using napi_set_threaded manually hardcoded in th

Re: ethtool 5.7: --change commands fail

On Sat, Jul 25, 2020 at 3:54 PM Michal Kubecek wrote: > > On Sat, Jul 25, 2020 at 09:49:36AM +0300, Ali MJ Al-Nasrawy wrote: > > ethtool: v5.7 > > kernel: v5.4.52 > > driver: r8169 + libphy > > > > Starting from v5.7, all ethtool --change commands fail to apply and > > show the following error mes

Re: [PATCH net-next] fib: use indirect call wrappers in the most common fib_rules_ops

Hi Brian, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Brian-Vazquez/fib-use-indirect-call-wrappers-in-the-most-common-fib_rules_ops/20200725-095008 base: https://git.kernel.org/pub/scm

[net-next v3 4/6] net: marvell: prestera: Add ethtool interface support

The ethtool API provides support for the configuration of the following features: speed and duplex, auto-negotiation, MDI-x, forward error correction, port media type. The API also provides information about the port status, hardware and software statistic. The following limitation exists: - p

[net-next v3 6/6] dt-bindings: marvell,prestera: Add description for device-tree bindings

Add brief description how to configure base mac address binding in device-tree. Describe requirement for the PCI port which is connected to the ASIC, to allow access to the firmware related registers. Signed-off-by: Vadym Kochan --- .../bindings/net/marvell,prestera.txt | 34 +++

[net-next v3 2/6] net: marvell: prestera: Add PCI interface support

Add PCI interface driver for Prestera Switch ASICs family devices, which provides: - Firmware loading mechanism - Requests & events handling to/from the firmware - Access to the firmware on the bus level The firmware has to be loaded each time device is reset. The driver is loading it

[net-next v3 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices

Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8 ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely wireless SMB deployment. The current implementation supports only boards designed for the Marvell Switchdev solution and requires special firmware. The core Preste

[net-next v3 3/6] net: marvell: prestera: Add basic devlink support

Add very basic support for devlink interface: - driver name - fw version - devlink ports Signed-off-by: Vadym Kochan --- drivers/net/ethernet/marvell/prestera/Kconfig | 1 + .../net/ethernet/marvell/prestera/Makefile| 2 +- .../net/ethernet/marvell/prestera/prestera.h | 4

[net-next v3 5/6] net: marvell: prestera: Add Switchdev driver implementation

The following features are supported: - VLAN-aware bridge offloading - VLAN-unaware bridge offloading - FDB offloading (learning, ageing) - Switchport configuration Currently there are some limitations like: - Only 1 VLAN-aware bridge instance supported - FDB ageing timeo

[net-next v3 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x)

Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8 ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely wireless SMB deployment. Prestera Switchdev is a firmware based driver that operates via PCI bus. The current implementation supports only boards designed for the

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, Jul 25, 2020 at 11:34:50AM +0200, Marek Behun wrote: > On Sat, 25 Jul 2020 11:23:39 +0200 > Pavel Machek wrote: > > > Hi! > > > > > +static const struct marvell_led_mode_info marvell_led_mode_info[] = { > > > + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 }, > > >

[net-next PATCH v7 6/6] net: dpaa2-mac: Add ACPI support for DPAA2 MAC driver

Modify dpaa2_mac_connect() to support ACPI along with DT. Modify dpaa2_mac_get_node() to get the dpmac fwnode from either DT or ACPI. Replace of_get_phy_mode with fwnode_get_phy_mode to get phy-mode for a dpmac_node. Define and use helper function find_phy_device() to find phy_dev that is later con

[net-next PATCH v7 0/6] ACPI support for dpaa2 MAC driver.

This patch series provides ACPI support for dpaa2 MAC driver. This also introduces ACPI mechanism to get PHYs registered on a MDIO bus and provide them to be connected to MAC. Previous discussions on this patchset is available at: https://lore.kernel.org/linux-acpi/20200715090400.4733-1-calv

[net-next PATCH v7 5/6] phylink: introduce phylink_fwnode_phy_connect()

Define phylink_fwnode_phy_connect() to connect phy specified by a fwnode to a phylink instance. Signed-off-by: Calvin Johnson Reviewed-by: Florian Fainelli --- Changes in v7: - assign flags to phy_dev Changes in v6: - clean up phylink_fwnode_phy_connect() Changes in v5: - return -EINVAL for

[net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY

Introduce ACPI mechanism to get PHYs registered on a MDIO bus and provide them to be connected to MAC. An ACPI node property "mdio-handle" is introduced to reference the MDIO bus on which PHYs are registered with autoprobing method used by mdiobus_register(). Describe properties "phy-channel" and

[net-next PATCH v7 4/6] net: phy: introduce phy_find_by_mdio_handle()

The PHYs on an mdiobus are probed and registered using mdiobus_register(). Later, for connecting these PHYs to MAC, the PHYs registered on the mdiobus have to be referenced. For each MAC node, a property "mdio-handle" is used to reference the MDIO bus on which the PHYs are registered. On getting h

[net-next PATCH v7 2/6] net: phy: introduce device_mdiobus_register()

Introduce device_mdiobus_register() to register mdiobus in cases of either DT or ACPI. Signed-off-by: Calvin Johnson --- Changes in v7: None Changes in v6: - change device_mdiobus_register() parameter position - improve documentation Changes in v5: - add description - clean up if else Changes

[net-next PATCH v7 3/6] net/fsl: use device_mdiobus_register()

Replace of_mdiobus_register() with device_mdiobus_register() to take care of both DT and ACPI mdiobus_register. Remove unused device_node pointer. Signed-off-by: Calvin Johnson --- Changes in v7: None Changes in v6: - change device_mdiobus_register() parameter position Changes in v5: None Cha

Re: [RFC 0/7] Add support to process rx packets in thread

Am 25.07.2020 um 14:25 schrieb Hillf Danton: On Sat, 25 Jul 2020 12:38:00 +0200 Sebastian Gottschall wrote: you may consider this https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html Thanks v

[PATCH] net: xfrm: xfrm_policy.c: remove some unnecessary cases in decode_session6

remove some unnecessary cases in decode_session6 Signed-off-by: B K Karthik --- net/xfrm/xfrm_policy.c | 4 1 file changed, 4 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index 19c5e0fa3f44..e1c988a89382 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_p

Re: [PATCH net-next] fib: use indirect call wrappers in the most common fib_rules_ops

Hi Brian, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Brian-Vazquez/fib-use-indirect-call-wrappers-in-the-most-common-fib_rules_ops/20200725-095008 base: https://git.kernel.org/pub/scm/linux

[PATCH] net: ipv6: fix slab-out-of-bounds Read in __xfrm6_tunnel_spi_check

use spi_byaddr instead of spi_byspi == BUG: KASAN: slab-out-of-bounds in __xfrm6_tunnel_spi_check+0x316/0x330 net/ipv6/xfrm6_tunnel.c:108 Read of size 8 at addr 8880a93a5e08 by task syz-executor.1/8482 CPU: 0 PID: 8482 Comm: syz-

Re: phc2sys - does it work?

On Sat, Jul 25, 2020 at 01:49:27PM +0100, Russell King - ARM Linux admin wrote: > Hi, > > I've been writing another PTP clock driver, and I'm wondering whether > phc2sys is actually working correctly. > > I'm running it with: phc2sys -c /dev/ptp1 -s CLOCK_REALTIME -q -m -O 0 > and I have addition

[PATCH v2 net] bareudp: forbid mixing IP and MPLS in multiproto mode

In multiproto mode, bareudp_xmit() accepts sending multicast MPLS and IPv6 packets regardless of the bareudp ethertype. In practice, this let an IP tunnel send multicast MPLS packets, or an MPLS tunnel send IPv6 packets. We need to restrict the test further, so that the multiproto mode only enable

Re: ethtool 5.7: --change commands fail

On Sat, Jul 25, 2020 at 09:49:36AM +0300, Ali MJ Al-Nasrawy wrote: > ethtool: v5.7 > kernel: v5.4.52 > driver: r8169 + libphy > > Starting from v5.7, all ethtool --change commands fail to apply and > show the following error message: > > $ ethtool -s ens5 autoneg off > netlink error: No such file

phc2sys - does it work?

Hi, I've been writing another PTP clock driver, and I'm wondering whether phc2sys is actually working correctly. I'm running it with: phc2sys -c /dev/ptp1 -s CLOCK_REALTIME -q -m -O 0 and I have additional pr_info() to debug in the clock driver. What I see is the "sys offset" that phc2sys comes

[PATCH] net: ipv6: fix slab-out-of-bounda Read in xfrm6_tunnel_alloc_spi

fix slab-out-of-bounds Read in xfrm6_tunnel_alloc_spi by checking for existance of head for the list spi_byspi == BUG: KASAN: slab-out-of-bounds in __xfrm6_tunnel_alloc_spi net/ipv6/xfrm6_tunnel.c:124 [inline] BUG: KASAN: slab-out-of

ethtool 5.7: --change commands fail

ethtool: v5.7 kernel: v5.4.52 driver: r8169 + libphy Starting from v5.7, all ethtool --change commands fail to apply and show the following error message: $ ethtool -s ens5 autoneg off netlink error: No such file or directory Cannot set new settings: No such file or directory not setting autone

Re: [PATCH net] bareudp: forbid mixing IP and MPLS in multiproto mode

On Fri, Jul 24, 2020 at 04:21:34PM -0700, Jakub Kicinski wrote: > On Fri, 24 Jul 2020 23:03:26 +0200 Guillaume Nault wrote: > > In multiproto mode, bareudp_xmit() accepts sending multicast MPLS and > > IPv6 packets regardless of the bareudp ethertype. In practice, this > > let an IP tunnel send mul

Re: [PATCH bpf-next] udp: reduce merge conflict on udp[46]_lib_lookup2

From: Willem de Bruijn Date: Fri, 24 Jul 2020 22:54:57 -0400 > From: Willem de Bruijn > > Commit efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") > > in net conflicts with > > Commit 72f7e9440e9b ("udp: Run SK_LOOKUP BPF program on socket lookup") > > in bpf-next. > > Commi

Re: [PATCH net] udp: Remove an unnecessary variable in udp[46]_lib_lookup2().

From: David Miller Date: Fri, 24 Jul 2020 16:48:47 -0700 (PDT) > From: Kuniyuki Iwashima > Date: Fri, 24 Jul 2020 15:13:04 +0900 > > > Yes. I think this kind of patch should be submitted to net-next, but > > this is for the net tree. Please let me add more description. > > This does not fix

Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY

On Sat, Jul 25, 2020 at 10:37 AM Calvin Johnson wrote: > On Fri, Jul 24, 2020 at 11:20:04PM +0300, Andy Shevchenko wrote: > > On Fri, Jul 24, 2020 at 11:13 PM Florian Fainelli > > wrote: > > > On 7/24/20 1:12 PM, Andy Shevchenko wrote: > > > > On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:

Re: [RFC 0/7] Add support to process rx packets in thread

you may consider this https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html years ago someone already wanted to bring this feature upstream, but it was denied. i already tested this patch the last

[PATCH v2 2/2] net: stmmac: Add dwmac-intel-plat for GBE driver

From: Rusaimi Amira Ruslan Add dwmac-intel-plat to enable the stmmac driver in Intel Keem Bay. Also add fix_mac_speed and tx_clk in order to change link speeds. This is required as mac_speed_o is not connected in the Intel Keem Bay SoC. Signed-off-by: Rusaimi Amira Ruslan Signed-off-by: Vineeth

[PATCH v2 1/2] dt-bindings: net: Add bindings for Intel Keem Bay

From: "Vineetha G. Jaya Kumaran" Add Device Tree bindings documentation for the ethernet controller on Intel Keem Bay. Signed-off-by: Vineetha G. Jaya Kumaran --- .../devicetree/bindings/net/intel,dwmac-plat.yaml | 121 + 1 file changed, 121 insertions(+) create mode 1006

[PATCH v2 0/2] Add Ethernet support for Intel Keem Bay SoC

From: "Vineetha G. Jaya Kumaran" Hello, This patch set enables support for Ethernet on the Intel Keem Bay SoC. The first patch contains the required Device Tree bindings documentation, while the second patch adds the Intel platform glue layer for the stmmac device driver. This driver was teste

Re: [PATCH RFC leds + net-next v2 1/1] net: phy: marvell: add support for PHY LEDs via LED class

Hi! > > > My main issue though is whether one "hw-control" trigger should be > > > registered via LED API and the specific mode should be chosen via > > > another sysfs file as in this RFC, or whether each HW control mode > > > should have its own trigger. The second solution would either result i

Re: [PATCH RFC leds + net-next v3 1/2] net: phy: add API for LEDs controlled by PHY HW

On Sat, 25 Jul 2020 11:21:24 +0200 Pavel Machek wrote: > Hi! > > > Many PHYs support various HW control modes for LEDs connected directly > > to them. > > > > This code adds a new private LED trigger called phydev-hw-mode. When > > this trigger is enabled for a LED, the various HW control modes

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat, 25 Jul 2020 11:23:39 +0200 Pavel Machek wrote: > Hi! > > > +static const struct marvell_led_mode_info marvell_led_mode_info[] = { > > + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 }, > > + { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 }

Re: [PATCH] ipv6: Fix nexthop reference count in ip6_route_info_create()

… > When ip6_route_info_create() returns, local variable "nh" becomes > invalid, so the refcount should be decreased to keep refcount balanced. Can it be helpful to use the term “reference count” in consistent ways? > Fix this issue How do you think about to replace this wording by the tag “Fix

[no subject]

Hello My Beloved, I am Mrs. Kristina Schwahlen, an aging widow suffering from long time illness (Esophageal Cancer). I have some important information (Charity Proposal) for you, Please reply (kschwah...@gmail.com) for more details. Your sister in the Lord, Mrs. Kristina Schwahlen

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

Hi! > +static const struct marvell_led_mode_info marvell_led_mode_info[] = { > + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 }, > + { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 }, > + { "1Gbps/100Mbps/10Mbps", { 0x2, -1, -1, -1,

Re: [PATCH RFC leds + net-next v3 1/2] net: phy: add API for LEDs controlled by PHY HW

Hi! > Many PHYs support various HW control modes for LEDs connected directly > to them. > > This code adds a new private LED trigger called phydev-hw-mode. When > this trigger is enabled for a LED, the various HW control modes which > the PHY supports for given LED can be get/set via hw_mode sysf

Re: [PATCH bpf-next] bpf: fix build on architectures with special bpf_user_pt_regs_t

On Fri, Jul 24, 2020 at 1:08 PM Song Liu wrote: > > Architectures like s390, powerpc, arm64, riscv have speical definition of > bpf_user_pt_regs_t. So we need to cast the pointer before passing it to > bpf_get_stack(). This is similar to bpf_get_stack_tp(). > > Fixes: 03d42fd2d83f ("bpf: Separate

[PATCH] ipv6: Fix nexthop refcnt leak when creating ipv6 route info

ip6_route_info_create() invokes nexthop_get(), which increases the refcount of the "nh". When ip6_route_info_create() returns, local variable "nh" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of

Re: [RESEND PATCH] ARM: dts: keystone-k2g-evm: fix rgmii phy-mode for ksz9031 phy

On Fri, Jul 24, 2020 at 11:57 PM santosh.shilim...@oracle.com wrote: > On 7/24/20 2:42 PM, Grygorii Strashko wrote: > > Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the > > KSZ9031 PHY") the networking is broken on keystone-k2g-evm board. > > > > The above board have phy-

Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY

On Fri, Jul 24, 2020 at 11:20:04PM +0300, Andy Shevchenko wrote: > On Fri, Jul 24, 2020 at 11:13 PM Florian Fainelli > wrote: > > On 7/24/20 1:12 PM, Andy Shevchenko wrote: > > > On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote: > > > > > >> I think we need to NACK all attempts to add ACPI sup

[PATCH net-next v5 2/2] hinic: add log in exception handling processes

improve the error message when functions return failure and dump relevant registers in some exception handling processes Signed-off-by: Luo bin --- V0~V1: fix some warning reported by sparse .../ethernet/huawei/hinic/hinic_hw_api_cmd.c | 27 +++- .../ethernet/huawei/hinic/hinic_hw_api_cmd.

[PATCH net-next v5 1/2] hinic: add support to handle hw abnormal event

add support to handle hw abnormal event such as hardware failure, cable unplugged,link error Signed-off-by: Luo bin --- V4~V5: remove 'err' variable in hinic_fw_reporter_dump V3~V4: remove 'watchdog_info' variable in hinic_fw_reporter_dump V2~V3: add devlink health support V1~V2: add link extende

[PATCH net-next v5 0/2] hinic: add some error messages for debug

patch #1: support to handle hw abnormal event patch #2: improve the error messages when functions return failure and dump relevant registers in some exception handling processes Luo bin (2): hinic: add support to handle hw abnormal event hinic: add log in exception handling processes

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior

Re: [PATCH v1 0/2] ptp: Add generic header parsing function

On Fri Jul 24 2020, Richard Cochran wrote: > On Fri, Jul 24, 2020 at 08:25:59AM +0200, Kurt Kanzenbach wrote: >> |static inline u8 ptp_get_msgtype(const struct ptp_header *hdr, unsigned int >> type) >> |{ >> |u8 msg; >> | >> |if (unlikely(type & PTP_CLASS_V1)) >> |/* msg type i

Re: [PATCH v2 0/8] Hirschmann Hellcreek DSA driver

On Fri Jul 24 2020, David Miller wrote: > Please never submit patches for serious review when the dependencies > haven't landed in the target tree yet. > > That makes so much wasted work for us and other reviewers. > > Thank you. > OK, noted. Sorry for that. Thanks, Kurt signature.asc Descripti