* Re: [PATCH net 0/3] MAINTAINERS updates
From: David Miller @ 2017-05-30 18:18 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, majd, saeedm, yishaih
In-Reply-To: <1496133846-18343-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 30 May 2017 11:44:03 +0300
> This patchset contains updates to the MAINTAINERS file.
> In the first patch, I replace Yishai as the maintainer of
> the mlx4_core driver.
>
> In the other two patches we move an RDMA header file from
> the list of the mlx4/mlx5 core driver into the respective
> IB driver, where it belongs.
>
> Series generated against net commit:
> 468b0df61a51 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
Series applied, thanks Tariq.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Fix netdev_features flag
From: David Miller @ 2017-05-30 18:16 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, arjun, swise
In-Reply-To: <1496131224-11688-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 30 May 2017 13:30:24 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> GRO is not supported by Chelsio HW when rx_csum is disabled.
> Update the netdev features flag when rx_csum is modified.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: FW upgrade fixes
From: David Miller @ 2017-05-30 18:13 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, arjun, leedom
In-Reply-To: <1496147766-12948-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 30 May 2017 18:06:06 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> Disable FW_OK flag while flashing Firmware. This will help to fix any
> potential mailbox timeouts during Firmware flash.
>
> Grab new devlog parameters after Firmware restart. When we FLASH new
> Firmware onto an adapter, the new Firmware may have the Firmware Device Log
> located at a different memory address or have a different size for it.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> v2:
> -Fix spelling mistake, "send" -> "sent"
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: add new T5 pci device id
From: David Miller @ 2017-05-30 18:12 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan
In-Reply-To: <1496125240-7439-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 30 May 2017 11:50:40 +0530
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume
From: Fabio Estevam @ 2017-05-30 18:12 UTC (permalink / raw)
To: Leonard Crestez
Cc: Shawn Guo, Florian Fainelli, Andrew Lunn, Andy Duan,
netdev@vger.kernel.org, Johan Hovold, linux-kernel,
Alexandre Belloni, Philipp Zabel, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <a8d0393c977b0d6fdab5d48ad13ca4d1ca893a07.1496164448.git.leonard.crestez@nxp.com>
Hi Leonard,
On Tue, May 30, 2017 at 2:34 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> These bits seem to be lost after a suspend/resume cycle so just set them
> again.
>
> This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
When you send a v2 addressing Florian's comment, please make sure you
send it to David Miller (netdev maintainer).
^ permalink raw reply
* Re: [PATCH net-next v2] cxgb4: keep carrier off before registering netdev
From: David Miller @ 2017-05-30 18:10 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, surendra
In-Reply-To: <1496124126-18597-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 30 May 2017 11:32:06 +0530
> From: Surendra Mobiya <surendra@chelsio.com>
>
> Mark carrier off before registering netdev to ensure that vlan device
> picks up the correct state of the carrier
>
> Signed-off-by: Surendra Mobiya <surendra@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> v2:
> - keep carrier off before registering netdev not after
Looks better, applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties
From: Florian Fainelli @ 2017-05-30 18:10 UTC (permalink / raw)
To: Leonard Crestez, Shawn Guo, Andrew Lunn, Andy Duan
Cc: Johan Hovold, Alexandre Belloni, Philipp Zabel, Fabio Estevam,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <d31aab90fbdecaf4c5f240becb2d0b0efb23f5c3.1496164448.git.leonard.crestez@nxp.com>
On 05/30/2017 10:34 AM, Leonard Crestez wrote:
> Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same
> register values can be set through the micrel phy driver by using dts
> properties.
>
> This seems preferable and allows cleanly fixing suspend/resume.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Should you have a Fixes: tag for that? Sounds like something you'd want
to backport to stable trees as well, no?
> ---
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> index f18e1f1..d2be8aa 100644
> --- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> +++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> @@ -120,10 +120,16 @@
>
> ethphy0: ethernet-phy@2 {
> reg = <2>;
> + micrel,led-mode = <1>;
> + clocks = <&clks IMX6UL_CLK_ENET_REF>;
> + clock-names = "rmii-ref";
> };
>
> ethphy1: ethernet-phy@1 {
> reg = <1>;
> + micrel,led-mode = <1>;
> + clocks = <&clks IMX6UL_CLK_ENET2_REF>;
> + clock-names = "rmii-ref";
> };
> };
> };
>
--
Florian
^ permalink raw reply
* Re: [PATCH net] net/mlx5: avoid build warning for uniprocessor
From: David Miller @ 2017-05-30 18:09 UTC (permalink / raw)
To: arnd
Cc: saeedm, matanb, leonro, mohamad, danielj, eli, avivh, huyn,
artemyko, netdev, linux-rdma, linux-kernel
In-Reply-To: <20170529130030.244337-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 29 May 2017 15:00:17 +0200
> Building the driver with CONFIG_SMP disabled results in a harmless
> warning:
>
> ethernet/mellanox/mlx5/core/main.c: In function 'mlx5_irq_set_affinity_hint':
> ethernet/mellanox/mlx5/core/main.c:615:6: error: unused variable 'irq' [-Werror=unused-variable]
>
> It's better to express the conditional compilation using IS_ENABLED()
> here, as that lets the compiler see what the intented use for the variable
> is, and that it can be silently discarded.
>
> Fixes: b665d98edc9a ("net/mlx5: Tolerate irq_set_affinity_hint() failures")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: Add missing static to stub functions
From: David Miller @ 2017-05-30 18:08 UTC (permalink / raw)
To: arnd; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20170529125612.110244-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 29 May 2017 14:56:01 +0200
> 'static' was not enough, the helpers must be 'static inline'
>
> net/dsa/mv88e6xxx/global2.h:123:12: error: 'mv88e6xxx_g2_misc_4_bit_port' defined but not used [-Werror=unused-function]
> net/dsa/mv88e6xxx/global2.h:117:12: error: 'mv88e6xxx_g2_pvt_write' defined but not used [-Werror=unused-function]
>
> Fixes: c21fbe29f858 ("net: dsa: mv88e6xxx: Add missing static to stub functions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume
From: Florian Fainelli @ 2017-05-30 18:05 UTC (permalink / raw)
To: Leonard Crestez, Shawn Guo, Andrew Lunn, Andy Duan
Cc: Johan Hovold, Alexandre Belloni, Philipp Zabel, Fabio Estevam,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <a8d0393c977b0d6fdab5d48ad13ca4d1ca893a07.1496164448.git.leonard.crestez@nxp.com>
On 05/30/2017 10:34 AM, Leonard Crestez wrote:
> These bits seem to be lost after a suspend/resume cycle so just set them
> again.
>
> This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/net/phy/micrel.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 6a5fd18..c53ee17 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -700,6 +700,9 @@ static int kszphy_suspend(struct phy_device *phydev)
>
> static int kszphy_resume(struct phy_device *phydev)
> {
> + struct kszphy_priv *priv = phydev->priv;
> + int ret;
> +
> genphy_resume(phydev);
>
> /* Enable PHY Interrupts */
> @@ -709,6 +712,18 @@ static int kszphy_resume(struct phy_device *phydev)
> phydev->drv->config_intr(phydev);
> }
>
> + if (priv->rmii_ref_clk_sel) {
> + ret = kszphy_rmii_clk_sel(phydev, priv->rmii_ref_clk_sel_val);
> + if (ret) {
> + phydev_err(phydev,
> + "failed to set rmii reference clock\n");
> + return ret;
> + }
> + }
> +
> + if (priv->led_mode >= 0)
> + kszphy_setup_led(phydev, priv->type->led_mode_reg, priv->led_mode);
Should not we actually call kszphy_config_init() in order to restore
broadcast and nand disable bits as well?
If not, I would be more comfortable if we did create a specific function
that takes care of setting the reference clock and LED mode.
Other than that, LGTM!
--
Florian
^ permalink raw reply
* Re: [PATCH v8 net-next 00/17] net: qualcomm: add QCA7000 UART driver
From: David Miller @ 2017-05-30 18:03 UTC (permalink / raw)
To: stefan.wahren-eS4NqCHxEME
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
LinoSanfilippo-Mmb7MZpHnFY, kubakici-5tc4TXWwyLM,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1496059045-13572-1-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
From: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Date: Mon, 29 May 2017 13:57:08 +0200
> The Qualcomm QCA7000 HomePlug GreenPHY supports two interfaces:
> UART and SPI. This patch series adds the missing support for UART.
>
> This driver based on the Qualcomm code [1], but contains some changes:
> * use random MAC address per default
> * use net_device_stats from device
> * share frame decoding between SPI and UART driver
> * improve error handling
> * reimplement tty_wakeup with work queue (based on slcan)
> * use new serial device bus instead of ldisc
>
> The patches 1 - 3 are just for clean up and are not related to
> the UART support. Patch 4 adds SET_NETDEV_DEV() to qca_spi.
> Patches 5 - 16 prepare the existing QCA7000 code for UART support.
> The last patch contains the new driver.
>
> The code itself has been tested on a Freescale i.MX28 board and
> a Raspberry Pi Zero.
Series applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/1] netvsc: Add #include's for csum_* function declarations
From: Joe Perches @ 2017-05-30 18:03 UTC (permalink / raw)
To: mikelley, davem, netdev, linux-kernel, devel, olaf, apw, jasowang,
leann.ogasawara, marcelo.cerri, sthemmin
In-Reply-To: <1496166184-19805-1-git-send-email-mikelley@microsoft.com>
On Tue, 2017-05-30 at 10:43 -0700, Michael Kelley wrote:
> Add direct #include statements for declarations of csum_tcpudp_magic()
> and csum_ipv6_magic(). While the needed #include's are picked up
> indirectly for the x86 architecture, they aren't on other
> architectures, resulting in compile errors.
[]
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 4421a6d..ca952b3 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -37,6 +37,8 @@
> #include <net/route.h>
> #include <net/sock.h>
> #include <net/pkt_sched.h>
> +#include <asm/checksum.h>
Maybe
#include <net/checksum.h>
instead?
> +#include <net/ip6_checksum.h>
>
> #include "hyperv_net.h"
>
^ permalink raw reply
* Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument
From: Kees Cook @ 2017-05-30 17:59 UTC (permalink / raw)
To: Djalal Harouni
Cc: Serge E. Hallyn, Rusty Russell, David S . Miller, Jessica Yu,
LKML, Network Development, linux-security-module,
kernel-hardening@lists.openwall.com, Andy Lutomirski,
Andrew Morton, James Morris, Paul Moore, Stephen Smalley,
Greg Kroah-Hartman, Tetsuo Handa, Ingo Molnar, Linux API,
Dongsu Park <dpar
In-Reply-To: <CAEiveUeZhHtPyLv8=3BsPh5Anr2ynnzD0bprUkeKUGygtRQKsw@mail.gmail.com>
On Wed, May 24, 2017 at 7:16 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> On Tue, May 23, 2017 at 9:19 PM, Kees Cook <keescook@google.com> wrote:
>> On Tue, May 23, 2017 at 3:29 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
>> Even in the existing code, there is a sense about CAP_NET_ADMIN and
>> CAP_SYS_MODULE having different privilege levels, in that
>> CAP_NET_ADMIN can only load netdev-%s modules, but CAP_SYS_MODULE can
>> load any module. What about refining request_module_cap() to _require_
>> an explicit string prefix instead of an arbitrary format string? e.g.
>> request_module_cap(CAP_NET_ADMIN, "netdev", "%s", name) which would
>> make requests for ("netdev-%s", name)
>>
>> I see a few options:
>>
>> 1) keep what you have for v4, and hope other places don't use
>> __request_module. (I'm not a fan of this.)
>
> Yes even if it is documented I wouldn't bet on it, though. :-)
Okay, we seem to agree: we'll not use #1.
>> 2) switch the logic on autoload==1 from OR to AND: both the specified
>> caps _and_ CAP_SYS_MODULE are required. (This seems like it might make
>> autoload==1 less useful.)
>
> That will restrict some userspace that works only with CAP_NET_ADMIN.
Nor #2.
>> 3) use the request_module_cap() outlined above, which requires that
>> modules being loaded under a CAP_SYS_MODULE-aliased capability are at
>> least restricted to a subset of kernel module names.
>
> This one tends to allow usability.
Right, discussed below...
>> 4) same as 3 but also insert autoload==2 level that switches from OR
>> to AND (bumping existing ==2 to ==3).
>
> I wouldn't expose autoload to callers, I think it is better if it
> stays a property of the module subsystem. But lets use the bump idea,
> please see below.
If we can't agree below, I think #4 would be a good way to allow for
both states.
>> What do you think?
>
> Ok so given that we already have modules_autoload_mode=2 disabled,
> maybe we go with 3) like this ?
>
> int __request_module(bool wait, int required_cap, const char *prefix,
> const char *name, ...);
> #define request_module(mod...) \
> __request_module(true, -1, NULL, mod)
> #define request_module_cap(required_cap, prefix, mod...) \
> __request_module(true, required_cap, prefix, mod)
>
> and we require allow_cap and prefix to be set.
>
> request_module_cap(CAP_NET_ADMIN, "netdev-", "%s", name) for
> net/core/dev_ioctl.c:dev_load()
>
> request_module_cap(CAP_NET_ADMIN, "tcp_", "%s", name) for
> net/ipv4/tcp_cong.c functions.
>
>
> Then
> __request_module()
> -> security_kernel_module_request(module_name, required_cap, prefix)
> -> may_autoload_module(current, module_name, required_cap, prefix)
>
>
> And update may_autoload_module() as below ? we hard code CAP_NET_ADMIN
> and CAP_SYS_MODULE inside and make them the only capabilities needed
> for a privileged auto-load operation.
I still think making a specific exception for CAP_NET_ADMIN is not the
right solution, instead allowing for non-CAP_SYS_MODULE caps when
using a distinct prefix.
> request_module_cap(CAP_SYS_MODULE, ...) or
> request_module_cap(CAP_NET_ADMIN, ...) if the autoload should be a
> privileged operation.
>
> Kees will this work ?
>
> Jessica, Rusty, Serge. What do you think ? I definitively think that
> module_autoload should be contained only inside the module subsystem..
I'd change it like this:
> +int may_autoload_module(struct task_struct *task, char *kmod_name,
> + int require_cap, char *prefix)
> +{
> + unsigned int autoload;
> + int module_require_cap = 0;
I'd initialize this to module_require_cap = CAP_SYS_MODULE;
> +
> + if (require_cap > 0) {
> + if (prefix == NULL || *prefix == '\0')
> + return -EPERM;
Since an unprefixed module load should only be CAP_SYS_MODULE, change
the above "if" to:
if (require_cap > 0 && prefix != NULL && *prefix != '\0')
> +
> + /*
> + * We only allow CAP_SYS_MODULE or CAP_NET_ADMIN for
> + * 'netdev-%s' modules for backward compatibility.
> + * Please do not overload capabilities.
> + */
> + if (require_cap == CAP_SYS_MODULE ||
> + require_cap == CAP_NET_ADMIN)
> + module_require_cap = require_cap;
> + else
> + return -EPERM;
> + }
And then drop all these checks, leaving only:
module_require_cap = require_cap;
> +
> + /* Get max value of sysctl and task "modules_autoload_mode" */
> + autoload = max_t(unsigned int, modules_autoload_mode,
> + task->modules_autoload_mode);
> +
> + /*
> + * If autoload is disabled then fail here and not bother at all
> + */
> + if (autoload == MODULES_AUTOLOAD_DISABLED)
> + return -EPERM;
> +
> + /*
> + * If caller require capabilities then we may not allow
> + * automatic module loading. We should not bypass callers.
> + * This allows to support networking code that uses CAP_NET_ADMIN
> + * for some aliased 'netdev-%s' modules.
> + *
> + * Explicitly bump autoload here if necessary
> + */
> + if (module_require_cap && autoload == MODULES_AUTOLOAD_ALLOWED)
> + autoload = MODULES_AUTOLOAD_PRIVILEGED;
I don't see a reason to bump the autoload level.
> +
> + if (autoload == MODULES_AUTOLOAD_ALLOWED)
> + return 0;
This test can be moved to above the AUTOLOAD_DISABLED test.
> + else if(autoload == MODULES_AUTOLOAD_PRIVILEGED) {
> + /*
> + * If module auto-load is a privileged operation then check
> + * if capabilities are set.
> + */
> + if (capable(CAP_SYS_MODULE) ||
> + (module_require_cap && capable(module_require_cap)))
> + return 0;
> + }
This test could drop the explicit CAP_SYS_MODULE test and just rely on
module_require_cap.
> +
> + return -EPERM;
> +}
> +
So, I would suggest:
int may_autoload_module(struct task_struct *task, char *kmod_name,
int require_cap, char *prefix)
{
unsigned int autoload;
int module_require_cap;
if (autoload == MODULES_AUTOLOAD_DISABLED)
return -EPERM;
/* Get max value of sysctl and task "modules_autoload_mode" */
autoload = max_t(unsigned int, modules_autoload_mode,
task->modules_autoload_mode);
if (autoload == MODULES_AUTOLOAD_ALLOWED)
return 0;
/*
* It should be impossible for autoload to have any other
* value at this point, so explicitly reject all other states.
*/
if (autoload != MODULES_AUTOLOAD_PRIVILEGED)
return -EPERM;
/* Verify that alternate capabilities requirements had a prefix. */
if (require_cap > 0 && prefix != NULL && *prefix != '\0')
module_require_cap = require_cap;
else
module_require_cap = CAP_SYS_MODULE;
return capable(module_require_cap);
}
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH net-next 1/1] netvsc: Add #include's for csum_* function declarations
From: Michael Kelley @ 2017-05-30 17:43 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang,
leann.ogasawara, marcelo.cerri, sthemmin
Cc: Michael Kelley
Add direct #include statements for declarations of csum_tcpudp_magic()
and csum_ipv6_magic(). While the needed #include's are picked up
indirectly for the x86 architecture, they aren't on other
architectures, resulting in compile errors.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4421a6d..ca952b3 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -37,6 +37,8 @@
#include <net/route.h>
#include <net/sock.h>
#include <net/pkt_sched.h>
+#include <asm/checksum.h>
+#include <net/ip6_checksum.h>
#include "hyperv_net.h"
--
1.7.1
^ permalink raw reply related
* [net-qed] question about potential null pointer dereference
From: Gustavo A. R. Silva @ 2017-05-30 17:42 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2; +Cc: netdev, linux-kernel
Hello everybody,
While looking into Coverity ID 1362293 I ran into the following piece
of code at drivers/net/ethernet/qlogic/qed/qed_sriov.c:3863:
3863static int
3864qed_iov_configure_min_tx_rate(struct qed_dev *cdev, int vfid, u32 rate)
3865{
3866 struct qed_vf_info *vf;
3867 u8 vport_id;
3868 int i;
3869
3870 for_each_hwfn(cdev, i) {
3871 struct qed_hwfn *p_hwfn = &cdev->hwfns[i];
3872
3873 if (!qed_iov_pf_sanity_check(p_hwfn, vfid)) {
3874 DP_NOTICE(p_hwfn,
3875 "SR-IOV sanity check failed,
can't set min rate\n");
3876 return -EINVAL;
3877 }
3878 }
3879
3880 vf = qed_iov_get_vf_info(QED_LEADING_HWFN(cdev), (u16)vfid, true);
3881 vport_id = vf->vport_id;
3882
3883 return qed_configure_vport_wfq(cdev, vport_id, rate);
3884}
The issue here is that in case function qed_iov_get_vf_info() at line
3880, returns NULL, a NULL pointer dereference will take place at line
3881.
Maybe a patch like the following could be applied in order to avoid
any potential NULL pointer dereference:
index 71e392f..6bf1f0e2 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -3878,6 +3878,9 @@ qed_iov_configure_min_tx_rate(struct qed_dev
*cdev, int vfid, u32 rate)
}
vf = qed_iov_get_vf_info(QED_LEADING_HWFN(cdev), (u16)vfid, true);
+ if (!vf)
+ return -EINVAL;
+
vport_id = vf->vport_id;
return qed_configure_vport_wfq(cdev, vport_id, rate);
What do you think?
I'd really appreciate any comment on this.
Thank you!
--
Gustavo A. R. Silva
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/3] perf, bpf: Add BPF support to all perf_event types
From: Alexei Starovoitov @ 2017-05-30 17:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: David S . Miller, Brendan Gregg, Daniel Borkmann, Teng Qin,
netdev, linux-kernel
In-Reply-To: <20170530165102.kvcutyfp6i2in2zx@hirez.programming.kicks-ass.net>
On 5/30/17 9:51 AM, Peter Zijlstra wrote:
> On Tue, May 30, 2017 at 08:52:14AM -0700, Alexei Starovoitov wrote:
>
>>> + if (!(event->attach_state & PERF_ATTACH_TASK) &&
>>> + event->cpu != cpu)
>>> + return false;
>>
>> we do if (unlikely(event->oncpu != cpu))
>> as dynamic check inside bpf_perf_event_read(), since we cannot do it
>> statically at perf_event_array update time.
>
> Right, that's what I thought.
>
>> If we drop the above 'if' and keep 'task==null' trick,
>> then indeed we can use this function as static check.
>
> Right, or otherwise have a special value to disable it.
>
>> Right now we're trying to keep as many checks as possible as
>> static checks to make bpf_perf_event_read() faster.
>> I guess we can drop that approach and do perf_event_valid_local()
>> check for every read since perf_event_read_local() does all the
>> same checks anyway.
>> So how about converting all WARN_ON in perf_event_read_local()
>> into 'return -EINVAL' and change func proto into:
>> int perf_event_read_local(struct perf_event *even, u64 *counter_val)
>
> I'm confused on how that is better. My recent patches to WARN should
> have greatly improved performance of WARN_ON_ONCE(). And looking at that
> code, I suspect its dominated by the POPF for inactive events.
>
>>> I cannot find reason for this comment. That is, why would
>>> perf_event_read_local() not support those two types?
>>
>> I don't know. What is the meaning of
>> reading tracepoint/breakpoint counter?
>
> They count like all other software events. +1 for each occurrence.
>
> So for instance, if you use irq_vectors:local_timer_entry you get how
> many cpu local timer instances happened during your measurement window.
>
> Same with a breakpoint, it counts how many times it got hit. Typically
> you'd want to install a custom handler on breakpoints to do something
> 'interesting', but even without that its acts like a normal software
> event.
>
>> Because of 'event->oncpu != cpu' dynamic check all counters are
>> expected to be per-cpu. I'm not sure how uncore counters work.
>
> Uncore thingies are assigned to any online CPU in their 'domain'.
>
>> What do they have in event->oncpu? -1? I guess they have pmu->count?
>> So we cannot read them from bpf program anyway?
>
> They have the CPU number of the CPU that's assigned to them. So you
> _could_ make use of them, but its a bit tricky to get them to work
> reliably because you'd have to get that CPU 'right' and it can change.
>
> Typically they would end up on the first CPU in their domain, but with
> CPU hotplug you can move them about and get confusion.
>
> I'd have to think on how to do that nicely.
>
>> If we change warn_ons in perf_event_read_local() to returns
>> them we can make per-task counters working.
>
> I'm not entirely sure I see how that is required. Should per task not
> already work? The WARN that's there will only trigger if you call them
> on the wrong task, which is something you shouldn't do anyway.
The kernel WARN is considered to be a bug of bpf infra. That's the
reason we do all these checks at map update time and at run-time.
The bpf program authors should be able to do all possible experiments
until their scripts work. Dealing with kernel warns and reboots is not
something user space folks like to do.
Today bpf_perf_event_read() for per-task events isn't really
working due to event->oncpu != cpu runtime check in there.
If we convert warns to returns the existing scripts will continue
to work as-is and per-task will be possible.
^ permalink raw reply
* [PATCH 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume
From: Leonard Crestez @ 2017-05-30 17:34 UTC (permalink / raw)
To: Shawn Guo, Florian Fainelli, Andrew Lunn, Andy Duan
Cc: Johan Hovold, Alexandre Belloni, Philipp Zabel, Fabio Estevam,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1496164448.git.leonard.crestez@nxp.com>
These bits seem to be lost after a suspend/resume cycle so just set them
again.
This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/net/phy/micrel.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 6a5fd18..c53ee17 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -700,6 +700,9 @@ static int kszphy_suspend(struct phy_device *phydev)
static int kszphy_resume(struct phy_device *phydev)
{
+ struct kszphy_priv *priv = phydev->priv;
+ int ret;
+
genphy_resume(phydev);
/* Enable PHY Interrupts */
@@ -709,6 +712,18 @@ static int kszphy_resume(struct phy_device *phydev)
phydev->drv->config_intr(phydev);
}
+ if (priv->rmii_ref_clk_sel) {
+ ret = kszphy_rmii_clk_sel(phydev, priv->rmii_ref_clk_sel_val);
+ if (ret) {
+ phydev_err(phydev,
+ "failed to set rmii reference clock\n");
+ return ret;
+ }
+ }
+
+ if (priv->led_mode >= 0)
+ kszphy_setup_led(phydev, priv->type->led_mode_reg, priv->led_mode);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties
From: Leonard Crestez @ 2017-05-30 17:34 UTC (permalink / raw)
To: Shawn Guo, Florian Fainelli, Andrew Lunn, Andy Duan
Cc: netdev, Johan Hovold, linux-kernel, Alexandre Belloni,
Philipp Zabel, Fabio Estevam, linux-arm-kernel
In-Reply-To: <cover.1496164448.git.leonard.crestez@nxp.com>
Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same
register values can be set through the micrel phy driver by using dts
properties.
This seems preferable and allows cleanly fixing suspend/resume.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
index f18e1f1..d2be8aa 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
@@ -120,10 +120,16 @@
ethphy0: ethernet-phy@2 {
reg = <2>;
+ micrel,led-mode = <1>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
};
ethphy1: ethernet-phy@1 {
reg = <1>;
+ micrel,led-mode = <1>;
+ clocks = <&clks IMX6UL_CLK_ENET2_REF>;
+ clock-names = "rmii-ref";
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] ARM: imx6ul-14x14-evk: Fix suspend over nfs by phy cleanup
From: Leonard Crestez @ 2017-05-30 17:34 UTC (permalink / raw)
To: Shawn Guo, Florian Fainelli, Andrew Lunn, Andy Duan
Cc: Johan Hovold, Alexandre Belloni, Philipp Zabel, Fabio Estevam,
netdev, linux-arm-kernel, linux-kernel
Right now attempting doing suspend/resume while root is mounted over NFS hangs
on imx6ul-14x14-evk. This is happening because ksz8081 phy fixups are lost on
resume.
Fix this by using equivalent devicetree properties instead of a phy fixup and
handling those properties on resume in the micrel driver.
Other solutions would be possible such as having a way to run phy fixups again
on resume. This alternative is precisely targeted.
In theory it might now be possible to remove the phy fixup from mach-imx6ul
entirely but it is possible that this would break other imx6ul boards which use
the same phy. The solution would be to patch their dts but it's not clear how
to identify affected boards.
This code is shared with imx6ull-14x14-evk but 6ull suspend needs an unrelated
patch: https://lkml.org/lkml/2017/5/30/584
Leonard Crestez (2):
ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties
net: phy: micrel: Restore led_mode and clk_sel on resume
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 6 ++++++
drivers/net/phy/micrel.c | 15 +++++++++++++++
2 files changed, 21 insertions(+)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next 1/3] netvsc: optimize calculation of number of slots
From: Stephen Hemminger @ 2017-05-30 17:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sthemmin
In-Reply-To: <20170529.204204.1236270965995441170.davem@davemloft.net>
On Mon, 29 May 2017 20:42:04 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> Stephen, please provide proper header "[PATCH net-next 0/3] " postings
> with your patch series, so we know at a high level what this patch
> series is doing, how it is doing it, and why it is doing it that
> way.
Sure, these were just misc small cleanups. Prefer to send them out
in small chunks, not mixed with bug fixes and new features.
> I've been quite liberal with your patch postings in the past, hoping
> you would catch on, but now I'm going to simply enforce what I ask
> of every other patch series submitter.
Sorry, thought it was obvious from content.
^ permalink raw reply
* ATENCIÓN
From: Sistemas administrador @ 2017-05-30 16:01 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH V6 net-next iproute] ip: Add support for netdev events to monitor
From: Stephen Hemminger @ 2017-05-30 17:12 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, dsahern, roopa, jiri, vfalico, andy, Vladislav Yasevich
In-Reply-To: <1495894476-9726-4-git-send-email-vyasevic@redhat.com>
On Sat, 27 May 2017 10:14:36 -0400
Vladislav Yasevich <vyasevich@gmail.com> wrote:
>
> +static const char *netdev_events[] = {"NONE",
> + "REBOOT",
> + "FEATURE CHANGE",
> + "BONDING FAILOVER",
> + "NOTIFY PEERS",
> + "RESEND IGMP",
> + "BONDING OPTION"};
Overall this looks fine, I will pickup the if_link.h from net-next.
One stylistic change.
Please add simple line break, and initialize by value:
static const char *netdev_events[] = {
[IFLA_EVENT_NONE] = "NONE",
...
Do you want some prefix or bounding around the event output?
Also a little concerned that the output format change may break some program
could the new output be at the end of the line?
^ permalink raw reply
* Re: [Patch net-next] net_sched: only create filter chains for new filters/actions
From: Cong Wang @ 2017-05-30 17:05 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiri Pirko
In-Reply-To: <20170527100559.GC1831@nanopsycho>
On Sat, May 27, 2017 at 3:05 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Cong, as you wisely put, I'm not aware of this pattern and I'm also
> unaware of existence of ternary operator. Are this notes necessary?
> Does that make you feel better?
>
You are more than just welcome to redirect my email to
your /dev/null. I am quite sure my email is waste for you.
Thanks!!
^ permalink raw reply
* [net-wireless-orinoco] question about potential null pointer dereference
From: Gustavo A. R. Silva @ 2017-05-30 17:00 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, netdev, linux-kernel
Hello everybody,
While looking into Coverity ID 1357460 I ran into the following piece
of code at drivers/net/wireless/intersil/orinoco/mic.c:48
48int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
49 u8 *da, u8 *sa, u8 priority,
50 u8 *data, size_t data_len, u8 *mic)
51{
52 SHASH_DESC_ON_STACK(desc, tfm_michael);
53 u8 hdr[ETH_HLEN + 2]; /* size of header + padding */
54 int err;
55
56 if (tfm_michael == NULL) {
57 printk(KERN_WARNING "orinoco_mic: tfm_michael == NULL\n");
58 return -1;
59 }
60
61 /* Copy header into buffer. We need the padding on the end zeroed */
62 memcpy(&hdr[0], da, ETH_ALEN);
63 memcpy(&hdr[ETH_ALEN], sa, ETH_ALEN);
64 hdr[ETH_ALEN * 2] = priority;
65 hdr[ETH_ALEN * 2 + 1] = 0;
66 hdr[ETH_ALEN * 2 + 2] = 0;
67 hdr[ETH_ALEN * 2 + 3] = 0;
68
69 desc->tfm = tfm_michael;
70 desc->flags = 0;
71
72 err = crypto_shash_setkey(tfm_michael, key, MIC_KEYLEN);
73 if (err)
74 return err;
75
76 err = crypto_shash_init(desc);
77 if (err)
78 return err;
79
80 err = crypto_shash_update(desc, hdr, sizeof(hdr));
81 if (err)
82 return err;
83
84 err = crypto_shash_update(desc, data, data_len);
85 if (err)
86 return err;
87
88 err = crypto_shash_final(desc, mic);
89 shash_desc_zero(desc);
90
91 return err;
92}
The issue here is that line 56 implies that pointer tfm_michael might
be NULL. If this is the case, there is a potential NULL pointer
dereference at line 52 once pointer tfm_michael is indirectly
dereferenced inside macro SHASH_DESC_ON_STACK().
My question is if there is any chance that pointer tfm_michael might
be NULL when calling macro SHASH_DESC_ON_STACK() ?
I'm trying to figure out if this is a false positive or something that
needs to be fixed somehow.
I'd really appreciate any comment on this.
Thank you!
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [PATCH v2 net-next 1/3] perf, bpf: Add BPF support to all perf_event types
From: Peter Zijlstra @ 2017-05-30 16:51 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Brendan Gregg, Daniel Borkmann, Teng Qin,
netdev, linux-kernel
In-Reply-To: <a6bf362c-9df9-f387-bac3-ab5516e4cb68@fb.com>
On Tue, May 30, 2017 at 08:52:14AM -0700, Alexei Starovoitov wrote:
> > + if (!(event->attach_state & PERF_ATTACH_TASK) &&
> > + event->cpu != cpu)
> > + return false;
>
> we do if (unlikely(event->oncpu != cpu))
> as dynamic check inside bpf_perf_event_read(), since we cannot do it
> statically at perf_event_array update time.
Right, that's what I thought.
> If we drop the above 'if' and keep 'task==null' trick,
> then indeed we can use this function as static check.
Right, or otherwise have a special value to disable it.
> Right now we're trying to keep as many checks as possible as
> static checks to make bpf_perf_event_read() faster.
> I guess we can drop that approach and do perf_event_valid_local()
> check for every read since perf_event_read_local() does all the
> same checks anyway.
> So how about converting all WARN_ON in perf_event_read_local()
> into 'return -EINVAL' and change func proto into:
> int perf_event_read_local(struct perf_event *even, u64 *counter_val)
I'm confused on how that is better. My recent patches to WARN should
have greatly improved performance of WARN_ON_ONCE(). And looking at that
code, I suspect its dominated by the POPF for inactive events.
> > I cannot find reason for this comment. That is, why would
> > perf_event_read_local() not support those two types?
>
> I don't know. What is the meaning of
> reading tracepoint/breakpoint counter?
They count like all other software events. +1 for each occurrence.
So for instance, if you use irq_vectors:local_timer_entry you get how
many cpu local timer instances happened during your measurement window.
Same with a breakpoint, it counts how many times it got hit. Typically
you'd want to install a custom handler on breakpoints to do something
'interesting', but even without that its acts like a normal software
event.
> Because of 'event->oncpu != cpu' dynamic check all counters are
> expected to be per-cpu. I'm not sure how uncore counters work.
Uncore thingies are assigned to any online CPU in their 'domain'.
> What do they have in event->oncpu? -1? I guess they have pmu->count?
> So we cannot read them from bpf program anyway?
They have the CPU number of the CPU that's assigned to them. So you
_could_ make use of them, but its a bit tricky to get them to work
reliably because you'd have to get that CPU 'right' and it can change.
Typically they would end up on the first CPU in their domain, but with
CPU hotplug you can move them about and get confusion.
I'd have to think on how to do that nicely.
> If we change warn_ons in perf_event_read_local() to returns
> them we can make per-task counters working.
I'm not entirely sure I see how that is required. Should per task not
already work? The WARN that's there will only trigger if you call them
on the wrong task, which is something you shouldn't do anyway.
^ 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