* Re: [PATCH] net: smc91x: fix neponset breakage by pxa u16 writes
From: David Miller @ 2016-10-20 15:21 UTC (permalink / raw)
To: robert.jarzmik; +Cc: nico, netdev, linux-kernel
In-Reply-To: <1476912230-18175-1-git-send-email-robert.jarzmik@free.fr>
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Wed, 19 Oct 2016 23:23:50 +0200
> The patch isolating the u16 writes for pxa assumed all machine_is_*()
> calls were removed, and therefore removed the mach-types.h include which
> provided them.
>
> Unfortunately 2 machine_is_*() remained in smc91x.c file including
> smc91x.h from which the include was removed, triggering the error:
> drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_drv_probe’:
> drivers/net/ethernet/smsc/smc91x.c:2380:2: error: implicit declaration
> of function ‘machine_is_assabet’
> [-Werror=implicit-function-declaration]
> if (machine_is_assabet() && machine_has_neponset())
>
> This adds back the wrongly removed include.
>
> Fixes: d09d747ae4c2 ("net: smc91x: isolate u16 writes alignment workaround")
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Applied.
^ permalink raw reply
* Re: [PATCH net] ila: Fix tailroom allocation of lwtstate
From: David Miller @ 2016-10-20 15:20 UTC (permalink / raw)
To: tgraf; +Cc: tom, netdev
In-Reply-To: <d7e2292a2be9d142a05b7c528746820bac358065.1476911506.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Wed, 19 Oct 2016 23:16:39 +0200
> Tailroom is supposed to be of length sizeof(struct ila_lwt) but
> sizeof(struct ila_params) is currently allocated.
>
> This leads to the dst_cache and connected member of ila_lwt being
> referenced out of bounds.
>
> struct ila_lwt {
> struct ila_params p;
> struct dst_cache dst_cache;
> u32 connected : 1;
> };
>
> Fixes: 65d7ab8de582 ("net: Identifier Locator Addressing module")
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> -stable candidate
This patch only applies to net-next, so I've applied it there.
Please explain how I should handle 'net' and -stable.
^ permalink raw reply
* Re: [PATCH net] net/sched: act_mirred: Use passed lastuse argument
From: David Miller @ 2016-10-20 15:15 UTC (permalink / raw)
To: ogerlitz; +Cc: amirva, jakub.kicinski, netdev, paulb
In-Reply-To: <1476888159-30332-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 19 Oct 2016 17:42:39 +0300
> From: Paul Blakey <paulb@mellanox.com>
>
> stats_update callback is called by NIC drivers doing hardware
> offloading of the mirred action. Lastuse is passed as argument
> to specify when the stats was actually last updated and is not
> always the current time.
>
> Fixes: 9798e6fe4f9b ('net: act_mirred: allow statistic updates from offloaded actions')
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net] bpf, test: fix ld_abs + vlan push/pop stress test
From: Daniel Borkmann @ 2016-10-20 15:13 UTC (permalink / raw)
To: davem; +Cc: alexei.starovoitov, netdev, Daniel Borkmann
After commit 636c2628086e ("net: skbuff: Remove errornous length
validation in skb_vlan_pop()") mentioned test case stopped working,
throwing a -12 (ENOMEM) return code. The issue however is not due to
636c2628086e, but rather due to a buggy test case that got uncovered
from the change in behaviour in 636c2628086e.
The data_size of that test case for the skb was set to 1. In the
bpf_fill_ld_abs_vlan_push_pop() handler bpf insns are generated that
loop with: reading skb data, pushing 68 tags, reading skb data,
popping 68 tags, reading skb data, etc, in order to force a skb
expansion and thus trigger that JITs recache skb->data. Problem is
that initial data_size is too small.
While before 636c2628086e, the test silently bailed out due to the
skb->len < VLAN_ETH_HLEN check with returning 0, and now throwing an
error from failing skb_ensure_writable(). Set at least minimum of
ETH_HLEN as an initial length so that on first push of data, equivalent
pop will succeed.
Fixes: 4d9c5c53ac99 ("test_bpf: add bpf_skb_vlan_push/pop() tests")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
lib/test_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 94346b4..0362da0 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -4831,7 +4831,7 @@ static int bpf_fill_ld_abs_vlan_push_pop(struct bpf_test *self)
{ },
INTERNAL,
{ 0x34 },
- { { 1, 0xbef } },
+ { { ETH_HLEN, 0xbef } },
.fill_helper = bpf_fill_ld_abs_vlan_push_pop,
},
/*
--
1.9.3
^ permalink raw reply related
* Re: [patch net 0/4] mlxsw: Couple of fixes
From: David Miller @ 2016-10-20 15:11 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1476972345-31568-1-git-send-email-jiri@resnulli.us>
All applied, thanks Jiri.
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Stephen Smalley @ 2016-10-20 14:58 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: e, paul
In-Reply-To: <1476946352-15770-1-git-send-email-xiyou.wangcong@gmail.com>
On 10/20/2016 02:52 AM, Cong Wang wrote:
> A kernel warning inside __local_bh_enable_ip() was reported by people
> running SELinux, this is caused due to some SELinux functions
> (indirectly) call peernet2id() with IRQ disabled in process context,
> when we re-enable BH with IRQ disabled kernel complains. Shut up this
> warning by saving IRQ context in peernet2id(), BH is still implicitly
> disabled.
Not sure this suffices; kill_fasync() -> send_sigio() ->
send_sigio_to_task() -> sigio_perm() -> security_file_send_sigiotask()
-> selinux_file_send_sigiotask() -> ... -> audit_log() -> ... ->
peernet2id()
>
> Fixes: bc51dddf98c9 ("netns: avoid disabling irq for netns id")
> Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
> Reported-by: Elad Raz <e@eladraz.com>
> Tested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/core/net_namespace.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 989434f..17b52a2 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -230,11 +230,16 @@ int peernet2id_alloc(struct net *net, struct net *peer)
> /* This function returns, if assigned, the id of a peer netns. */
> int peernet2id(struct net *net, struct net *peer)
> {
> + unsigned long flags;
> int id;
>
> - spin_lock_bh(&net->nsid_lock);
> + /* This is ugly, technically we only need to disable BH, however some
> + * callers (indirectly) call this with IRQ disabled, which implies
> + * that we should save the IRQ context here.
> + */
> + spin_lock_irqsave(&net->nsid_lock, flags);
> id = __peernet2id(net, peer);
> - spin_unlock_bh(&net->nsid_lock);
> + spin_unlock_irqrestore(&net->nsid_lock, flags);
> return id;
> }
> EXPORT_SYMBOL(peernet2id);
>
^ permalink raw reply
* RE: [PATCH net] tipc: Guard against tiny MTU in tipc_msg_build()
From: Jon Maloy @ 2016-10-20 14:51 UTC (permalink / raw)
To: Ben Hutchings, Ying Xue; +Cc: netdev@vger.kernel.org, Qian Zhang, Eric Dumazet
In-Reply-To: <1476967585.2709.52.camel@decadent.org.uk>
> -----Original Message-----
> From: Ben Hutchings [mailto:ben@decadent.org.uk]
> Sent: Thursday, 20 October, 2016 08:46
> To: Ying Xue <ying.xue0@gmail.com>; Jon Maloy <jon.maloy@ericsson.com>
> Cc: netdev@vger.kernel.org; Qian Zhang <zhangqian-c@360.cn>; Eric Dumazet
> <edumazet@google.com>
> Subject: Re: [PATCH net] tipc: Guard against tiny MTU in tipc_msg_build()
>
> On Thu, 2016-10-20 at 17:30 +0800, Ying Xue wrote:
> > On 10/19/2016 10:16 AM, Ben Hutchings wrote:
> > > Qian Zhang (张谦) reported a potential socket buffer overflow in
> > > tipc_msg_build(). The minimum fragment length needs to be checked
> > > against the maximum packet size, which is based on the link MTU.
> [...]
> > >
> > > --- a/net/tipc/msg.c
> > > +++ b/net/tipc/msg.c
> > > @@ -274,6 +274,10 @@ int tipc_msg_build(struct tipc_msg *mhdr, struct
> msghdr *m,
> > > > > goto error;
> > > > > }
> > >
> > > > > + /* Check that fragment and message header will fit */
> > > > > + if (INT_H_SIZE + mhsz > pktmax)
> > > + return -EMSGSIZE;
> >
> >
> > The "mhsz" represents the size of tipc packet header for current socket,
> > INT_H_SIZE indicates the size of tipc internal message header. So it
> > seems unreasonable to identify whether the sum of both header sizes is
> > bigger than MTU size. In my opinion, it's better to use MAX_H_SIZE to
> > compare it with pktmax. If MAX_H_SIZE is bigger than pktmax, we should
> > return EMSGSIZE error code.
>
> At this point we're about to copy INT_H_SIZE + mhsz bytes into the
> first fragment. If that's already limited to be less than or equal to
> MAX_H_SIZE, comparing with MAX_H_SIZE would be fine. But if MAX_H_SIZE
> is the maximum value of mhsz, that won't be good enough.
MAX_H_SIZE is 60 bytes, but in practice you will never see an mhsz larger than the biggest header we are actually using, which is MCAST_H_SIZE (==44 bytes).
INT_H_SIZE is 40 bytes, so you are in reality testing for whether we have an mtu < 84 bytes.
You won't find any interfaces or protocols that come even close to this limitation, so to me this test is redundant.
Regards
///jon
>
> Ben.
>
> > > +
> > > > > /* Prepare reusable fragment header */
> > > > > tipc_msg_init(msg_prevnode(mhdr), &pkthdr,
> MSG_FRAGMENTER,
> > > > > FIRST_FRAGMENT, INT_H_SIZE,
> msg_destnode(mhdr));
> > >
> >
> >
> >
> --
> Ben Hutchings
> Never put off till tomorrow what you can avoid all together.
^ permalink raw reply
* Re: [PATCH 1/4] kconfig: introduce the "imply" keyword
From: Edward Cree @ 2016-10-20 14:52 UTC (permalink / raw)
To: Nicolas Pitre, John Stultz, Richard Cochran, Yann E MORIN
Cc: Thomas Gleixner, Josh Triplett, netdev, linux-kbuild,
linux-kernel
In-Reply-To: <1476920573-14384-2-git-send-email-nicolas.pitre@linaro.org>
On 20/10/16 00:42, Nicolas Pitre wrote:
> diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
> index 069fcb3eef..c96127f648 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -113,6 +113,33 @@ applicable everywhere (see syntax).
> That will limit the usefulness but on the other hand avoid
> the illegal configurations all over.
>
> +- weak reverse dependencies: "imply" <symbol> ["if" <expr>]
> + This is similar to "select" as it enforces a lower limit on another
> + symbol except that the "implied" config symbol's value may still be
> + set to n from a direct dependency or with a visible prompt.
> + Given the following example:
> +
> + config FOO
> + tristate
> + imply BAZ
> +
> + config BAZ
> + tristate
> + depends on BAr
> +
> + The following values are possible:
> +
> + FOO BAR BAR's default choice for BAZ
Should the third column not be "BAZ's default"?
> + --------------- --------------- --------------- --------------
> + n y n N/m/y
> + m y m M/y/n
> + y y y Y/n
> + y n * N
Also, I don't think having any FOO=y should preclude BAZ=m. Suppose both
FOO and FOO2 imply BAZ, FOO=y and FOO2=m. Then if BAZ-features are only
desired for driver FOO2, BAz=m makes sense.
There is also the case of drivers with the ability to detect at runtime
whether BAZ is present, rather than making the decision at build time, but
I'm not sure how common that is.
-Ed
^ permalink raw reply
* Re: [PATCH v4 net-next 1/7] ipv6: Fix Makefile conditional to use CONFIG_INET
From: David Miller @ 2016-10-20 14:38 UTC (permalink / raw)
To: tom; +Cc: netdev, kernel-team
In-Reply-To: <CALx6S34ypSKUg715g1K783ze95ko1SeSA+Yb0JFqvfsSHwxQug@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 19 Oct 2016 20:16:01 -0700
> Please don't apply this. It's like whack-a-mole trying to resolve all
> the dependencies. I'll resubmit the series without this.
Ok.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: ethtool -x full support
From: Eric Dumazet @ 2016-10-20 14:26 UTC (permalink / raw)
To: Mintz, Yuval; +Cc: David Miller, netdev, Ariel Elior
In-Reply-To: <BL2PR07MB2306E14F54D13CA215D8923C8DD50@BL2PR07MB2306.namprd07.prod.outlook.com>
On Thu, 2016-10-20 at 12:27 +0000, Mintz, Yuval wrote:
> > > From: Eric Dumazet <edumazet@google.com>
> > >
> > > Implement ethtool -x full support, so that rss key can be fetched
> > > instead of assuming it matches /proc/sys/net/core/netdev_rss_key
> > > content.
> >
> > I'll send a V2, tested with CONFIG_BNX2X_SRIOV=y ;)
> >
>
> Hi Eric,
>
> Thanks for this. Are you planning on sending v2 or do you want us to take over?
>
> BTW, what's the benefit of changing the RSS keys? Giving the hash properties,
> in which scenarios would we gain by switching keys?
I will send a v2
Changing keys once a day or so might be important for security
purposes.
I wont give details here ;)
Thanks.
^ permalink raw reply
* Re: [PATCH 3/4] ptp_clock: allow for it to be optional
From: Richard Cochran @ 2016-10-20 14:06 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Yann E MORIN, Thomas Gleixner, Josh Triplett, netdev,
linux-kbuild, linux-kernel
In-Reply-To: <1476920573-14384-4-git-send-email-nicolas.pitre@linaro.org>
On Wed, Oct 19, 2016 at 07:42:52PM -0400, Nicolas Pitre wrote:
> +static inline void ptp_clock_event(struct ptp_clock *ptp,
> + struct ptp_clock_event *event)
> +{ (void)event; }
Just out of curiosity, why do you need that cast?
(I thought the kernel's gcc settings don't enable the warning for
unused arguments.)
Thanks,
Richard
^ permalink raw reply
* [patch net 4/4] mlxsw: pci: Fix reset wait for SwitchX2
From: Jiri Pirko @ 2016-10-20 14:05 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1476972345-31568-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
SwitchX2 firmware does not implement reset done yet. Moreover, when
busy-polled for ready magic, that slows down firmware and reset takes
longer than the defined timeout, causing initialization to fail.
So restore the previous behaviour and just sleep in this case.
Fixes: 233fa44bd67a ("mlxsw: pci: Implement reset done check")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/pci.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index e742bd4..912f71f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -1838,11 +1838,17 @@ static const struct mlxsw_bus mlxsw_pci_bus = {
.cmd_exec = mlxsw_pci_cmd_exec,
};
-static int mlxsw_pci_sw_reset(struct mlxsw_pci *mlxsw_pci)
+static int mlxsw_pci_sw_reset(struct mlxsw_pci *mlxsw_pci,
+ const struct pci_device_id *id)
{
unsigned long end;
mlxsw_pci_write32(mlxsw_pci, SW_RESET, MLXSW_PCI_SW_RESET_RST_BIT);
+ if (id->device == PCI_DEVICE_ID_MELLANOX_SWITCHX2) {
+ msleep(MLXSW_PCI_SW_RESET_TIMEOUT_MSECS);
+ return 0;
+ }
+
wmb(); /* reset needs to be written before we read control register */
end = jiffies + msecs_to_jiffies(MLXSW_PCI_SW_RESET_TIMEOUT_MSECS);
do {
@@ -1909,7 +1915,7 @@ static int mlxsw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
mlxsw_pci->pdev = pdev;
pci_set_drvdata(pdev, mlxsw_pci);
- err = mlxsw_pci_sw_reset(mlxsw_pci);
+ err = mlxsw_pci_sw_reset(mlxsw_pci, id);
if (err) {
dev_err(&pdev->dev, "Software reset failed\n");
goto err_sw_reset;
--
2.5.5
^ permalink raw reply related
* [patch net 3/4] mlxsw: switchx2: Fix ethernet port initialization
From: Jiri Pirko @ 2016-10-20 14:05 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1476972345-31568-1-git-send-email-jiri@resnulli.us>
From: Elad Raz <eladr@mellanox.com>
When creating an ethernet port fails, we must move the port to disable,
otherwise putting the port in switch partition 0 (ETH) or 1 (IB) will
always fails.
Fixes: 31557f0f9755 ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support")
Signed-off-by: Elad Raz <eladr@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
index c0c23e2..92bda87 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
@@ -1088,6 +1088,7 @@ static int mlxsw_sx_port_create(struct mlxsw_sx *mlxsw_sx, u8 local_port)
err_port_admin_status_set:
err_port_mtu_set:
err_port_speed_set:
+ mlxsw_sx_port_swid_set(mlxsw_sx_port, MLXSW_PORT_SWID_DISABLED_PORT);
err_port_swid_set:
err_port_system_port_mapping_set:
port_not_usable:
--
2.5.5
^ permalink raw reply related
* [patch net 2/4] mlxsw: spectrum_router: Make mlxsw_sp_router_fib4_del return void and remove warn
From: Jiri Pirko @ 2016-10-20 14:05 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1476972345-31568-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
The function return value is not checked anywhere. Also, the warning
causes huge slowdown when removing large number of FIB entries which
were not offloaded, because of ordering issue. Ido's preparing
a patchset to fix the ordering issue, but that is definitelly not
net tree material.
Fixes: b45f64d16d45 ("mlxsw: spectrum_router: Use FIB notifications instead of switchdev calls")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 1b3a2cb..f3d50d3 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -1820,19 +1820,17 @@ static int mlxsw_sp_router_fib4_add(struct mlxsw_sp *mlxsw_sp,
return err;
}
-static int mlxsw_sp_router_fib4_del(struct mlxsw_sp *mlxsw_sp,
- struct fib_entry_notifier_info *fen_info)
+static void mlxsw_sp_router_fib4_del(struct mlxsw_sp *mlxsw_sp,
+ struct fib_entry_notifier_info *fen_info)
{
struct mlxsw_sp_fib_entry *fib_entry;
if (mlxsw_sp->router.aborted)
- return 0;
+ return;
fib_entry = mlxsw_sp_fib_entry_find(mlxsw_sp, fen_info);
- if (!fib_entry) {
- dev_warn(mlxsw_sp->bus_info->dev, "Failed to find FIB4 entry being removed.\n");
- return -ENOENT;
- }
+ if (!fib_entry)
+ return;
if (fib_entry->ref_count == 1) {
mlxsw_sp_fib_entry_del(mlxsw_sp, fib_entry);
@@ -1840,7 +1838,6 @@ static int mlxsw_sp_router_fib4_del(struct mlxsw_sp *mlxsw_sp,
}
mlxsw_sp_fib_entry_put(mlxsw_sp, fib_entry);
- return 0;
}
static int mlxsw_sp_router_set_abort_trap(struct mlxsw_sp *mlxsw_sp)
--
2.5.5
^ permalink raw reply related
* [patch net 1/4] mlxsw: spectrum_router: Use correct tree index for binding
From: Jiri Pirko @ 2016-10-20 14:05 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1476972345-31568-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
By a mistake, there is tree index 0 passed to RALTB. Should be
MLXSW_SP_LPM_TREE_MIN.
Fixes: b45f64d16d45 ("mlxsw: spectrum_router: Use FIB notifications instead of switchdev calls")
Reported-by: Yotam Gigi <yotamg@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 78fc557d..1b3a2cb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -1862,7 +1862,8 @@ static int mlxsw_sp_router_set_abort_trap(struct mlxsw_sp *mlxsw_sp)
if (err)
return err;
- mlxsw_reg_raltb_pack(raltb_pl, 0, MLXSW_REG_RALXX_PROTOCOL_IPV4, 0);
+ mlxsw_reg_raltb_pack(raltb_pl, 0, MLXSW_REG_RALXX_PROTOCOL_IPV4,
+ MLXSW_SP_LPM_TREE_MIN);
err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(raltb), raltb_pl);
if (err)
return err;
--
2.5.5
^ permalink raw reply related
* [patch net 0/4] mlxsw: Couple of fixes
From: Jiri Pirko @ 2016-10-20 14:05 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, ogerlitz
From: Jiri Pirko <jiri@mellanox.com>
Elad Raz (1):
mlxsw: switchx2: Fix ethernet port initialization
Jiri Pirko (3):
mlxsw: spectrum_router: Use correct tree index for binding
mlxsw: spectrum_router: Make mlxsw_sp_router_fib4_del return void and
remove warn
mlxsw: pci: Fix reset wait for SwitchX2
drivers/net/ethernet/mellanox/mlxsw/pci.c | 10 ++++++++--
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 16 +++++++---------
drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 1 +
3 files changed, 16 insertions(+), 11 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [PATCH 4/4] posix-timers: make it configurable
From: Richard Cochran @ 2016-10-20 14:02 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Yann E MORIN, Thomas Gleixner, Josh Triplett, netdev,
linux-kbuild, linux-kernel
In-Reply-To: <1476920573-14384-5-git-send-email-nicolas.pitre@linaro.org>
On Wed, Oct 19, 2016 at 07:42:53PM -0400, Nicolas Pitre wrote:
> +config POSIX_TIMERS
> + bool "Posix Clocks & timers" if EXPERT
> + default y
> + help
> + This includes native support for POSIX timers to the kernel.
> + Most embedded systems may have no use for them and therefore they
This sentence doesn't make sense. How about:
Some embedded systems have no use for them ...
> + can be configured out to reduce the size of the kernel image.
Thanks,
Richard
^ permalink raw reply
* [PATCH net v3] net: add recursion limit to GRO
From: Sabrina Dubroca @ 2016-10-20 13:58 UTC (permalink / raw)
To: netdev
Cc: Sabrina Dubroca, Eric Dumazet, Tom Herbert, Jiri Benc,
Hannes Frederic Sowa
Currently, GRO can do unlimited recursion through the gro_receive
handlers. This was fixed for tunneling protocols by limiting tunnel GRO
to one level with encap_mark, but both VLAN and TEB still have this
problem. Thus, the kernel is vulnerable to a stack overflow, if we
receive a packet composed entirely of VLAN headers.
This patch adds a recursion counter to the GRO layer to prevent stack
overflow. When a gro_receive function hits the recursion limit, GRO is
aborted for this skb and it is processed normally. This recursion
counter is put in the GRO CB, but could be turned into a percpu counter
if we run out of space in the CB.
Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.
Fixes: CVE-2016-7039
Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.")
Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
v2: add unlikely() annotations, suggested by Eric Dumazet
benchmark didn't show a difference between CB and pcpu variable for
the recursion counter, so I'm sticking with the CB
v3: add call_gro_receive_sk, suggested by Tom Herbert
drivers/net/geneve.c | 2 +-
drivers/net/vxlan.c | 2 +-
include/linux/netdevice.h | 39 ++++++++++++++++++++++++++++++++++++++-
net/8021q/vlan.c | 2 +-
net/core/dev.c | 1 +
net/ethernet/eth.c | 2 +-
net/ipv4/af_inet.c | 2 +-
net/ipv4/fou.c | 4 ++--
net/ipv4/gre_offload.c | 2 +-
net/ipv4/udp_offload.c | 2 +-
net/ipv6/ip6_offload.c | 2 +-
11 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 3c20e87bb761..16af1ce99233 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -453,7 +453,7 @@ static struct sk_buff **geneve_gro_receive(struct sock *sk,
skb_gro_pull(skb, gh_len);
skb_gro_postpull_rcsum(skb, gh, gh_len);
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
flush = 0;
out_unlock:
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e7d16687538b..c1639a3e95a4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -583,7 +583,7 @@ static struct sk_buff **vxlan_gro_receive(struct sock *sk,
}
}
- pp = eth_gro_receive(head, skb);
+ pp = call_gro_receive(eth_gro_receive, head, skb);
flush = 0;
out:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 465e128699a1..91ee3643ccc8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2169,7 +2169,10 @@ struct napi_gro_cb {
/* Used to determine if flush_id can be ignored */
u8 is_atomic:1;
- /* 5 bit hole */
+ /* Number of gro_receive callbacks this packet already went through */
+ u8 recursion_counter:4;
+
+ /* 1 bit hole */
/* used to support CHECKSUM_COMPLETE for tunneling protocols */
__wsum csum;
@@ -2180,6 +2183,40 @@ struct napi_gro_cb {
#define NAPI_GRO_CB(skb) ((struct napi_gro_cb *)(skb)->cb)
+#define GRO_RECURSION_LIMIT 15
+static inline int gro_recursion_inc_test(struct sk_buff *skb)
+{
+ return ++NAPI_GRO_CB(skb)->recursion_counter == GRO_RECURSION_LIMIT;
+}
+
+typedef struct sk_buff **(*gro_receive_t)(struct sk_buff **, struct sk_buff *);
+static inline struct sk_buff **call_gro_receive(gro_receive_t cb,
+ struct sk_buff **head,
+ struct sk_buff *skb)
+{
+ if (unlikely(gro_recursion_inc_test(skb))) {
+ NAPI_GRO_CB(skb)->flush |= 1;
+ return NULL;
+ }
+
+ return cb(head, skb);
+}
+
+typedef struct sk_buff **(*gro_receive_sk_t)(struct sock *, struct sk_buff **,
+ struct sk_buff *);
+static inline struct sk_buff **call_gro_receive_sk(gro_receive_sk_t cb,
+ struct sock *sk,
+ struct sk_buff **head,
+ struct sk_buff *skb)
+{
+ if (unlikely(gro_recursion_inc_test(skb))) {
+ NAPI_GRO_CB(skb)->flush |= 1;
+ return NULL;
+ }
+
+ return cb(sk, head, skb);
+}
+
struct packet_type {
__be16 type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 8de138d3306b..f2531ad66b68 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -664,7 +664,7 @@ static struct sk_buff **vlan_gro_receive(struct sk_buff **head,
skb_gro_pull(skb, sizeof(*vhdr));
skb_gro_postpull_rcsum(skb, vhdr, sizeof(*vhdr));
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/core/dev.c b/net/core/dev.c
index b09ac57f4348..dbc871306910 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4511,6 +4511,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
NAPI_GRO_CB(skb)->flush = 0;
NAPI_GRO_CB(skb)->free = 0;
NAPI_GRO_CB(skb)->encap_mark = 0;
+ NAPI_GRO_CB(skb)->recursion_counter = 0;
NAPI_GRO_CB(skb)->is_fou = 0;
NAPI_GRO_CB(skb)->is_atomic = 1;
NAPI_GRO_CB(skb)->gro_remcsum_start = 0;
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 66dff5e3d772..02acfff36028 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -439,7 +439,7 @@ struct sk_buff **eth_gro_receive(struct sk_buff **head,
skb_gro_pull(skb, sizeof(*eh));
skb_gro_postpull_rcsum(skb, eh, sizeof(*eh));
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 1effc986739e..9648c97e541f 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1391,7 +1391,7 @@ struct sk_buff **inet_gro_receive(struct sk_buff **head, struct sk_buff *skb)
skb_gro_pull(skb, sizeof(*iph));
skb_set_transport_header(skb, skb_gro_offset(skb));
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index cf50f7e2b012..030d1531e897 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -249,7 +249,7 @@ static struct sk_buff **fou_gro_receive(struct sock *sk,
if (!ops || !ops->callbacks.gro_receive)
goto out_unlock;
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
@@ -441,7 +441,7 @@ static struct sk_buff **gue_gro_receive(struct sock *sk,
if (WARN_ON_ONCE(!ops || !ops->callbacks.gro_receive))
goto out_unlock;
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
flush = 0;
out_unlock:
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index 96e0efecefa6..d5cac99170b1 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -229,7 +229,7 @@ static struct sk_buff **gre_gro_receive(struct sk_buff **head,
/* Adjusted NAPI_GRO_CB(skb)->csum after skb_gro_pull()*/
skb_gro_postpull_rcsum(skb, greh, grehlen);
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
flush = 0;
out_unlock:
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index f9333c963607..b2be1d9757ef 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -295,7 +295,7 @@ struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb,
skb_gro_pull(skb, sizeof(struct udphdr)); /* pull encapsulating udp header */
skb_gro_postpull_rcsum(skb, uh, sizeof(struct udphdr));
- pp = udp_sk(sk)->gro_receive(sk, head, skb);
+ pp = call_gro_receive_sk(udp_sk(sk)->gro_receive, sk, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index e7bfd55899a3..1fcf61f1cbc3 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -246,7 +246,7 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
skb_gro_postpull_rcsum(skb, iph, nlen);
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
--
2.10.0
^ permalink raw reply related
* Re: [Patch net v2] ipv6: fix a potential deadlock in do_ipv6_setsockopt()
From: Eric Dumazet @ 2016-10-20 13:47 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, sploving1, Marcelo Ricardo Leitner
In-Reply-To: <1476945312-15572-1-git-send-email-xiyou.wangcong@gmail.com>
On Wed, 2016-10-19 at 23:35 -0700, Cong Wang wrote:
> Baozeng reported this deadlock case:
...
> +
> +void ipv6_sock_mc_close(struct sock *sk)
> +{
> + struct ipv6_pinfo *np = inet6_sk(sk);
> +
> + if (!rcu_access_pointer(np->ipv6_mc_list))
> + return;
I wonder if rcu_dereference_protected(..., lockdep_sock_is_held(sk))
could be used instead, to get lockdep support ?
> + rtnl_lock();
> + __ipv6_sock_mc_close(sk);
> rtnl_unlock();
> }
>
Thanks !
^ permalink raw reply
* Re: [PATCH 1/9] ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)
From: David Lebrun @ 2016-10-20 13:04 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALx6S35sU+aw3UvMTknj8SjJP4O=Q-9eVV3OC640Qzces_eE7w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
On 10/17/2016 07:01 PM, Tom Herbert wrote:
>> > +
>> > + if (skb->ip_summed == CHECKSUM_COMPLETE)
>> > + skb->ip_summed = CHECKSUM_NONE;
>> > +
> Because the packet is being changed? Would it make sense to update the
> checksum complete value based on the changes being made. Consider the
> case that the next hop is local to the host (someone may try to
> implement network virtualization this way).
>
Rethinking about that: even if the next hop is local, I am not sure to
see the benefits of updating the checksum instead of setting
CHECKSUM_NONE. For example, if the next and final hop is local and the
packet carries a TCP payload, tcp_checksum_complete() would force the
recomputation of the checksum anyway (unless ip_summed ==
CHECKSUM_UNNECESSARY).
So I fail to see a path where updating the checksum would be beneficial.
Am I missing something ?
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* RE: [RFC 2/6] qed: Add iSCSI out of order packet handling.
From: Mintz, Yuval @ 2016-10-20 12:58 UTC (permalink / raw)
To: Hannes Reinecke, Rangankar, Manish, lduncan@suse.com,
cleech@redhat.com
Cc: martin.petersen@oracle.com, jejb@linux.vnet.ibm.com,
linux-scsi@vger.kernel.org, netdev@vger.kernel.org,
Dept-Eng QLogic Storage Upstream, Easi, Arun
In-Reply-To: <f8c5d8d1-0e69-00c2-9349-de611c4b6c08@suse.de>
> > This patch adds out of order packet handling for hardware offloaded
> > iSCSI. Out of order packet handling requires driver buffer allocation
> > and assistance.
> >
> > Signed-off-by: Arun Easi <arun.easi@cavium.com>
> > Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
> >
> Hmm. The entire out-of-order handling is pretty generic. I really wonder
> if this doesn't apply to iSCSI in general; surely iscsi_tcp suffers from
> the same problem, no?
> If so, wouldn't it be better to move it into generic (iSCSI) code so
> that all implementations would benefit from it?
[disclaimer - I'm far from knowledgeable in iscsi ]
I agree that the problem of out-of-order handling is probably generic,
but our solution is very device oriented.
As the device lacks [a lot of] internal memory, it uses the host memory
for out-of-order buffers and the driver assistance in pushing them when
they are needed.
>From driver perspective, all the data is completely opaque; All it does is
follow the firmware's guidance in storing & re-transmitting buffers when
required.
Now, I guess the logic could be divided between hardware-specifics -
Interaction with 'client' [in our case, device's firmware], to receive
new data, instructions regarding placement and re-transmission,
and a lower generic data structure which supports manipulation of
buffers [push-left, push-right, join, etc.].
But given that the data-structure would completely lacks all
protocol-knowledge [as our implementation doesn't have nor require such],
I think there would be very little gain - we might find out that as much
as 80% of the code is device interaction, and the remaining so-called
'generic' data-structure won't be that useful to other clients as it was
closely tied to our device needs and API.
Either way, placing this under iscsi would probably be insufficient for our
future needs, as our qed-iwarp driver would also require this functionality.
Thanks,
Yuval
^ permalink raw reply
* Re: Need help with mdiobus_register and phy
From: Zefir Kurtisi @ 2016-10-20 12:55 UTC (permalink / raw)
To: Timur Tabi, Andrew Lunn; +Cc: Florian Fainelli, netdev
In-Reply-To: <58076403.3060608@codeaurora.org>
On 10/19/2016 02:16 PM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> Ok then, if you can wait some days, I'll prepare and provide you a more detailed
>> failure report to allow you testing if the issue happens with other NICs.
>
> That sounds great.
>
I am now able again to reproduce the issue reliably, let's see if it is helpful
enough to check if this a problem unique to our setup.
As described earlier, the HW is as follows:
(copper)--[at8031]--(SGMII)--[eTSEC/mpc85xx]
We are using OpenWRT/LEDE as SW platform, therefore I can't do the tests on the
latest kernel but provide a reference to inspect the problem. The kernel used is
4.4.21 with the relevant drivers (ath803x and gianfar_driver) being either clean
or patched with OWRT/LEDE modifications (issue happens in either case).
The process for detecting the failure is rather trivial: continuously put the
Ethernet interface down and up and try to get some data through until it fails.
The script I used to run on the device (over serial) is:
#----------------------------------------------------------
HOST=192.168.1.100
TIMEOUT=20
while true; do
ifconfig eth0 down
ifconfig eth0 up
ping $HOST -c 1 -w $TIMEOUT || {
echo "Ping failed after $TIMEOUT seconds"
exit 1
}
done
#----------------------------------------------------------
In my setup, it takes less than 5 minutes for the script to exit. Once running
into this state, the relevant registers read from at803x are as follows:
* copper status (0x01): 0x796d
* fiber status (0x01): 0x6149
* copper phy specific status (0x11): 0xbc10
* fiber phy specific status (0x11): 0x8100
* copper/fiber status (0x1b): 0x020e
In essence
* the copper link is up with autonegotiation completed
(switch/peer link indication is also up), but
* the SGMII link is down
(bits LINK and MR_AN_COMPLETE in PHY specific status fiber cleared)
* although SGMII is synchronized (SYNC_STATUS bit in same register set)
The SGMII link does not recover from this state thereafter, the only reliable way
to get it up again I found is to do a power down/up cycle at the fiber/SGMII side,
which is what the patch I contributed does.
Now the interesting (and new for me) part is: if I remove the at803x driver from
the system and use the generic phy instead, the problem does not happen (or at
least not while running for one full day). I don't see any significant differences
between what at803x does above genphy (gpio based HW reset is not run for 8031 in
at803x_link_change_notify()). Using the genphy is not an option for us, since we
have the PHY also attached to fiber and need dedicated handling.
Hope this helps for the beginning, let me know if you need more information.
Cheers,
Zefir
^ permalink raw reply
* Re: [PATCH net] tipc: Guard against tiny MTU in tipc_msg_build()
From: Ben Hutchings @ 2016-10-20 12:46 UTC (permalink / raw)
To: Ying Xue, Jon Maloy; +Cc: netdev, Qian Zhang, Eric Dumazet
In-Reply-To: <6a69780d-0797-b5af-fc90-04960bbb21c6@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
On Thu, 2016-10-20 at 17:30 +0800, Ying Xue wrote:
> On 10/19/2016 10:16 AM, Ben Hutchings wrote:
> > Qian Zhang (张谦) reported a potential socket buffer overflow in
> > tipc_msg_build(). The minimum fragment length needs to be checked
> > against the maximum packet size, which is based on the link MTU.
[...]
> >
> > --- a/net/tipc/msg.c
> > +++ b/net/tipc/msg.c
> > @@ -274,6 +274,10 @@ int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m,
> > > > goto error;
> > > > }
> >
> > > > + /* Check that fragment and message header will fit */
> > > > + if (INT_H_SIZE + mhsz > pktmax)
> > + return -EMSGSIZE;
>
>
> The "mhsz" represents the size of tipc packet header for current socket,
> INT_H_SIZE indicates the size of tipc internal message header. So it
> seems unreasonable to identify whether the sum of both header sizes is
> bigger than MTU size. In my opinion, it's better to use MAX_H_SIZE to
> compare it with pktmax. If MAX_H_SIZE is bigger than pktmax, we should
> return EMSGSIZE error code.
At this point we're about to copy INT_H_SIZE + mhsz bytes into the
first fragment. If that's already limited to be less than or equal to
MAX_H_SIZE, comparing with MAX_H_SIZE would be fine. But if MAX_H_SIZE
is the maximum value of mhsz, that won't be good enough.
Ben.
> > +
> > > > /* Prepare reusable fragment header */
> > > > tipc_msg_init(msg_prevnode(mhdr), &pkthdr, MSG_FRAGMENTER,
> > > > FIRST_FRAGMENT, INT_H_SIZE, msg_destnode(mhdr));
> >
>
>
>
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] davinci_emac: fix setting the mac from DT
From: Tony Lindgren @ 2016-10-20 12:41 UTC (permalink / raw)
To: Jeroen Hofstee
Cc: netdev, David S . Miller, Anant Gole, Chaithrika U S, linux-omap
In-Reply-To: <1476904973-13226-1-git-send-email-jhofstee@victronenergy.com>
* Jeroen Hofstee <jhofstee@victronenergy.com> [161019 12:39]:
> commit 9120bd6e9f77 ("net: davinci_emac: Get device dm816x MAC address
> using the cpsw code") sets the mac address to the one stored in the chip
> unconditionally, overwritten the one already set from the device tree.
> This patch makes sure the mac from DT is preserved.
>
> On a am3517 this address is incorrectly read as all zeros, making it
> impossible to set a valid mac address without this patch.
OK, at least I don't have better ideas for fixing this:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* RE: [PATCH net-next] bnx2x: ethtool -x full support
From: Mintz, Yuval @ 2016-10-20 12:27 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Ariel Elior
In-Reply-To: <1476818655.5650.69.camel@edumazet-glaptop3.roam.corp.google.com>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Implement ethtool -x full support, so that rss key can be fetched
> > instead of assuming it matches /proc/sys/net/core/netdev_rss_key
> > content.
>
> I'll send a V2, tested with CONFIG_BNX2X_SRIOV=y ;)
>
Hi Eric,
Thanks for this. Are you planning on sending v2 or do you want us to take over?
BTW, what's the benefit of changing the RSS keys? Giving the hash properties,
in which scenarios would we gain by switching keys?
Thanks,
Yuval
^ 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