* [PATCH net-next] igc: Make function igc_write_rss_indir_tbl() static
From: Wei Yongjun @ 2019-02-16 2:04 UTC (permalink / raw)
To: Jeff Kirsher, Sasha Neftin
Cc: Wei Yongjun, intel-wired-lan, netdev, kernel-janitors
Fixes the following sparse warning:
drivers/net/ethernet/intel/igc/igc_ethtool.c:646:6: warning:
symbol 'igc_write_rss_indir_tbl' was not declared. Should it be static?
Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c
index eff37a6c0afa..544239422577 100644
--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -643,7 +643,7 @@ static int igc_set_coalesce(struct net_device *netdev,
return 0;
}
-void igc_write_rss_indir_tbl(struct igc_adapter *adapter)
+static void igc_write_rss_indir_tbl(struct igc_adapter *adapter)
{
struct igc_hw *hw = &adapter->hw;
u32 reg = IGC_RETA(0);
^ permalink raw reply related
* Re: [PATCH net 2/2] tcp: tcp_v4_err() should be more careful
From: Neal Cardwell @ 2019-02-16 2:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Yuchung Cheng,
soukjin bae
In-Reply-To: <20190215213621.183537-3-edumazet@google.com>
On Fri, Feb 15, 2019 at 4:36 PM Eric Dumazet <edumazet@google.com> wrote:
>
> ICMP handlers are not very often stressed, we should
> make them more resilient to bugs that might surface in
> the future.
>
> If there is no packet in retransmit queue, we should
> avoid a NULL deref.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: soukjin bae <soukjin.bae@samsung.com>
> ---
> net/ipv4/tcp_ipv4.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks!
neal
^ permalink raw reply
* Re: [PATCH net 1/2] tcp: clear icsk_backoff in tcp_write_queue_purge()
From: Neal Cardwell @ 2019-02-16 2:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Yuchung Cheng,
soukjin bae
In-Reply-To: <20190215213621.183537-2-edumazet@google.com>
On Fri, Feb 15, 2019 at 4:36 PM Eric Dumazet <edumazet@google.com> wrote:
>
> soukjin bae reported a crash in tcp_v4_err() handling
> ICMP_DEST_UNREACH after tcp_write_queue_head(sk)
> returned a NULL pointer.
>
> Current logic should have prevented this :
>
> if (seq != tp->snd_una || !icsk->icsk_retransmits ||
> !icsk->icsk_backoff || fastopen)
> break;
>
> Problem is the write queue might have been purged
> and icsk_backoff has not been cleared.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: soukjin bae <soukjin.bae@samsung.com>
> ---
> net/ipv4/tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks!
neal
^ permalink raw reply
* Re: [PATCH net 2/2] tcp: tcp_v4_err() should be more careful
From: Soheil Hassas Yeganeh @ 2019-02-16 2:31 UTC (permalink / raw)
To: Neal Cardwell
Cc: Eric Dumazet, David S . Miller, netdev, Eric Dumazet,
Yuchung Cheng, soukjin bae
In-Reply-To: <CADVnQymt=dtyQDhMNFz4Wmbeqbies_nwvU7fxawyizOji5H7eg@mail.gmail.com>
On Fri, Feb 15, 2019 at 9:21 PM Neal Cardwell <ncardwell@google.com> wrote:
>
> On Fri, Feb 15, 2019 at 4:36 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > ICMP handlers are not very often stressed, we should
> > make them more resilient to bugs that might surface in
> > the future.
> >
> > If there is no packet in retransmit queue, we should
> > avoid a NULL deref.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Reported-by: soukjin bae <soukjin.bae@samsung.com>
> > ---
> > net/ipv4/tcp_ipv4.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Thanks you for the fix, Eric!
>
> Thanks!
>
> neal
^ permalink raw reply
* [PATCH net-next] ptr_ring: remove duplicated include from ptr_ring.h
From: YueHaibing @ 2019-02-16 2:37 UTC (permalink / raw)
To: davem, mst, xiyou.wangcong, parri.andrea; +Cc: linux-kernel, netdev, YueHaibing
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
include/linux/ptr_ring.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 186cd8e..8da46ac 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -26,7 +26,6 @@
#include <linux/cache.h>
#include <linux/types.h>
#include <linux/compiler.h>
-#include <linux/cache.h>
#include <linux/slab.h>
#include <asm/errno.h>
#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
From: YueHaibing @ 2019-02-16 2:40 UTC (permalink / raw)
To: Al Viro; +Cc: Andrew Lunn, davem, f.fainelli, hkallweit1, linux-kernel, netdev
In-Reply-To: <20190201042411.GM2217@ZenIV.linux.org.uk>
On 2019/2/1 12:24, Al Viro wrote:
> On Tue, Jan 29, 2019 at 11:30:27AM +0800, YueHaibing wrote:
>>>> gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
>>>> "reset-gpios", 0, GPIOD_OUT_LOW,
>>>> "PHY reset");
>>>> - if (PTR_ERR(gpiod) == -ENOENT ||
>>>> - PTR_ERR(gpiod) == -ENOSYS)
>>>> - gpiod = NULL;
>>>> - else if (IS_ERR(gpiod))
>>>> - return PTR_ERR(gpiod);
>>>> + if (IS_ERR(gpiod)) {
>>>> + ret = PTR_ERR(gpiod);
>>>> + if (ret == -ENOENT || ret == -ENOSYS)
>>>> + gpiod = NULL;
>>>> + else
>>>> + return ret;
>>>> + }
>
> Rule of the thumb: PTR_ERR(p) == -E... is almost always better off
> as p == ERR_PTR(-E...)
Ok, will fix it.
>
> .
>
^ permalink raw reply
* Re: [net-next 5/5] net: sock: remove the definition of SOCK_DEBUG()
From: Yafang Shao @ 2019-02-16 2:50 UTC (permalink / raw)
To: Joe Perches
Cc: Eric Dumazet, Cong Wang, David Miller, Daniel Borkmann, netdev,
shaoyafang
In-Reply-To: <620a93625ac3709bf6df5e31bcdcdd319db140ef.camel@perches.com>
On Sat, Feb 16, 2019 at 2:51 AM Joe Perches <joe@perches.com> wrote:
>
> On Fri, 2019-02-15 at 10:22 -0800, Eric Dumazet wrote:
> > On Fri, Feb 15, 2019 at 10:13 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > > On Fri, Feb 15, 2019 at 8:26 AM Eric Dumazet <edumazet@google.com> wrote:
> > > > On Fri, Feb 15, 2019 at 6:50 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> > > > > As SOCK_DEBUG() isn't used any more, we can get ride of it now.
> > > > >
> > > >
> > > > No, we are still using this infrastructure from time to time.
> > > >
> > > > I told you I agreed to remove the current (obsolete) TCP call sites,
> > > > I never suggested to remove SOCK_DEBUG() completely.
> > >
> > > Since when do we upstream care about any out-of-tree users?
> > >
> > > You can always carry a patch to keep it downstream if you want,
> > > no one can stop you doing it.
> >
> > Somehow the patch series seems to present things in this way :
> >
> > Eric Dumazet suggested to remove completely the SOCK_DEBUG() interface.
>
> Well, you kinda did.
> It's certainly reasonable to interpret what you wrote as such.
>
> On Tue, 2019-02-12 at 18:15 -0800, Eric Dumazet wrote:
> > Just remove all SOCK_DEBUG() calls, there are leftovers of very ancient times.
>
> My suggestion would be to undefine SOCK_DEBUGGING.
>
This seems like a reasonable trade-off decision.
I will change it like this.
> Something like:
> ---
> include/net/sock.h | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 328cb7cb7b0b..7e39bdfa342a 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -81,14 +81,17 @@
> */
>
> /* Define this to get the SOCK_DBG debugging facility. */
> -#define SOCK_DEBUGGING
> +/* #define SOCK_DEBUGGING */
> #ifdef SOCK_DEBUGGING
> -#define SOCK_DEBUG(sk, msg...) do { if ((sk) && sock_flag((sk), SOCK_DBG)) \
> - printk(KERN_DEBUG msg); } while (0)
> +#define SOCK_DEBUG(sk, fmt, ...) \
> +do { \
> + if ((sk) && sock_flag((sk), SOCK_DBG)) \
> + printk(KERN_DEBUG fmt, ##__VA_ARGS__); \
> +} while (0)
> #else
> /* Validate arguments and do nothing */
> -static inline __printf(2, 3)
> -void SOCK_DEBUG(const struct sock *sk, const char *msg, ...)
> +__printf(2, 3)
> +static inline void SOCK_DEBUG(const struct sock *sk, const char *fmt, ...)
> {
> }
> #endif
>
>
Thanks
Yafang
^ permalink raw reply
* RE: [PATCH 1/2] i40e: move i40e_xsk_umem function
From: Brown, Aaron F @ 2019-02-16 2:54 UTC (permalink / raw)
To: Björn Töpel, intel-wired-lan@lists.osuosl.org
Cc: Topel, Bjorn, Karlsson, Magnus, magnus.karlsson@gmail.com,
netdev@vger.kernel.org, Sokolowski, Jan
In-Reply-To: <20190212085205.7848-2-bjorn.topel@gmail.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Björn Töpel
> Sent: Tuesday, February 12, 2019 12:52 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Topel, Bjorn <bjorn.topel@intel.com>; Karlsson, Magnus
> <magnus.karlsson@intel.com>; magnus.karlsson@gmail.com;
> netdev@vger.kernel.org; Sokolowski, Jan <jan.sokolowski@intel.com>
> Subject: [PATCH 1/2] i40e: move i40e_xsk_umem function
>
> From: Björn Töpel <bjorn.topel@intel.com>
>
> The i40e_xsk_umem function was explicitly inlined in i40e.h. There is
> no reason for that, so move it to i40e_main.c instead.
>
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e.h | 14 --------------
> drivers/net/ethernet/intel/i40e/i40e_main.c | 20 ++++++++++++++++++++
> 2 files changed, 20 insertions(+), 14 deletions(-)
>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [PATCH 2/2] i40e: add tracking of AF_XDP ZC state for each queue pair
From: Brown, Aaron F @ 2019-02-16 2:54 UTC (permalink / raw)
To: Björn Töpel, intel-wired-lan@lists.osuosl.org
Cc: Topel, Bjorn, Karlsson, Magnus, magnus.karlsson@gmail.com,
netdev@vger.kernel.org, Sokolowski, Jan
In-Reply-To: <20190212085205.7848-3-bjorn.topel@gmail.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Björn Töpel
> Sent: Tuesday, February 12, 2019 12:52 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Topel, Bjorn <bjorn.topel@intel.com>; Karlsson, Magnus
> <magnus.karlsson@intel.com>; magnus.karlsson@gmail.com;
> netdev@vger.kernel.org; Sokolowski, Jan <jan.sokolowski@intel.com>
> Subject: [PATCH 2/2] i40e: add tracking of AF_XDP ZC state for each queue
> pair
>
> From: Björn Töpel <bjorn.topel@intel.com>
>
> In commit f3fef2b6e1cc ("i40e: Remove umem from VSI") a regression was
> introduced; When the VSI was reset, the setup code would try to enable
> AF_XDP ZC unconditionally (as long as there was a umem placed in the
> netdev._rx struct). Here, we add a bitmap to the VSI that tracks if a
> certain queue pair has been "zero-copy enabled" via the ndo_bpf. The
> bitmap is used in i40e_xsk_umem, and enables zero-copy if and only if
> XDP is enabled, the corresponding qid in the bitmap is set and the
> umem is non-NULL.
>
> Fixes: f3fef2b6e1cc ("i40e: Remove umem from VSI")
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e.h | 2 ++
> drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++++++-
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 3 +++
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* [PATCH v2 net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
From: YueHaibing @ 2019-02-16 2:59 UTC (permalink / raw)
To: davem, andrew, f.fainelli, hkallweit1; +Cc: linux-kernel, netdev, YueHaibing
Fix coccinelle warning:
./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
fix this by using IS_ERR before PTR_ERR
Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: remove variable 'ret'
---
drivers/net/phy/mdio_bus.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 3d31358..debc74c 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -48,11 +48,12 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
"reset-gpios", 0, GPIOD_OUT_LOW,
"PHY reset");
- if (PTR_ERR(gpiod) == -ENOENT ||
- PTR_ERR(gpiod) == -ENOSYS)
- gpiod = NULL;
- else if (IS_ERR(gpiod))
- return PTR_ERR(gpiod);
+ if (IS_ERR(gpiod)) {
+ if (PTR_ERR(gpiod) == -ENOENT || PTR_ERR(gpiod) == -ENOSYS)
+ gpiod = NULL;
+ else
+ return PTR_ERR(gpiod);
+ }
mdiodev->reset = gpiod;
--
2.7.4
^ permalink raw reply related
* Re: pull-request: mac80211 2019-02-15
From: David Miller @ 2019-02-16 3:42 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190215125146.18856-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 15 Feb 2019 13:51:45 +0100
> It's clear things are winding down, this is basically just the stuff
> from Herbert that we've been discussing. I threw in a simple error
> path fix, mostly because it's simple :-)
>
> Please pull and let me know if there's any problem.
Ok, pulled, thanks Johannes.
^ permalink raw reply
* [PATCH bpf-next] tools/libbpf: support bigger BTF data sizes
From: Andrii Nakryiko @ 2019-02-16 3:52 UTC (permalink / raw)
To: andrii.nakryiko, netdev, bpf, kernel-team, yhs, ast, kafai,
daniel, acme
Cc: Andrii Nakryiko
While it's understandable why kernel limits number of BTF types to 65535
and size of string section to 64KB, in libbpf as user-space library it's
too restrictive. E.g., pahole converting DWARF to BTF type information
for Linux kernel generates more than 3 million BTF types and more than
3MB of strings, before deduplication. So to allow btf__dedup() to do its
work, we need to be able to load bigger BTF sections using btf__new().
Singed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/lib/bpf/btf.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index ade1c32fb083..68b50e9bbde1 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -16,7 +16,8 @@
#define max(a, b) ((a) > (b) ? (a) : (b))
#define min(a, b) ((a) < (b) ? (a) : (b))
-#define BTF_MAX_NR_TYPES 65535
+#define BTF_MAX_NR_TYPES 0x7fffffff
+#define BTF_MAX_STR_OFFSET 0x7fffffff
#define IS_MODIFIER(k) (((k) == BTF_KIND_TYPEDEF) || \
((k) == BTF_KIND_VOLATILE) || \
@@ -175,7 +176,7 @@ static int btf_parse_str_sec(struct btf *btf)
const char *start = btf->nohdr_data + hdr->str_off;
const char *end = start + btf->hdr->str_len;
- if (!hdr->str_len || hdr->str_len - 1 > BTF_MAX_NAME_OFFSET ||
+ if (!hdr->str_len || hdr->str_len - 1 > BTF_MAX_STR_OFFSET ||
start[0] || end[-1]) {
pr_debug("Invalid BTF string section\n");
return -EINVAL;
@@ -1882,7 +1883,7 @@ static int btf_dedup_prim_types(struct btf_dedup *d)
*/
static inline bool is_type_mapped(struct btf_dedup *d, uint32_t type_id)
{
- return d->map[type_id] <= BTF_MAX_TYPE;
+ return d->map[type_id] <= BTF_MAX_NR_TYPES;
}
/*
@@ -2033,7 +2034,7 @@ static int btf_dedup_is_equiv(struct btf_dedup *d, __u32 cand_id,
canon_id = resolve_fwd_id(d, canon_id);
hypot_type_id = d->hypot_map[canon_id];
- if (hypot_type_id <= BTF_MAX_TYPE)
+ if (hypot_type_id <= BTF_MAX_NR_TYPES)
return hypot_type_id == cand_id;
if (btf_dedup_hypot_map_add(d, canon_id, cand_id))
@@ -2252,7 +2253,7 @@ static int btf_dedup_struct_type(struct btf_dedup *d, __u32 type_id)
__u32 h;
/* already deduped or is in process of deduping (loop detected) */
- if (d->map[type_id] <= BTF_MAX_TYPE)
+ if (d->map[type_id] <= BTF_MAX_NR_TYPES)
return 0;
t = d->btf->types[type_id];
@@ -2329,7 +2330,7 @@ static int btf_dedup_ref_type(struct btf_dedup *d, __u32 type_id)
if (d->map[type_id] == BTF_IN_PROGRESS_ID)
return -ELOOP;
- if (d->map[type_id] <= BTF_MAX_TYPE)
+ if (d->map[type_id] <= BTF_MAX_NR_TYPES)
return resolve_type_id(d, type_id);
t = d->btf->types[type_id];
@@ -2509,7 +2510,7 @@ static int btf_dedup_remap_type_id(struct btf_dedup *d, __u32 type_id)
resolved_type_id = resolve_type_id(d, type_id);
new_type_id = d->hypot_map[resolved_type_id];
- if (new_type_id > BTF_MAX_TYPE)
+ if (new_type_id > BTF_MAX_NR_TYPES)
return -EINVAL;
return new_type_id;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] net: ip6_gre: initialize erspan_ver just for erspan tunnels
From: David Miller @ 2019-02-16 4:15 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: netdev, petrm
In-Reply-To: <a08d2d1dbe3a498244867308adf37259bed30f37.1550239457.git.lorenzo.bianconi@redhat.com>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date: Fri, 15 Feb 2019 15:10:32 +0100
> After commit c706863bc890 ("net: ip6_gre: always reports o_key to
> userspace"), ip6gre and ip6gretap tunnels started reporting TUNNEL_KEY
> output flag even if it is not configured.
> ip6gre_fill_info checks erspan_ver value to add TUNNEL_KEY for
> erspan tunnels, however in commit 84581bdae9587 ("erspan: set
> erspan_ver to 1 by default when adding an erspan dev")
> erspan_ver is initialized to 1 even for ip6gre or ip6gretap
> Fix the issue moving erspan_ver initialization in a dedicated routine
>
> Fixes: c706863bc890 ("net: ip6_gre: always reports o_key to userspace")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][next] mlxsw: core: fix spelling mistake "temprature" -> "temperature"
From: David Miller @ 2019-02-16 4:17 UTC (permalink / raw)
To: colin.king; +Cc: jiri, idosch, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190215151153.17206-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 15 Feb 2019 15:11:53 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in several dev_err messages, fix these.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks Colin.
^ permalink raw reply
* Re: [PATCH] net: phy: xgmiitorgmii: Support generic PHY status read
From: David Miller @ 2019-02-16 4:21 UTC (permalink / raw)
To: paul.kocialkowski
Cc: netdev, linux-arm-kernel, linux-kernel, andrew, f.fainelli,
hkallweit1, michal.simek, thomas.petazzoni
In-Reply-To: <20190215161708.18645-1-paul.kocialkowski@bootlin.com>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri, 15 Feb 2019 17:17:08 +0100
> Some PHY drivers like the generic one do not provide a read_status
> callback on their own but rely on genphy_read_status being called
> directly.
>
> With the current code, this results in a NULL function pointer call.
> Call genphy_read_status instead when there is no specific callback.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Applied, thanks.
Unfortunately I only noticed your updated version with the Fixes tag
after pushing this version out. I'll be more careful next time :)
^ permalink raw reply
* Re: [PATCH] net: Fix for_each_netdev_feature on Big endian
From: David Miller @ 2019-02-16 4:24 UTC (permalink / raw)
To: hauke.mehrtens; +Cc: netdev, jarod, hauke, stable
In-Reply-To: <20190215165854.25842-1-hauke.mehrtens@intel.com>
From: Hauke Mehrtens <hauke.mehrtens@intel.com>
Date: Fri, 15 Feb 2019 17:58:54 +0100
> The features attribute is of type u64 and stored in the native endianes on
> the system. The for_each_set_bit() macro takes a pointer to a 32 bit array
> and goes over the bits in this area. On little Endian systems this also
> works with an u64 as the most significant bit is on the highest address,
> but on big endian the words are swapped. When we expect bit 15 here we get
> bit 47 (15 + 32).
>
> This patch converts it more or less to its own for_each_set_bit()
> implementation which works on 64 bit integers directly. This is then
> completely in host endianness and should work like expected.
>
> Fixes: fd867d51f ("net/core: generic support for disabling netdev features down stack")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hauke Mehrtens <hauke.mehrtens@intel.com>
Applied and queued up for -stable.
Please do not CC: stable for networking fixes, I handle -stable submissions
myself manually and this is documented in the netdev FAQ.
^ permalink raw reply
* Re: [PATCH net-next] net/ipv6: prefer rcu_access_pointer() over rcu_dereference()
From: David Miller @ 2019-02-16 4:26 UTC (permalink / raw)
To: pabeni; +Cc: netdev, dsahern
In-Reply-To: <52d4aee68b816ce36c0d4f4398ae143a2ebbdba4.1550249827.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 15 Feb 2019 18:15:37 +0100
> rt6_cache_allowed_for_pmtu() checks for rt->from presence, but
> it does not access the RCU protected pointer. We can use
> rcu_access_pointer() and clean-up the code a bit. No functional
> changes intended.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: validate untrusted gso packets without csum offload
From: David Miller @ 2019-02-16 4:31 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: netdev, edumazet, jasowang, maximmi, willemb, syzkaller
In-Reply-To: <20190215171547.247018-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Fri, 15 Feb 2019 12:15:47 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> Syzkaller again found a path to a kernel crash through bad gso input.
> By building an excessively large packet to cause an skb field to wrap.
>
> If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dropped in
> skb_partial_csum_set.
>
> GSO packets that do not set checksum offload are suspicious and rare.
> Most callers of virtio_net_hdr_to_skb already pass them to
> skb_probe_transport_header.
>
> Move that test forward, change it to detect parse failure and drop
> packets on failure as those cleary are not one of the legitimate
> VIRTIO_NET_HDR_GSO types.
>
> Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
> Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied and queued up for -stable, thanks Willem.
> This captures a variety of bad gso packets, but to tighten further:
>
> - drop SKB_GSO_DODGY packets with ipip/sit/.. , which cannot be legal.
> by ipip_gso_segment wrappers around inet_gso_segment
> expands on 121d57af308d ("gso: validate gso_type in GSO handlers")
>
> - limit the number of ipv6 exthdrs allowed from dodgy sources.
> not sure where to draw the line. but not at 64K ;)
>
> - validate the network and transport protocol returned in
> skb_probe_transport_header against the VIRTIO_NET_HDR_GSO type
>
> - probe all dodgy GSO packets, also those that set checksum offload.
> this will have a performance impact, discussed previously in
> http://patchwork.ozlabs.org/patch/861874/
> but it would have blocked this latest bug as well
>
> All but the last one seem pretty uncontroversial to me. If no one
> objects I plan to send those to net-next.
No objections from me.
^ permalink raw reply
* Re: [PATCH net-next] selftests: forwarding: Add some missing configuration symbols
From: David Miller @ 2019-02-16 4:32 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, shuah, idosch, jiri, linux-kselftest, linux-kernel
In-Reply-To: <20190215181457.21101-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Feb 2019 10:14:52 -0800
> For the forwarding selftests to work, we need network namespaces when
> using veth/vrf otherwise ping/ping6 commands like these:
>
> ip vrf exec vveth0 /bin/ping 192.0.2.2 -c 10 -i 0.1 -w 5
>
> will fail because network namespaces may not be enabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/7] s390/qeth: updates 2019-02-15
From: David Miller @ 2019-02-16 4:35 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20190215182231.90709-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 15 Feb 2019 19:22:24 +0100
> please apply a few more qeth patches to net-next. Along with some smaller
> improvements, this revamps our code for the SW statistics that are exposed
> through ETHTOOL_GSTATS.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/5] net: dsa: b53: VLAN and L2 fixes
From: David Miller @ 2019-02-16 4:38 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot
In-Reply-To: <20190215201653.20988-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Feb 2019 12:16:48 -0800
> This patch series contains a collection of fixes to the b53 driver in
> order to:
>
> - consistently program the same default VLAN ID when a port is bridged
> or not
> - properly account for VLAN filtering being turned on/off and turning
> on ingress VID checking accordingly
> - have SYSTEMPORT properly forward BPDU frames to the network stack
> (which it did not)
> - do not assume that WoL is supported by the DSA master network device
> we are connected to
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/9] net: Get rid of switchdev_port_attr_get()
From: David Miller @ 2019-02-16 4:49 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, idosch, linux-kernel, devel, bridge, jiri, andrew,
vivien.didelot
In-Reply-To: <77c28e2d-cd29-4932-5cfe-64799c730ede@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Feb 2019 16:37:38 -0800
> David, please ignore this version, I will repost one that actually
> builds, need to keep mangling with my kernel configuration and keep
> those drivers enabled...
Ok.
^ permalink raw reply
* Re: [MERGE HELP] cls_tcindex.c
From: David Miller @ 2019-02-16 4:49 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, vladbu
In-Reply-To: <CAM_iQpXCfNYSbawk8tZa+4oXb3DOYRv04eDJ1V8OAEndO14MYw@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 15 Feb 2019 17:31:41 -0800
> I will cherry-pick the first two patches for net-next and send them to you.
Ok, thanks Cong.
^ permalink raw reply
* [PATCH net-next v3 4/9] mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_GET/SET
From: Florian Fainelli @ 2019-02-16 4:55 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, idosch, linux-kernel, devel, bridge, jiri,
andrew, vivien.didelot
In-Reply-To: <20190216045556.3514-1-f.fainelli@gmail.com>
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare mlxsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
mlxsw_sp_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../mellanox/mlxsw/spectrum_switchdev.c | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 95e37de3e48f..c6d7bb70e8f2 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -3443,6 +3443,26 @@ mlxsw_sp_switchdev_handle_vxlan_obj_del(struct net_device *vxlan_dev,
}
}
+static int
+mlxsw_sp_switchdev_port_attr_event(unsigned long event, struct net_device *dev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = mlxsw_sp_port_attr_set(dev, port_attr_info->attr,
+ port_attr_info->trans);
+ break;
+ case SWITCHDEV_PORT_ATTR_GET:
+ err = mlxsw_sp_port_attr_get(dev, port_attr_info->attr);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int mlxsw_sp_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -3466,6 +3486,9 @@ static int mlxsw_sp_switchdev_blocking_event(struct notifier_block *unused,
mlxsw_sp_port_dev_check,
mlxsw_sp_port_obj_del);
return notifier_from_errno(err);
+ case SWITCHDEV_PORT_ATTR_SET:
+ case SWITCHDEV_PORT_ATTR_GET:
+ return mlxsw_sp_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
^ permalink raw reply related
* [PATCH net-next v3 6/9] staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_GET/SET
From: Florian Fainelli @ 2019-02-16 4:55 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, idosch, linux-kernel, devel, bridge, jiri,
andrew, vivien.didelot
In-Reply-To: <20190216045556.3514-1-f.fainelli@gmail.com>
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ethsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
swdev_port_attr_{set,get} calls.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index e559f4c25cf7..bc9e7de07200 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -1111,6 +1111,27 @@ ethsw_switchdev_port_obj_event(unsigned long event, struct net_device *netdev,
return notifier_from_errno(err);
}
+static int
+ethsw_switchdev_port_attr_event(unsigned long event,
+ struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err = -EOPNOTSUPP;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = swdev_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+ break;
+ case SWITCHDEV_PORT_ATTR_GET:
+ err = swdev_port_attr_get(netdev, port_attr_info->attr);
+ break;
+ }
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
static int port_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -1123,6 +1144,9 @@ static int port_switchdev_blocking_event(struct notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD: /* fall through */
case SWITCHDEV_PORT_OBJ_DEL:
return ethsw_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET:
+ case SWITCHDEV_PORT_ATTR_GET:
+ return ethsw_switchdev_port_attr_event(event, dev, ptr);
}
return NOTIFY_DONE;
--
2.19.1
^ permalink raw reply related
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