* [iproute2-next v3 1/2] tipc: JSON support for showing nametable
From: Hoang Le @ 2018-06-12 2:32 UTC (permalink / raw)
To: netdev, tipc-discussion
Add json output support for nametable show
Example output:
$tipc -j -p nametable show
[ {
"type": 0,
"lower": 16781313,
"upper": 16781313,
"scope": "zone",
"port": 0,
"node": ""
},{
"type": 0,
"lower": 16781416,
"upper": 16781416,
"scope": "cluster",
"port": 0,
"node": ""
} ]
v2:
Replace variable 'json_flag' by 'json' declared in include/utils.h
Add new parameter '-pretty' to support pretty output
v3:
Update manual page
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
---
man/man8/tipc-nametable.8 | 10 ++++++++++
man/man8/tipc.8 | 9 +++++++++
tipc/nametable.c | 31 ++++++++++++++++++++++---------
tipc/tipc.c | 20 +++++++++++++++++++-
4 files changed, 60 insertions(+), 10 deletions(-)
diff --git a/man/man8/tipc-nametable.8 b/man/man8/tipc-nametable.8
index 4bcefe47f6b1..b187d25e1e1f 100644
--- a/man/man8/tipc-nametable.8
+++ b/man/man8/tipc-nametable.8
@@ -18,6 +18,16 @@ tipc-nametable \- show TIPC nametable
Options (flags) that can be passed anywhere in the command chain.
.TP
.BR "\-h" , " --help"
+
+.TP
+.BR "\-j", " \-json"
+Output results in JavaScript Object Notation (JSON).
+
+.TP
+.BR "\-p", " \-pretty"
+The default JSON format is compact and more efficient to parse but hard for most users to read.
+This flag adds indentation for readability.
+
Show help about last valid command. For example
.B tipc nametable --help
will show nametable help and
diff --git a/man/man8/tipc.8 b/man/man8/tipc.8
index 32943fa50b23..6706cca12427 100644
--- a/man/man8/tipc.8
+++ b/man/man8/tipc.8
@@ -40,6 +40,15 @@ will show bearer help and
.B tipc --help
will show general help. The position of the option in the string is irrelevant.
+.TP
+.BR "\-j", " \-json"
+Output results in JavaScript Object Notation (JSON).
+
+.TP
+.BR "\-p", " \-pretty"
+The default JSON format is compact and more efficient to parse but hard for most users to read.
+This flag adds indentation for readability.
+
.SH COMMANDS
.TP
diff --git a/tipc/nametable.c b/tipc/nametable.c
index ae73dfa5f8b9..eb4bd0bda835 100644
--- a/tipc/nametable.c
+++ b/tipc/nametable.c
@@ -21,6 +21,7 @@
#include "msg.h"
#include "nametable.h"
#include "misc.h"
+#include "utils.h"
#define PORTID_STR_LEN 45 /* Four u32 and five delimiter chars */
@@ -46,7 +47,7 @@ static int nametable_show_cb(const struct nlmsghdr *nlh, void *data)
if (!publ[TIPC_NLA_NAME_TABLE_PUBL])
return MNL_CB_ERROR;
- if (!*iteration)
+ if (!*iteration && !is_json_context())
printf("%-10s %-10s %-10s %-8s %-10s %-33s\n",
"Type", "Lower", "Upper", "Scope", "Port",
"Node");
@@ -54,13 +55,20 @@ static int nametable_show_cb(const struct nlmsghdr *nlh, void *data)
hash2nodestr(mnl_attr_get_u32(publ[TIPC_NLA_PUBL_NODE]), str);
- printf("%-10u %-10u %-10u %-8s %-10u %s\n",
- mnl_attr_get_u32(publ[TIPC_NLA_PUBL_TYPE]),
- mnl_attr_get_u32(publ[TIPC_NLA_PUBL_LOWER]),
- mnl_attr_get_u32(publ[TIPC_NLA_PUBL_UPPER]),
- scope[mnl_attr_get_u32(publ[TIPC_NLA_PUBL_SCOPE])],
- mnl_attr_get_u32(publ[TIPC_NLA_PUBL_REF]),
- str);
+ open_json_object(NULL);
+ print_uint(PRINT_ANY, "type", "%-10u",
+ mnl_attr_get_u32(publ[TIPC_NLA_PUBL_TYPE]));
+ print_uint(PRINT_ANY, "lower", "%-10u",
+ mnl_attr_get_u32(publ[TIPC_NLA_PUBL_LOWER]));
+ print_uint(PRINT_ANY, "upper", "%-10u",
+ mnl_attr_get_u32(publ[TIPC_NLA_PUBL_UPPER]));
+ print_string(PRINT_ANY, "scope", "%-8s",
+ scope[mnl_attr_get_u32(publ[TIPC_NLA_PUBL_SCOPE])]);
+ print_uint(PRINT_ANY, "port", "%-10u",
+ mnl_attr_get_u32(publ[TIPC_NLA_PUBL_REF]));
+ print_string(PRINT_ANY, "node", "%s", str);
+ print_string(PRINT_FP, NULL, "\n", "");
+ close_json_object();
return MNL_CB_OK;
}
@@ -70,6 +78,7 @@ static int cmd_nametable_show(struct nlmsghdr *nlh, const struct cmd *cmd,
{
int iteration = 0;
char buf[MNL_SOCKET_BUFFER_SIZE];
+ int rc = 0;
if (help_flag) {
fprintf(stderr, "Usage: %s nametable show\n", cmdl->argv[0]);
@@ -81,7 +90,11 @@ static int cmd_nametable_show(struct nlmsghdr *nlh, const struct cmd *cmd,
return -1;
}
- return msg_dumpit(nlh, nametable_show_cb, &iteration);
+ new_json_obj(json);
+ rc = msg_dumpit(nlh, nametable_show_cb, &iteration);
+ delete_json_obj();
+
+ return rc;
}
void cmd_nametable_help(struct cmdl *cmdl)
diff --git a/tipc/tipc.c b/tipc/tipc.c
index 600d5e2a160f..f85ddee0e278 100644
--- a/tipc/tipc.c
+++ b/tipc/tipc.c
@@ -24,6 +24,8 @@
#include "cmdl.h"
int help_flag;
+int json;
+int pretty;
static void about(struct cmdl *cmdl)
{
@@ -33,6 +35,8 @@ static void about(struct cmdl *cmdl)
"\n"
"Options:\n"
" -h, --help \t\tPrint help for last given command\n"
+ " -j, --json \t\tJson format printouts\n"
+ " -p, --pretty \t\tpretty print\n"
"\n"
"Commands:\n"
" bearer - Show or modify bearers\n"
@@ -53,6 +57,8 @@ int main(int argc, char *argv[])
const struct cmd cmd = {"tipc", NULL, about};
struct option long_options[] = {
{"help", no_argument, 0, 'h'},
+ {"json", no_argument, 0, 'j'},
+ {"pretty", no_argument, 0, 'p'},
{0, 0, 0, 0}
};
const struct cmd cmds[] = {
@@ -69,7 +75,7 @@ int main(int argc, char *argv[])
do {
int option_index = 0;
- i = getopt_long(argc, argv, "h", long_options, &option_index);
+ i = getopt_long(argc, argv, "hjp", long_options, &option_index);
switch (i) {
case 'h':
@@ -79,6 +85,18 @@ int main(int argc, char *argv[])
*/
help_flag = 1;
break;
+ case 'j':
+ /*
+ * Enable json format printouts
+ */
+ json = 1;
+ break;
+ case 'p':
+ /*
+ * Enable json pretty output
+ */
+ pretty = 1;
+ break;
case -1:
/* End of options */
break;
--
2.7.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* linux-next: build failure in Linus' tree
From: Stephen Rothwell @ 2018-06-12 2:26 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Miller,
Networking, Michael Ellerman, Benjamin Herrenschmidt, PowerPC
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hi all,
Building Linus' tree, today's linux-next build (powerpc allyesconfig)
failed like this:
ld: net/bpfilter/bpfilter_umh.o: compiled for a little endian system and target is big endian
ld: failed to merge target specific data of file net/bpfilter/bpfilter_umh.o
This has come to light since I started using a native compiler (i.e. one
that can build executables, not just the kernel) for my PowerPC builds
on a powerpcle host.
I have switched back to my limited compiler.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Michael S. Tsirkin @ 2018-06-12 2:17 UTC (permalink / raw)
To: Jason Wang
Cc: Sridhar Samudrala, alexander.h.duyck, virtio-dev, qemu-devel,
jiri, kubakici, netdev, jesse.brandeburg, virtualization,
loseweigh, aaron.f.brown
In-Reply-To: <dc8b1669-b8b6-fb59-94e2-6e4de6b96572@redhat.com>
On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote:
>
>
> On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
> > On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote:
> > > This feature bit can be used by hypervisor to indicate virtio_net device to
> > > act as a standby for another device with the same MAC address.
> > >
> > > I tested this with a small change to the patch to mark the STANDBY feature 'true'
> > > by default as i am using libvirt to start the VMs.
> > > Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
> > > XML file?
> > >
> > > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> > So I do not think we can commit to this interface: we
> > really need to control visibility of the primary device.
>
> The problem is legacy guest won't use primary device at all if we do this.
And that's by design - I think it's the only way to ensure the
legacy guest isn't confused.
> How about control the visibility of standby device?
>
> Thanks
standy the always there to guarantee no downtime.
> > However just for testing purposes, we could add a non-stable
> > interface "x-standby" with the understanding that as any
> > x- prefix it's unstable and will be changed down the road,
> > likely in the next release.
> >
> >
> > > ---
> > > hw/net/virtio-net.c | 2 ++
> > > include/standard-headers/linux/virtio_net.h | 3 +++
> > > 2 files changed, 5 insertions(+)
> > >
> > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > index 90502fca7c..38b3140670 100644
> > > --- a/hw/net/virtio-net.c
> > > +++ b/hw/net/virtio-net.c
> > > @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
> > > true),
> > > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
> > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
> > > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY,
> > > + false),
> > > DEFINE_PROP_END_OF_LIST(),
> > > };
> > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
> > > index e9f255ea3f..01ec09684c 100644
> > > --- a/include/standard-headers/linux/virtio_net.h
> > > +++ b/include/standard-headers/linux/virtio_net.h
> > > @@ -57,6 +57,9 @@
> > > * Steering */
> > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > > +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
> > > + * with the same MAC.
> > > + */
> > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
> > > #ifndef VIRTIO_NET_NO_LEGACY
> > > --
> > > 2.14.3
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Michael S. Tsirkin @ 2018-06-12 2:14 UTC (permalink / raw)
To: Siwei Liu
Cc: Jakub Kicinski, Stephen Hemminger, Jiri Pirko, kys, haiyangz,
David Miller, Samudrala, Sridhar, Netdev, Stephen Hemminger
In-Reply-To: <CADGSJ23Pb-hQkrV8ogvC7kAGGMfU9DTW_JGkzmGrmLvx6Esu_w@mail.gmail.com>
On Mon, Jun 11, 2018 at 11:56:56AM -0700, Siwei Liu wrote:
> The current implementation may only work with new userspace, even so
> the eth0/eth0nsby naming is not consistenly persisted due to races in
> bus probing.
Which race do you mean exactly?
--
MST
^ permalink raw reply
* [PATCH iproute2-next] ip-xfrm: Add support for OUTPUT_MARK
From: Subash Abhinov Kasiviswanathan @ 2018-06-12 2:11 UTC (permalink / raw)
To: lorenzo, netdev, stephen, dsahern; +Cc: Subash Abhinov Kasiviswanathan
This patch adds support for OUTPUT_MARK in xfrm state to exercise the
functionality added by kernel commit 077fbac405bf
("net: xfrm: support setting an output mark.").
Sample output with output-mark -
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0x00004321 reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
output-mark 0x20000
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
ip/ipxfrm.c | 5 +++++
ip/xfrm_state.c | 9 +++++++++
man/man8/ip-xfrm.8 | 2 ++
3 files changed, 16 insertions(+)
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index 12c2f72..601f9b8 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -956,6 +956,11 @@ void xfrm_state_info_print(struct xfrm_usersa_info *xsinfo,
fprintf(fp, "%s %s", (char *)(sctx + 1), _SL_);
}
+ if (tb[XFRMA_OUTPUT_MARK]) {
+ __u32 output_mark = rta_getattr_u32(tb[XFRMA_OUTPUT_MARK]);
+
+ fprintf(fp, "\toutput-mark 0x%x %s", output_mark, _SL_);
+ }
}
void xfrm_policy_info_print(struct xfrm_userpolicy_info *xpinfo,
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index 85d959c..d005802 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -61,6 +61,7 @@ static void usage(void)
fprintf(stderr, " [ flag FLAG-LIST ] [ sel SELECTOR ] [ LIMIT-LIST ] [ encap ENCAP ]\n");
fprintf(stderr, " [ coa ADDR[/PLEN] ] [ ctx CTX ] [ extra-flag EXTRA-FLAG-LIST ]\n");
fprintf(stderr, " [ offload [dev DEV] dir DIR ]\n");
+ fprintf(stderr, " [ output-mark OUTPUT-MARK]\n");
fprintf(stderr, "Usage: ip xfrm state allocspi ID [ mode MODE ] [ mark MARK [ mask MASK ] ]\n");
fprintf(stderr, " [ reqid REQID ] [ seq SEQ ] [ min SPI max SPI ]\n");
fprintf(stderr, "Usage: ip xfrm state { delete | get } ID [ mark MARK [ mask MASK ] ]\n");
@@ -322,6 +323,7 @@ static int xfrm_state_modify(int cmd, unsigned int flags, int argc, char **argv)
struct xfrm_user_sec_ctx sctx;
char str[CTX_BUF_SIZE];
} ctx = {};
+ __u32 output_mark = 0;
while (argc > 0) {
if (strcmp(*argv, "mode") == 0) {
@@ -437,6 +439,10 @@ static int xfrm_state_modify(int cmd, unsigned int flags, int argc, char **argv)
invarg("value after \"offload dir\" is invalid", *argv);
is_offload = false;
}
+ } else if (strcmp(*argv, "output-mark") == 0) {
+ NEXT_ARG();
+ if (get_u32(&output_mark, *argv, 0))
+ invarg("value after \"output-mark\" is invalid", *argv);
} else {
/* try to assume ALGO */
int type = xfrm_algotype_getbyname(*argv);
@@ -720,6 +726,9 @@ static int xfrm_state_modify(int cmd, unsigned int flags, int argc, char **argv)
}
}
+ if (output_mark != 0)
+ addattr32(&req.n, sizeof(req.buf), XFRMA_OUTPUT_MARK, output_mark);
+
if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0)
exit(1);
diff --git a/man/man8/ip-xfrm.8 b/man/man8/ip-xfrm.8
index 988cc6a..e001596 100644
--- a/man/man8/ip-xfrm.8
+++ b/man/man8/ip-xfrm.8
@@ -59,6 +59,8 @@ ip-xfrm \- transform configuration
.IR CTX " ]"
.RB "[ " extra-flag
.IR EXTRA-FLAG-LIST " ]"
+.RB "[ " output-mark
+.IR OUTPUT-MARK " ]"
.ti -8
.B "ip xfrm state allocspi"
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] net: qcom/emac: Add missing of_node_put()
From: Timur Tabi @ 2018-06-12 2:03 UTC (permalink / raw)
To: YueHaibing, davem; +Cc: linux-kernel, netdev
In-Reply-To: <20180611130345.15172-1-yuehaibing@huawei.com>
On 6/11/18 8:03 AM, YueHaibing wrote:
> Add missing of_node_put() call for device node returned by
> of_parse_phandle().
Hmmmm... This shouldn't be necessary. I was very careful with calls to
of_node_put(). Give me a day or two to confirm, please.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH bpf v2] tools/bpftool: fix a bug in bpftool perf
From: Yonghong Song @ 2018-06-12 2:01 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whether bpf subcommand
BPF_TASK_FD_QUERY is supported in kernel or not. It does it
by opening a file with argv[0] and feeds the file descriptor
and current task pid to the kernel for querying.
Such an approach won't work if the argv[0] cannot be opened
successfully in the current directory. This is especially
true when bpftool is accessible through PATH env variable.
The error below reflects the open failure for file argv[0]
at home directory.
[yhs@localhost ~]$ which bpftool
/usr/local/sbin/bpftool
[yhs@localhost ~]$ bpftool perf
Error: perf_query_support: No such file or directory
To fix the issue, let us open root directory ("/")
which exists in every linux system. With the fix, the
error message will correctly reflect the permission issue.
[yhs@localhost ~]$ which bpftool
/usr/local/sbin/bpftool
[yhs@localhost ~]$ bpftool perf
Error: perf_query_support: Operation not permitted
HINT: non root or kernel doesn't support TASK_FD_QUERY
Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/bpf/bpftool/perf.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Changelogs:
v1 -> v2:
. remove '\n' in the p_err format string in order to
have valid json output.
diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
index ac6b1a12c9b7..239715aa6fb9 100644
--- a/tools/bpf/bpftool/perf.c
+++ b/tools/bpf/bpftool/perf.c
@@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
if (perf_query_supported)
goto out;
- fd = open(bin_name, O_RDONLY);
- if (fd < 0) {
- p_err("perf_query_support: %s", strerror(errno));
+ fd = open("/", O_RDONLY);
+ if (fd > 0) {
+ p_err("perf_query_support: cannot open directory \"/\" (%s)",
+ strerror(errno));
goto out;
}
--
2.14.3
^ permalink raw reply related
* Re: [PULL] vhost: cleanups and fixes
From: Linus Torvalds @ 2018-06-12 1:59 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: KVM list, Network Development, Linux Kernel Mailing List,
Bjorn Andersson, Andrew Morton, virtualization
In-Reply-To: <20180612042600-mutt-send-email-mst@kernel.org>
On Mon, Jun 11, 2018 at 6:36 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> Maybe it will help to have GFP_NONE which will make any allocation
> fail if attempted. Linus, would this address your comment?
It would definitely have helped me initially overlook that call chain.
But then when I started looking at the whole dma_map_page() thing, it
just raised my hackles again.
I would seriously suggest having a much simpler version for the "no
allocation, no dma mapping" case, so that it's *obvious* that that
never happens.
So instead of having virtio_balloon_send_free_pages() call a really
generic complex chain of functions that in _some_ cases can do memory
allocation, why isn't there a short-circuited "vitruque_add_datum()"
that is guaranteed to never do anything like that?
Honestly, I look at "add_one_sg()" and it really doesn't make me
happy. It looks hacky as hell. If I read the code right, you're really
trying to just queue up a simple tuple of <pfn,len>, except you encode
it as a page pointer in order to play games with the SG logic, and
then you hmap that to the ring, except in this case it's all a fake
ring that just adds the cpu-physical address instead.
And to figuer that out, it's like five layers of indirection through
different helper functions that *can* do more generic things but in
this case don't.
And you do all of this from a core VM callback function with some
_really_ core VM locks held.
That makes no sense to me.
How about this:
- get rid of all that code
- make the core VM callback save the "these are the free memory
regions" in a fixed and limited array. One that DOES JUST THAT. No
crazy "SG IO dma-mapping function crap". Just a plain array of a fixed
size, pre-allocated for that virtio instance.
- make it obvious that what you do in that sequence is ten
instructions and no allocations ("Look ma, I wrote a value to an array
and incremented the array idex, and I'M DONE")
- then in that workqueue entry that you start *anyway*, you empty the
array and do all the crazy virtio stuff.
In fact, while at it, just simplify the VM interface too. Instead of
traversing a random number of buddy lists, just trraverse *one* - the
top-level one. Are you seriously ever going to shrink or mark
read-only anythin *but* something big enough to be in the maximum
order?
MAX_ORDER is what, 11? So we're talking 8MB blocks. Do you *really*
want the balloon code to work on smaller things, particularly since
the whole interface is fundamentally racy and opportunistic to begin
with?
The whole sequence of events really looks "this is too much
complexity, and way too fragile" to me at so many levels.
Linus
^ permalink raw reply
* Re: [PULL] vhost: cleanups and fixes
From: Michael S. Tsirkin @ 2018-06-12 1:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: nilal, KVM list, Network Development, Linux Kernel Mailing List,
Bjorn Andersson, Andrew Morton, virtualization
In-Reply-To: <CA+55aFzrPgnd7hRPrkeV+jX-MSwOZf7T4wKxz66Lk4oub3PZsw@mail.gmail.com>
On Mon, Jun 11, 2018 at 11:32:41AM -0700, Linus Torvalds wrote:
> On Mon, Jun 11, 2018 at 9:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>
> Is this really a good idea?
Well knowing which pages are unused does seem to be useful. Do you
refer to this generally or to the idea of scanning the free list,
or to the specific implementation issues you listed below?
> Plus it seems entirely broken.
>
> The report_pfn_range() callback is done under the zone lock, but
> virtio_balloon_send_free_pages() (which is the only callback used that
> I can find) does add_one_sg(), which does virtqueue_add_inbuf(vq, &sg,
> 1, vq, GFP_KERNEL);
>
> So now we apparently do a GFP_KERNEL allocation insider the mm zone
> lock, which is broken on just _so_ many levels.
>
> Pulled and then unpulled again.
>
> Either somebody needs to explain why I'm wrong and you can re-submit
> this, or this kind of garbage needs to go away.
>
> I do *not* want to be in the situation where I pull stuff from the
> virtio people that adds completely broken core VM functionality.
>
> Because if I'm in that situation, I will stop pulling from you guys.
> Seriously. You have *no* place sending me broken shit that is outside
> the virtio layer.
>
> Subsystems that break code MM will get shunned. You just aren't
> important enough to allow you breaking code VM.
>
> Linus
So no, it doesn't do any allocations - GFP_KERNEL or otherwise, but I
agree how it might be confusing.
So I'll drop this for now, but it would be nice if there is a bit more
direction on this feature since I know several people are trying to work
on this.
--
MST
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Jason Wang @ 2018-06-12 1:54 UTC (permalink / raw)
To: Michael S. Tsirkin, Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, qemu-devel, jiri, kubakici, netdev,
jesse.brandeburg, virtualization, loseweigh, aaron.f.brown
In-Reply-To: <20180611202207-mutt-send-email-mst@kernel.org>
On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
> On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote:
>> This feature bit can be used by hypervisor to indicate virtio_net device to
>> act as a standby for another device with the same MAC address.
>>
>> I tested this with a small change to the patch to mark the STANDBY feature 'true'
>> by default as i am using libvirt to start the VMs.
>> Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
>> XML file?
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> So I do not think we can commit to this interface: we
> really need to control visibility of the primary device.
The problem is legacy guest won't use primary device at all if we do this.
How about control the visibility of standby device?
Thanks
> However just for testing purposes, we could add a non-stable
> interface "x-standby" with the understanding that as any
> x- prefix it's unstable and will be changed down the road,
> likely in the next release.
>
>
>> ---
>> hw/net/virtio-net.c | 2 ++
>> include/standard-headers/linux/virtio_net.h | 3 +++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>> index 90502fca7c..38b3140670 100644
>> --- a/hw/net/virtio-net.c
>> +++ b/hw/net/virtio-net.c
>> @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
>> true),
>> DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
>> DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
>> + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY,
>> + false),
>> DEFINE_PROP_END_OF_LIST(),
>> };
>>
>> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
>> index e9f255ea3f..01ec09684c 100644
>> --- a/include/standard-headers/linux/virtio_net.h
>> +++ b/include/standard-headers/linux/virtio_net.h
>> @@ -57,6 +57,9 @@
>> * Steering */
>> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>>
>> +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
>> + * with the same MAC.
>> + */
>> #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
>>
>> #ifndef VIRTIO_NET_NO_LEGACY
>> --
>> 2.14.3
^ permalink raw reply
* Re: [PATCH bpf] tools/bpftool: fix a bug in bpftool perf
From: Yonghong Song @ 2018-06-12 1:51 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180611184902.23c13235@cakuba.netronome.com>
On 6/11/18 6:49 PM, Jakub Kicinski wrote:
> On Mon, 11 Jun 2018 18:15:16 -0700, Yonghong Song wrote:
>> Commit b04df400c302 ("tools/bpftool: add perf subcommand")
>> introduced bpftool subcommand perf to query bpf program
>> kuprobe and tracepoint attachments.
>>
>> The perf subcommand will first test whether bpf subcommand
>> BPF_TASK_FD_QUERY is supported in kernel or not. It does it
>> by opening a file with argv[0] and feeds the file descriptor
>> and current task pid to the kernel for querying.
>>
>> Such an approach won't work if the argv[0] cannot be opened
>> successfully in the current directory. This is especially
>> true when bpftool is accessible through PATH env variable.
>> The error below reflects the open failure for file argv[0]
>> at home directory.
>>
>> [yhs@localhost ~]$ which bpftool
>> /usr/local/sbin/bpftool
>> [yhs@localhost ~]$ bpftool perf
>> Error: perf_query_support: No such file or directory
>>
>> To fix the issue, let us open root directory ("/")
>> which exists in every linux system. With the fix, the
>> error message will correctly reflect the permission issue.
>>
>> [yhs@localhost ~]$ which bpftool
>> /usr/local/sbin/bpftool
>> [yhs@localhost ~]$ bpftool perf
>> Error: perf_query_support: Operation not permitted
>> HINT: non root or kernel doesn't support TASK_FD_QUERY
>>
>> Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
>> Reported-by: Alexei Starovoitov <ast@kernel.org>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>> tools/bpf/bpftool/perf.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
>> index ac6b1a12c9b7..f1e4c9b270e2 100644
>> --- a/tools/bpf/bpftool/perf.c
>> +++ b/tools/bpf/bpftool/perf.c
>> @@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
>> if (perf_query_supported)
>> goto out;
>>
>> - fd = open(bin_name, O_RDONLY);
>> - if (fd < 0) {
>> - p_err("perf_query_support: %s", strerror(errno));
>> + fd = open("/", O_RDONLY);
>> + if (fd > 0) {
>> + p_err("perf_query_support: cannot open directory \"/\" (%s)\n",
>
> nit: no \n at the end of p_err() format, because it breaks JSON :(
Thanks for letting me know. Will send v2 to fix this!
>
>> + strerror(errno));
>> goto out;
>> }
>>
>
^ permalink raw reply
* Re: [PATCH bpf] tools/bpftool: fix a bug in bpftool perf
From: Jakub Kicinski @ 2018-06-12 1:49 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180612011516.4171096-1-yhs@fb.com>
On Mon, 11 Jun 2018 18:15:16 -0700, Yonghong Song wrote:
> Commit b04df400c302 ("tools/bpftool: add perf subcommand")
> introduced bpftool subcommand perf to query bpf program
> kuprobe and tracepoint attachments.
>
> The perf subcommand will first test whether bpf subcommand
> BPF_TASK_FD_QUERY is supported in kernel or not. It does it
> by opening a file with argv[0] and feeds the file descriptor
> and current task pid to the kernel for querying.
>
> Such an approach won't work if the argv[0] cannot be opened
> successfully in the current directory. This is especially
> true when bpftool is accessible through PATH env variable.
> The error below reflects the open failure for file argv[0]
> at home directory.
>
> [yhs@localhost ~]$ which bpftool
> /usr/local/sbin/bpftool
> [yhs@localhost ~]$ bpftool perf
> Error: perf_query_support: No such file or directory
>
> To fix the issue, let us open root directory ("/")
> which exists in every linux system. With the fix, the
> error message will correctly reflect the permission issue.
>
> [yhs@localhost ~]$ which bpftool
> /usr/local/sbin/bpftool
> [yhs@localhost ~]$ bpftool perf
> Error: perf_query_support: Operation not permitted
> HINT: non root or kernel doesn't support TASK_FD_QUERY
>
> Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
> Reported-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> tools/bpf/bpftool/perf.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
> index ac6b1a12c9b7..f1e4c9b270e2 100644
> --- a/tools/bpf/bpftool/perf.c
> +++ b/tools/bpf/bpftool/perf.c
> @@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
> if (perf_query_supported)
> goto out;
>
> - fd = open(bin_name, O_RDONLY);
> - if (fd < 0) {
> - p_err("perf_query_support: %s", strerror(errno));
> + fd = open("/", O_RDONLY);
> + if (fd > 0) {
> + p_err("perf_query_support: cannot open directory \"/\" (%s)\n",
nit: no \n at the end of p_err() format, because it breaks JSON :(
> + strerror(errno));
> goto out;
> }
>
^ permalink raw reply
* Re: [PULL] vhost: cleanups and fixes
From: Michael S. Tsirkin @ 2018-06-12 1:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: KVM list, Network Development, Linux Kernel Mailing List,
Bjorn Andersson, Andrew Morton, virtualization
In-Reply-To: <CA+55aFz4uBHaWnBarVUEG90s2ucyVtoLmwYpYVwDV+XQESNRqw@mail.gmail.com>
On Mon, Jun 11, 2018 at 11:44:05AM -0700, Linus Torvalds wrote:
> On Mon, Jun 11, 2018 at 11:32 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So now we apparently do a GFP_KERNEL allocation insider the mm zone
> > lock, which is broken on just _so_ many levels.
>
> Oh, I see the comment about how it doesn't actually do an allocation
> at all because it's a single-entry.
>
> Still too damn ugly to live, and much too fragile. No way in hell do
> we even _hint_ at a GFP_KERNEL when we're inside a context that can't
> do any memory allocation at all.
>
> Plus I'm not convinced it's a "no allocation" path even despite that
> comment, because it also does a "dma_map_page()" etc, which can cause
> allocations to do the dma mapping thing afaik. No?
Well no because DMA is triggered by the IOMMU flag and
that is always off for the balloon. But I hear what you
are saying about it being fragile.
> Maybe there's some reason why that doesn't happen either, but
> basically this whole callchain looks *way* to complicated to be used
> under a core VM spinlock.
>
> Linus
Maybe it will help to have GFP_NONE which will make any allocation
fail if attempted. Linus, would this address your comment?
--
MST
^ permalink raw reply
* Re: [PATCH 1/2] Convert target drivers to use sbitmap
From: Jens Axboe @ 2018-06-12 1:18 UTC (permalink / raw)
To: Matthew Wilcox, linux-kernel, linux-scsi, target-devel,
linux1394-devel, linux-usb, kvm, virtualization, netdev,
Juergen Gross, qla2xxx-upstream, Kent Overstreet
Cc: Matthew Wilcox
In-Reply-To: <3a56027b-47bc-dcb8-a465-3670031572f1@kernel.dk>
On 5/15/18 10:11 AM, Jens Axboe wrote:
> On 5/15/18 10:00 AM, Matthew Wilcox wrote:
>> From: Matthew Wilcox <mawilcox@microsoft.com>
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands. Since the sbitmap is more used than
>> the percpu_ida, convert the percpu_ida users to the sbitmap API.
>
> It should also be the same performance as percpu_ida in light use, and
> performs much better at > 50% utilization of the tag space. I think
> that's better justification than "more used than".
>
>> diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c
>> index 4435bf374d2d..28bcffae609f 100644
>> --- a/drivers/target/iscsi/iscsi_target_util.c
>> +++ b/drivers/target/iscsi/iscsi_target_util.c
>> @@ -17,7 +17,7 @@
>> ******************************************************************************/
>>
>> #include <linux/list.h>
>> -#include <linux/percpu_ida.h>
>> +#include <linux/sched/signal.h>
>> #include <net/ipv6.h> /* ipv6_addr_equal() */
>> #include <scsi/scsi_tcq.h>
>> #include <scsi/iscsi_proto.h>
>> @@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
>> spin_unlock_bh(&cmd->r2t_lock);
>> }
>>
>> +int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
>> +{
>> + int tag = -1;
>> + DEFINE_WAIT(wait);
>> + struct sbq_wait_state *ws;
>> +
>> + if (state == TASK_RUNNING)
>> + return tag;
>> +
>> + ws = &se_sess->sess_tag_pool.ws[0];
>> + for (;;) {
>> + prepare_to_wait_exclusive(&ws->wait, &wait, state);
>> + if (signal_pending_state(state, current))
>> + break;
>> + schedule();
>> + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup);
>> + }
>> +
>> + finish_wait(&ws->wait, &wait);
>> + return tag;
>> +}
>
> Seems like that should be:
>
>
> ws = &se_sess->sess_tag_pool.ws[0];
> for (;;) {
> prepare_to_wait_exclusive(&ws->wait, &wait, state);
> if (signal_pending_state(state, current))
> break;
> tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup);
> if (tag != -1)
> break;
> schedule();
> }
>
> finish_wait(&ws->wait, &wait);
> return tag;
>
>> /*
>> * May be called from software interrupt (timer) context for allocating
>> * iSCSI NopINs.
>> @@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn *conn, int state)
>> {
>> struct iscsi_cmd *cmd;
>> struct se_session *se_sess = conn->sess->se_sess;
>> - int size, tag;
>> + int size, tag, cpu;
>>
>> - tag = percpu_ida_alloc(&se_sess->sess_tag_pool, state);
>> + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, &cpu);
>> + if (tag < 0)
>> + tag = iscsit_wait_for_tag(se_sess, state, &cpu);
>> if (tag < 0)
>> return NULL;
>
> Might make sense to just roll the whole thing into iscsi_get_tag(), that
> would be cleaner.
>
> sbitmap should provide a helper for that, but we can do that cleanup
> later. That would encapsulate things like the per-cpu caching hint too,
> for instance.
>
> Rest looks fine to me.
Are you going to push this further? I really think we should.
--
Jens Axboe
^ permalink raw reply
* [PATCH bpf] tools/bpftool: fix a bug in bpftool perf
From: Yonghong Song @ 2018-06-12 1:15 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whether bpf subcommand
BPF_TASK_FD_QUERY is supported in kernel or not. It does it
by opening a file with argv[0] and feeds the file descriptor
and current task pid to the kernel for querying.
Such an approach won't work if the argv[0] cannot be opened
successfully in the current directory. This is especially
true when bpftool is accessible through PATH env variable.
The error below reflects the open failure for file argv[0]
at home directory.
[yhs@localhost ~]$ which bpftool
/usr/local/sbin/bpftool
[yhs@localhost ~]$ bpftool perf
Error: perf_query_support: No such file or directory
To fix the issue, let us open root directory ("/")
which exists in every linux system. With the fix, the
error message will correctly reflect the permission issue.
[yhs@localhost ~]$ which bpftool
/usr/local/sbin/bpftool
[yhs@localhost ~]$ bpftool perf
Error: perf_query_support: Operation not permitted
HINT: non root or kernel doesn't support TASK_FD_QUERY
Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/bpf/bpftool/perf.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
index ac6b1a12c9b7..f1e4c9b270e2 100644
--- a/tools/bpf/bpftool/perf.c
+++ b/tools/bpf/bpftool/perf.c
@@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
if (perf_query_supported)
goto out;
- fd = open(bin_name, O_RDONLY);
- if (fd < 0) {
- p_err("perf_query_support: %s", strerror(errno));
+ fd = open("/", O_RDONLY);
+ if (fd > 0) {
+ p_err("perf_query_support: cannot open directory \"/\" (%s)\n",
+ strerror(errno));
goto out;
}
--
2.14.3
^ permalink raw reply related
* [PATCH RFC] tcp: Do not reload skb pointer after skb_gro_receive().
From: David Miller @ 2018-06-12 1:00 UTC (permalink / raw)
To: netdev; +Cc: edumazet
This is not necessary. skb_gro_receive() will never change what
'head' points to.
In it's original implementation (see commit 71d93b39e52e ("net: Add
skb_gro_receive")), it did:
====================
+ *head = nskb;
+ nskb->next = p->next;
+ p->next = NULL;
====================
This sequence was removed in commit 58025e46ea2d ("net: gro: remove
obsolete code from skb_gro_receive()")
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index 4d58e2ce0b5b..8cc7c3487330 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -268,8 +268,6 @@ struct sk_buff **tcp_gro_receive(struct sk_buff **head, struct sk_buff *skb)
goto out_check_final;
}
- p = *head;
- th2 = tcp_hdr(p);
tcp_flag_word(th2) |= flags & (TCP_FLAG_FIN | TCP_FLAG_PSH);
out_check_final:
^ permalink raw reply related
* Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 5/7] net: Add generic ndo_select_queue functions
From: Alexander Duyck @ 2018-06-12 0:52 UTC (permalink / raw)
To: kbuild test robot, Jeff Kirsher
Cc: Alexander Duyck, Netdev, intel-wired-lan, kbuild-all
In-Reply-To: <201806120507.3D5zIr3A%fengguang.wu@intel.com>
Jeff,
Looks like I have some bugs on non-x86 architecture. I need to address
these in a v2 of this set so please hold off on applying until I can
get that submitted either tonight or tomorrow morning.
Thanks.
- Alex
On Mon, Jun 11, 2018 at 4:10 PM, kbuild test robot <lkp@intel.com> wrote:
> Hi Alexander,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on net-next/master]
> [also build test ERROR on next-20180608]
> [cannot apply to v4.17]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Alexander-Duyck/Add-support-for-L2-Fwd-Offload-w-o-ndo_select_queue/20180612-015220
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
>>> drivers/net//ethernet/ti/netcp_core.c:1968:22: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .ndo_select_queue = dev_pick_tx_zero,
> ^~~~~~~~~~~~~~~~
> drivers/net//ethernet/ti/netcp_core.c:1968:22: note: (near initialization for 'netcp_netdev_ops.ndo_select_queue')
> cc1: some warnings being treated as errors
>
> vim +1968 drivers/net//ethernet/ti/netcp_core.c
>
> 1955
> 1956 static const struct net_device_ops netcp_netdev_ops = {
> 1957 .ndo_open = netcp_ndo_open,
> 1958 .ndo_stop = netcp_ndo_stop,
> 1959 .ndo_start_xmit = netcp_ndo_start_xmit,
> 1960 .ndo_set_rx_mode = netcp_set_rx_mode,
> 1961 .ndo_do_ioctl = netcp_ndo_ioctl,
> 1962 .ndo_get_stats64 = netcp_get_stats,
> 1963 .ndo_set_mac_address = eth_mac_addr,
> 1964 .ndo_validate_addr = eth_validate_addr,
> 1965 .ndo_vlan_rx_add_vid = netcp_rx_add_vid,
> 1966 .ndo_vlan_rx_kill_vid = netcp_rx_kill_vid,
> 1967 .ndo_tx_timeout = netcp_ndo_tx_timeout,
>> 1968 .ndo_select_queue = dev_pick_tx_zero,
> 1969 .ndo_setup_tc = netcp_setup_tc,
> 1970 };
> 1971
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: pull-request: bpf 2018-06-12
From: David Miller @ 2018-06-12 0:39 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180611235956.6040-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 12 Jun 2018 01:59:56 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Avoid an allocation warning in AF_XDP by adding __GFP_NOWARN for the
> umem setup, from Björn.
>
> 2) Silence a warning in bpf fs when an application tries to open(2) a
> pinned bpf obj due to missing fops. Add a dummy open fop that continues
> to just bail out in such case, from Daniel.
>
> 3) Fix a BPF selftest urandom_read build issue where gcc complains that
> it gets built twice, from Anders.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [net 0/5][pull request] Intel Wired LAN Driver Updates 2018-06-11
From: David Miller @ 2018-06-12 0:30 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180611161630.21338-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 11 Jun 2018 09:16:25 -0700
> This series contains fixes to ixgbe IPsec and MACVLAN.
>
> Alex provides the 5 fixes in this series, starting with fixing an issue
> where num_rx_pools was not being populated until after the queues and
> interrupts were reinitialized when enabling MACVLAN interfaces. Updated
> to use CONFIG_XFRM_OFFLOAD instead of CONFIG_XFRM, since the code
> requires CONFIG_XFRM_OFFLOAD to be enabled. Moved the IPsec
> initialization function to be more consistent with the placement of
> similar initialization functions and before the call to reset the
> hardware, which will clean up any link issues that may have been
> introduced. Fixed the boolean logic that was testing for transmit OR
> receive ready bits, when it should have been testing for transmit AND
> receive ready bits. Fixed the bit definitions for SECTXSTAT and SECRXSTAT
> registers and ensure that if IPsec is disabled on the part, do not
> enable it.
>
> The following are changes since commit f0dc7f9c6dd99891611fca5849cbc4c6965b690e:
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 10GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Samudrala, Sridhar @ 2018-06-12 0:08 UTC (permalink / raw)
To: Michael S. Tsirkin, Stephen Hemminger
Cc: kys, haiyangz, davem, netdev, Stephen Hemminger
In-Reply-To: <04210bba-f67a-dd10-cdce-c7d140dcecbe@intel.com>
On 6/11/2018 12:34 PM, Samudrala, Sridhar wrote:
>
> On 6/11/2018 11:10 AM, Michael S. Tsirkin wrote:
>> On Mon, Jun 04, 2018 at 08:42:31PM -0700, Stephen Hemminger wrote:
>>> * Set permanent and current address of net_failover device
>>> to match the primary.
We copy the dev_addr of standby dev to failover_dev in net_failover_create()
before calling register_netdev().
register_netdev() does a copy of dev_addr to perm_addr.
So i don't think this is an issue.
>>>
>>> * Carrier should be marked off before registering device
>>> the net_failover device.
Will fix this and also a couple of places dev_err() needs to be replaced with netdev_err()
>> Sridhar, do we want to address this?
>> If yes, could you please take a look at addressing these
>> meanwhile, while we keep arguing about making API changes?
>
> Sure. I will submit patches to address these issues raised by Stephen.
>
>
^ permalink raw reply
* pull-request: bpf 2018-06-12
From: Daniel Borkmann @ 2018-06-11 23:59 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Avoid an allocation warning in AF_XDP by adding __GFP_NOWARN for the
umem setup, from Björn.
2) Silence a warning in bpf fs when an application tries to open(2) a
pinned bpf obj due to missing fops. Add a dummy open fop that continues
to just bail out in such case, from Daniel.
3) Fix a BPF selftest urandom_read build issue where gcc complains that
it gets built twice, from Anders.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 66e58e0ef80a56a1d7857b6ce121141563cdd93e:
bpfilter: fix race in pipe access (2018-06-07 20:07:28 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to a343993c518ce252b62ec00ac06bccfb1d17129d:
xsk: silence warning on memory allocation failure (2018-06-11 23:49:07 +0200)
----------------------------------------------------------------
Anders Roxell (1):
selftests: bpf: fix urandom_read build issue
Björn Töpel (1):
xsk: silence warning on memory allocation failure
Daniel Borkmann (1):
bpf: implement dummy fops for bpf objects
kernel/bpf/inode.c | 14 ++++++++++++--
net/xdp/xdp_umem.c | 3 ++-
tools/testing/selftests/bpf/Makefile | 4 +---
3 files changed, 15 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH v2 net-next] vlan: implement vlan id and protocol changes
From: Chas Williams @ 2018-06-11 23:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Chas Williams
In-Reply-To: <20180610231912.1543-1-3chas3@gmail.com>
vlan_changelink silently ignores attempts to change the vlan id
or protocol id of an existing vlan interface. Implement by adding
the new vlan id and protocol to the interface's vlan group and then
removing the old vlan id and protocol from the vlan group.
Signed-off-by: Chas Williams <3chas3@gmail.com>
---
include/linux/netdevice.h | 1 +
net/8021q/vlan.c | 4 ++--
net/8021q/vlan.h | 2 ++
net/8021q/vlan_netlink.c | 38 ++++++++++++++++++++++++++++++++++++++
net/core/dev.c | 1 +
5 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 3ec9850c7936..a95ae238addf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2409,6 +2409,7 @@ enum netdev_cmd {
NETDEV_CVLAN_FILTER_DROP_INFO,
NETDEV_SVLAN_FILTER_PUSH_INFO,
NETDEV_SVLAN_FILTER_DROP_INFO,
+ NETDEV_CHANGEVLAN,
};
const char *netdev_cmd_to_name(enum netdev_cmd cmd);
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 73a65789271b..b5e0ad1a581a 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -51,8 +51,8 @@ const char vlan_version[] = DRV_VERSION;
/* End of global variables definitions. */
-static int vlan_group_prealloc_vid(struct vlan_group *vg,
- __be16 vlan_proto, u16 vlan_id)
+int vlan_group_prealloc_vid(struct vlan_group *vg,
+ __be16 vlan_proto, u16 vlan_id)
{
struct net_device **array;
unsigned int pidx, vidx;
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index 44df1c3df02d..c734dd21d70d 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -116,6 +116,8 @@ int register_vlan_dev(struct net_device *dev, struct netlink_ext_ack *extack);
void unregister_vlan_dev(struct net_device *dev, struct list_head *head);
bool vlan_dev_inherit_address(struct net_device *dev,
struct net_device *real_dev);
+int vlan_group_prealloc_vid(struct vlan_group *vg,
+ __be16 vlan_proto, u16 vlan_id);
static inline u32 vlan_get_ingress_priority(struct net_device *dev,
u16 vlan_tci)
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index 9b60c1e399e2..0e59babe6651 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -107,10 +107,48 @@ static int vlan_changelink(struct net_device *dev, struct nlattr *tb[],
struct nlattr *data[],
struct netlink_ext_ack *extack)
{
+ struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
struct ifla_vlan_flags *flags;
struct ifla_vlan_qos_mapping *m;
struct nlattr *attr;
int rem;
+ int err;
+ __be16 vlan_proto = vlan->vlan_proto;
+ u16 vlan_id = vlan->vlan_id;
+
+ if (data[IFLA_VLAN_ID])
+ vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
+
+ if (data[IFLA_VLAN_PROTOCOL])
+ vlan_proto = nla_get_be16(data[IFLA_VLAN_PROTOCOL]);
+
+ if (vlan->vlan_id != vlan_id || vlan->vlan_proto != vlan_proto) {
+ struct net_device *real_dev = vlan->real_dev;
+ struct vlan_info *vlan_info;
+ struct vlan_group *grp;
+ __be16 old_vlan_proto = vlan->vlan_proto;
+ u16 old_vlan_id = vlan->vlan_id;
+
+ err = vlan_vid_add(real_dev, vlan_proto, vlan_id);
+ if (err)
+ return err;
+ vlan_info = rtnl_dereference(real_dev->vlan_info);
+ grp = &vlan_info->grp;
+ err = vlan_group_prealloc_vid(grp, vlan_proto, vlan_id);
+ if (err < 0) {
+ vlan_vid_del(real_dev, vlan_proto, vlan_id);
+ return err;
+ }
+ vlan_group_set_device(grp, vlan_proto, vlan_id, dev);
+ vlan->vlan_proto = vlan_proto;
+ vlan->vlan_id = vlan_id;
+
+ vlan_group_set_device(grp, old_vlan_proto, old_vlan_id, NULL);
+ vlan_vid_del(real_dev, old_vlan_proto, old_vlan_id);
+
+ err = call_netdevice_notifiers(NETDEV_CHANGEVLAN, dev);
+ notifier_to_errno(err);
+ }
if (data[IFLA_VLAN_FLAGS]) {
flags = nla_data(data[IFLA_VLAN_FLAGS]);
diff --git a/net/core/dev.c b/net/core/dev.c
index 6e18242a1cae..849fdb60fd21 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1587,6 +1587,7 @@ const char *netdev_cmd_to_name(enum netdev_cmd cmd)
N(UDP_TUNNEL_DROP_INFO) N(CHANGE_TX_QUEUE_LEN)
N(CVLAN_FILTER_PUSH_INFO) N(CVLAN_FILTER_DROP_INFO)
N(SVLAN_FILTER_PUSH_INFO) N(SVLAN_FILTER_DROP_INFO)
+ N(CHANGEVLAN)
}
#undef N
return "UNKNOWN_NETDEV_EVENT";
--
2.14.3
^ permalink raw reply related
* Re: [PATCH] tcp: verify the checksum of the first data segment in a new connection
From: van der Linden, Frank @ 2018-06-11 23:43 UTC (permalink / raw)
To: Eric Dumazet, edumazet@google.com, netdev@vger.kernel.org
In-Reply-To: <20599722-9a2f-38c8-e4b8-d2eaf40197ab@gmail.com>
Yeah, true, it's missing INERRS in this case. I'll fix it up a bit.
Frank
On 6/11/18, 4:38 PM, "Eric Dumazet" <eric.dumazet@gmail.com> wrote:
On 06/11/2018 04:25 PM, van der Linden, Frank wrote:
> A few comments on this one:
>
> - obviously this is fairly serious, as it can let corrupted data all the way up to the application
Sure, although anyone relying on CRC checksum for ensuring TCP data integrity
has big troubles ;)
I would rather have a refined version of this patch doing a "goto csum_error"
so that we properly increment TCP_MIB_CSUMERRORS and TCP_MIB_INERRS
Thanks !
^ permalink raw reply
* Re: [PATCH net] net/ipv6: Ensure cfg is properly initialized in ipv6_create_tempaddr
From: David Miller @ 2018-06-11 23:39 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20180611141212.26371-1-dsahern@kernel.org>
From: dsahern@kernel.org
Date: Mon, 11 Jun 2018 07:12:12 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Valdis reported a BUG in ipv6_add_addr:
...
> Looking at the code I found 1 element (peer_pfx) of the newly introduced
> ifa6_config struct that is not initialized. Use a memset rather than hard
> coding an init for each struct element.
>
> Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
> Fixes: e6464b8c63619 ("net/ipv6: Convert ipv6_add_addr to struct ifa6_config")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCH] tcp: verify the checksum of the first data segment in a new connection
From: Eric Dumazet @ 2018-06-11 23:37 UTC (permalink / raw)
To: van der Linden, Frank, edumazet@google.com,
netdev@vger.kernel.org
In-Reply-To: <631FD61F-40EF-4B6A-BD30-6C208DD450B7@amazon.com>
On 06/11/2018 04:25 PM, van der Linden, Frank wrote:
> A few comments on this one:
>
> - obviously this is fairly serious, as it can let corrupted data all the way up to the application
Sure, although anyone relying on CRC checksum for ensuring TCP data integrity
has big troubles ;)
I would rather have a refined version of this patch doing a "goto csum_error"
so that we properly increment TCP_MIB_CSUMERRORS and TCP_MIB_INERRS
Thanks !
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox