* [PATCH 0/5] staging: remove ncpfs and ipx code
From: Greg Kroah-Hartman @ 2018-06-01 18:45 UTC (permalink / raw)
To: devel; +Cc: netdev, linux-kernel, Greg Kroah-Hartman
The ncpfs filesystem and ipx networking code moved into the
drivers/staging/ tree back in November of last year. Since then, no one
has steped up to take over maintance of this code. Given that it has
been more than 6 months, it is time to delete it.
Note, there is more work to be done to remove the ipx header files
completly, as it is burried deep into the networking stack in places. I
will work on a patch series to complete that later, after this is
merged, in order to clean up the last remaining bits properly.
Unless there are any objections, I'll take this through my staging tree.
Greg Kroah-Hartman (5):
staging: ncpfs: delete it
ncpfs: remove compat functionality
ncpfs: remove Documentation
ncpfs: remove uapi .h files
staging: ipx: delete it from the tree
Documentation/filesystems/00-INDEX | 2 -
Documentation/filesystems/ncpfs.txt | 12 -
drivers/staging/Kconfig | 4 -
drivers/staging/Makefile | 2 -
drivers/staging/ipx/Kconfig | 61 -
drivers/staging/ipx/Makefile | 8 -
drivers/staging/ipx/TODO | 4 -
drivers/staging/ipx/af_ipx.c | 2082 ------------------------
drivers/staging/ipx/ipx_proc.c | 338 ----
drivers/staging/ipx/ipx_route.c | 293 ----
drivers/staging/ipx/pe2.c | 36 -
drivers/staging/ipx/sysctl_net_ipx.c | 40 -
drivers/staging/ncpfs/Kconfig | 108 --
drivers/staging/ncpfs/Makefile | 17 -
drivers/staging/ncpfs/TODO | 4 -
drivers/staging/ncpfs/dir.c | 1232 --------------
drivers/staging/ncpfs/file.c | 263 ---
drivers/staging/ncpfs/getopt.c | 76 -
drivers/staging/ncpfs/getopt.h | 17 -
drivers/staging/ncpfs/inode.c | 1067 ------------
drivers/staging/ncpfs/ioctl.c | 923 -----------
drivers/staging/ncpfs/mmap.c | 125 --
drivers/staging/ncpfs/ncp_fs.h | 101 --
drivers/staging/ncpfs/ncp_fs_i.h | 31 -
drivers/staging/ncpfs/ncp_fs_sb.h | 174 --
drivers/staging/ncpfs/ncplib_kernel.c | 1326 ---------------
drivers/staging/ncpfs/ncplib_kernel.h | 215 ---
drivers/staging/ncpfs/ncpsign_kernel.c | 128 --
drivers/staging/ncpfs/ncpsign_kernel.h | 27 -
drivers/staging/ncpfs/sock.c | 855 ----------
drivers/staging/ncpfs/symlink.c | 182 ---
fs/compat.c | 72 +-
include/uapi/linux/ncp.h | 202 ---
include/uapi/linux/ncp_fs.h | 147 --
include/uapi/linux/ncp_mount.h | 72 -
include/uapi/linux/ncp_no.h | 20 -
36 files changed, 1 insertion(+), 10265 deletions(-)
delete mode 100644 Documentation/filesystems/ncpfs.txt
delete mode 100644 drivers/staging/ipx/Kconfig
delete mode 100644 drivers/staging/ipx/Makefile
delete mode 100644 drivers/staging/ipx/TODO
delete mode 100644 drivers/staging/ipx/af_ipx.c
delete mode 100644 drivers/staging/ipx/ipx_proc.c
delete mode 100644 drivers/staging/ipx/ipx_route.c
delete mode 100644 drivers/staging/ipx/pe2.c
delete mode 100644 drivers/staging/ipx/sysctl_net_ipx.c
delete mode 100644 drivers/staging/ncpfs/Kconfig
delete mode 100644 drivers/staging/ncpfs/Makefile
delete mode 100644 drivers/staging/ncpfs/TODO
delete mode 100644 drivers/staging/ncpfs/dir.c
delete mode 100644 drivers/staging/ncpfs/file.c
delete mode 100644 drivers/staging/ncpfs/getopt.c
delete mode 100644 drivers/staging/ncpfs/getopt.h
delete mode 100644 drivers/staging/ncpfs/inode.c
delete mode 100644 drivers/staging/ncpfs/ioctl.c
delete mode 100644 drivers/staging/ncpfs/mmap.c
delete mode 100644 drivers/staging/ncpfs/ncp_fs.h
delete mode 100644 drivers/staging/ncpfs/ncp_fs_i.h
delete mode 100644 drivers/staging/ncpfs/ncp_fs_sb.h
delete mode 100644 drivers/staging/ncpfs/ncplib_kernel.c
delete mode 100644 drivers/staging/ncpfs/ncplib_kernel.h
delete mode 100644 drivers/staging/ncpfs/ncpsign_kernel.c
delete mode 100644 drivers/staging/ncpfs/ncpsign_kernel.h
delete mode 100644 drivers/staging/ncpfs/sock.c
delete mode 100644 drivers/staging/ncpfs/symlink.c
delete mode 100644 include/uapi/linux/ncp.h
delete mode 100644 include/uapi/linux/ncp_fs.h
delete mode 100644 include/uapi/linux/ncp_mount.h
delete mode 100644 include/uapi/linux/ncp_no.h
--
2.17.1
^ permalink raw reply
* Re: [PATCH V2 mlx5-next 0/2] Mellanox, mlx5 new device events
From: Leon Romanovsky @ 2018-06-01 19:30 UTC (permalink / raw)
To: David Miller; +Cc: dledford, saeedm, netdev, linux-rdma, jgg
In-Reply-To: <20180601.130818.1180539221546183992.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
On Fri, Jun 01, 2018 at 01:08:18PM -0400, David Miller wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
> Date: Fri, 1 Jun 2018 19:21:26 +0300
>
> > Of course, it is harmless for both of you to pull, but it looks like
> > extra work which is not needed for you.
>
> Just put net-next or rdma-next in the subject line(s) and that will
> make it very clear what it expected to happen.
It was our intention too.
Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [net-next:master 379/380] drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:144:5: sparse: symbol 'mvpp2_percpu_read_relaxed' was not declared. Should it be static?
From: kbuild test robot @ 2018-06-01 19:46 UTC (permalink / raw)
To: Maxime Chevallier
Cc: kbuild-all, netdev, Antoine Tenart, Thomas Petazzoni, Yan Markman,
Stefan Chulski, linux-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 07f7ee6ec0e2193f1abca36cd7154986aec4893e
commit: db9d7d36eecc8926f03a8f2e46781887577b3353 [379/380] net: mvpp2: Split the PPv2 driver to a dedicated directory
reproduce:
# apt-get install sparse
git checkout db9d7d36eecc8926f03a8f2e46781887577b3353
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:144:5: sparse: symbol 'mvpp2_percpu_read_relaxed' was not declared. Should it be static?
>> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:1699:15: sparse: expression using sizeof(void)
>> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2620:36: sparse: incorrect type in argument 2 (different base types) @@ expected int [signed] l3_proto @@ got restricted __be1int [signed] l3_proto @@
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2620:36: expected int [signed] l3_proto
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2620:36: got restricted __be16 [usertype] protocol
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2874:28: sparse: expression using sizeof(void)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2874:28: sparse: expression using sizeof(void)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2885:34: sparse: expression using sizeof(void)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:2885:34: sparse: expression using sizeof(void)
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH net-next] net: mvpp2: mvpp2_percpu_read_relaxed() can be static
From: kbuild test robot @ 2018-06-01 19:46 UTC (permalink / raw)
To: Maxime Chevallier
Cc: kbuild-all, netdev, Antoine Tenart, Thomas Petazzoni, Yan Markman,
Stefan Chulski, linux-kernel
In-Reply-To: <201806020329.B1k6qmEB%fengguang.wu@intel.com>
Fixes: db9d7d36eecc ("net: mvpp2: Split the PPv2 driver to a dedicated directory")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 45622bf..0319ed9 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -141,7 +141,7 @@ void mvpp2_percpu_write_relaxed(struct mvpp2 *priv, int cpu,
writel_relaxed(data, priv->swth_base[cpu] + offset);
}
-u32 mvpp2_percpu_read_relaxed(struct mvpp2 *priv, int cpu,
+static u32 mvpp2_percpu_read_relaxed(struct mvpp2 *priv, int cpu,
u32 offset)
{
return readl_relaxed(priv->swth_base[cpu] + offset);
^ permalink raw reply related
* [bpf PATCH v2] bpf: sockmap, fix crash when ipv6 sock is added
From: John Fastabend @ 2018-06-01 19:46 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
This fixes a crash where we assign tcp_prot to IPv6 sockets instead
of tcpv6_prot.
Previously we overwrote the sk->prot field with tcp_prot even in the
AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
are used. Further, only allow ESTABLISHED connections to join the
map per note in TLS ULP,
/* The TLS ulp is currently supported only for TCP sockets
* in ESTABLISHED state.
* Supporting sockets in LISTEN state will require us
* to modify the accept implementation to clone rather then
* share the ulp context.
*/
Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
'netperf -H [IPv4]'. The ESTABLISHED check resolves the previously
crashing case here.
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Reported-by: syzbot+5c063698bdbfac19f363@syzkaller.appspotmail.com
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Wei Wang <weiwan@google.com>
---
kernel/bpf/sockmap.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 95a84b2..1c8bf18 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -41,6 +41,7 @@
#include <linux/mm.h>
#include <net/strparser.h>
#include <net/tcp.h>
+#include <net/transp_v6.h>
#include <linux/ptr_ring.h>
#include <net/inet_common.h>
#include <linux/sched/signal.h>
@@ -134,6 +135,8 @@ static bool bpf_tcp_stream_read(const struct sock *sk)
}
static struct proto tcp_bpf_proto;
+static struct proto tcpv6_bpf_proto;
+
static int bpf_tcp_init(struct sock *sk)
{
struct smap_psock *psock;
@@ -154,13 +157,21 @@ static int bpf_tcp_init(struct sock *sk)
psock->sk_proto = sk->sk_prot;
if (psock->bpf_tx_msg) {
+ tcpv6_bpf_proto.sendmsg = bpf_tcp_sendmsg;
+ tcpv6_bpf_proto.sendpage = bpf_tcp_sendpage;
+ tcpv6_bpf_proto.recvmsg = bpf_tcp_recvmsg;
+ tcpv6_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
tcp_bpf_proto.sendmsg = bpf_tcp_sendmsg;
tcp_bpf_proto.sendpage = bpf_tcp_sendpage;
tcp_bpf_proto.recvmsg = bpf_tcp_recvmsg;
tcp_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
}
- sk->sk_prot = &tcp_bpf_proto;
+ if (sk->sk_family == AF_INET6)
+ sk->sk_prot = &tcpv6_bpf_proto;
+ else
+ sk->sk_prot = &tcp_bpf_proto;
+
rcu_read_unlock();
return 0;
}
@@ -1072,6 +1083,8 @@ static int bpf_tcp_ulp_register(void)
{
tcp_bpf_proto = tcp_prot;
tcp_bpf_proto.close = bpf_tcp_close;
+ tcpv6_bpf_proto = tcpv6_prot;
+ tcpv6_bpf_proto.close = bpf_tcp_close;
/* Once BPF TX ULP is registered it is never unregistered. It
* will be in the ULP list for the lifetime of the system. Doing
* duplicate registers is not a problem.
@@ -1689,6 +1702,14 @@ static int sock_map_ctx_update_elem(struct bpf_sock_ops_kern *skops,
sock = skops->sk;
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state. Supporting sockets in LISTEN state will require us to
+ * modify the accept implementation to clone rather then share the
+ * ulp context.
+ */
+ if (sock->sk_state != TCP_ESTABLISHED)
+ return -ENOTSUPP;
+
/* 1. If sock map has BPF programs those will be inherited by the
* sock being added. If the sock is already attached to BPF programs
* this results in an error.
^ permalink raw reply related
* Re: [PATCH iproute2 v2] ipaddress: strengthen check on 'label' input
From: Stephen Hemminger @ 2018-06-01 19:56 UTC (permalink / raw)
To: Patrick Talbert; +Cc: netdev
In-Reply-To: <1527605827-25516-1-git-send-email-ptalbert@redhat.com>
On Tue, 29 May 2018 16:57:07 +0200
Patrick Talbert <ptalbert@redhat.com> wrote:
> As mentioned in the ip-address man page, an address label must
> be equal to the device name or prefixed by the device name
> followed by a colon. Currently the only check on this input is
> to see if the device name appears at the beginning of the label
> string.
>
> This commit adds an additional check to ensure label == dev or
> continues with a colon.
>
> Signed-off-by: Patrick Talbert <ptalbert@redhat.com>
> Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
Yes, this looks better but still have some feedback.
> ---
> ip/ipaddress.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 00da14c..fce2008 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -2040,6 +2040,22 @@ static bool ipaddr_is_multicast(inet_prefix *a)
> return false;
> }
>
> +static bool is_valid_label(const char *dev, const char *label)
> +{
> + char alias[strlen(dev) + 1];
> +
> + if (strlen(label) < strlen(dev))
> + return false;
> +
> + strcpy(alias, dev);
> + strcat(alias, ":");
> + if (strncmp(label, dev, strlen(dev)) == 0 ||
> + strncmp(label, alias, strlen(alias)) == 0)
> + return true;
> + else
> + return false;
> +}
This string copying and comparison still is much more overhead than it
needs to be. The following tests out to be equivalent with a single strncmp
and strlen.
Why not just:
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 00da14c6f97c..eac489e94fe4 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -2040,6 +2040,16 @@ static bool ipaddr_is_multicast(inet_prefix *a)
return false;
}
+static bool is_valid_label(const char *label, const char *dev)
+{
+ size_t len = strlen(dev);
+
+ if (strncmp(label, dev, len) != 0)
+ return false;
+
+ return label[len] == '\0' || label[len] == ':';
+}
+
Doesn't matter much now, but code seems to get copied.
^ permalink raw reply related
* Re: [bpf PATCH v2] bpf: sockmap, fix crash when ipv6 sock is added
From: Eric Dumazet @ 2018-06-01 19:58 UTC (permalink / raw)
To: John Fastabend, edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180601194641.5717.11725.stgit@john-Precision-Tower-5810>
On 06/01/2018 03:46 PM, John Fastabend wrote:
> This fixes a crash where we assign tcp_prot to IPv6 sockets instead
> of tcpv6_prot.
...
> + /* ULPs are currently supported only for TCP sockets in ESTABLISHED
> + * state. Supporting sockets in LISTEN state will require us to
> + * modify the accept implementation to clone rather then share the
> + * ulp context.
> + */
> + if (sock->sk_state != TCP_ESTABLISHED)
> + return -ENOTSUPP;
> +
> /* 1. If sock map has BPF programs those will be inherited by the
> * sock being added. If the sock is already attached to BPF programs
> * this results in an error.
>
Next question will be then : What happens if syzbot uses tcp_disconnect() and then listen() ?
Thanks !
^ permalink raw reply
* Re: [PATCH v2 iproute2-next] ip route: print RTA_CACHEINFO if it exists
From: Stephen Hemminger @ 2018-06-01 20:00 UTC (permalink / raw)
To: dsahern; +Cc: netdev, David Ahern
In-Reply-To: <20180530153009.4409-1-dsahern@kernel.org>
On Wed, 30 May 2018 08:30:09 -0700
dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> RTA_CACHEINFO can be sent for non-cloned routes. If the attribute is
> present print it. Allows route dumps to print expires times for example
> which can exist on FIB entries.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [PATCH iproute2] ip: IFLA_NEW_NETNSID/IFLA_NEW_IFINDEX support
From: Stephen Hemminger @ 2018-06-01 20:02 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
In-Reply-To: <b20932cf-3426-8c82-8496-cdae1738a4fe@6wind.com>
On Fri, 1 Jun 2018 17:02:18 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 31/05/2018 à 17:51, Nicolas Dichtel a écrit :
> > Le 31/05/2018 à 17:46, Stephen Hemminger a écrit :
> >> On Thu, 31 May 2018 16:28:48 +0200
> > [snip]
> >> This makes sense. All of linkinfo that is present should be displayed.
> >>
> >> Both netns and ifindex are really unsigned values. Use __u32 and print_uint.
> > Ok.
> I replied a bit quickly, both are signed values:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/rtnetlink.c#n1621
>
>
> Regards,
> Nicolas
Ok, Applied orignal patch
^ permalink raw reply
* Re: [PATCH] iproute2: fix 'ip xfrm monitor all' command
From: Stephen Hemminger @ 2018-06-01 20:03 UTC (permalink / raw)
To: Nathan Harold; +Cc: netdev
In-Reply-To: <20180530191132.62598-1-nharold@google.com>
On Wed, 30 May 2018 12:11:32 -0700
Nathan Harold <nharold@google.com> wrote:
> Currently, calling 'ip xfrm monitor all' will
> actually invoke the 'all-nsid' command because the
> soft-match for 'all-nsid' occurs before the precise
> match for 'all'. This patch rearranges the checks
> so that the 'all' command, itself an alias for
> invoking 'ip xfrm monitor' with no argument, can
> be called consistent with the syntax for other ip
> commands that accept an 'all'.
>
> Signed-off-by: Nathan Harold <nharold@google.com>
Looks good, applied. After review it shouldn't break any existing command lines.
^ permalink raw reply
* Re: [PATCH rdma-next v3 05/14] IB/uverbs: Add create/destroy counters support
From: Jason Gunthorpe @ 2018-06-01 20:54 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Boris Pismenny,
Matan Barak, Michael J . Ruhl, Or Gerlitz, Raed Salem,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180531134341.18441-6-leon@kernel.org>
> diff --git a/drivers/infiniband/core/uverbs_std_types_counters.c b/drivers/infiniband/core/uverbs_std_types_counters.c
> new file mode 100644
> index 000000000000..a5bc50ceee13
> +++ b/drivers/infiniband/core/uverbs_std_types_counters.c
> @@ -0,0 +1,100 @@
> +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) */
Check patch tells me this is malformed should be:
// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
Apparently the WITH Linux-syscall-note is only used in uapi header
files.
> +/*
> + * Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
> + *
> + * This software is available to you under a choice of one of two
> + * licenses. You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * OpenIB.org BSD license below:
> + *
> + * Redistribution and use in source and binary forms, with or
> + * without modification, are permitted provided that the following
> + * conditions are met:
> + *
> + * - Redistributions of source code must retain the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer.
> + *
> + * - Redistributions in binary form must reproduce the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer in the documentation and/or other materials
> + * provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
And this is not a SPDX BSD-2-Clause license, this is the SPDX
Linux-OpenIB license.
Please be careful to use the correct tag with SPDX..
Also can you check if these SPDX tags are what are intended:
include/rdma/restrack.h:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
drivers/infiniband/core/restrack.c:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
drivers/infiniband/hw/mlx5/ib_rep.c:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
drivers/infiniband/hw/mlx5/ib_rep.h:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
I'm not super excited about the license proliferation, so if they
should have been OR Linux-OpenIB as well then please send a patch.
Jason
^ permalink raw reply
* Re: [PATCH rdma-next v3 00/14] Verbs flow counters support
From: Jason Gunthorpe @ 2018-06-01 21:11 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Boris Pismenny,
Matan Barak, Michael J . Ruhl, Or Gerlitz, Raed Salem,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180531134341.18441-1-leon@kernel.org>
On Thu, May 31, 2018 at 04:43:27PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Changelog:
> v2->v3:
> * Change function mlx5_fc_query signature to hide the details of
> internal core driver struct mlx5_fc
> * Add commen to data[] field at struct mlx5_ib_flow_counters_data (mlx5-abi.h)
> * Use array of struct mlx5_ib_flow_counters_desc to clarify the output
> v1->v2:
> * Removed conversion from struct mlx5_fc* to void*
> * Fixed one place with double space in it
> * Balanced release of hardware handler in case of counters allocation failure
> * Added Tested-by
> * Minimize time spent holding mutex lock
> * Fixed deadlock caused by nested lock in error path
> * Protect from handler pointer derefence in the error paths
Okay,
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
I've revised some of the commit messages, fixed the two bad
check-patch warnings, and fixed the patch ordering..
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=wip/jgg-counters
Please send a PR with the mlx-core bits and above commits.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH 0/4] RFC CPSW switchdev mode
From: Grygorii Strashko @ 2018-06-01 21:29 UTC (permalink / raw)
To: Ilias Apalodimas, netdev, ivan.khoronzhuk, nsekhar, jiri, ivecera
Cc: francois.ozog, yogeshs, spatton
In-Reply-To: <1527144984-31236-1-git-send-email-ilias.apalodimas@linaro.org>
Hi Ilias,
On 05/24/2018 01:56 AM, Ilias Apalodimas wrote:
> Hello,
>
> This is adding a new mode on the cpsw driver based around switchdev.
> In order to enable this you need to enable CONFIG_NET_SWITCHDEV,
> CONFIG_BRIDGE_VLAN_FILTERING, CONFIG_TI_CPSW_SWITCHDEV
> and add to udev config:
>
> SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="0f011900", \
> ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
> Since the phys_switch_id is based on cpsw version, users with different
> version will need to do 'ip -d link show dev sw0p0 | grep switchid' and
> replace with the correct value.
>
> This patch creates 3 ports, sw0p0, sw0p1 and sw0p2.
> sw0p1 and sw0p2 are the netdev interfaces connected to PHY devices
> while sw0p0 is the switch 'cpu facing port'.
> sw0p0 will be unable to receive and transmit traffic and it's not 100% within
> switchdev scope but, it's used to configure switch cpu port individually as
> this is needed for various switch features and configuration scenarios.
First, sorry for delayed reply it was very tough week (new SoC).
Second, Thanks a lot for your great work. I'm still testing it with different
use cases and trying to consolidate my reply for all questions.
All, thanks for your comments.
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH 4/4] cpsw: add switchdev support
From: Florian Fainelli @ 2018-06-01 21:48 UTC (permalink / raw)
To: Ilias Apalodimas, Andrew Lunn
Cc: netdev, grygorii.strashko, ivan.khoronzhuk, nsekhar, jiri,
ivecera, francois.ozog, yogeshs, spatton
In-Reply-To: <20180525045647.GA1758@apalos>
On 05/24/2018 09:56 PM, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 06:39:04PM +0200, Andrew Lunn wrote:
>> On Thu, May 24, 2018 at 04:32:34PM +0300, Ilias Apalodimas wrote:
>>> On Thu, May 24, 2018 at 03:12:29PM +0200, Andrew Lunn wrote:
>>>> Device tree is supposed to describe the hardware. Using that hardware
>>>> in different ways is not something you should describe in DT.
>>>>
>>> The new switchdev mode is applied with a .config option in the kernel. What you
>>> see is pre-existing code, so i am not sure if i should change it in this
>>> patchset.
>>
>> If you break the code up into a library and two drivers, it becomes a
>> moot point.
> Agree
>
>>
>> But what i don't like here is that the device tree says to do dual
>> mac. But you ignore that and do sometime else. I would prefer that if
>> DT says dual mac, and switchdev is compiled in, the probe fails with
>> EINVAL. Rather than ignore something, make it clear it is invalid.
> The switch has 3 modes of operation as is.
> 1. switch mode, to enable that you don't need to add anything on
> the DTS and linux registers a single netdev interface.
> 2. dual mac mode, this is when you need to add dual_emac; on the DTS.
> 3. switchdev mode which is controlled by a .config option, since as you
> pointed out DTS was not made for controlling config options.
>
> I agree that this is far from beautiful. If the driver remains as in though,
> i'd prefer either keeping what's there or making "switchdev" a DTS option,
> following the pre-existing erroneous usage rather than making the device
> unusable. If we end up returning some error and refuse to initialize, users
> that remote upgrade their equipment, without taking a good look at changelog,
> will loose access to their devices with no means of remotely fixing that.
It seems to me that the mistake here is seeing multiple modes of
operations for the cpsw. There are not actually many, there is one
usage, and then there is what you can and cannot offload. The basic
premise with switchdev and DSA (which uses switchdev) is that each
user-facing port of your switch needs to work as if it were a normal
Ethernet NIC, that is what you call dual-MAC I believe. Then, when you
create a bridge and you enslave those ports into the bridge, you need to
have forwarding done in hardware between these two ports when the
SMAC/DMAC are not for the host/CPU/management interface and you must
simultaneously still have the host have the ability to send/receive
traffic through the bridge device.
It seems to me like this is entirely doable given that the dual MAC use
case is supported already.
switchdev is just a stateless framework to get notified from the
networking stack about what you can possibly offload in hardware, so
having a DTS option gate that is unfortunately wrong because it is
really implementing a SW policy in DTS which is not what it is meant for.
--
Florian
^ permalink raw reply
* Re: [PATCH] ieee802154: mcr20a: add missing includes
From: Xue Liu @ 2018-06-01 21:52 UTC (permalink / raw)
To: arnd
Cc: alex. aring, Stefan Schmidt, David S. Miller, colin.king,
Gustavo A. R. Silva, linux-wpan - ML, netdev, linux-kernel
In-Reply-To: <20180530214732.1021121-1-arnd@arndb.de>
Hello Arnd,
Thanks for the fix.
Acked-by: Xue Liu <liuxuenetmail@gmail.com>
On Wed, 30 May 2018 at 23:47, Arnd Bergmann <arnd@arndb.de> wrote:
>
> Without CONFIG_GPIOLIB, some headers are not included implicitly,
> leading to a build failure:
>
> drivers/net/ieee802154/mcr20a.c: In function 'mcr20a_probe':
> drivers/net/ieee802154/mcr20a.c:1347:13: error: implicit declaration of function 'irq_get_trigger_type'; did you mean 'irq_get_irqchip_state'? [-Werror=implicit-function-declaration]
>
> This includes gpio/consumer.h and irq.h directly rather through the
> gpiolib header.
>
> Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ieee802154/mcr20a.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index de0d7f28a181..e428277781ac 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -15,10 +15,11 @@
> */
> #include <linux/kernel.h>
> #include <linux/module.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/spi/spi.h>
> #include <linux/workqueue.h>
> #include <linux/interrupt.h>
> +#include <linux/irq.h>
> #include <linux/skbuff.h>
> #include <linux/of_gpio.h>
> #include <linux/regmap.h>
> --
> 2.9.0
>
--
^ permalink raw reply
* Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
From: Qing Huang @ 2018-06-01 22:05 UTC (permalink / raw)
To: Michal Hocko
Cc: Eric Dumazet, David Miller, tariqt, haakon.bugge, yanjun.zhu,
netdev, linux-rdma, linux-kernel, gi-oh.kim,
santosh.shilimkar@oracle.com
In-Reply-To: <20180601073137.GV15278@dhcp22.suse.cz>
On 6/1/2018 12:31 AM, Michal Hocko wrote:
> On Thu 31-05-18 19:04:46, Qing Huang wrote:
>>
>> On 5/31/2018 2:10 AM, Michal Hocko wrote:
>>> On Thu 31-05-18 10:55:32, Michal Hocko wrote:
>>>> On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
>>> [...]
>>>>> I merely copied/pasted from alloc_skb_with_frags() :/
>>>> I will have a look at it. Thanks!
>>> OK, so this is an example of an incremental development ;).
>>>
>>> __GFP_NORETRY was added by ed98df3361f0 ("net: use __GFP_NORETRY for
>>> high order allocations") to prevent from OOM killer. Yet this was
>>> not enough because fb05e7a89f50 ("net: don't wait for order-3 page
>>> allocation") didn't want an excessive reclaim for non-costly orders
>>> so it made it completely NOWAIT while it preserved __GFP_NORETRY in
>>> place which is now redundant. Should I send a patch?
>>>
>> Just curious, how about GFP_ATOMIC flag? Would it work in a similar fashion?
>> We experimented
>> with it a bit in the past but it seemed to cause other issue in our tests.
>> :-)
> GFP_ATOMIC is a non-sleeping (aka no reclaim) context with an access to
> memory reserves. So the risk is that you deplete those reserves and
> cause issues to other subsystems which need them as well.
>
>> By the way, we didn't encounter any OOM killer events. It seemed that the
>> mlx4_alloc_icm() triggered slowpath.
>> We still had about 2GB free memory while it was highly fragmented.
> The compaction was able to make a reasonable forward progress for you.
> But considering mlx4_alloc_icm is called with GFP_KERNEL resp. GFP_HIGHUSER
> then the OOM killer is clearly possible as long as the order is lower
> than 4.
The allocation was 256KB so the order was much higher than 4. The
compaction seemed to be the root
cause for our problem. It took too long to finish its work while putting
mlx4_alloc_icm to sleep in a heavily
fragmented memory situation . Will NORETRY flag avoid the compaction ops
and fail the 256KB allocation
immediately so mlx4_alloc_icm can enter adjustable lower order
allocation code path quickly?
Thanks.
>
>> #0 [ffff8801f308b380] remove_migration_pte at ffffffff811f0e0b
>> #1 [ffff8801f308b3e0] rmap_walk_file at ffffffff811cb890
>> #2 [ffff8801f308b440] rmap_walk at ffffffff811cbaf2
>> #3 [ffff8801f308b450] remove_migration_ptes at ffffffff811f0db0
>> #4 [ffff8801f308b490] __unmap_and_move at ffffffff811f2ea6
>> #5 [ffff8801f308b4e0] unmap_and_move at ffffffff811f2fc5
>> #6 [ffff8801f308b540] migrate_pages at ffffffff811f3219
>> #7 [ffff8801f308b5c0] compact_zone at ffffffff811b707e
>> #8 [ffff8801f308b650] compact_zone_order at ffffffff811b735d
>> #9 [ffff8801f308b6e0] try_to_compact_pages at ffffffff811b7485
>> #10 [ffff8801f308b770] __alloc_pages_direct_compact at ffffffff81195f96
>> #11 [ffff8801f308b7b0] __alloc_pages_slowpath at ffffffff811978a1
>> #12 [ffff8801f308b890] __alloc_pages_nodemask at ffffffff81197ec1
>> #13 [ffff8801f308b970] alloc_pages_current at ffffffff811e261f
>> #14 [ffff8801f308b9e0] mlx4_alloc_icm at ffffffffa01f39b2 [mlx4_core]
>>
>> Thanks!
^ permalink raw reply
* Re: [net-next:master 375/376] net/core/rtnetlink.c:3099:1: warning: the frame size of 1280 bytes is larger than 1024 bytes
From: Kees Cook @ 2018-06-01 22:06 UTC (permalink / raw)
To: kbuild test robot, Richard Weinberger, Jeff Dike,
Ramkumar Ramachandra
Cc: kbuild-all, Network Development
In-Reply-To: <201806011352.TzDirc4T%fengguang.wu@intel.com>
On Thu, May 31, 2018 at 10:07 PM, kbuild test robot <lkp@intel.com> wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> head: 4b8e6ac41a594ea67ded6af6af5935f03221ea4c
> commit: ccf8dbcd062a930e64741c939ca784d15316aa0c [375/376] rtnetlink: Remove VLA usage
> config: um-x86_64_defconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> git checkout ccf8dbcd062a930e64741c939ca784d15316aa0c
> # save the attached .config to linux build tree
> make ARCH=um SUBARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
> net/core/rtnetlink.c: In function 'rtnl_newlink':
>>> net/core/rtnetlink.c:3099:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> }
> ^
The recent removal of the VLA has exposed how large it's possible for
this stack allocation to get (i.e. it was hidden from the checker
before because it was a VLA). This warning doesn't trip on regular
x86_64 because the -Wframe-larger-than is 2048. It seems like 64-bit
um should have the same 64-bit value (instead of using the 32-bit
value):
arch/um/configs/x86_64_defconfig:CONFIG_FRAME_WARN=1024
lib/Kconfig.debug:
config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
default 3072 if KASAN_EXTRA
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
default 1280 if (!64BIT && PARISC)
default 1024 if (!64BIT && !PARISC)
default 2048 if 64BIT
Just dropping the defconfig there should fix it. (And I think it was
just a mistake to port that value when splitting the um defconfig in
commit e40f04d040c6 ("arch/um: make it work with defconfig and
x86_64").
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: suspicius csum initialization in vmxnet3_rx_csum
From: Neil Horman @ 2018-06-01 22:12 UTC (permalink / raw)
To: Ronak Doshi; +Cc: Paolo Abeni, Guolin Yang, Boon Ang, Louis Luo, netdev
In-Reply-To: <alpine.OSX.2.21.1806011100140.27872@doshir-m01.vmware.com>
On Fri, Jun 01, 2018 at 11:10:01AM -0700, Ronak Doshi wrote:
>
>
> On Thu, 31 May 2018, Neil Horman wrote:
>
> > On Thu, May 31, 2018 at 11:02:34AM -0700, Ronak Doshi wrote:
> > >
> > > On Wed, 30 May 2018, Paolo Abeni wrote:
> > >
> > > > Hi,
> > > >
> > > > On Thu, 2018-05-24 at 21:48 +0000, Guolin Yang wrote:
> > > > > Yes, that code is not correct, we should fix that code
> > > >
> > > > Did you have any chance to address the issue and/or to give a more in-
> > > > deepth look to the change proposed in my initial email?
> > > >
> > > Hi Paolo,
> > >
> > > Can you provide the esx build you are using? It can be found using
> > > "vmware -vl" on ESX host.
> > >
> > > Did you try your proposed fix and did it work? Are you sure the packet
> > > hits the below if block and not the else block? I still don't think the
> > > ICMP packet will go through the below if block.
> > >
> > > if (gdesc->rcd.csum) {
> > > skb->csum = htons(gdesc->rcd.csum);
> > > skb->ip_summed = CHECKSUM_PARTIAL;
> > > } else {
> > > skb_checksum_none_assert(skb);
> > > }
> > >
> > > The vmxnet3 emulation does not calculate rcd.csum for ICMP packet and
> > > hence should go through the else block i.e. checksum none.
> > >
> > What packet types will rcd.csum be set for?
> > Neil
> >
> I looked thorugh the emulation code and found that rcd.csum is not set.
> For valid v4/v6, TCP/UDP packets the code block above the mentioend "if"
> block will be executed or else it will go through checksum none.
>
> That's why I wanted to know (in previous emails) which ESX build is being
> used while this was tested. The code block under "if (gdesc->rcd.csum)"
> block might seem incorrect but it shouldn't be hit as rcd.csum is not set.
> Hence, I asked did the fix provided by Paolo worked for the icmp test?
>
Paolo will have to tell you that specifically I'm afraid. I'm not sure if the patch was tested or not.
> Thanks,
> Ronak
>
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: Fix null-ptr-deref in rtnl_newlink
From: Kees Cook @ 2018-06-01 22:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: bhole_prashant_q7, David Miller, Daniel Borkmann,
Alexei Starovoitov, Kirill Tkhai, Florian Westphal, netdev
In-Reply-To: <CANn89iKuLWFf_pCBmiDr1E+3WZxxm1nvu0FJjB9k256EFZqP6w@mail.gmail.com>
On Fri, Jun 1, 2018 at 1:26 AM, Eric Dumazet <edumazet@google.com> wrote:
> On Fri, Jun 1, 2018 at 4:18 AM Prashant Bhole
> <bhole_prashant_q7@lab.ntt.co.jp> wrote:
>>
>> In rtnl_newlink(), NULL check is performed on m_ops however member of
>> ops is accessed. Fixed by accessing member of m_ops instead of ops.
>>
>> [ 345.432629] BUG: KASAN: null-ptr-deref in rtnl_newlink+0x400/0x1110
>> [ 345.432629] Read of size 4 at addr 0000000000000088 by task ip/986
>> [ 345.432629]
>> [ 345.432629] CPU: 1 PID: 986 Comm: ip Not tainted 4.17.0-rc6+ #9
>> [ 345.432629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
>> [ 345.432629] Call Trace:
>> [ 345.432629] dump_stack+0xc6/0x150
>> [ 345.432629] ? dump_stack_print_info.cold.0+0x1b/0x1b
>> [ 345.432629] ? kasan_report+0xb4/0x410
>> [ 345.432629] kasan_report.cold.4+0x8f/0x91
>> [ 345.432629] ? rtnl_newlink+0x400/0x1110
>> [ 345.432629] rtnl_newlink+0x400/0x1110
>> [...]
>>
>> Fixes: ccf8dbcd062a ("rtnetlink: Remove VLA usage")
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>> ---
>> net/core/rtnetlink.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 8ca49a0e13fb..9a1ba2015ad8 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -2936,7 +2936,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
>> }
>>
>> if (m_ops) {
>> - if (ops->slave_maxtype > RTNL_SLAVE_MAX_TYPE)
>> + if (m_ops->slave_maxtype > RTNL_SLAVE_MAX_TYPE)
>> return -EINVAL;
>
>
> Oh nice
>
> CC Kees Cook.
Argh. Thank you, yes.
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH V2 mlx5-next 0/2] Mellanox, mlx5 new device events
From: Saeed Mahameed @ 2018-06-02 0:13 UTC (permalink / raw)
To: davem@davemloft.net
Cc: Jason Gunthorpe, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Leon Romanovsky
In-Reply-To: <20180531.153603.45475041396194381.davem@davemloft.net>
On Thu, 2018-05-31 at 15:36 -0400, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Wed, 30 May 2018 10:59:48 -0700
>
> > The following series is for mlx5-next tree [1], it adds the support
> > of two
> > new device events, from Ilan Tayari:
> >
> > 1. High temperature warnings.
> > 2. FPGA QP error event.
> >
> > In case of no objection this series will be applied to mlx5-next
> > tree
> > and will be sent later as a pull request to both rdma and net
> > trees.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.
> > git/log/?h=mlx5-next
> >
> > v1->v2:
> > - improve commit message of the FPGA QP error event patch.
>
> Series applied, thanks.
Hey Dave, this series was meant to go to mlx5-next tree as stated in
the cover letter and patches titles "[PATCH V2 mlx5-next 0/2]".
It is ok you applied those patches to net-next this time, but for next
time I would like to apply them myself to mlx5-next and send a clean
pull request later to both rdma and net trees.
Is there a way for me to mark them as delegated in patchwork ?
I see that i have "update Properties" option in patchwork but i don't
know how to use it or whether I am allowed to do anything with it.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH V2 mlx5-next 0/2] Mellanox, mlx5 new device events
From: Saeed Mahameed @ 2018-06-02 0:17 UTC (permalink / raw)
To: davem@davemloft.net
Cc: Jason Gunthorpe, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Leon Romanovsky
In-Reply-To: <34cedd2bed26c85e886426bde8635081a4b36e64.camel@mellanox.com>
On Fri, 2018-06-01 at 17:13 -0700, saeedm@mellanox.com wrote:
> On Thu, 2018-05-31 at 15:36 -0400, David Miller wrote:
> > From: Saeed Mahameed <saeedm@mellanox.com>
> > Date: Wed, 30 May 2018 10:59:48 -0700
> >
> > > The following series is for mlx5-next tree [1], it adds the
> > > support
> > > of two
> > > new device events, from Ilan Tayari:
> > >
> > > 1. High temperature warnings.
> > > 2. FPGA QP error event.
> > >
> > > In case of no objection this series will be applied to mlx5-next
> > > tree
> > > and will be sent later as a pull request to both rdma and net
> > > trees.
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linu
> > > x.
> > > git/log/?h=mlx5-next
> > >
> > > v1->v2:
> > > - improve commit message of the FPGA QP error event patch.
> >
> > Series applied, thanks.
>
> Hey Dave, this series was meant to go to mlx5-next tree as stated in
> the cover letter and patches titles "[PATCH V2 mlx5-next 0/2]".
>
> It is ok you applied those patches to net-next this time, but for
> next
> time I would like to apply them myself to mlx5-next and send a clean
> pull request later to both rdma and net trees.
>
Sorry please ignore, I just saw that this was sorted out .. :).
Thanks A lot !
> Is there a way for me to mark them as delegated in patchwork ?
> I see that i have "update Properties" option in patchwork but i don't
> know how to use it or whether I am allowed to do anything with it.
>
It would be great if we can mark such patches in patchwork though..
> Thanks,
> Saeed.
^ permalink raw reply
* [PATCH 00/20] Netfilter/IPVS updates for net-next
From: Pablo Neira Ayuso @ 2018-06-02 0:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter/IPVS updates for your net-next
tree, the most relevant things in this batch are:
1) Compile masquerade infrastructure into NAT module, from Florian Westphal.
Same thing with the redirection support.
2) Abort transaction if early initialization of the commit phase fails.
Also from Florian.
3) Get rid of synchronize_rcu() by using rule array in nf_tables, from
Florian.
4) Abort nf_tables batch if fatal signal is pending, from Florian.
5) Use .call_rcu nfnetlink from nf_tables to make dumps fully lockless.
From Florian Westphal.
6) Support to match transparent sockets from nf_tables, from Máté Eckl.
7) Audit support for nf_tables, from Phil Sutter.
8) Validate chain dependencies from commit phase, fall back to fine grain
validation only in case of errors.
9) Attach dst to skbuff from netfilter flowtable packet path, from
Jason A. Donenfeld.
10) Use artificial maximum attribute cap to remove VLA from nfnetlink.
Patch from Kees Cook.
11) Add extension to allow to forward packets through neighbour layer.
12) Add IPv6 conntrack helper support to IPVS, from Julian Anastasov.
13) Add IPv6 FTP conntrack support to IPVS, from Julian Anastasov.
Plus patches including small incremental improvements.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Thanks.
----------------------------------------------------------------
The following changes since commit 5b79c2af667c0e2684f2a6dbf6439074b78f490c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-05-26 19:46:15 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git HEAD
for you to fetch changes up to d12e12299a6915fc10131602cca41170e46ae755:
ipvs: add ipv6 support to ftp (2018-06-01 14:01:54 +0200)
----------------------------------------------------------------
Florian Westphal (8):
netfilter: nat: merge ipv4/ipv6 masquerade code into main nat module
netfilter: nat: merge nf_nat_redirect into nf_nat
netfilter: nfnetlink: allow commit to fail
netfilter: nf_tables: remove synchronize_rcu in commit phase
netfilter: nft_compat: use call_rcu for nfnl_compat_get
netfilter: nf_tables: fix endian mismatch in return type
netfilter: nf_tables: fail batch if fatal signal is pending
netfilter: nf_tables: use call_rcu in netlink dumps
Jason A. Donenfeld (1):
netfilter: nf_flow_table: attach dst to skbs
Julian Anastasov (2):
ipvs: add full ipv6 support to nfct
ipvs: add ipv6 support to ftp
Kees Cook (1):
netfilter: nfnetlink: Remove VLA usage
Máté Eckl (2):
netfilter: add includes to nf_socket.h
netfilter: nf_tables: add support for native socket matching
Pablo Neira Ayuso (2):
netfilter: nf_tables: fix chain dependency validation
netfilter: nft_fwd_netdev: allow to forward packets via neighbour layer
Phil Sutter (1):
netfilter: nf_tables: Add audit support to log statement
Taehee Yoo (1):
netfilter: nf_tables: remove unused variables
Wei Yongjun (1):
netfilter: nat: make symbol nat_hook static
kbuild test robot (1):
netfilter: fix ptr_ret.cocci warnings
include/linux/netfilter/nfnetlink.h | 1 +
include/net/ip_vs.h | 10 +-
include/net/netfilter/nf_socket.h | 6 +-
include/net/netfilter/nf_tables.h | 7 +
include/net/netfilter/nf_tables_core.h | 8 +
include/net/netns/nftables.h | 1 +
include/uapi/linux/netfilter/nf_tables.h | 34 ++
net/ipv4/netfilter/Kconfig | 5 +-
net/ipv4/netfilter/Makefile | 4 +-
net/ipv4/netfilter/nf_nat_masquerade_ipv4.c | 4 -
net/ipv6/netfilter/Kconfig | 5 +-
net/ipv6/netfilter/Makefile | 2 +-
net/ipv6/netfilter/nf_nat_masquerade_ipv6.c | 4 -
net/netfilter/Kconfig | 15 +-
net/netfilter/Makefile | 3 +-
net/netfilter/ipvs/ip_vs_app.c | 24 +-
net/netfilter/ipvs/ip_vs_ftp.c | 467 +++++++++++++++++----------
net/netfilter/ipvs/ip_vs_nfct.c | 101 +++---
net/netfilter/ipvs/ip_vs_proto_sctp.c | 4 +-
net/netfilter/ipvs/ip_vs_proto_tcp.c | 4 +-
net/netfilter/ipvs/ip_vs_proto_udp.c | 4 +-
net/netfilter/nf_flow_table_ip.c | 6 +-
net/netfilter/nf_nat_core.c | 2 +-
net/netfilter/nf_nat_redirect.c | 4 -
net/netfilter/nf_tables_api.c | 469 +++++++++++++++++++++++-----
net/netfilter/nf_tables_core.c | 40 +--
net/netfilter/nfnetlink.c | 44 ++-
net/netfilter/nft_compat.c | 29 +-
net/netfilter/nft_fwd_netdev.c | 146 ++++++++-
net/netfilter/nft_hash.c | 10 +-
net/netfilter/nft_immediate.c | 27 +-
net/netfilter/nft_log.c | 92 +++++-
net/netfilter/nft_lookup.c | 47 +++
net/netfilter/nft_numgen.c | 5 +-
net/netfilter/nft_socket.c | 143 +++++++++
35 files changed, 1372 insertions(+), 405 deletions(-)
create mode 100644 net/netfilter/nft_socket.c
^ permalink raw reply
* [PATCH 01/20] netfilter: add includes to nf_socket.h
From: Pablo Neira Ayuso @ 2018-06-02 0:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180602002259.4024-1-pablo@netfilter.org>
From: Máté Eckl <ecklm94@gmail.com>
These have to be included always when nf_socket.h is included.
Signed-off-by: Máté Eckl <ecklm94@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/netfilter/nf_socket.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/net/netfilter/nf_socket.h b/include/net/netfilter/nf_socket.h
index 8230fefff9f5..29b6313f0557 100644
--- a/include/net/netfilter/nf_socket.h
+++ b/include/net/netfilter/nf_socket.h
@@ -2,10 +2,8 @@
#ifndef _NF_SOCK_H_
#define _NF_SOCK_H_
-struct net_device;
-struct sk_buff;
-struct sock;
-struct net;
+#include <net/sock.h>
+#include <net/inet_timewait_sock.h>
static inline bool nf_sk_is_transparent(struct sock *sk)
{
--
2.11.0
^ permalink raw reply related
* [PATCH 03/20] netfilter: nat: merge nf_nat_redirect into nf_nat
From: Pablo Neira Ayuso @ 2018-06-02 0:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180602002259.4024-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
Similar to previous patch, this time, merge redirect+nat.
The redirect module is just 2k in size, get rid of it and make
redirect part available from the nat core.
before:
text data bss dec hex filename
19461 1484 4138 25083 61fb net/netfilter/nf_nat.ko
1236 792 0 2028 7ec net/netfilter/nf_nat_redirect.ko
after:
20340 1508 4138 25986 6582 net/netfilter/nf_nat.ko
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/Kconfig | 6 +-----
net/netfilter/Makefile | 2 +-
net/netfilter/nf_nat_redirect.c | 4 ----
3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index a5b60e6a983e..3ec8886850b2 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -433,11 +433,7 @@ config NF_NAT_TFTP
default NF_NAT && NF_CONNTRACK_TFTP
config NF_NAT_REDIRECT
- tristate "IPv4/IPv6 redirect support"
- depends on NF_NAT
- help
- This is the kernel functionality to redirect packets to local
- machine through NAT.
+ bool
config NETFILTER_SYNPROXY
tristate
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 1aa710b5d384..9b3434360d49 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_NF_LOG_COMMON) += nf_log_common.o
obj-$(CONFIG_NF_LOG_NETDEV) += nf_log_netdev.o
obj-$(CONFIG_NF_NAT) += nf_nat.o
-obj-$(CONFIG_NF_NAT_REDIRECT) += nf_nat_redirect.o
+nf_nat-$(CONFIG_NF_NAT_REDIRECT) += nf_nat_redirect.o
# NAT helpers
obj-$(CONFIG_NF_NAT_AMANDA) += nf_nat_amanda.o
diff --git a/net/netfilter/nf_nat_redirect.c b/net/netfilter/nf_nat_redirect.c
index 7c4bb0a773ca..adee04af8d43 100644
--- a/net/netfilter/nf_nat_redirect.c
+++ b/net/netfilter/nf_nat_redirect.c
@@ -15,7 +15,6 @@
#include <linux/inetdevice.h>
#include <linux/ip.h>
#include <linux/kernel.h>
-#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/netfilter.h>
#include <linux/types.h>
@@ -124,6 +123,3 @@ nf_nat_redirect_ipv6(struct sk_buff *skb, const struct nf_nat_range2 *range,
return nf_nat_setup_info(ct, &newrange, NF_NAT_MANIP_DST);
}
EXPORT_SYMBOL_GPL(nf_nat_redirect_ipv6);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Patrick McHardy <kaber@trash.net>");
--
2.11.0
^ permalink raw reply related
* [PATCH 04/20] netfilter: nfnetlink: allow commit to fail
From: Pablo Neira Ayuso @ 2018-06-02 0:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180602002259.4024-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
->commit() cannot fail at the moment.
Followup-patch adds kmalloc calls in the commit phase, so we'll need
to be able to handle errors.
Make it so that -EGAIN causes a full replay, and make other errors
cause the transaction to fail.
Failing is ok from a consistency point of view as long as we
perform all actions that could return an error before
we increment the generation counter and the base seq.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nfnetlink.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 03ead8a9e90c..88c9e222b670 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -441,7 +441,14 @@ static void nfnetlink_rcv_batch(struct sk_buff *skb, struct nlmsghdr *nlh,
kfree_skb(skb);
goto replay;
} else if (status == NFNL_BATCH_DONE) {
- ss->commit(net, oskb);
+ err = ss->commit(net, oskb);
+ if (err == -EAGAIN) {
+ status |= NFNL_BATCH_REPLAY;
+ goto done;
+ } else if (err) {
+ ss->abort(net, oskb);
+ netlink_ack(oskb, nlmsg_hdr(oskb), err, NULL);
+ }
} else {
ss->abort(net, oskb);
}
--
2.11.0
^ 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