* RE: [iproute PATCH 4/4] lib: Enable colored output only for TTYs
From: David Laight @ 2018-08-15 15:34 UTC (permalink / raw)
To: 'Stephen Hemminger', David Ahern
Cc: Phil Sutter, netdev@vger.kernel.org, Till Maas
In-Reply-To: <20180815080406.7110bd76@xeon-e3>
From: Stephen Hemminger
> Sent: 15 August 2018 16:04
...
> > This also disables color sequence when the output is piped to a pager
> > such as less which with the -R argument can handle it just fine.
> >
> > ie., the user needs to remove the color arg when that output is not wanted.
>
> If you are going to change the color enabling, why not make it compatible
> with what ls does?
Indeed - otherwise it is very hard to debug the colour escape sequences.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack (CVE-2018-5390)
From: Greg KH @ 2018-08-15 15:41 UTC (permalink / raw)
To: Mao Wenan; +Cc: dwmw2, netdev, eric.dumazet, edumazet, davem, ycheng, jdw
In-Reply-To: <20180815132432.GE31330@kroah.com>
On Wed, Aug 15, 2018 at 03:24:32PM +0200, Greg KH wrote:
> On Wed, Aug 15, 2018 at 09:20:59PM +0800, Mao Wenan wrote:
> > There are five patches to fix CVE-2018-5390 in latest mainline
> > branch, but only two patches exist in stable 4.4 and 3.18:
> > dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> > 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> > but I have tested with these patches, and found the cpu usage was very high.
> > test results:
> > with fix patch： 78.2% ksoftirqd
> > no fix patch： 90% ksoftirqd
> >
> > After analysing the codes of stable 4.4, and debuging the
> > system, the search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
> > So I think only two patches can't fix the CVE-2018-5390.
> > So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
> > instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
> > good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>
> Thanks for doing this work, I had some questions on the individual
> patches. Can you address them and resend?
Also, always cc: the stable@vger list when sending stable patches so
that others can review and comment on them.
thanks,
greg k-h
^ permalink raw reply
* Re: [bpf PATCH] samples/bpf: all XDP samples should unload xdp/bpf prog on SIGTERM
From: Y Song @ 2018-08-15 15:47 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, jhsiao
In-Reply-To: <153434503438.22833.15753974916276608956.stgit@firesoul>
On Wed, Aug 15, 2018 at 7:57 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> It is common XDP practice to unload/deattach the XDP bpf program,
> when the XDP sample program is Ctrl-C interrupted (SIGINT) or
> killed (SIGTERM).
>
> The samples/bpf programs xdp_redirect_cpu and xdp_rxq_info,
> forgot to trap signal SIGTERM (which is the default signal used
> by the kill command).
>
> This was discovered by Red Hat QA, which automated scripts depend
> on killing the XDP sample program after a timeout period.
>
> Fixes: fad3917e361b ("samples/bpf: add cpumap sample program xdp_redirect_cpu")
> Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to xdp_rxq_info")
> Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> samples/bpf/xdp_redirect_cpu_user.c | 3 ++-
> samples/bpf/xdp_rxq_info_user.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] net: dsa: add support for ksz9897 ethernet switch
From: Lad Prabhakar @ 2018-08-15 15:51 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Andrew Lunn,
Vivien Didelot, Florian Fainelli
Cc: netdev, devicetree, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
ksz9477 is superset of ksz9xx series, driver just works
out of the box for ksz9897 chip with this patch.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Documentation/devicetree/bindings/net/dsa/ksz.txt | 4 +++-
drivers/net/dsa/microchip/ksz_common.c | 9 +++++++++
drivers/net/dsa/microchip/ksz_spi.c | 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
index a700943..ac145b8 100644
--- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
+++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
@@ -4,7 +4,9 @@ Microchip KSZ Series Ethernet switches
Required properties:
- compatible: For external switch chips, compatible string must be exactly one
- of: "microchip,ksz9477"
+ of the following:
+ - "microchip,ksz9477"
+ - "microchip,ksz9897"
See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
required and optional properties.
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 7210c49..54e0ca6 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -1102,6 +1102,15 @@ static const struct ksz_chip_data ksz_switch_chips[] = {
.cpu_ports = 0x7F, /* can be configured as cpu port */
.port_cnt = 7, /* total physical port count */
},
+ {
+ .chip_id = 0x00989700,
+ .dev_name = "KSZ9897",
+ .num_vlans = 4096,
+ .num_alus = 4096,
+ .num_statics = 16,
+ .cpu_ports = 0x7F, /* can be configured as cpu port */
+ .port_cnt = 7, /* total physical port count */
+ },
};
static int ksz_switch_init(struct ksz_device *dev)
diff --git a/drivers/net/dsa/microchip/ksz_spi.c b/drivers/net/dsa/microchip/ksz_spi.c
index c519469..8c1778b 100644
--- a/drivers/net/dsa/microchip/ksz_spi.c
+++ b/drivers/net/dsa/microchip/ksz_spi.c
@@ -195,6 +195,7 @@ static int ksz_spi_remove(struct spi_device *spi)
static const struct of_device_id ksz_dt_ids[] = {
{ .compatible = "microchip,ksz9477" },
+ { .compatible = "microchip,ksz9897" },
{},
};
MODULE_DEVICE_TABLE(of, ksz_dt_ids);
--
2.7.4
^ permalink raw reply related
* [iproute PATCH 1/4] tc: Fix typo in check for colored output
From: Phil Sutter @ 2018-08-15 16:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Till Maas, David Ahern
In-Reply-To: <20180815162127.21477-1-phil@nwl.cc>
The check used binary instead of boolean AND, which means colored output
was enabled only if the number of specified '-color' flags was odd.
Fixes: 2d165c0811058 ("tc: implement color output")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
tc/tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/tc.c b/tc/tc.c
index 3bb5910ffac52..3bb893756f40e 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -515,7 +515,7 @@ int main(int argc, char **argv)
_SL_ = oneline ? "\\" : "\n";
- if (color & !json)
+ if (color && !json)
enable_color();
if (batch_file)
--
2.18.0
^ permalink raw reply related
* [iproute PATCH 2/4] bridge: Fix check for colored output
From: Phil Sutter @ 2018-08-15 16:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Till Maas, David Ahern
In-Reply-To: <20180815162127.21477-1-phil@nwl.cc>
There is no point in calling enable_color() conditionally if it was
already called for each time '-color' flag was parsed. Align the
algorithm with that in ip and tc by actually making use of 'color'
variable.
Fixes: e9625d6aead11 ("Merge branch 'iproute2-master' into iproute2-next")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
bridge/bridge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bridge/bridge.c b/bridge/bridge.c
index 7fcfe1116f6e5..289a157d37f03 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -174,7 +174,7 @@ main(int argc, char **argv)
if (netns_switch(argv[1]))
exit(-1);
} else if (matches(opt, "-color") == 0) {
- enable_color();
+ ++color;
} else if (matches(opt, "-compressvlans") == 0) {
++compress_vlans;
} else if (matches(opt, "-force") == 0) {
--
2.18.0
^ permalink raw reply related
* [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Phil Sutter @ 2018-08-15 16:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Till Maas, David Ahern
In-Reply-To: <20180815162127.21477-1-phil@nwl.cc>
Add an additional prerequisite to check_enable_color() to make sure
stdout actually points to an open TTY device. Otherwise calls like
| ip -color a s >/tmp/foo
will print color escape sequences into that file. Allow to override this
check by specifying '-color' flag more than once.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
Changes since v1:
- Allow to override isatty() check by specifying '-color' flag more than
once.
- Document new behaviour in man pages.
---
lib/color.c | 6 +++++-
man/man8/bridge.8 | 5 ++++-
man/man8/ip.8 | 5 ++++-
man/man8/tc.8 | 5 ++++-
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/lib/color.c b/lib/color.c
index edf96e5c6ecd7..3a66d8ccb4b00 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -3,6 +3,7 @@
#include <stdarg.h>
#include <stdlib.h>
#include <string.h>
+#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <linux/if.h>
@@ -79,7 +80,10 @@ void enable_color(void)
int check_enable_color(int color, int json)
{
- if (color && !json) {
+ if (json || !color)
+ return 1;
+
+ if (color > 1 || isatty(fileno(stdout))) {
enable_color();
return 0;
}
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index e7f7148315e19..b865e8b6cd771 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -171,7 +171,10 @@ return code will be non zero.
.TP
.BR "\-c" , " -color"
-Use color output.
+Use color output if stdout is a terminal. Specify twice to enable color output
+irrespective of stdout state. This flag is ignored if
+.B \-json
+is also given.
.TP
.BR "\-j", " \-json"
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 0087d18b74706..c5484bbc11483 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -188,7 +188,10 @@ executes specified command over all objects, it depends if command supports this
.TP
.BR "\-c" , " -color"
-Use color output.
+Use color output if stdout is a terminal. Specify twice to enable color output
+irrespective of stdout state. This flag is ignored if
+.B \-json
+is also given.
.TP
.BR "\-t" , " \-timestamp"
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index 840880fbdba63..cbe7ac1847bbb 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -730,7 +730,10 @@ option.
.TP
.BR "\ -color"
-Use color output.
+Use color output if stdout is a terminal. Specify twice to enable color output
+irrespective of stdout state. This flag is ignored if
+.B \-json
+is also given.
.TP
.BR "\-j", " \-json"
--
2.18.0
^ permalink raw reply related
* [iproute PATCH 3/4] Merge common code for conditionally colored output
From: Phil Sutter @ 2018-08-15 16:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Till Maas, David Ahern
In-Reply-To: <20180815162127.21477-1-phil@nwl.cc>
Instead of calling enable_color() conditionally with identical check in
three places, introduce check_enable_color() which does it in one place.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
bridge/bridge.c | 3 +--
include/color.h | 1 +
ip/ip.c | 3 +--
lib/color.c | 9 +++++++++
tc/tc.c | 3 +--
5 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/bridge/bridge.c b/bridge/bridge.c
index 289a157d37f03..451d684e0bcfd 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -200,8 +200,7 @@ main(int argc, char **argv)
_SL_ = oneline ? "\\" : "\n";
- if (color && !json)
- enable_color();
+ check_enable_color(color, json);
if (batch_file)
return batch(batch_file);
diff --git a/include/color.h b/include/color.h
index c80359d3e2e95..4f2c918db7e43 100644
--- a/include/color.h
+++ b/include/color.h
@@ -13,6 +13,7 @@ enum color_attr {
};
void enable_color(void);
+int check_enable_color(int color, int json);
void set_color_palette(void);
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...);
enum color_attr ifa_family_color(__u8 ifa_family);
diff --git a/ip/ip.c b/ip/ip.c
index 71d5170c0cc23..38eac5ec1e17d 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -304,8 +304,7 @@ int main(int argc, char **argv)
_SL_ = oneline ? "\\" : "\n";
- if (color && !json)
- enable_color();
+ check_enable_color(color, json);
if (batch_file)
return batch(batch_file);
diff --git a/lib/color.c b/lib/color.c
index da1f516cb2492..edf96e5c6ecd7 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -77,6 +77,15 @@ void enable_color(void)
set_color_palette();
}
+int check_enable_color(int color, int json)
+{
+ if (color && !json) {
+ enable_color();
+ return 0;
+ }
+ return 1;
+}
+
void set_color_palette(void)
{
char *p = getenv("COLORFGBG");
diff --git a/tc/tc.c b/tc/tc.c
index 3bb893756f40e..e775550174473 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -515,8 +515,7 @@ int main(int argc, char **argv)
_SL_ = oneline ? "\\" : "\n";
- if (color && !json)
- enable_color();
+ check_enable_color(color, json);
if (batch_file)
return batch(batch_file);
--
2.18.0
^ permalink raw reply related
* [iproute PATCH v2 0/4] A bunch of fixes regarding colored output
From: Phil Sutter @ 2018-08-15 16:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Till Maas, David Ahern
This series contains fixes for conditionally colored output in patches 1
and 2. Patch 3 merges the common conditionals from ip, tc and bridge
tools. Patch 4 then adds a further restriction to colored output to
prevent garbled output when redirecting into a file.
Changes since v1:
- Adjusted last patch according to feedback. Details given in changelog
of that patch.
Phil Sutter (4):
tc: Fix typo in check for colored output
bridge: Fix check for colored output
Merge common code for conditionally colored output
lib: Enable colored output only for TTYs
bridge/bridge.c | 5 ++---
include/color.h | 1 +
ip/ip.c | 3 +--
lib/color.c | 13 +++++++++++++
man/man8/bridge.8 | 5 ++++-
man/man8/ip.8 | 5 ++++-
man/man8/tc.8 | 5 ++++-
tc/tc.c | 3 +--
8 files changed, 30 insertions(+), 10 deletions(-)
--
2.18.0
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: David Ahern @ 2018-08-15 16:24 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger; +Cc: netdev, Till Maas
In-Reply-To: <20180815162127.21477-5-phil@nwl.cc>
On 8/15/18 10:21 AM, Phil Sutter wrote:
> Add an additional prerequisite to check_enable_color() to make sure
> stdout actually points to an open TTY device. Otherwise calls like
>
> | ip -color a s >/tmp/foo
>
> will print color escape sequences into that file. Allow to override this
> check by specifying '-color' flag more than once.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Changes since v1:
> - Allow to override isatty() check by specifying '-color' flag more than
> once.
That adds overhead to my workflow where I almost always have to pipe the
output of ip to a pager.
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Phil Sutter @ 2018-08-15 16:39 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev, Till Maas
In-Reply-To: <06633975-40ae-f3d6-b5a9-8a947752e400@gmail.com>
On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
> On 8/15/18 10:21 AM, Phil Sutter wrote:
> > Add an additional prerequisite to check_enable_color() to make sure
> > stdout actually points to an open TTY device. Otherwise calls like
> >
> > | ip -color a s >/tmp/foo
> >
> > will print color escape sequences into that file. Allow to override this
> > check by specifying '-color' flag more than once.
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> > Changes since v1:
> > - Allow to override isatty() check by specifying '-color' flag more than
> > once.
>
> That adds overhead to my workflow where I almost always have to pipe the
> output of ip to a pager.
alias ip='ip -color -color'
Another alternative may be to introduce -autocolor flag. Establishing
the same syntax as used by 'ls' is not as trivial due to the simple
commandline parsing used in 'ip'.
Cheers, Phil
^ permalink raw reply
* Re: samples don't build on v4.18
From: Jakub Kicinski @ 2018-08-15 19:34 UTC (permalink / raw)
To: Joel Fernandes
Cc: LKML, wangnan0, open list:BPF (Safe dynamic programs and tools),
Alexei Starovoitov, acme, Chenbo Feng
In-Reply-To: <20180815030132.GA204101@joelaf.mtv.corp.google.com>
On Tue, 14 Aug 2018 20:01:32 -0700, Joel Fernandes wrote:
> On Tue, Aug 14, 2018 at 06:22:21PM -0700, Joel Fernandes wrote:
> > Forgot to add the patch author, doing so now. thanks
> >
> > On Tue, Aug 14, 2018 at 6:20 PM, Joel Fernandes <joelaf@google.com> wrote:
> > >
> > > Hi,
> > > When building BPF samples on v4.18, I get the following errors:
> > >
> > > $ cd samples/bpf/
> > > $ make
> > >
> > > Auto-detecting system features:
> > > ... libelf: [ OFF ]
> > > ... bpf: [ OFF ]
> > >
> > > No libelf found
> > > Makefile:213: recipe for target 'elfdep' failed
> > > -----------
> > >
> > > I bissected it down to commit 5f9380572b4bb24f60cd492b1
> > >
> > > Author: Jakub Kicinski <jakub.kicinski@netronome.com>
> > > Date: Thu May 10 10:24:39 2018 -0700
> > >
> > > samples: bpf: compile and link against full libbpf
> > > ---------
> > >
> > > Checking out a kernel before this commit makes the samples build. Also I do
> > > have libelf on my system.
> > >
> > > Any thoughts on this issue?
>
> There is some weirdness going on with my kernel tree. If I do a fresh clone
> of v4.18 and build samples, everything works.
>
> However if I take my existing checkout, do a:
> git clean -f -d
> make mrproper
>
> Then I try to build the samples, I get the "No libelf found".
>
> Obviously the existing checked out kernel tree is in some weird state that I
> am not yet able to fix. But atleast if I blow the whole tree and clone again,
> I'm able to build...
>
> Is this related to the intermittent "No libelf found" issues that were
> recently discussed?
Can't reproduce, could you provide all exact commands you run to see
this, including the initial clone?
12:32 linux$ git clean -f -d
12:32 linux$ make mrproper
CLEAN .
CLEAN arch/x86/tools
CLEAN .tmp_versions
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN scripts/mod
CLEAN scripts
CLEAN include/config usr/include include/generated arch/x86/include/generated
CLEAN .config .config.old
12:32 linux$ make defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
12:32 linux$ make headers_install
UPD include/generated/uapi/linux/version.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/poll.h
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
HOSTCC arch/x86/tools/relocs_common.o
HOSTLD arch/x86/tools/relocs
HOSTCC scripts/unifdef
INSTALL usr/include/asm-generic/ (37 files)
INSTALL usr/include/drm/ (26 files)
INSTALL usr/include/linux/ (497 files)
INSTALL usr/include/linux/android/ (1 file)
INSTALL usr/include/linux/byteorder/ (2 files)
INSTALL usr/include/linux/caif/ (2 files)
INSTALL usr/include/linux/can/ (6 files)
INSTALL usr/include/linux/cifs/ (1 file)
INSTALL usr/include/linux/dvb/ (8 files)
INSTALL usr/include/linux/genwqe/ (1 file)
INSTALL usr/include/linux/hdlc/ (1 file)
INSTALL usr/include/linux/hsi/ (2 files)
INSTALL usr/include/linux/iio/ (2 files)
INSTALL usr/include/linux/isdn/ (1 file)
INSTALL usr/include/linux/mmc/ (1 file)
INSTALL usr/include/linux/netfilter/ (88 files)
INSTALL usr/include/linux/netfilter/ipset/ (4 files)
INSTALL usr/include/linux/netfilter_arp/ (2 files)
INSTALL usr/include/linux/netfilter_bridge/ (17 files)
INSTALL usr/include/linux/netfilter_ipv4/ (9 files)
INSTALL usr/include/linux/netfilter_ipv6/ (13 files)
INSTALL usr/include/linux/nfsd/ (5 files)
INSTALL usr/include/linux/raid/ (2 files)
INSTALL usr/include/linux/sched/ (1 file)
INSTALL usr/include/linux/spi/ (1 file)
INSTALL usr/include/linux/sunrpc/ (1 file)
INSTALL usr/include/linux/tc_act/ (15 files)
INSTALL usr/include/linux/tc_ematch/ (5 files)
INSTALL usr/include/linux/usb/ (12 files)
INSTALL usr/include/linux/wimax/ (1 file)
INSTALL usr/include/misc/ (2 files)
INSTALL usr/include/mtd/ (5 files)
INSTALL usr/include/rdma/ (25 files)
INSTALL usr/include/rdma/hfi/ (2 files)
INSTALL usr/include/scsi/ (4 files)
INSTALL usr/include/scsi/fc/ (4 files)
INSTALL usr/include/sound/ (16 files)
INSTALL usr/include/video/ (3 files)
INSTALL usr/include/xen/ (4 files)
INSTALL usr/include/asm/ (62 files)
12:32 linux$ cd samples/bpf/
12:32 bpf$ make LLC=llc-6.0 LLVM_OBJCOPY=llvm-objcopy-6.0 CLANG=clang-6.0
make -C ../../ /tmp/linux/samples/bpf/ BPF_SAMPLES_PATH=/tmp/linux/samples/bpf
make[1]: Entering directory '/tmp/linux'
scripts/kconfig/conf --syncconfig Kconfig
SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_64.h
UPD include/config/kernel.release
WRAP arch/x86/include/generated/asm/dma-contiguous.h
WRAP arch/x86/include/generated/asm/early_ioremap.h
WRAP arch/x86/include/generated/asm/mcs_spinlock.h
WRAP arch/x86/include/generated/asm/mm-arch-hooks.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
UPD include/generated/bounds.h
UPD include/generated/timeconst.h
CC arch/x86/kernel/asm-offsets.s
UPD include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
DESCEND objtool
HOSTCC /tmp/linux/tools/objtool/fixdep.o
HOSTLD /tmp/linux/tools/objtool/fixdep-in.o
LINK /tmp/linux/tools/objtool/fixdep
CC /tmp/linux/tools/objtool/exec-cmd.o
CC /tmp/linux/tools/objtool/help.o
CC /tmp/linux/tools/objtool/pager.o
CC /tmp/linux/tools/objtool/parse-options.o
CC /tmp/linux/tools/objtool/run-command.o
CC /tmp/linux/tools/objtool/sigchain.o
CC /tmp/linux/tools/objtool/subcmd-config.o
LD /tmp/linux/tools/objtool/libsubcmd-in.o
AR /tmp/linux/tools/objtool/libsubcmd.a
CC /tmp/linux/tools/objtool/arch/x86/decode.o
LD /tmp/linux/tools/objtool/arch/x86/objtool-in.o
CC /tmp/linux/tools/objtool/builtin-check.o
CC /tmp/linux/tools/objtool/builtin-orc.o
CC /tmp/linux/tools/objtool/check.o
CC /tmp/linux/tools/objtool/orc_gen.o
CC /tmp/linux/tools/objtool/orc_dump.o
CC /tmp/linux/tools/objtool/elf.o
CC /tmp/linux/tools/objtool/special.o
CC /tmp/linux/tools/objtool/objtool.o
CC /tmp/linux/tools/objtool/libstring.o
CC /tmp/linux/tools/objtool/str_error_r.o
LD /tmp/linux/tools/objtool/objtool-in.o
LINK /tmp/linux/tools/objtool/objtool
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
UPD scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
HOSTCC scripts/kallsyms
HOSTCC scripts/pnmtologo
HOSTCC scripts/conmakehash
HOSTCC scripts/sortextable
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
make -C /tmp/linux/samples/bpf/../../tools/lib/bpf/ RM='rm -rf' LDFLAGS= srctree=/tmp/linux/samples/bpf/../../ O=
HOSTCC fixdep.o
HOSTLD fixdep-in.o
LINK fixdep
CC libbpf.o
CC bpf.o
CC nlattr.o
CC btf.o
LD libbpf-in.o
LINK libbpf.a
LINK libbpf.so
HOSTCC /tmp/linux/samples/bpf/test_lru_dist
HOSTCC /tmp/linux/samples/bpf/sock_example
HOSTCC /tmp/linux/samples/bpf/bpf_load.o
HOSTCC /tmp/linux/samples/bpf/fds_example.o
HOSTLD /tmp/linux/samples/bpf/fds_example
HOSTCC /tmp/linux/samples/bpf/sockex1_user.o
HOSTLD /tmp/linux/samples/bpf/sockex1
HOSTCC /tmp/linux/samples/bpf/sockex2_user.o
HOSTLD /tmp/linux/samples/bpf/sockex2
HOSTCC /tmp/linux/samples/bpf/sockex3_user.o
HOSTLD /tmp/linux/samples/bpf/sockex3
HOSTCC /tmp/linux/samples/bpf/tracex1_user.o
HOSTLD /tmp/linux/samples/bpf/tracex1
HOSTCC /tmp/linux/samples/bpf/tracex2_user.o
HOSTLD /tmp/linux/samples/bpf/tracex2
HOSTCC /tmp/linux/samples/bpf/tracex3_user.o
HOSTLD /tmp/linux/samples/bpf/tracex3
HOSTCC /tmp/linux/samples/bpf/tracex4_user.o
HOSTLD /tmp/linux/samples/bpf/tracex4
HOSTCC /tmp/linux/samples/bpf/tracex5_user.o
HOSTLD /tmp/linux/samples/bpf/tracex5
HOSTCC /tmp/linux/samples/bpf/tracex6_user.o
HOSTLD /tmp/linux/samples/bpf/tracex6
HOSTCC /tmp/linux/samples/bpf/tracex7_user.o
HOSTLD /tmp/linux/samples/bpf/tracex7
HOSTCC /tmp/linux/samples/bpf/test_probe_write_user_user.o
HOSTLD /tmp/linux/samples/bpf/test_probe_write_user
HOSTCC /tmp/linux/samples/bpf/trace_output_user.o
HOSTCC /tmp/linux/samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.o
HOSTLD /tmp/linux/samples/bpf/trace_output
HOSTCC /tmp/linux/samples/bpf/lathist_user.o
HOSTLD /tmp/linux/samples/bpf/lathist
HOSTCC /tmp/linux/samples/bpf/offwaketime_user.o
HOSTLD /tmp/linux/samples/bpf/offwaketime
HOSTCC /tmp/linux/samples/bpf/spintest_user.o
HOSTLD /tmp/linux/samples/bpf/spintest
HOSTCC /tmp/linux/samples/bpf/map_perf_test_user.o
HOSTLD /tmp/linux/samples/bpf/map_perf_test
HOSTCC /tmp/linux/samples/bpf/test_overhead_user.o
HOSTLD /tmp/linux/samples/bpf/test_overhead
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_array_pin.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_array_pin
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_attach.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_attach
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_attach2.o
HOSTCC /tmp/linux/samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_attach2
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_sock.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_sock
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_sock2.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_sock2
HOSTCC /tmp/linux/samples/bpf/xdp1_user.o
HOSTLD /tmp/linux/samples/bpf/xdp1
HOSTLD /tmp/linux/samples/bpf/xdp2
HOSTCC /tmp/linux/samples/bpf/xdp_router_ipv4_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_router_ipv4
HOSTCC /tmp/linux/samples/bpf/test_current_task_under_cgroup_user.o
HOSTLD /tmp/linux/samples/bpf/test_current_task_under_cgroup
HOSTCC /tmp/linux/samples/bpf/trace_event_user.o
HOSTLD /tmp/linux/samples/bpf/trace_event
HOSTCC /tmp/linux/samples/bpf/sampleip_user.o
HOSTLD /tmp/linux/samples/bpf/sampleip
HOSTCC /tmp/linux/samples/bpf/tc_l2_redirect_user.o
HOSTLD /tmp/linux/samples/bpf/tc_l2_redirect
HOSTCC /tmp/linux/samples/bpf/lwt_len_hist_user.o
HOSTLD /tmp/linux/samples/bpf/lwt_len_hist
HOSTCC /tmp/linux/samples/bpf/xdp_tx_iptunnel_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_tx_iptunnel
HOSTCC /tmp/linux/samples/bpf/test_map_in_map_user.o
HOSTLD /tmp/linux/samples/bpf/test_map_in_map
HOSTCC /tmp/linux/samples/bpf/cookie_uid_helper_example.o
HOSTLD /tmp/linux/samples/bpf/per_socket_stats_example
HOSTCC /tmp/linux/samples/bpf/load_sock_ops.o
HOSTLD /tmp/linux/samples/bpf/load_sock_ops
HOSTCC /tmp/linux/samples/bpf/xdp_redirect_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_redirect
HOSTCC /tmp/linux/samples/bpf/xdp_redirect_map_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_redirect_map
HOSTCC /tmp/linux/samples/bpf/xdp_redirect_cpu_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_redirect_cpu
HOSTCC /tmp/linux/samples/bpf/xdp_monitor_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_monitor
HOSTCC /tmp/linux/samples/bpf/xdp_rxq_info_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_rxq_info
HOSTCC /tmp/linux/samples/bpf/syscall_tp_user.o
HOSTLD /tmp/linux/samples/bpf/syscall_tp
HOSTCC /tmp/linux/samples/bpf/cpustat_user.o
HOSTLD /tmp/linux/samples/bpf/cpustat
HOSTCC /tmp/linux/samples/bpf/xdp_adjust_tail_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_adjust_tail
HOSTCC /tmp/linux/samples/bpf/xdpsock_user.o
HOSTLD /tmp/linux/samples/bpf/xdpsock
HOSTCC /tmp/linux/samples/bpf/xdp_fwd_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_fwd
HOSTCC /tmp/linux/samples/bpf/task_fd_query_user.o
HOSTLD /tmp/linux/samples/bpf/task_fd_query
CC /tmp/linux/samples/bpf/syscall_nrs.s
CLANG-bpf /tmp/linux/samples/bpf/sockex1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sockex2_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sockex3_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex2_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex3_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex4_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex5_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex6_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex7_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sock_flags_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_probe_write_user_kern.o
CLANG-bpf /tmp/linux/samples/bpf/trace_output_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcbpf1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tc_l2_redirect_kern.o
CLANG-bpf /tmp/linux/samples/bpf/lathist_kern.o
CLANG-bpf /tmp/linux/samples/bpf/offwaketime_kern.o
CLANG-bpf /tmp/linux/samples/bpf/spintest_kern.o
CLANG-bpf /tmp/linux/samples/bpf/map_perf_test_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_overhead_tp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_overhead_raw_tp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_overhead_kprobe_kern.o
CLANG-bpf /tmp/linux/samples/bpf/parse_varlen.o
CLANG-bpf /tmp/linux/samples/bpf/parse_simple.o
CLANG-bpf /tmp/linux/samples/bpf/parse_ldabs.o
CLANG-bpf /tmp/linux/samples/bpf/test_cgrp2_tc_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp2_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_router_ipv4_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_current_task_under_cgroup_kern.o
CLANG-bpf /tmp/linux/samples/bpf/trace_event_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sampleip_kern.o
CLANG-bpf /tmp/linux/samples/bpf/lwt_len_hist_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_tx_iptunnel_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_map_in_map_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_synrto_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_rwnd_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_bufs_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_cong_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_iw_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_clamp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_basertt_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_redirect_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_redirect_map_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_redirect_cpu_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_monitor_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_rxq_info_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp2skb_meta_kern.o
CLANG-bpf /tmp/linux/samples/bpf/syscall_tp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/cpustat_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_adjust_tail_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdpsock_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_fwd_kern.o
CLANG-bpf /tmp/linux/samples/bpf/task_fd_query_kern.o
make[1]: Leaving directory '/tmp/linux'
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: David Ahern @ 2018-08-15 16:43 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger, netdev, Till Maas
In-Reply-To: <20180815163944.GT32448@orbyte.nwl.cc>
On 8/15/18 10:39 AM, Phil Sutter wrote:
> On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
>> On 8/15/18 10:21 AM, Phil Sutter wrote:
>>> Add an additional prerequisite to check_enable_color() to make sure
>>> stdout actually points to an open TTY device. Otherwise calls like
>>>
>>> | ip -color a s >/tmp/foo
>>>
>>> will print color escape sequences into that file. Allow to override this
>>> check by specifying '-color' flag more than once.
>>>
>>> Signed-off-by: Phil Sutter <phil@nwl.cc>
>>> ---
>>> Changes since v1:
>>> - Allow to override isatty() check by specifying '-color' flag more than
>>> once.
>>
>> That adds overhead to my workflow where I almost always have to pipe the
>> output of ip to a pager.
>
> alias ip='ip -color -color'
no. Don't impact existing users.
>
> Another alternative may be to introduce -autocolor flag. Establishing
> the same syntax as used by 'ls' is not as trivial due to the simple
> commandline parsing used in 'ip'.
I disagree with ignoring or overriding an argument a user passes in. You
are guessing what is the correct output and you are guessing wrong.
There is nothing wrong with piping output to a file and the viewing that
file through 'less -R'.
If a user does not want the color codes in the file, then that user can
drop the -color arg. iproute2 commands should not be guessing.
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Phil Sutter @ 2018-08-15 16:51 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev, Till Maas
In-Reply-To: <0ce24184-cf62-5623-5a7c-b1b32ab8b1c3@gmail.com>
On Wed, Aug 15, 2018 at 10:43:25AM -0600, David Ahern wrote:
> On 8/15/18 10:39 AM, Phil Sutter wrote:
> > On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
> >> On 8/15/18 10:21 AM, Phil Sutter wrote:
> >>> Add an additional prerequisite to check_enable_color() to make sure
> >>> stdout actually points to an open TTY device. Otherwise calls like
> >>>
> >>> | ip -color a s >/tmp/foo
> >>>
> >>> will print color escape sequences into that file. Allow to override this
> >>> check by specifying '-color' flag more than once.
> >>>
> >>> Signed-off-by: Phil Sutter <phil@nwl.cc>
> >>> ---
> >>> Changes since v1:
> >>> - Allow to override isatty() check by specifying '-color' flag more than
> >>> once.
> >>
> >> That adds overhead to my workflow where I almost always have to pipe the
> >> output of ip to a pager.
> >
> > alias ip='ip -color -color'
>
> no. Don't impact existing users.
That's a possible fix for *your* workflow. If applied to the shell
handling that workflow, it won't impact existing users.
> > Another alternative may be to introduce -autocolor flag. Establishing
> > the same syntax as used by 'ls' is not as trivial due to the simple
> > commandline parsing used in 'ip'.
>
> I disagree with ignoring or overriding an argument a user passes in. You
> are guessing what is the correct output and you are guessing wrong.
> There is nothing wrong with piping output to a file and the viewing that
> file through 'less -R'.
>
> If a user does not want the color codes in the file, then that user can
> drop the -color arg. iproute2 commands should not be guessing.
OK, I got it. Should I respin the fixes or will you apply the series
partially?
Thanks, Phil
^ permalink raw reply
* Re: [PATCH net-next][RFC] net/tls: Add support for async decryption of tls records
From: Dave Watson @ 2018-08-15 16:55 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180814141758.4930-1-vakul.garg@nxp.com>
On 08/14/18 07:47 PM, Vakul Garg wrote:
> Incoming TLS records which are directly decrypted into user space
> application buffer i.e. records which are decrypted in zero-copy mode
> are submitted for async decryption. When the decryption cryptoapi
> returns -EINPROGRESS, the next tls record is parsed and then submitted
> for decryption. The references to records which has been sent for async
> decryption are dropped. This happens in a loop for all the records that
> can be decrypted in zero-copy mode. For records for which decryption is
> not possible in zero-copy mode, asynchronous decryption is not used and
> we wait for decryption crypto api to complete.
>
> For crypto requests executing in async fashion, the memory for
> aead_request, sglists and skb etc is freed from the decryption
> completion handler. The decryption completion handler wakesup the
> sleeping user context. This happens when the user context is done
> enqueueing all the crypto requests and is waiting for all the async
> operations to finish. Since the splice() operation does not use
> zero-copy decryption, async remains disabled for splice().
I found it a little hard to understand what you are trying to do based
on the commit message. Reading the code, it looks like if the recv()
spans multiple TLS records, we will start decryption on all of them,
and only wait right before recv() returns, yes? This approach sounds
great to me.
Three of the selftests are failing for me:
[ FAIL ] tls.recv_partial
[ FAIL ] tls.recv_peek
[ FAIL ] tls.recv_peek_multiple
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: David Ahern @ 2018-08-15 16:57 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger, netdev, Till Maas
In-Reply-To: <20180815165115.GU32448@orbyte.nwl.cc>
On 8/15/18 10:51 AM, Phil Sutter wrote:
> Should I respin the fixes or will you apply the series
> partially?
Stephen has released 4.18 but not merged -next to master yet, so I
applied the first 3 to -next.
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: Eric Biggers @ 2018-08-15 19:57 UTC (permalink / raw)
To: D. J. Bernstein
Cc: Jason A. Donenfeld, Eric Biggers, Linux Crypto Mailing List, LKML,
Netdev, David Miller, Andrew Lutomirski, Greg Kroah-Hartman,
Samuel Neves, Tanja Lange, Jean-Philippe Aumasson,
Karthikeyan Bhargavan
In-Reply-To: <20180815162819.22765.qmail@cr.yp.to>
On Wed, Aug 15, 2018 at 04:28:19PM -0000, D. J. Bernstein wrote:
> Eric Biggers writes:
> > I've also written a scalar ChaCha20 implementation (no NEON instructions!) that
> > is 12.2 cpb on one block at a time on Cortex-A7, taking advantage of the free
> > rotates; that would be useful for the single permutation used to compute
> > XChaCha's subkey, and also for the ends of messages.
>
> This is also how ends of messages are handled in the 2012 implementation
> crypto_stream/salsa20/armneon6 (see "mainloop1") inside the SUPERCOP
> benchmarking framework:
>
> https://bench.cr.yp.to/supercop.html
>
> This code is marginally different from Eric's new code because the
> occasional loads and stores are scheduled for the Cortex-A8 rather than
> the Cortex-A7, and because it's Salsa20 rather than ChaCha20.
>
> The bigger picture is that there are 63 implementations of Salsa20 and
> ChaCha20 in SUPERCOP from 10 authors showing various implementation
> techniques, including all the techniques that have been mentioned in
> this thread; and centralized benchmarks on (e.g.)
>
> https://bench.cr.yp.to/results-stream.html#amd64-kizomba
> https://bench.cr.yp.to/web-impl/amd64-kizomba-crypto_stream-salsa20.html
>
> showing what's fastest on various platforms, using well-developed
> benchmarking tools that produce repeatable, meaningful measurements.
> There are also various papers explaining the main techniques.
>
> Of course it's possible that new code will do better, especially on
> platforms with different performance characteristics from the platforms
> previously targeted. Contributing new implementations to SUPERCOP is
> easy---which is why SUPERCOP already has thousands of implementations of
> hundreds of cryptographic functions---and is a more effective way to
> advertise speedups than adding code merely to (e.g.) the Linux kernel.
> Infrastructure is centralized in SUPERCOP to minimize per-implementation
> work. There's no risk of being rejected on the basis of cryptographic
> concerns (MD5, Speck, and RSA-512 are included in the benchmarks) or
> code-style concerns. Users can then decide which implementations best
> meet their requirements.
>
> "Do better" seems to be what's happened for the Cortex-A7. The best
> SUPERCOP speeds (from code targeting the Cortex-A8 etc.) are 13.42
> cycles/byte for 4096 bytes for ChaCha20; 12.2, 11.9, and 11.3 sound
> noticeably better. The Cortex-A7 is an interesting case because it's
> simultaneously (1) widely deployed---more than a billion units sold---
> but (2) poorly documented. If you want to know, e.g., which instructions
> can dual-issue with loads/FPU moves/..., then you won't be able to find
> anything from ARM giving the answer. I've started building an automated
> tool to compute the full CPU pipeline structure from benchmarks, but
> this isn't ready yet.
>
Hi Dan, are you saying I should contribute my scalar ChaCha implementation,
and/or the Linux kernel's ChaCha NEON implementation, to SUPERCOP? Just a few
comments: there doesn't appear to be an official git repository for SUPERCOP,
nor is there any mention of how to send patches, nor is there any COPYING or
LICENSE file, nor even a README file. So, while I'm interested, from my
perspective SUPERCOP doesn't seem friendly to contributions. You'd probably
attract more contributors if you followed established open source conventions.
Another issue is that the ChaCha code in SUPERCOP is duplicated for each number
of rounds: 8, 12, and 20. So if anyone adds a new ChaCha implementation, they'd
apparently have to add 3 copies of it, which isn't very maintainable.
There are actually only two ARM NEON implementations of ChaCha20 in SUPERCOP:
(1) the one in crypto_stream/chacha20/moon/neon/32/chacha.S which looks like an
'objdump' output as it has no comments or anything that would make it readable
like macros and register aliases; and (2) the one in
crypto_stream/chacha20/dolbeau/arm-neon/, which uses a method similar to the
Linux implementation but it uses GCC intrinsics, so its performance will heavily
depend on how the compiler assigns and spills registers, which can vary greatly
depending on the compiler version and options.
I understand that Salsa20 is similar to ChaCha, and that ideas from Salsa20
implementations often apply to ChaCha too. But it's not always obvious what
carries over and what doesn't; the rotation amounts can matter a lot, for
example, as different rotations can be implemented in different ways. Nor is it
always obvious which ideas from SSE2 or AVX2 implementations (for example) carry
over to NEON implementations, as these instruction sets are different enough
that each has its own unique quirks and optimizations.
Previously I also found that OpenSSL's ARM NEON implementation of Poly1305 is
much faster than the implementations in SUPERCOP, as well as more
understandable. (I don't know the 'qhasm' language, for example.) So from my
perspective, I've had more luck with OpenSSL than SUPERCOP when looking for fast
implementations of crypto algorithms. Have you considered adding the OpenSSL
implementations to SUPERCOP?
In the end though, both Linux and OpenSSL don't need every implementation under
the sun, but rather a small number of implementations that provide "good"
performance on nearly all CPUs, while not necessarily being optimal on every CPU
out there. I.e., some tradeoffs are necessary and acceptable. So for
ChaCha{12,20} on ARM we should choose which 2-3 implementations are most
valuable to have and make them as generally well optimized as possible. Based
on the research I've seen and done, I think they're likely to be:
- a 1x_scalar implementation
- a 3x_NEON+1x_scalar implementation like OpenSSL's
- a 4x_NEON implementation like Linux's current one
Currently my main argument is just that having the 3x_NEON+1x_scalar method be
the only NEON implementation is probably insufficient, as there are important
CPUs where the 4x_NEON method is significantly faster.
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: ravb: Add support for r8a774a1 SoC
From: Rob Herring @ 2018-08-15 20:18 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Mark Rutland, Fabrizio Castro, Sergei Shtylyov, David S. Miller,
Geert Uytterhoeven, Simon Horman, Biju Das, Yoshihiro Shimoda,
netdev, linux-renesas-soc, devicetree, linux-kernel, Simon Horman,
Chris Paterson
In-Reply-To: <1534250017-15725-1-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, 14 Aug 2018 13:33:37 +0100, Fabrizio Castro wrote:
> Document RZ/G2M (R8A774A1) SoC bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* RE: [PATCH net-next][RFC] net/tls: Add support for async decryption of tls records
From: Vakul Garg @ 2018-08-15 17:29 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180815164548.ikdrxliwtmqdgt3c@davejwatson-mba.local>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Wednesday, August 15, 2018 10:26 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davem@davemloft.net
> Subject: Re: [PATCH net-next][RFC] net/tls: Add support for async decryption
> of tls records
>
> On 08/14/18 07:47 PM, Vakul Garg wrote:
> > Incoming TLS records which are directly decrypted into user space
> > application buffer i.e. records which are decrypted in zero-copy mode
> > are submitted for async decryption. When the decryption cryptoapi
> > returns -EINPROGRESS, the next tls record is parsed and then submitted
> > for decryption. The references to records which has been sent for
> > async decryption are dropped. This happens in a loop for all the
> > records that can be decrypted in zero-copy mode. For records for which
> > decryption is not possible in zero-copy mode, asynchronous decryption
> > is not used and we wait for decryption crypto api to complete.
> >
> > For crypto requests executing in async fashion, the memory for
> > aead_request, sglists and skb etc is freed from the decryption
> > completion handler. The decryption completion handler wakesup the
> > sleeping user context. This happens when the user context is done
> > enqueueing all the crypto requests and is waiting for all the async
> > operations to finish. Since the splice() operation does not use
> > zero-copy decryption, async remains disabled for splice().
>
> I found it a little hard to understand what you are trying to do based on the
> commit message.
Ok, I will rewrite it.
> Reading the code, it looks like if the recv() spans multiple
> TLS records, we will start decryption on all of them, and only wait right
> before recv() returns, yes? This approach sounds great to me.
>
Yes, that's the idea. I am firing as many decryption jobs as possible till I run
out of user application provided buffer space.
> Three of the selftests are failing for me:
>
> [ FAIL ] tls.recv_partial
> [ FAIL ] tls.recv_peek
> [ FAIL ] tls.recv_peek_multiple
Will look into it.
Thanks for spending time in review my patch.
The patch is showing good performance benefits.
^ permalink raw reply
* [PATCH net-next] Documentation: networking: ti-cpsw: correct cbs parameters for Eth1 100Mb
From: Ivan Khoronzhuk @ 2018-08-15 20:29 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: corbet, netdev, linux-doc, linux-kernel, Ivan Khoronzhuk
If set cbs parameters calculated for 1000Mb, but use on 100Mb port
w/o h/w offload (for cpsw offload it doesn't matter), it works
incorrectly. According to the example and testing board, second port
is 100Mb interface. Correct them on recalculated for 100Mb interface.
It allows to use the same command for CBS software implementation for
board in example.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on net-next/master
Documentation/networking/ti-cpsw.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ti-cpsw.txt b/Documentation/networking/ti-cpsw.txt
index 67039205bd69..d4d4c0751a09 100644
--- a/Documentation/networking/ti-cpsw.txt
+++ b/Documentation/networking/ti-cpsw.txt
@@ -469,17 +469,18 @@ $ tc -g class show dev eth1
14)
// Set rate for class A - 31 Mbit (tc0, txq2) using CBS Qdisc for Eth1
-// here only idle slope is important, others ignored
+// here only idle slope is important, others ignored, but calculated
+// for interface speed - 100Mb for eth1 port.
// Set it +1 Mb for reserve (important!)
-$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1453 \
-hicredit 47 sendslope -969000 idleslope 31000 offload 1
+$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1035 \
+hicredit 465 sendslope -69000 idleslope 31000 offload 1
net eth1: set FIFO3 bw = 31
15)
// Set rate for class B - 11 Mbit (tc1, txq3) using CBS Qdisc for Eth1
// Set it +1 Mb for reserve (important!)
-$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1483 \
-hicredit 34 sendslope -989000 idleslope 11000 offload 1
+$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1335 \
+hicredit 405 sendslope -89000 idleslope 11000 offload 1
net eth1: set FIFO2 bw = 11
16)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Arnd Bergmann @ 2018-08-15 20:33 UTC (permalink / raw)
To: Bryan.Whitehead
Cc: UNGLinuxDriver, David Miller, YueHaibing, Networking,
Linux Kernel Mailing List
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D2644073E9C4@CHN-SV-EXMX02.mchp-main.com>
On Wed, Aug 15, 2018 at 8:03 PM <Bryan.Whitehead@microchip.com> wrote:
>
> >
> > Question: this is the only ptp driver that sets the hardware time to the
> > current system time in TAI. Why does it do that?
>
> This is done when the driver starts up after reset. Otherwise the clock is off by 48 years.
> It seemed to me that the system time was the most appropriate clock to sync to.
> If my reasoning is incorrect, please enlighten me.
I've never worked with PTP, but my understanding from looking at the other
drivers is that the time normally gets set either from another host through the
PTP protocol, or using clock_settime() from user space with the current time.
Arnd
^ permalink raw reply
* RE: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Bryan.Whitehead @ 2018-08-15 20:41 UTC (permalink / raw)
To: arnd; +Cc: UNGLinuxDriver, davem, yuehaibing, netdev, linux-kernel
In-Reply-To: <CAK8P3a0f38ev5E4Zvg_3BS+1UN2NzYSw+dyRHXDwLCWgREXJ6g@mail.gmail.com>
> > > Question: this is the only ptp driver that sets the hardware time to
> > > the current system time in TAI. Why does it do that?
> >
> > This is done when the driver starts up after reset. Otherwise the clock is off
> by 48 years.
> > It seemed to me that the system time was the most appropriate clock to
> sync to.
> > If my reasoning is incorrect, please enlighten me.
>
> I've never worked with PTP, but my understanding from looking at the other
> drivers is that the time normally gets set either from another host through
> the PTP protocol, or using clock_settime() from user space with the current
> time.
Those methods will still work. But if it's not set by those methods, I thought the clock should at least be set once on driver startup to align with the system clock. After that, other methods are free to reset it again.
Bryan
^ permalink raw reply
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Arnd Bergmann @ 2018-08-15 20:44 UTC (permalink / raw)
To: Bryan.Whitehead
Cc: UNGLinuxDriver, David Miller, YueHaibing, Networking,
Linux Kernel Mailing List, Richard Cochran
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D2644073EA26@CHN-SV-EXMX02.mchp-main.com>
On Wed, Aug 15, 2018 at 10:41 PM <Bryan.Whitehead@microchip.com> wrote:
>
> > > > Question: this is the only ptp driver that sets the hardware time to
> > > > the current system time in TAI. Why does it do that?
> > >
> > > This is done when the driver starts up after reset. Otherwise the clock is off
> > by 48 years.
> > > It seemed to me that the system time was the most appropriate clock to
> > sync to.
> > > If my reasoning is incorrect, please enlighten me.
> >
> > I've never worked with PTP, but my understanding from looking at the other
> > drivers is that the time normally gets set either from another host through
> > the PTP protocol, or using clock_settime() from user space with the current
> > time.
>
> Those methods will still work. But if it's not set by those methods, I thought the
> clock should at least be set once on driver startup to align with the system clock.
> After that, other methods are free to reset it again.
(adding Richard Cochran to Cc for more insight here)
I would argue that it's more important that the driver behaves like all other
PTP implementations. If we want the behavior to be that the initial PTP time is
set to the ktime_get_clocktai_ts64() value, then this should be done by the
PTP core rather than the device driver. If there is a good reason that the
other drivers don't do it like this, then I would assume the same reason applies
to lan743x.
Arnd
^ permalink raw reply
* Re: [RFC PATCH v1 1/3] dt-bindings: net: Add 'mac-address-lookup' property
From: Rob Herring @ 2018-08-15 20:45 UTC (permalink / raw)
To: Brian Norris
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Andrew Lunn,
Florian Fainelli, Dmitry Torokhov, Guenter Roeck, netdev,
devicetree, linux-kernel, Julius Werner, Stephen Boyd,
Brian Norris
In-Reply-To: <20180814223758.117433-2-briannorris@chromium.org>
On Tue, Aug 14, 2018 at 03:37:56PM -0700, Brian Norris wrote:
> Some firmwares present data tables that can be parsed to retrieve
> device-specific details, like MAC addresses. While in some cases, one
> could teach the firmware to understand the device tree format and insert
> a 'mac-address'/'local-mac-address' property into the FDT on its own,
> this method can be brittle (e.g., involving memorizing expected FDT
> structure), and it's not strictly necessary -- especially when parsers
> for such firmware formats are already needed in the OS for other
> reasons.
If you have an 'ethernetN' alias then you don't need to know the
structure. IIRC, that is what u-boot does.
>
> One such format: the Vital Product Data (VPD) [1] used by Coreboot. It
> supports a table of key/value pairs, and some systems keep MAC addresses
> there in a well-known format. Allow a device tree to specify
> (1) that the MAC address for a given device is stored in the VPD table
> and
> (2) what key should be used to retrieve the MAC address for said
> device (e.g., "ethernet_mac0" or "wifi_mac1").
>
> [1] Ref:
> https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> TL;DR: VPD consists of a TLV-like table, with key/value pairs of
> strings. This is often stored persistently on the boot flash and
> presented via in-memory Coreboot tables, for the operating system to
> read.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Documentation/devicetree/bindings/net/ethernet.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
> index cfc376bc977a..d3fd1da18bf4 100644
> --- a/Documentation/devicetree/bindings/net/ethernet.txt
> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> @@ -4,6 +4,18 @@ NOTE: All 'phy*' properties documented below are Ethernet specific. For the
> generic PHY 'phys' property, see
> Documentation/devicetree/bindings/phy/phy-bindings.txt.
>
> +- mac-address-lookup: string, indicating a method by which a MAC address may be
> + discovered for this device. Methods may be parameterized by some value, such
> + that the method can determine the device's MAC address using that parameter.
> + For example, a firmware might store MAC addresses in a table, keyed by some
> + predetermined string, and baked in read-only flash. A lookup method "foo"
> + with a parameter "bar" should be written "foo:bar".
> + Supported values for method:
> + "google-vpd" - Google's Vital Product Data (VPD), as used in the Coreboot
> + project. Documentation for VPD can be found at:
> + https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> + Example:
> + mac-address-lookup = "google-vpd:ethernet_mac0"
This doesn't strike me as a very DT style way of describing this. I
would expect something like a phandle to the VPD and an identifier.
Also, an already common way besides local-mac-address is using nvmem
binding which wouldn't use this and perhaps could be used here? This
feels very much Google specific, not common (and maybe that is fine).
Rob
^ permalink raw reply
* RE: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Bryan.Whitehead @ 2018-08-15 20:50 UTC (permalink / raw)
To: arnd
Cc: UNGLinuxDriver, davem, yuehaibing, netdev, linux-kernel,
richardcochran
In-Reply-To: <CAK8P3a3guebtDLNhbQwNmA2nq=raKiP8ztGRpb03r0XD8h+ZNA@mail.gmail.com>
> > > > > Question: this is the only ptp driver that sets the hardware
> > > > > time to the current system time in TAI. Why does it do that?
> > > >
> > > > This is done when the driver starts up after reset. Otherwise the
> > > > clock is off
> > > by 48 years.
> > > > It seemed to me that the system time was the most appropriate
> > > > clock to
> > > sync to.
> > > > If my reasoning is incorrect, please enlighten me.
> > >
> > > I've never worked with PTP, but my understanding from looking at the
> > > other drivers is that the time normally gets set either from another
> > > host through the PTP protocol, or using clock_settime() from user
> > > space with the current time.
> >
> > Those methods will still work. But if it's not set by those methods, I
> > thought the clock should at least be set once on driver startup to align with
> the system clock.
> > After that, other methods are free to reset it again.
>
> (adding Richard Cochran to Cc for more insight here)
>
> I would argue that it's more important that the driver behaves like all other
> PTP implementations. If we want the behavior to be that the initial PTP time
> is set to the ktime_get_clocktai_ts64() value, then this should be done by the
> PTP core rather than the device driver. If there is a good reason that the
> other drivers don't do it like this, then I would assume the same reason
> applies to lan743x.
>
Sounds reasonable to me. I will yield to Richard's insight.
But it would be nice if requirements like these were documented.
^ 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