* Re: [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER
From: Roman Gushchin @ 2018-10-04 19:41 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, daniel@iogearbox.net, luto@amacapital.net,
viro@zeniv.linux.org.uk, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Kernel Team
In-Reply-To: <20181004025750.498303-2-ast@kernel.org>
On Wed, Oct 03, 2018 at 07:57:45PM -0700, Alexei Starovoitov wrote:
> Similar to networking sandboxing programs and cgroup-v2 based hooks
> (BPF_CGROUP_INET_[INGRESS|EGRESS,] BPF_CGROUP_INET[4|6]_[BIND|CONNECT], etc)
> introduce basic per-container sandboxing for file access via
> new BPF_PROG_TYPE_FILE_FILTER program type that attaches after
> security_file_open() LSM hook and works as additional file_open filter.
> The new cgroup bpf hook is called BPF_CGROUP_FILE_OPEN.
>
> Just like other cgroup-bpf programs new BPF_PROG_TYPE_FILE_FILTER type
> is only available to root.
>
> This program type has access to single argument 'struct bpf_file_info'
> that contains standard sys_stat fields:
> struct bpf_file_info {
> __u64 inode;
> __u32 dev_major;
> __u32 dev_minor;
> __u32 fs_magic;
> __u32 mnt_id;
> __u32 nlink;
> __u32 mode; /* file mode S_ISDIR, S_ISLNK, 0755, etc */
> __u32 flags; /* open flags O_RDWR, O_CREAT, etc */
> };
It's probably nice to have file uid/gid as well.
Thanks!
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 04/16] i40e: Replace spin_is_locked() with lockdep
From: Bowers, AndrewX @ 2018-10-04 18:56 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: netdev@vger.kernel.org
In-Reply-To: <20181003053902.6910-5-ldr709@gmail.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Lance Roy
> Sent: Tuesday, October 2, 2018 10:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: netdev@vger.kernel.org; Lance Roy <ldr709@gmail.com>; intel-wired-
> lan@lists.osuosl.org; Paul E. McKenney <paulmck@linux.ibm.com>; David S.
> Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH 04/16] i40e: Replace spin_is_locked() with
> lockdep
>
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is also a
> step towards possibly removing spin_is_locked().
>
> Signed-off-by: Lance Roy <ldr709@gmail.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: intel-wired-lan@lists.osuosl.org
> Cc: <netdev@vger.kernel.org>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
^ permalink raw reply
* Re: Kernel oops with mlx5 and dual XDP redirect programs
From: Toke Høiland-Jørgensen @ 2018-10-04 12:03 UTC (permalink / raw)
To: Saeed Mahameed, netdev@vger.kernel.org
Cc: Eran Ben Elisha, Tariq Toukan, brouer@redhat.com
In-Reply-To: <4e2cfdc3db244f4b9483a0c3dfc62fae55238bb3.camel@mellanox.com>
Saeed Mahameed <saeedm@mellanox.com> writes:
> On Wed, 2018-10-03 at 11:30 +0200, Toke Høiland-Jørgensen wrote:
>> Hi Saeed
>>
>> I can reliably oops the kernel with the mlx5 driver, by installing
>> XDP_REDIRECT programs on two devices so they redirect to each other,
>> and then remove them while there is traffic on the interface.
>>
>> Steps to reproduce:
>>
>> # cd ~/build/linux/samples/bpf
>> # ./xdp_redirect_map $(</sys/class/net/ens1f1/ifindex)
>> $(</sys/class/net/ens1f0/ifindex)
>> # ./xdp_redirect_map $(</sys/class/net/ens1f0/ifindex)
>> $(</sys/class/net/ens1f1/ifindex)
>>
>> Now, run some traffic (e.g., using pktgen) across the interfaces, and
>> while the traffic is running, interrupt one of the xdp_redirect_map
>> commands (thus unloading the eBPF program). This results in a kernel
>> oops with the backtrace below. I get no crash if there's only a
>> single
>> XDP program.
>
> Hi Toke,
>
> What looks like happening is that while the traffic is being redirected
> to the other device, the driver is trying to unload the program and
> restarting the rings from below call trace we can see:
Yeah, thought it was something like that, since it only happens on the
bidirectional redirect...
> I think that the mlx5 driver doesn't know how to tell the other device
> to stop transmitting to it while it is resetting.. Maybe tariq or
> Jesper know more about this ?
> I will look at this tomorrow after noon and will try to repro...
Great, thanks! :)
-Toke
^ permalink raw reply
* Re: [PATCH RFC,net-next 1/3] ip_tunnel: add type field to struct ip_tunnel_info
From: Daniel Borkmann @ 2018-10-04 12:00 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, roopa, amir, pshelar, u9012063,
alexei.starovoitov
In-Reply-To: <20181004105618.pugjxorqyuapwlzl@salvia>
On 10/04/2018 12:56 PM, Pablo Neira Ayuso wrote:
> On Thu, Oct 04, 2018 at 11:25:33AM +0200, Daniel Borkmann wrote:
>> On 10/04/2018 02:03 AM, Pablo Neira Ayuso wrote:
[...]
>>> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
>>> index a70097ecf33c..1ee2509534df 100644
>>> --- a/net/openvswitch/flow_netlink.c
>>> +++ b/net/openvswitch/flow_netlink.c
>>> @@ -2602,6 +2602,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,
>>> ovs_tun->tun_dst = tun_dst;
>>>
>>> tun_info = &tun_dst->u.tun_info;
>>> + tun_info->type = IP_TUNNEL_TYPE_UNSPEC;
>>> tun_info->mode = IP_TUNNEL_INFO_TX;
>>> if (key.tun_proto == AF_INET6)
>>> tun_info->mode |= IP_TUNNEL_INFO_IPV6;
>>>
>>
>> If so then this should also be made explicit IP_TUNNEL_TYPE_UNSPEC in BPF code
>> since all these tunnel types are supported there as well.
>
> Are you refering to proper initialization? I can see a memset() there
> for the ip_tunnel_info structure, which is implicitly setting
> tun_info->type to zero, ie. IP_TUNNEL_TYPE_UNSPEC.
>
> I can also make it explicit there if you prefer.
Yeah that would be my preference as otherwise we might miss future changes there.
Thanks,
Daniel
^ permalink raw reply
* pull-request: ieee802154-next 2018-10-04
From: Stefan Schmidt @ 2018-10-04 11:27 UTC (permalink / raw)
To: davem; +Cc: linux-wpan, alex.aring, netdev
Hello Dave.
An update from ieee802154 for *net-next*
A very quite cycle in the ieee802154 subsystem. We only have two cleanup
patches for this pull request.
Xue removed the platform_data struct handling from the mcr20a driver and
Alexander cleaned up some left overs in the hwsim driver.
Please pull, or let me know if there are any problems.
regards
Stefan Schmidt
The following changes since commit 1042caa79e9351b81ed19dc8d2d7fd6ff51a4422:
net-ipv4: remove 2 always zero parameters from ipv4_redirect() (2018-09-26 20:30:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git ieee802154-for-davem-2018-10-04
for you to fetch changes up to 154113eb17735197796ff5f477c6243d00f2c5dc:
ieee802154: hwsim: remove not used ifup list (2018-10-02 17:14:13 +0200)
----------------------------------------------------------------
Alexander Aring (1):
ieee802154: hwsim: remove not used ifup list
Xue Liu (1):
ieee802154: mcr20a: Remove struct mcr20a_platform_data
drivers/net/ieee802154/mac802154_hwsim.c | 8 ----
drivers/net/ieee802154/mcr20a.c | 64 +++++++-------------------------
2 files changed, 13 insertions(+), 59 deletions(-)
^ permalink raw reply
* Re: [PATCH RFC,net-next 1/3] ip_tunnel: add type field to struct ip_tunnel_info
From: Pablo Neira Ayuso @ 2018-10-04 10:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, netfilter-devel, roopa, amir, pshelar, u9012063,
alexei.starovoitov
In-Reply-To: <81675bff-ec49-a40a-ffab-2c298b506154@iogearbox.net>
On Thu, Oct 04, 2018 at 11:25:33AM +0200, Daniel Borkmann wrote:
> On 10/04/2018 02:03 AM, Pablo Neira Ayuso wrote:
> > This new field allows you to restrict the metadata template for a given
> > tunnel driver. This is convenient in scenarios that combine different
> > tunneling drivers, to deal with possible misconfigurations given that
> > the template can be interpreted by any target tunnel driver. Default
> > value is IP_TUNNEL_TYPE_UNSPEC, to retain the existing behaviour. This
> > also implicitly exposes what drivers are currently supported in the
> > IP_TUNNEL_INFO_TX mode.
> >
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > ---
> > drivers/net/geneve.c | 3 ++-
> > drivers/net/vxlan.c | 13 +++++++------
> > include/net/dst_metadata.h | 1 +
> > include/net/ip_tunnels.h | 16 ++++++++++++++++
> > net/ipv4/ip_gre.c | 2 ++
> > net/ipv6/ip6_gre.c | 2 ++
> > net/openvswitch/flow_netlink.c | 1 +
> > 7 files changed, 31 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> > index 6625fabe2c88..c383c394f0d2 100644
> > --- a/drivers/net/geneve.c
> > +++ b/drivers/net/geneve.c
> > @@ -920,7 +920,8 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
> >
> > if (geneve->collect_md) {
> > info = skb_tunnel_info(skb);
> > - if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX))) {
> > + if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX) ||
> > + !ip_tunnel_type(info, IP_TUNNEL_TYPE_GENEVE))) {
> > err = -EINVAL;
> > netdev_dbg(dev, "no tunnel metadata\n");
> > goto tx_error;
> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> > index e5d236595206..8cca91b572bd 100644
> > --- a/drivers/net/vxlan.c
> > +++ b/drivers/net/vxlan.c
> > @@ -2296,14 +2296,15 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
> > skb_reset_mac_header(skb);
> >
> > if (vxlan->cfg.flags & VXLAN_F_COLLECT_METADATA) {
> > - if (info && info->mode & IP_TUNNEL_INFO_BRIDGE &&
> > - info->mode & IP_TUNNEL_INFO_TX) {
> > + if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX) ||
> > + !ip_tunnel_type(info, IP_TUNNEL_TYPE_VXLAN))) {
> > + kfree_skb(skb);
> > + return NETDEV_TX_OK;
> > + }
> > + if (info->mode & IP_TUNNEL_INFO_BRIDGE) {
> > vni = tunnel_id_to_key32(info->key.tun_id);
> > } else {
> > - if (info && info->mode & IP_TUNNEL_INFO_TX)
> > - vxlan_xmit_one(skb, dev, vni, NULL, false);
> > - else
> > - kfree_skb(skb);
> > + vxlan_xmit_one(skb, dev, vni, NULL, false);
> > return NETDEV_TX_OK;
> > }
> > }
> > diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
> > index 56cb3c38569a..674116f7fa4a 100644
> > --- a/include/net/dst_metadata.h
> > +++ b/include/net/dst_metadata.h
> > @@ -100,6 +100,7 @@ static inline struct metadata_dst *tun_rx_dst(int md_size)
> > if (!tun_dst)
> > return NULL;
> >
> > + tun_dst->u.tun_info.type = IP_TUNNEL_TYPE_UNSPEC;
> > tun_dst->u.tun_info.options_len = 0;
> > tun_dst->u.tun_info.mode = 0;
> > return tun_dst;
> > diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
> > index b0d022ff6ea1..985d24b6a102 100644
> > --- a/include/net/ip_tunnels.h
> > +++ b/include/net/ip_tunnels.h
> > @@ -66,7 +66,16 @@ struct ip_tunnel_key {
> > GENMASK((FIELD_SIZEOF(struct ip_tunnel_info, \
> > options_len) * BITS_PER_BYTE) - 1, 0)
> >
> > +enum ip_tunnel_type {
> > + IP_TUNNEL_TYPE_UNSPEC = 0,
> > + IP_TUNNEL_TYPE_GRE,
> > + IP_TUNNEL_TYPE_VXLAN,
> > + IP_TUNNEL_TYPE_GENEVE,
> > + IP_TUNNEL_TYPE_ERSPAN,
> > +};
> > +
> > struct ip_tunnel_info {
> > + enum ip_tunnel_type type;
> > struct ip_tunnel_key key;
> > #ifdef CONFIG_DST_CACHE
> > struct dst_cache dst_cache;
> > @@ -75,6 +84,13 @@ struct ip_tunnel_info {
> > u8 mode;
> > };
> >
> > +static inline bool ip_tunnel_type(const struct ip_tunnel_info *tun_info,
> > + enum ip_tunnel_type type)
> > +{
> > + return tun_info->type == IP_TUNNEL_TYPE_UNSPEC ||
> > + tun_info->type == type;
> > +}
> > +
> > /* 6rd prefix/relay information */
> > #ifdef CONFIG_IPV6_SIT_6RD
> > struct ip_tunnel_6rd_parm {
> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> > index c3385a84f8ff..3ad12135c3d3 100644
> > --- a/net/ipv4/ip_gre.c
> > +++ b/net/ipv4/ip_gre.c
> > @@ -534,6 +534,7 @@ static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
> >
> > tun_info = skb_tunnel_info(skb);
> > if (unlikely(!tun_info || !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> > + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_GRE) ||
> > ip_tunnel_info_af(tun_info) != AF_INET))
> > goto err_free_skb;
> >
> > @@ -585,6 +586,7 @@ static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev,
> >
> > tun_info = skb_tunnel_info(skb);
> > if (unlikely(!tun_info || !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> > + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_ERSPAN) ||
> > ip_tunnel_info_af(tun_info) != AF_INET))
> > goto err_free_skb;
> >
> > diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> > index 515adbdba1d2..675f373809ee 100644
> > --- a/net/ipv6/ip6_gre.c
> > +++ b/net/ipv6/ip6_gre.c
> > @@ -732,6 +732,7 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb,
> > tun_info = skb_tunnel_info(skb);
> > if (unlikely(!tun_info ||
> > !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> > + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_GRE) ||
> > ip_tunnel_info_af(tun_info) != AF_INET6))
> > return -EINVAL;
> >
> > @@ -960,6 +961,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,
> > tun_info = skb_tunnel_info(skb);
> > if (unlikely(!tun_info ||
> > !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> > + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_ERSPAN) ||
> > ip_tunnel_info_af(tun_info) != AF_INET6))
> > return -EINVAL;
> >
> > diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> > index a70097ecf33c..1ee2509534df 100644
> > --- a/net/openvswitch/flow_netlink.c
> > +++ b/net/openvswitch/flow_netlink.c
> > @@ -2602,6 +2602,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,
> > ovs_tun->tun_dst = tun_dst;
> >
> > tun_info = &tun_dst->u.tun_info;
> > + tun_info->type = IP_TUNNEL_TYPE_UNSPEC;
> > tun_info->mode = IP_TUNNEL_INFO_TX;
> > if (key.tun_proto == AF_INET6)
> > tun_info->mode |= IP_TUNNEL_INFO_IPV6;
> >
>
> If so then this should also be made explicit IP_TUNNEL_TYPE_UNSPEC in BPF code
> since all these tunnel types are supported there as well.
Are you refering to proper initialization? I can see a memset() there
for the ip_tunnel_info structure, which is implicitly setting
tun_info->type to zero, ie. IP_TUNNEL_TYPE_UNSPEC.
I can also make it explicit there if you prefer.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 00/29] at24: remove at24_platform_data
From: Bartosz Golaszewski @ 2018-10-04 11:06 UTC (permalink / raw)
To: Florian Fainelli
Cc: Brian Norris, David S . Miller, Jonathan Corbet, Sekhar Nori,
Kevin Hilman, Russell King, Arnd Bergmann, Greg Kroah-Hartman,
David Woodhouse, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <a4c2e6cf-749a-83a1-0bda-43ddb7e744cd@gmail.com>
śr., 3 paź 2018 o 23:04 Florian Fainelli <f.fainelli@gmail.com> napisał(a):
>
>
>
> On 10/3/2018 1:15 PM, Bartosz Golaszewski wrote:
> > pt., 31 sie 2018 o 21:46 Brian Norris <computersforpeace@gmail.com> napisał(a):
> >>
> >> Hi,
> >>
> >> On Fri, Aug 10, 2018 at 10:04:57AM +0200, Bartosz Golaszewski wrote:
> >>> Most boards use the EEPROM to store the MAC address. This series adds
> >>> support for cell lookups to the nvmem framework, registers relevant
> >>> cells for all users, adds nvmem support to eth_platform_get_mac_address(),
> >>> converts davinci_emac driver to using it and replaces at24_platform_data
> >>> with device properties.
> >>
> >> We already have:
> >>
> >> of_get_nvmem_mac_address() (which does exactly what you're adding,
> >> except it's DT specific)
> >> of_get_mac_address()
> >> fwnode_get_mac_address()
> >> device_get_mac_address()
> >>
> >> and now you've taught me that this exists too:
> >>
> >> eth_platform_get_mac_address()
> >>
> >> These mostly don't share code, and with your series, they'll start to
> >> diverge even more as to what they support. Can you please help rectify
> >> that, instead of widening the gap?
> >>
> >> For instance, you can delete most of eth_platform_get_mac_address() and
> >> replace it with device_get_mac_address() [1]. And you could add your new
> >> stuff to fwnode_get_mac_address().
> >>
> >> And important part to note here is that you code isn't just useful for
> >> ethernet -- it could be useful for Wifi devices too. So IMO, sticking it
> >> only in an "eth" function is the wrong move.
> >>
> >> Brian
> >>
> >> [1] arch_get_platform_mac_address() is the only part I wouldn't want to
> >> replicate into a truly generic helper. The following should be a no-op
> >> refactor, AIUI:
> >>
> >
> > The only user of arch_get_platform_mac_address() is sparc. It returns
> > an address that seems to be read from some kind of EEPROM. I'm not
> > familiar with this arch though. I'm wondering if we could somehow
> > seamlessly remove this call and then convert all users of
> > eth_platform_get_mac_address() to using device_get_mac_address()?
> >
> > David: I couldn't find a place in sparc code where any ethernet device
> > would be registered, so is there a chance that nobody is using it?
>
> SPARC uses a true Open Firmware implementation, so it would register
> drivers through the CONFIG_OF infrastructure.
> --
I'm seeing that there are only six callers of
eth_platform_get_mac_address() (the only function which calls
arch_get_platform_mac_address()).
Of these six callers four are intel ethernet drivers and two are usb
ethernet adapter drivers.
Is it even possible that sparc wants to get the mac address for a usb
adapter from some memory chip? Maybe we *can* safely remove that
function completely? That would allow us to simplify a lot of code.
Bart
^ permalink raw reply
* Re: How to post rxrpc patches for net-next with deps on net?
From: David Howells @ 2018-10-04 10:49 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, netdev
In-Reply-To: <20181004.033603.80798676270756244.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> Just FYI, net has been merged into net-next.
I saw, thanks. I've rebased my rxrpc-next on it, tagged it and pushed. Will
mail a request soon.
Thanks,
David
^ permalink raw reply
* Re: [PATCH v4 net-next 0/9] bnxt_en: devlink param updates
From: Jiri Pirko @ 2018-10-04 10:39 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, gerlitz.or, michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538631832-15481-1-git-send-email-vasundhara-v.volam@broadcom.com>
Thu, Oct 04, 2018 at 07:43:43AM CEST, vasundhara-v.volam@broadcom.com wrote:
>This patchset adds support for 3 generic and 1 driver-specific devlink
>parameters. Add documentation for these configuration parameters.
>
>Also, this patchset adds support to return proper error code if
>HWRM_NVM_GET/SET_VARIABLE commands return error code
>HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
>
>v3->v4:
>-Remove extra definition of NVM_OFF_HW_TC_OFFLOAD from bnxt_devlink.h
>-Remove type information for generic parameters from
>devlink-params-bnxt.txt
>
>v2->v3:
>-Remove description of generic parameters from devlink-params-bnxt.txt
>
>v1->v2:
>-Remove hw_tc_offload parameter.
>-Update all patches with Cc of MAINTAINERS.
>-Add more description in commit message for device specific parameter.
>-Add a new Documentation/networking/devlink-params.txt with some
>generic devlink parameters information.
>-Add a new Documentation/networking/devlink-params-bnxt.txt with devlink
>parameters information that are supported by bnxt_en driver.
>
>Vasundhara Volam (9):
> devlink: Add generic parameter ignore_ari
> devlink: Add generic parameter msix_vec_per_pf_max
> devlink: Add generic parameter msix_vec_per_pf_min
> bnxt_en: Use ignore_ari devlink parameter
> bnxt_en: return proper error when FW returns
> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
> bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
> params.
> bnxt_en: Add a driver specific gre_ver_check devlink parameter.
> devlink: Add Documentation/networking/devlink-params.txt
> devlink: Add Documentation/networking/devlink-params-bnxt.txt
Looks good to me. For the whole set:
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: How to post rxrpc patches for net-next with deps on net?
From: David Miller @ 2018-10-04 10:36 UTC (permalink / raw)
To: dhowells; +Cc: netdev
In-Reply-To: <20181003.144740.2213999958916677392.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 03 Oct 2018 14:47:40 -0700 (PDT)
> From: David Howells <dhowells@redhat.com>
> Date: Wed, 03 Oct 2018 21:29:19 +0100
>
>> I have some rxrpc patches to post for your net-next/master branch, but there's
>> a dependency in them on the rxrpc-fixes-20180928 tag you pulled into your
>> net/master branch.
>>
>> What's the best way to handle this?
>>
>> (1) Wait for you to merge net into net-next?
>>
>> (2) Base it on my own merge of rxrpc-fixes-20180928 into net-next? I had to
>> fix up drivers/net/ethernet/netronome/nfp/nfp_net_common.c in the merge
>> I'm currently using.
>>
>> (3) Let you fix up the discrepency between the two branches? Two lines that
>> got removed in the rxrpc-fixes-20180928 tag cause a merge failure in
>> net/rxrpc/conn_object.c when applying it to raw net-next by their
>> unexpected presence. It's nothing too bad.
>
> The best way to make me aware of the dependency, and wait for net to get merged
> into net-next.
>
> I plan to do either this evening or some time tomorrow afternoon.
Just FYI, net has been merged into net-next.
^ permalink raw reply
* Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket
From: Alexei Starovoitov @ 2018-10-04 17:19 UTC (permalink / raw)
To: David Howells; +Cc: David Ahern, netdev, linux-afs, linux-kernel
In-Reply-To: <25668.1538672073@warthog.procyon.org.uk>
On Thu, Oct 04, 2018 at 05:54:33PM +0100, David Howells wrote:
> David Ahern <dsahern@gmail.com> wrote:
>
> > These do not add any real value. You are only dumping the skb address,
>
> Not in and of themselves, no - but in combination with tracepoints elsewhere,
> where you can use the skb address as a key to follow the lifetime of a
> particular skb.
>
> > and you can get the same effect with a probe on the function and dumping
> > the value of the register with the skb argument.
>
> Installing a probe requires various preconditions, including your kernel not
> being locked down and having the source around AIUI.
>
> Anyway, I've no especially strong feelings about this patch - it's been useful
> for me and it might be useful to others.
I don't quite see what value this tracepoint adds.
Just use kprobe in the same spot? Or tcpdump?
How was it useful for you? and why it couldn't have been achieved by other means?
^ permalink raw reply
* Re: [PATCH v2] qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers
From: David Miller @ 2018-10-04 16:58 UTC (permalink / raw)
To: natechancellor
Cc: Ariel.Elior, netdev, linux-kernel, ndesaulniers,
Dept-EngEverestLinuxL2, Tomer.Tayar
In-Reply-To: <20181004163919.13972-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Thu, 4 Oct 2018 09:39:20 -0700
> Clang warns when one enumerated type is implicitly converted to another.
>
> drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
> conversion from enumeration type 'enum core_tx_dest' to different
> enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
> tx_pkt.tx_dest = p_ll2_conn->tx_dest;
> ~ ~~~~~~~~~~~~^~~~~~~
> 1 warning generated.
>
> Fix this by using a switch statement to convert between the enumerated
> values since they are not 1 to 1, which matches how the rest of the
> driver handles this conversion.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Suggested-by: Tomer Tayar <Tomer.Tayar@cavium.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v1 -> v2:
>
> * Use an explicit switch statement to convert between the enumerated
> types like the rest of the driver, as suggested by Tomer.
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 3/4] usbnet: smsc95xx: check for csum being in last four bytes
From: Ben Hutchings @ 2018-10-04 16:55 UTC (permalink / raw)
To: Ben Dooks, netdev; +Cc: linux-kernel, linux-usb, oneukum, linux-kernel, davem
In-Reply-To: <20181002092645.1115-4-ben.dooks@codethink.co.uk>
On Tue, 2018-10-02 at 10:26 +0100, Ben Dooks wrote:
[...]
> @@ -2031,7 +2045,8 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet *dev,
> > }
>
> if (csum) {
> - if (skb->len <= 45) {
> + /* note, csum does not work if csum in last DWORD of packet */
> + if (skb->len <= 45 || !smsc95xx_can_checksum(skb)) {
It would make more sense to move the length check into
smsc95xx_can_checksum() as well.
Ben.
> /* workaround - hardware tx checksum does not work
> * properly with extremely small packets */
> long csstart = skb_checksum_start_offset(skb);
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
^ permalink raw reply
* Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket
From: David Howells @ 2018-10-04 16:54 UTC (permalink / raw)
To: David Ahern; +Cc: dhowells, netdev, linux-afs, linux-kernel
In-Reply-To: <f4d5ec71-b09a-84fa-599e-d0482cdb77b7@gmail.com>
David Ahern <dsahern@gmail.com> wrote:
> These do not add any real value. You are only dumping the skb address,
Not in and of themselves, no - but in combination with tracepoints elsewhere,
where you can use the skb address as a key to follow the lifetime of a
particular skb.
> and you can get the same effect with a probe on the function and dumping
> the value of the register with the skb argument.
Installing a probe requires various preconditions, including your kernel not
being locked down and having the source around AIUI.
Anyway, I've no especially strong feelings about this patch - it's been useful
for me and it might be useful to others.
David
^ permalink raw reply
* Re: [PATCH 2/4] usbnet: smsc95xx: align tx-buffer to word
From: Ben Hutchings @ 2018-10-04 16:53 UTC (permalink / raw)
To: Ben Dooks, netdev; +Cc: linux-kernel, linux-usb, oneukum, linux-kernel, davem
In-Reply-To: <20181002092645.1115-3-ben.dooks@codethink.co.uk>
On Tue, 2018-10-02 at 10:26 +0100, Ben Dooks wrote:
> The tegra driver requires alignment of the buffer, so try and
> make this better by pushing the buffer start back to an word
> aligned address. At the worst this makes memcpy() easier as
> it is word aligned, at best it makes sure the usb can directly
> map the buffer.
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> [todo - make this configurable]
[...]
I don't think you need a separate kconfig symbol for this. Aligning RX
buffers to words (or better, cache lines) is almost always a win, so
long as the CPU can handle misaligned fields in the network/transport
headers. You can use #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to
check that.
It seems like NET_IP_ALIGN should be defined to 0 or 2 depending on
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, but NET_IP_ALIGN predates the
latter.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
^ permalink raw reply
* RE: [PATCH v2] qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers
From: Tayar, Tomer @ 2018-10-04 16:46 UTC (permalink / raw)
To: Nathan Chancellor, Elior, Ariel, David S. Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Nick Desaulniers, Dept-Eng Everest Linux L2
In-Reply-To: <20181004163919.13972-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Sent: Thursday, October 04, 2018 7:39 PM
> Clang warns when one enumerated type is implicitly converted to another.
>
> drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
> conversion from enumeration type 'enum core_tx_dest' to different
> enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
> tx_pkt.tx_dest = p_ll2_conn->tx_dest;
> ~ ~~~~~~~~~~~~^~~~~~~
> 1 warning generated.
>
> Fix this by using a switch statement to convert between the enumerated
> values since they are not 1 to 1, which matches how the rest of the
> driver handles this conversion.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Suggested-by: Tomer Tayar <Tomer.Tayar@cavium.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v1 -> v2:
>
> * Use an explicit switch statement to convert between the enumerated
> types like the rest of the driver, as suggested by Tomer.
Thanks
Acked-by: Tomer Tayar <Tomer.Tayar@cavium.com>
^ permalink raw reply
* Re: [PATCH net-next 0/9] rxrpc: Development
From: David Miller @ 2018-10-04 16:44 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <153866103101.27255.4710558896251591679.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 04 Oct 2018 14:50:31 +0100
> Here are some development patches for AF_RXRPC. The most significant points
> are:
...
> The patches are tagged here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-next-20181004
Pulled, thanks David.
^ permalink raw reply
* Re: [PATCH net-next] dns: Allow the dns resolver to retrieve a server set
From: David Miller @ 2018-10-04 16:42 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel, linux-nfs, linux-cifs
In-Reply-To: <153865967530.25761.13226347009462917363.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 04 Oct 2018 14:27:55 +0100
> Allow the DNS resolver to retrieve a set of servers and their associated
> addresses, ports, preference and weight ratings.
...
> This can then be used to fetch a whole cell's VL-server configuration for
> AFS, for example.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thanks David.
^ permalink raw reply
* [PATCH v2] qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers
From: Nathan Chancellor @ 2018-10-04 16:39 UTC (permalink / raw)
To: Ariel Elior, David S. Miller
Cc: netdev, linux-kernel, Nick Desaulniers, Dept-EngEverestLinuxL2,
Tomer Tayar, Nathan Chancellor
In-Reply-To: <20181004000912.22242-1-natechancellor@gmail.com>
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
conversion from enumeration type 'enum core_tx_dest' to different
enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
tx_pkt.tx_dest = p_ll2_conn->tx_dest;
~ ~~~~~~~~~~~~^~~~~~~
1 warning generated.
Fix this by using a switch statement to convert between the enumerated
values since they are not 1 to 1, which matches how the rest of the
driver handles this conversion.
Link: https://github.com/ClangBuiltLinux/linux/issues/125
Suggested-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Use an explicit switch statement to convert between the enumerated
types like the rest of the driver, as suggested by Tomer.
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index da13117a604a..aa633381aa47 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -796,7 +796,18 @@ qed_ooo_submit_tx_buffers(struct qed_hwfn *p_hwfn,
tx_pkt.vlan = p_buffer->vlan;
tx_pkt.bd_flags = bd_flags;
tx_pkt.l4_hdr_offset_w = l4_hdr_offset_w;
- tx_pkt.tx_dest = p_ll2_conn->tx_dest;
+ switch (p_ll2_conn->tx_dest) {
+ case CORE_TX_DEST_NW:
+ tx_pkt.tx_dest = QED_LL2_TX_DEST_NW;
+ break;
+ case CORE_TX_DEST_LB:
+ tx_pkt.tx_dest = QED_LL2_TX_DEST_LB;
+ break;
+ case CORE_TX_DEST_DROP:
+ default:
+ tx_pkt.tx_dest = QED_LL2_TX_DEST_DROP;
+ break;
+ }
tx_pkt.first_frag = first_frag;
tx_pkt.first_frag_len = p_buffer->packet_length;
tx_pkt.cookie = p_buffer;
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket
From: David Ahern @ 2018-10-04 16:36 UTC (permalink / raw)
To: David Howells, netdev; +Cc: linux-afs, linux-kernel
In-Reply-To: <153864184110.20296.16498481420320274305.stgit@warthog.procyon.org.uk>
On 10/4/18 2:30 AM, David Howells wrote:
> Add three tracepoints to the UDP/UDP6 code to trace three aspects of
> sk_buff handling:
>
> (1) UDP packets that are about to be handed off to the IP layer to be
> transmitted.
>
> (2) UDP packets that have just arrived at the socket.
These do not add any real value. You are only dumping the skb address,
and you can get the same effect with a probe on the function and dumping
the value of the register with the skb argument.
^ permalink raw reply
* Re: [PATCH][liquidio-next] liquidio: fix a couple of spelling mistakes
From: David Miller @ 2018-10-04 16:33 UTC (permalink / raw)
To: colin.king
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, kernel-janitors, linux-kernel
In-Reply-To: <20181004121118.18014-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 4 Oct 2018 13:11:18 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistakes in dev_dbg warning messages
>
> "Reloade" -> "Reload"
> "chang" -> "change"
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] qed: Remove unneeded enumerated type core_tx_dest
From: Nathan Chancellor @ 2018-10-04 16:27 UTC (permalink / raw)
To: Tayar, Tomer
Cc: Elior, Ariel, Dept-Eng Everest Linux L2, David S. Miller,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Nick Desaulniers
In-Reply-To: <CY1PR07MB2554AFA55E8084990E14D55780EA0@CY1PR07MB2554.namprd07.prod.outlook.com>
On Thu, Oct 04, 2018 at 04:23:43PM +0000, Tayar, Tomer wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Sent: Thursday, October 04, 2018 3:09 AM
>
> > Clang warns when one enumerated type is implicitly converted to another.
> >
> > drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
> > conversion from enumeration type 'enum core_tx_dest' to different
> > enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
> > tx_pkt.tx_dest = p_ll2_conn->tx_dest;
> > ~ ~~~~~~~~~~~~^~~~~~~
> > 1 warning generated.
> >
> > These enumerated types are not 1 to 1:
> >
> > /* Light L2 TX Destination */
> > enum core_tx_dest {
> > CORE_TX_DEST_NW,
> > CORE_TX_DEST_LB,
> > CORE_TX_DEST_RESERVED,
> > CORE_TX_DEST_DROP,
> > MAX_CORE_TX_DEST
> > };
> >
> > enum qed_ll2_tx_dest {
> > QED_LL2_TX_DEST_NW, /* Light L2 TX Destination to the Network */
> > QED_LL2_TX_DEST_LB, /* Light L2 TX Destination to the Loopback */
> > QED_LL2_TX_DEST_DROP, /* Light L2 Drop the TX packet */
> > QED_LL2_TX_DEST_MAX
> > };
> >
> > Fix this conversion warning by adding CORE_TX_DEST_DROP to
> > qed_ll2_tx_dest and converting all values of core_tx_dest to
> > the equivalent value in qed_ll2_tx_dest so that there is no
> > conversion warning or functional change.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/125
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> [...]
>
> > -/* Light L2 TX Destination */
> > -enum core_tx_dest {
> > - CORE_TX_DEST_NW,
> > - CORE_TX_DEST_LB,
> > - CORE_TX_DEST_RESERVED,
> > - CORE_TX_DEST_DROP,
> > - MAX_CORE_TX_DEST
> > -};
>
> [...]
>
> > QED_LL2_TX_DEST_NW, /* Light L2 TX Destination to the Network */
> > QED_LL2_TX_DEST_LB, /* Light L2 TX Destination to the Loopback */
> > QED_LL2_TX_DEST_DROP, /* Light L2 Drop the TX packet */
> > + QED_LL2_TX_DEST_DROP_CORE, /* CORE_TX_DEST_DROP value */
> > QED_LL2_TX_DEST_MAX
> > };
>
> Thanks Nathan for finding this issue.
> "enum core_tx_dest" is for the interface with the device FW, while "enum qed_ll2_tx_dest" is for the interface with other qed* kernel modules.
> The distinction is on purpose, so "enum core_tx_dest" shouldn't be deleted.
> Maybe an explicit switch/case would be better as a fix?
> E.g. -
> - tx_pkt.tx_dest = p_ll2_conn->tx_dest;
> + switch (p_ll2_conn->tx_dest) {
> + case CORE_TX_DEST_NW:
> + tx_pkt.tx_dest = QED_LL2_TX_DEST_NW;
> + break;
> + case CORE_TX_DEST_LB:
> + tx_pkt.tx_dest = QED_LL2_TX_DEST_LB;
> + break;
> + case CORE_TX_DEST_DROP:
> + tx_pkt.tx_dest = QED_LL2_TX_DEST_DROP;
> + break;
> + default:
> + tx_pkt.tx_dest = QED_LL2_TX_DEST_DROP;
> + }
>
Hi Tomer,
Yes, that should work and it would match the rest of the driver's
handling of this distinction. I will go ahead and spin up a v2 here
shortly for review, thank you.
Nathan
^ permalink raw reply
* Re: [PATCH RFC,net-next 1/3] ip_tunnel: add type field to struct ip_tunnel_info
From: Daniel Borkmann @ 2018-10-04 9:25 UTC (permalink / raw)
To: Pablo Neira Ayuso, netdev
Cc: netfilter-devel, roopa, amir, pshelar, u9012063,
alexei.starovoitov
In-Reply-To: <20181004000345.2380-2-pablo@netfilter.org>
On 10/04/2018 02:03 AM, Pablo Neira Ayuso wrote:
> This new field allows you to restrict the metadata template for a given
> tunnel driver. This is convenient in scenarios that combine different
> tunneling drivers, to deal with possible misconfigurations given that
> the template can be interpreted by any target tunnel driver. Default
> value is IP_TUNNEL_TYPE_UNSPEC, to retain the existing behaviour. This
> also implicitly exposes what drivers are currently supported in the
> IP_TUNNEL_INFO_TX mode.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> drivers/net/geneve.c | 3 ++-
> drivers/net/vxlan.c | 13 +++++++------
> include/net/dst_metadata.h | 1 +
> include/net/ip_tunnels.h | 16 ++++++++++++++++
> net/ipv4/ip_gre.c | 2 ++
> net/ipv6/ip6_gre.c | 2 ++
> net/openvswitch/flow_netlink.c | 1 +
> 7 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index 6625fabe2c88..c383c394f0d2 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -920,7 +920,8 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
>
> if (geneve->collect_md) {
> info = skb_tunnel_info(skb);
> - if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX))) {
> + if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX) ||
> + !ip_tunnel_type(info, IP_TUNNEL_TYPE_GENEVE))) {
> err = -EINVAL;
> netdev_dbg(dev, "no tunnel metadata\n");
> goto tx_error;
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index e5d236595206..8cca91b572bd 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -2296,14 +2296,15 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
> skb_reset_mac_header(skb);
>
> if (vxlan->cfg.flags & VXLAN_F_COLLECT_METADATA) {
> - if (info && info->mode & IP_TUNNEL_INFO_BRIDGE &&
> - info->mode & IP_TUNNEL_INFO_TX) {
> + if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX) ||
> + !ip_tunnel_type(info, IP_TUNNEL_TYPE_VXLAN))) {
> + kfree_skb(skb);
> + return NETDEV_TX_OK;
> + }
> + if (info->mode & IP_TUNNEL_INFO_BRIDGE) {
> vni = tunnel_id_to_key32(info->key.tun_id);
> } else {
> - if (info && info->mode & IP_TUNNEL_INFO_TX)
> - vxlan_xmit_one(skb, dev, vni, NULL, false);
> - else
> - kfree_skb(skb);
> + vxlan_xmit_one(skb, dev, vni, NULL, false);
> return NETDEV_TX_OK;
> }
> }
> diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
> index 56cb3c38569a..674116f7fa4a 100644
> --- a/include/net/dst_metadata.h
> +++ b/include/net/dst_metadata.h
> @@ -100,6 +100,7 @@ static inline struct metadata_dst *tun_rx_dst(int md_size)
> if (!tun_dst)
> return NULL;
>
> + tun_dst->u.tun_info.type = IP_TUNNEL_TYPE_UNSPEC;
> tun_dst->u.tun_info.options_len = 0;
> tun_dst->u.tun_info.mode = 0;
> return tun_dst;
> diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
> index b0d022ff6ea1..985d24b6a102 100644
> --- a/include/net/ip_tunnels.h
> +++ b/include/net/ip_tunnels.h
> @@ -66,7 +66,16 @@ struct ip_tunnel_key {
> GENMASK((FIELD_SIZEOF(struct ip_tunnel_info, \
> options_len) * BITS_PER_BYTE) - 1, 0)
>
> +enum ip_tunnel_type {
> + IP_TUNNEL_TYPE_UNSPEC = 0,
> + IP_TUNNEL_TYPE_GRE,
> + IP_TUNNEL_TYPE_VXLAN,
> + IP_TUNNEL_TYPE_GENEVE,
> + IP_TUNNEL_TYPE_ERSPAN,
> +};
> +
> struct ip_tunnel_info {
> + enum ip_tunnel_type type;
> struct ip_tunnel_key key;
> #ifdef CONFIG_DST_CACHE
> struct dst_cache dst_cache;
> @@ -75,6 +84,13 @@ struct ip_tunnel_info {
> u8 mode;
> };
>
> +static inline bool ip_tunnel_type(const struct ip_tunnel_info *tun_info,
> + enum ip_tunnel_type type)
> +{
> + return tun_info->type == IP_TUNNEL_TYPE_UNSPEC ||
> + tun_info->type == type;
> +}
> +
> /* 6rd prefix/relay information */
> #ifdef CONFIG_IPV6_SIT_6RD
> struct ip_tunnel_6rd_parm {
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index c3385a84f8ff..3ad12135c3d3 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -534,6 +534,7 @@ static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
>
> tun_info = skb_tunnel_info(skb);
> if (unlikely(!tun_info || !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_GRE) ||
> ip_tunnel_info_af(tun_info) != AF_INET))
> goto err_free_skb;
>
> @@ -585,6 +586,7 @@ static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev,
>
> tun_info = skb_tunnel_info(skb);
> if (unlikely(!tun_info || !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_ERSPAN) ||
> ip_tunnel_info_af(tun_info) != AF_INET))
> goto err_free_skb;
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 515adbdba1d2..675f373809ee 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -732,6 +732,7 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb,
> tun_info = skb_tunnel_info(skb);
> if (unlikely(!tun_info ||
> !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_GRE) ||
> ip_tunnel_info_af(tun_info) != AF_INET6))
> return -EINVAL;
>
> @@ -960,6 +961,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,
> tun_info = skb_tunnel_info(skb);
> if (unlikely(!tun_info ||
> !(tun_info->mode & IP_TUNNEL_INFO_TX) ||
> + !ip_tunnel_type(tun_info, IP_TUNNEL_TYPE_ERSPAN) ||
> ip_tunnel_info_af(tun_info) != AF_INET6))
> return -EINVAL;
>
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index a70097ecf33c..1ee2509534df 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -2602,6 +2602,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,
> ovs_tun->tun_dst = tun_dst;
>
> tun_info = &tun_dst->u.tun_info;
> + tun_info->type = IP_TUNNEL_TYPE_UNSPEC;
> tun_info->mode = IP_TUNNEL_INFO_TX;
> if (key.tun_proto == AF_INET6)
> tun_info->mode |= IP_TUNNEL_INFO_IPV6;
>
If so then this should also be made explicit IP_TUNNEL_TYPE_UNSPEC in BPF code
since all these tunnel types are supported there as well.
Thanks,
Daniel
^ permalink raw reply
* Re: [net-next 07/13] ixgbe: Fix crash with VFs and flow director on interface flap
From: Sergei Shtylyov @ 2018-10-04 9:12 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: Radoslaw Tyl, netdev, nhorman, sassmann
In-Reply-To: <20181003202511.29684-8-jeffrey.t.kirsher@intel.com>
Hello!
On 10/3/2018 11:25 PM, Jeff Kirsher wrote:
> From: Radoslaw Tyl <radoslawx.tyl@intel.com>
>
> This patch fix crash when we have restore flow director filters after reset
Fixes. Restored?
> adapter. In ixgbe_fdir_filter_restore() filter->action is outside of the
> rx_ring array, as it has a VF identifier in the upper 32 bits.
>
> Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index ddc22557155b..2928ce7653eb 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
[...]
> @@ -5187,12 +5188,17 @@ static void ixgbe_fdir_filter_restore(struct ixgbe_adapter *adapter)
>
> hlist_for_each_entry_safe(filter, node2,
> &adapter->fdir_filter_list, fdir_node) {
> + action = filter->action;
> + if (action != IXGBE_FDIR_DROP_QUEUE && action != 0)
> + action =
> + (action >> ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF) - 1;
Could you indent with extra tab here?
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] socket: Tighten no-error check in bind()
From: Jakub Sitnicki @ 2018-10-04 9:09 UTC (permalink / raw)
To: netdev
move_addr_to_kernel() returns only negative values on error, or zero on
success. Rewrite the error check to an idiomatic form to avoid confusing
the reader.
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
---
net/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/socket.c b/net/socket.c
index 01f3f8f32d6f..713dc4833d40 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1475,7 +1475,7 @@ int __sys_bind(int fd, struct sockaddr __user *umyaddr, int addrlen)
sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (sock) {
err = move_addr_to_kernel(umyaddr, addrlen, &address);
- if (err >= 0) {
+ if (!err) {
err = security_socket_bind(sock,
(struct sockaddr *)&address,
addrlen);
--
2.17.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