* Re: [PATCH v3,net-next 2/2] ip6_gre: simplify gre header parsing in ip6gre_err
From: David Miller @ 2018-09-16 22:34 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, jbenc, netdev, linux-kernel
In-Reply-To: <1536899208-2958-2-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Fri, 14 Sep 2018 12:26:48 +0800
> Same as ip_gre, use gre_parse_header to parse gre header in gre error
> handler code.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/smc: cast sizeof to int for comparison
From: YueHaibing @ 2018-09-17 3:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: davem, ubraun, linux-kernel, netdev, linux-s390
In-Reply-To: <87zhwj6liz.fsf@igel.home>
On 2018/9/15 19:35, Andreas Schwab wrote:
> On Sep 15 2018, YueHaibing <yuehaibing@huawei.com> wrote:
>
>> Comparing an int to a size, which is unsigned, causes the int to become
>> unsigned, giving the wrong result. kernel_sendmsg can return a negative
>> error code.
>>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> net/smc/smc_clc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/smc/smc_clc.c b/net/smc/smc_clc.c
>> index 83aba9a..fd0f5ce 100644
>> --- a/net/smc/smc_clc.c
>> +++ b/net/smc/smc_clc.c
>> @@ -446,7 +446,7 @@ int smc_clc_send_proposal(struct smc_sock *smc, int smc_type,
>> vec[i++].iov_len = sizeof(trl);
>> /* due to the few bytes needed for clc-handshake this cannot block */
>> len = kernel_sendmsg(smc->clcsock, &msg, vec, i, plen);
>> - if (len < sizeof(pclc)) {
>> + if (len < (int)sizeof(pclc)) {
>> if (len >= 0) {
>> reason_code = -ENETUNREACH;
>> smc->sk.sk_err = -reason_code;
>
> It would perhaps be better to handle len < 0 first.
That need refactor the err hangding, is worth doing it?
>
> Andreas.
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] net/sched: act_police: lockless data path
From: David Miller @ 2018-09-16 22:32 UTC (permalink / raw)
To: dcaratti; +Cc: jhs, xiyou.wangcong, jiri, netdev
In-Reply-To: <cover.1536852493.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Thu, 13 Sep 2018 19:29:11 +0200
> the data path of 'police' action can be faster if we avoid using spinlocks:
> - patch 1 converts act_police to use per-cpu counters
> - patch 2 lets act_police use RCU to access its configuration data.
>
> test procedure (using pktgen from https://github.com/netoptimizer):
> # ip link add name eth1 type dummy
> # ip link set dev eth1 up
> # tc qdisc add dev eth1 clsact
> # tc filter add dev eth1 egress matchall action police \
> > rate 2gbit burst 100k conform-exceed pass/pass index 100
> # for c in 1 2 4; do
> > ./pktgen_bench_xmit_mode_queue_xmit.sh -v -s 64 -t $c -n 5000000 -i eth1
> > done
>
> test results (avg. pps/thread):
>
> $c | before patch | after patch | improvement
> ----+--------------+--------------+-------------
> 1 | 3518448 | 3591240 | irrelevant
> 2 | 3070065 | 3383393 | 10%
> 4 | 1540969 | 3238385 | 110%
Series applied.
^ permalink raw reply
* Re: [PATCH net 0/2] udp: add missing check on edumx rx path
From: David Miller @ 2018-09-16 22:28 UTC (permalink / raw)
To: pabeni; +Cc: netdev, tom
In-Reply-To: <cover.1536848512.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 13 Sep 2018 16:27:19 +0200
> The early demux RX path for the UDP protocol is currently missing
> some checks. Both ipv4 and ipv6 implementations lack checksum conversion
> and the ipv6 implementation additionally lack the zero checksum
> validation.
>
> The first patch takes care of UDPv4 and the second one of UDPv6
Series applied and queued up for -stable.
^ permalink raw reply
* Oddities with connmark
From: Алексей Болдырев @ 2018-09-16 21:16 UTC (permalink / raw)
To: netdev
Actually, there is a suricata with the following rules:
#pass tls any any -> any any (pcre: "/play.google.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2466;)
#pass tls any any -> any any (pcre: "/google.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2465;)
#pass tls any any -> any any (pcre: "/gstatic.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2467;)
#pass tls any any -> any any (pcre: "/googleservice.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2467;)
pass tls any any -> any any (pcre: "/youtube.com/s"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2455;)
pass tls any any -> any any (pcre: "/googlevideo.com/s"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2456;)
pass http any any <> any any (content: "tactical-market.ru"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2457;)
pass http any any <> any any (content: "voent.org"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2458;)
pass http any any <> any any (content: "h-mag.ru"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2459;)
pass tls any any <> any any (content: "voent.org";tls_sni;nfq_set_mark:0x4/0xffffffff; sid:2460;)
pass tls any any <> any any (content: "h-mag.ru";tls_sni;nfq_set_mark:0x4/0xffffffff; sid:2461;)
rejectboth tcp any any <> any any (content: "GET http://";content: "Host: "; sid:2462;)
pass http any any <> any any (content: "302";http_stat_code;content: "ivrn.net";http_header;nfq_set_mark:0x64/0xffffffff; sid:2463;)
pass ssh any any <> any any (nfq_set_mark:0x6/0xffffffff; sid:2464;)
#reject tls any any <> any any (content:"www.youtube.com"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2456;)
#ytimg.com
iptables:
Chain PREROUTING (policy ACCEPT 228K packets, 138M bytes)
pkts bytes target prot opt in out source destination
11 3630 RETURN all -- * * 0.0.0.0 255.255.255.255
127K 121M RETURN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
187 11489 RETURN all -- ppp0 * 0.0.0.0/0 0.0.0.0/0
10365 2323K RETURN all -- vpns0.10 * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 rpfilter invert LOG flags 0 level 4 prefix "IP SPOOFING: "
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 rpfilter invert
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 -m ipv4options --flags 7
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 -m ipv4options --flags 3
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 -m ipv4options --flags 9
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 match-set dpi_detect dst MARK xset 0x40/0xfe
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 match-set dpi_detect src MARK xset 0x40/0xfe
Chain INPUT (policy ACCEPT 107K packets, 45M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 120K packets, 93M bytes)
pkts bytes target prot opt in out source destination
241K 185M DPI all -- * * 0.0.0.0/0 0.0.0.0/0
120K 93M DPI_SH all -- * * 0.0.0.0/0 0.0.0.0/0
2063 123K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 109K packets, 24M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 229K packets, 116M bytes)
pkts bytes target prot opt in out source destination
Chain DPI (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 198.18.0.0/15 192.168.0.0/15
0 0 RETURN all -- * * 192.168.0.0/16 198.18.0.0/15
0 0 RETURN all -- * * 192.168.0.0/16 192.168.0.0/16
121K 93M NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 0
Chain DPI_SH (1 references)
pkts bytes target prot opt in out source destination
3542 2688K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match 0x8/0xfe
53 45450 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x8/0xfe CONNMARK xset 0x8/0xfe
0 0 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4/0xfe CONNMARK xset 0x4/0xfe
8 9366 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2/0xfe CONNMARK xset 0x2/0xfe
24094 27M CLASSIFY all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match 0x2/0xfe CLASSIFY set 1:11
0 0 CLASSIFY all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match 0x4/0xfe CLASSIFY set 1:12
0 0 SET all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x64/0xfe add-set dpi_detect src
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x64/0xfe LOG flags 0 level 4 prefix "INFOROOM DPI: "
ip6tables:
Chain PREROUTING (policy ACCEPT 314 packets, 60079 bytes)
pkts bytes target prot opt in out source destination
0 0 RETURN all eth1 * ::/0 ::/0
6722 5704K RETURN all ppp0 * ::/0 ::/0
2 112 RETURN all vpns0.10 * ::/0 ::/0
0 0 LOG all * * ::/0 ::/0 rpfilter invert LOG flags 0 level 4 prefix "IP6 SPOOFING: "
0 0 DROP all * * ::/0 ::/0 rpfilter invert
Chain INPUT (policy ACCEPT 15 packets, 984 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 299 packets, 59095 bytes)
pkts bytes target prot opt in out source destination
23065 13M DPI all * * ::/0 ::/0
11539 6450K DPI_SH all * * ::/0 ::/0
172 13760 TCPMSS tcp * * ::/0 ::/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 13 packets, 896 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 312 packets, 59991 bytes)
pkts bytes target prot opt in out source destination
Chain DPI (1 references)
pkts bytes target prot opt in out source destination
1 1280 RETURN all * * 2a01:d0:c353::/48 2a01:d0:c353::/48
0 0 RETURN all * * 2a01:d0:c353::/48 2a01:d0:c353::/48
11526 6448K NFQUEUE all * * ::/0 ::/0 mark match ! 0x1/0x1 NFQUEUE num 0
Chain DPI_SH (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all * * ::/0 ::/0 connmark match 0x8/0xfe
0 0 CONNMARK all * * ::/0 ::/0 mark match 0x8/0xfe CONNMARK xset 0x8/0xfe
0 0 CONNMARK all * * ::/0 ::/0 mark match 0x4/0xfe CONNMARK xset 0x4/0xfe
31 36225 CONNMARK all * * ::/0 ::/0 mark match 0x2/0xfe CONNMARK xset 0x2/0xfe
215 86776 CLASSIFY all * * ::/0 ::/0 connmark match 0x2/0xfe CLASSIFY set 1:11
0 0 CLASSIFY all * * ::/0 ::/0 connmark match 0x4/0xfe CLASSIFY set 1:12
0 0 LOG all * * ::/0 ::/0 mark match 0x64/0xfe LOG flags 0 level 4 prefix "INFOROOM DPI: "
Now the question: why when going on google.com, the rule
314 115K CLASSIFY all * * ::/0 ::/0 connmark match 0x2/0xfe CLASSIFY set 1:11
starts to work? In theory, it should work if you go to youtube.com.
^ permalink raw reply
* Re: [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: Vladimir Zapolskiy @ 2018-09-16 21:11 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <1537103622-63482-1-git-send-email-zhongjiang@huawei.com>
On 09/16/2018 04:13 PM, zhong jiang wrote:
> of_node_put has taken the null pinter check into account. So it is
> safe to remove the duplicated check before of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
typo in the commit message, s/pinter/pointer/
Other than that please feel free to add my
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
^ permalink raw reply
* Re: [PATCH RFC net-next] Amiga PCMCIA 100 MBit card support
From: Michael Schmitz @ 2018-09-16 21:09 UTC (permalink / raw)
To: ALeX Kazik, netdev; +Cc: Linux/m68k, Rolf Anders
In-Reply-To: <20180915203338.GA39871@MacBook.local>
Thanks for your patch!
On 16/09/18 08:40, ALeX Kazik wrote:
> This adds an option to change the (10 MBit only) "apne" driver to support
> the 10/100 Mbit cards (e.g. Netgear FA411, CNet Singlepoint) instead.
>
> A new configure option is added as a bool to the apne driver to change the
> behaviour to support some new cards instead.
> The option can be only enabled if no other 8390 driver is active because the
> 8390 library is modified when activated.
>
> The patch is initially from http://www.g-mb.de/pcmcia_e.html and adapted by
> me from the 2.6 version.
>
> The contained reset fix is required to use a pcmcia card after a reset/reboot,
> and is also only activated with new option. (Background, as far as I
> understood it: The pcmcia reset line is not connected and after a reset/reboot
> the pcmcia card is in an undefined state and needs a manual reset.)
> This reset patch is probably useful to all Amiga pcmcia drivers (network and
> other) but since I do not own any other card I can't verify that.
>
> Signed-off-by: ALeX Kazik <alex@kazik.de>
> Tested-by: ALeX Kazik <alex@kazik.de>
>
> diff -urp linux-4.18.7/drivers/net/ethernet/8390/8390.h linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h
> --- linux-4.18.7/drivers/net/ethernet/8390/8390.h 2018-09-09 10:32:43.000000000 +0200
> +++ linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h 2018-09-15 14:51:00.000000000 +0200
> @@ -222,4 +222,21 @@ struct ei_device {
> #define ENTSR_CDH 0x40 /* The collision detect "heartbeat" signal was lost. */
> #define ENTSR_OWC 0x80 /* There was an out-of-window collision. */
>
> +/* Change the driver to support word access instead of byte access.
> + * Cards that work with byte access will not work with word access.
> + */
> +#ifdef CONFIG_APNE100MBIT
> +/* redefine inb to do word accesses */
> +#undef inb
> +#define inb(x) ((x) & 1 ? inw((x) - 1) & 0xff : inw(x) >> 8)
> +#undef inb_p
> +#define inb_p(x) inb(x)
> +
> +/* The following redefinition of outb isn't necessary, but may be faster on
> + * slow processors.
> + */
> +#undef outb
> +#define outb(x, y) raw_outb(x, (y) + GAYLE_IO + (((y) & 1) ? GAYLE_ODD : 0))
> +#endif
> +
> #endif /* _8390_h */
> Only in linux-4.18.7-patched/drivers/net/ethernet/8390/: 8390.h.orig
> diff -urp linux-4.18.7/drivers/net/ethernet/8390/Kconfig linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig
> --- linux-4.18.7/drivers/net/ethernet/8390/Kconfig 2018-09-09 10:32:43.000000000 +0200
> +++ linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig 2018-09-15 14:34:18.000000000 +0200
> @@ -142,6 +142,22 @@ config APNE
> To compile this driver as a module, choose M here: the module
> will be called apne.
>
> +if APNE
> +config APNE100MBIT
> + bool "PCMCIA NE2000 100MBit support"
> + default n
> + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n
> + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n
> + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
> + depends on XSURF100=n && ZORRO8390=n
ARM_ETHERH and MCF8390 can't be configured along with APNE, so these are
safe to leave out here.
AX88796, HYDRA, MAC8390, XSURF100 and ZORRO8390 all use the lib8390.c
core, and define ei_inb() to use MMIO type access macros such as
read_8(). These won't be affected at all by your redefinition of inb(),
and can also be left out of the above list.
I suspect NE2K_PCI can't be selected on m68k for lack of PCI support,
might also be safe to drop.
The rest looks fine to me!
Cheers,
Michael
> + ---help---
> + This changes the driver to support ONLY 10/100Mbit cards (e.g. Netgear
> + FA411, CNet Singlepoint).
> + Cards that worked with the original version won't with this version.
> +
> + Say N, unless you absolutely know what you are doing.
> +endif
> +
> config PCMCIA_PCNET
> tristate "NE2000 compatible PCMCIA support"
> depends on PCMCIA
> diff -urp linux-4.18.7/drivers/net/ethernet/8390/apne.c linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c
> --- linux-4.18.7/drivers/net/ethernet/8390/apne.c 2018-09-09 10:32:43.000000000 +0200
> +++ linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c 2018-09-15 14:48:27.000000000 +0200
> @@ -590,6 +590,16 @@ static int init_pcmcia(void)
> #endif
> u_long offset;
>
> +#ifdef CONFIG_APNE100MBIT
> + /* reset card (idea taken from CardReset by Artur Pogoda) */
> + {
> + u_char tmp = gayle.intreq;
> +
> + gayle.intreq = 0xff; mdelay(1);
> + gayle.intreq = tmp; mdelay(300);
> + }
> +#endif
> +
> pcmcia_reset();
> pcmcia_program_voltage(PCMCIA_0V);
> pcmcia_access_speed(PCMCIA_SPEED_250NS);
^ permalink raw reply
* RE: [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: Andy Duan @ 2018-09-17 1:55 UTC (permalink / raw)
To: zhong jiang, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1537103622-63482-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com> Sent: 2018年9月16日 21:14
> of_node_put has taken the null pinter check into account. So it is safe to
> remove the duplicated check before of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 2708297..67d6c9d 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2055,8 +2055,7 @@ static int fec_enet_mii_init(struct
> platform_device *pdev)
>
> node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> err = of_mdiobus_register(fep->mii_bus, node);
> - if (node)
> - of_node_put(node);
> + of_node_put(node);
> if (err)
> goto err_out_free_mdiobus;
>
> --
> 1.7.12.4
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] System specification health API
From: Andrew Lunn @ 2018-09-16 19:57 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jakub Kicinski, Eran Ben Elisha, netdev, Jiri Pirko,
Andy Gospodarek, Michael Chan, Simon Horman, Alexander Duyck,
Florian Fainelli, Tal Alon, Ariel Almog
In-Reply-To: <20180916122939.498f7e0f@xeon-e3>
> Why is this going under iproute rather than using one of the existing sensor API's.
> For example Intel NIC's have thermal sensors etc.
Hi Stephen
These are not that sort of sensors. This is part of the naming problem
here. It is not really to do with health, it is about exceptions and
bugs. And the sensors are more like timeouts and watchdogs.
It is clear that the current names lead to a lot of confusion. Maybe:
health -> exception
sensor -> condition
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc
From: Martin Willi @ 2018-09-16 19:51 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-kernel, netdev, linux-crypto, davem, gregkh, Samuel Neves,
Andy Lutomirski, Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <20180914162240.7925-19-Jason@zx2c4.com>
Hi Jason,
> Now that ChaCha20 is in Zinc, we can have the crypto API code simply
> call into it.
> delete mode 100644 arch/x86/crypto/chacha20-avx2-x86_64.S
> delete mode 100644 arch/x86/crypto/chacha20-ssse3-x86_64.S
I did some trivial benchmarking with tcrypt for the ChaCha20Poly1305
AEAD as used by IPsec. This is on a box with AVX2, which is probably
the configuration mostly used these days. With Zinc I get:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-software,poly1305-software)) decryption
> test 0 (288 bit key, 16 byte blocks): 743510 operations in 1 seconds (11896160 bytes)
> test 1 (288 bit key, 64 byte blocks): 743190 operations in 1 seconds (47564160 bytes)
> test 2 (288 bit key, 256 byte blocks): 701461 operations in 1 seconds (179574016 bytes)
> test 3 (288 bit key, 512 byte blocks): 681567 operations in 1 seconds (348962304 bytes)
> test 4 (288 bit key, 1024 byte blocks): 572854 operations in 1 seconds (586602496 bytes)
> test 5 (288 bit key, 2048 byte blocks): 434477 operations in 1 seconds (889808896 bytes)
> test 6 (288 bit key, 4096 byte blocks): 293553 operations in 1 seconds (1202393088 bytes)
> test 7 (288 bit key, 8192 byte blocks): 173351 operations in 1 seconds (1420091392 bytes)
Using the existing implementation, this was:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-simd,poly1305-simd)) decryption
> test 0 (288 bit key, 16 byte blocks): 1064524 operations in 1 seconds (17032384 bytes)
> test 1 (288 bit key, 64 byte blocks): 1016046 operations in 1 seconds (65026944 bytes)
> test 2 (288 bit key, 256 byte blocks): 829566 operations in 1 seconds (212368896 bytes)
> test 3 (288 bit key, 512 byte blocks): 778912 operations in 1 seconds (398802944 bytes)
> test 4 (288 bit key, 1024 byte blocks): 622331 operations in 1 seconds (637266944 bytes)
> test 5 (288 bit key, 2048 byte blocks): 441790 operations in 1 seconds (904785920 bytes)
> test 6 (288 bit key, 4096 byte blocks): 280616 operations in 1 seconds (1149403136 bytes)
> test 7 (288 bit key, 8192 byte blocks): 158800 operations in 1 seconds (1300889600 bytes)
I've also experimented with the SIMD context save/restore amortization
from patch one on the existing implementation:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-simd,poly1305-simd)) decryption
> test 0 (288 bit key, 16 byte blocks): 1088215 operations in 1 seconds (17411440 bytes)
> test 1 (288 bit key, 64 byte blocks): 1001788 operations in 1 seconds (64114432 bytes)
> test 2 (288 bit key, 256 byte blocks): 870193 operations in 1 seconds (222769408 bytes)
> test 3 (288 bit key, 512 byte blocks): 822149 operations in 1 seconds (420940288 bytes)
> test 4 (288 bit key, 1024 byte blocks): 647447 operations in 1 seconds (662985728 bytes)
> test 5 (288 bit key, 2048 byte blocks): 454734 operations in 1 seconds (931295232 bytes)
> test 6 (288 bit key, 4096 byte blocks): 286995 operations in 1 seconds (1175531520 bytes)
> test 7 (288 bit key, 8192 byte blocks): 162028 operations in 1 seconds (1327333376 bytes)
For large blocks your implementation is faster; for typical IPsec MTUs
this degrades performance by ~10% and more.
Martin
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] System specification health API
From: Stephen Hemminger @ 2018-09-16 19:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Eran Ben Elisha, netdev, Jiri Pirko, Andy Gospodarek,
Michael Chan, Simon Horman, Alexander Duyck, Andrew Lunn,
Florian Fainelli, Tal Alon, Ariel Almog
In-Reply-To: <20180913103604.0ef868f4@cakuba.netronome.com>
On Thu, 13 Sep 2018 10:36:04 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote:
> > The health spec is targeted for Real Time Alerting, in order to know when
> > something bad had happened to a PCI device
>
> By spec you mean some standards body spec you implement or this
> proposal is a spec?
>
> > - Provide alert debug information
> > - Self healing
> > - If problem needs vendor support, provide a way to gather all needed debugging
> > information.
> >
> > The health contains sensors which sense for malfunction. Once sensor triggered,
> > actions such as logs and correction can be taken.
> > Sensors are sensing the health state and can trigger correction action.
> >
> > The sensors are divided into the following groups
> > - Hardware sensor - a sensor which is triggered by the device due to
> > malfunction.
> > - Software sensor - a sensor which is triggered by the software due to
> > malfunction.
> > Both group of sensors can be triggered due to error event or due to a periodic check.
> >
> > Actions are the way to handle sensor events. Action can be in one of the
> > following groups:
> > - Dump - SW trace, SW dump, HW trace, HW dump
> > - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
> > Actions can be performed by SW or HW.
> >
> > User is allowed to enable or disable sensors and sensor2action mapping.
> >
> > This RFC man page patch describes the suggested API of devlink-health in order
> > to control sensors and actions.
>
> I like the idea of configuring response to events like this, although
> I'm not sure the name sensor is appropriate here - perhaps exception or
> error would be better? Are there going to be values reported?
>
> I'm not so sure about HW sensors in relation to existing HWMON
> infrastructure... I assume you're targeting things like say some HW
> engine/block reporting it encountered an error? Sounds good, too.
>
> Are the actions all envisioned to be performed by the driver?
> Firmware? Hardware? I guess that distinction can be added later.
> For FW/HW actions we would go back to the problem of persistence of
> the setting since it was only implemented for params :S
>
> Is the dump option going to tie back into region snapshots?
Why is this going under iproute rather than using one of the existing sensor API's.
For example Intel NIC's have thermal sensors etc.
^ permalink raw reply
* Re: [PATH RFC net-next 1/8] net: phy: Move linkmode helpers to somewhere public
From: Andrew Lunn @ 2018-09-16 19:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <a896ca76-d585-5f12-faca-e6ad5f386d4e@gmail.com>
> Good idea, I wonder if we should create a more specific directory within
> include/linux/ that can host a variety of PHYLIB, PHYLINK and what not
> header files, but this could be solved later on.
I'm leaving it for later.
We would also need to figure out a name for this directory. phy is
already used by the generic phy subsystem. So i guess we would have to
use something like ethernet-phy.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 2/4] net: enable UDP gro on demand.
From: Willem de Bruijn @ 2018-09-16 18:23 UTC (permalink / raw)
To: Paolo Abeni
Cc: Network Development, David Miller, Willem de Bruijn,
steffen.klassert
In-Reply-To: <CAF=yD-JQtW7MW8UZHbNqB5zrYL+f4q1b1CiPnL0oy94_gopUcA@mail.gmail.com>
On Fri, Sep 14, 2018 at 1:16 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Fri, Sep 14, 2018 at 11:47 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > Currently, the UDP GRO callback is always invoked, regardless of
> > the existence of any actual user (e.g. a UDP tunnel). With retpoline
> > enabled, this causes measurable overhead.
> >
> > This changeset introduces explicit accounting of the sockets requiring
> > UDP GRO and updates the UDP offloads at runtime accordingly, so that
> > the GRO callback is present (and invoked) only when there is at least
> > one socket requiring it.
>
> I have a difference solution both to the UDP socket lookup avoidance
> and configurable GRO in general.
>
> I've been sitting on it for too long. Let me slightly clean it up and
> send it out for discussion sake..
http://patchwork.ozlabs.org/project/netdev/list/?series=65763
That udp gro implementation is clearly less complete than yours in
this patchset. The point I wanted to bring up for discussion is not the
protocol implementation, but the infrastructure for enabling it
conditionally.
Assuming cycle cost is comparable, what do you think of using the
existing sk offload callbacks to enable this on a per-socket basis?
As for the protocol-wide knob, I do strongly prefer something that can
work for all protocols, not just UDP. I also implemented a version that
atomically swaps the struct ptr instead of the flag based approach I sent
for review. I'm fairly agnostic about that point. One subtle issue is that I
believe we need to keep the gro_complete callbacks enabled, as gro
packets may be queued for completion when gro_receive gets disabled.
^ permalink raw reply
* Re: [PATCH net-next RFC 5/8] net: deconstify net_offload
From: Willem de Bruijn @ 2018-09-16 18:12 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: Network Development, Paolo Abeni, steffen.klassert, David Miller,
Willem de Bruijn
In-Reply-To: <55c49b73544397757ad2cf22598519b1@codeaurora.org>
On Fri, Sep 14, 2018 at 11:30 PM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> On 2018-09-14 11:59, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > With configurable gro, the flags field in net_offloads may be changed.
> >
> > Remove the const keyword. This is a noop otherwise.
> >
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
> > diff --git a/net/sctp/offload.c b/net/sctp/offload.c
> > index 123e9f2dc226..ad504b83245d 100644
> > --- a/net/sctp/offload.c
> > +++ b/net/sctp/offload.c
> > @@ -90,7 +90,7 @@ static struct sk_buff *sctp_gso_segment(struct
> > sk_buff
> > *skb,
> > return segs;
> > }
> >
> > -static const struct net_offload sctp_offload = {
> > +static struct net_offload sctp_offload = {
> > .callbacks = {
> > .gso_segment = sctp_gso_segment,
> > },
>
> Hi Willem
>
> sctp6 also needs to be deconstified.
>
> diff --git a/net/sctp/offload.c b/net/sctp/offload.c
> index ad504b8..4be7794 100644
> --- a/net/sctp/offload.c
> +++ b/net/sctp/offload.c
> @@ -96,7 +96,7 @@ static struct sk_buff *sctp_gso_segment(struct sk_buff
> *skb,
> },
> };
>
> -static const struct net_offload sctp6_offload = {
> +static struct net_offload sctp6_offload = {
> .callbacks = {
> .gso_segment = sctp_gso_segment,
> },
Thanks! I'll update that.
^ permalink raw reply
* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Willem de Bruijn @ 2018-09-16 18:10 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: Network Development, Paolo Abeni, steffen.klassert, David Miller,
Willem de Bruijn
In-Reply-To: <d2d549af137b9ec0b62d6ac7c6b7f97a@codeaurora.org>
On Fri, Sep 14, 2018 at 11:37 PM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> On 2018-09-14 11:59, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > Avoid the socket lookup cost in udp_gro_receive if no socket has a
> > gro callback configured.
> >
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index 4f6aa95a9b12..f44fe328aa0f 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct
> > list_head *head,
> > {
> > struct udphdr *uh = udp_gro_udphdr(skb);
> >
> > - if (unlikely(!uh))
> > + if (unlikely(!uh) ||
> > !static_branch_unlikely(&udp_encap_needed_key))
> > goto flush;
> >
>
> Hi Willem
>
> Does this need to be
>
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 6dd3f0a..fcd5589 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -407,7 +407,7 @@ static struct sk_buff *udp4_gro_receive(struct
> list_head *head,
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
>
> - if (unlikely(!uh) ||
> !static_branch_unlikely(&udp_encap_needed_key))
> + if (unlikely(!uh) ||
> static_branch_unlikely(&udp_encap_needed_key))
> goto flush;
>
> /* Don't bother verifying checksum if we're going to flush
> anyway. */
>
> I tried setting UDP_GRO socket option and I had to make this change to
> exercise the udp_gro_receive_cb code path.
Thanks for trying it out, Subash.
The static_branch logic is correct as is. It skips the gro logic if
the static key is not enabled.
But there is indeed a bug. the UDP_GRO setsockopt has to enable
the static key. A full patch is more complete, but this should fix it for
now:
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2506,6 +2506,7 @@ int udp_lib_setsockopt(struct sock *sk, int
level, int optname,
if (!udp_sk(sk)->gro_receive) {
udp_sk(sk)->gro_complete = udp_gro_complete_cb;
udp_sk(sk)->gro_receive = udp_gro_receive_cb;
+ udp_encap_enable();
sorry about that. I had tested the two patches independently, but
apparently not on top of each other.
Independent of udp gro, I tested the static key by running udp_rr
with perf record -a -g and looking for __udp4_lib_lookup. With the
patch, all calls are from __udp4_lib_rcv else udp_gro_receive also
shows up. I had to stress the porttable by opening ~32K ports.
Also, the simple patch to udpgso_bench_rx.c that I used to test
gro:
diff --git a/tools/testing/selftests/net/udpgso_bench_rx.c
b/tools/testing/selftests/net/udpgso_bench_rx.c
index 727cf67a3f75..35ba8567fc56 100644
--- a/tools/testing/selftests/net/udpgso_bench_rx.c
+++ b/tools/testing/selftests/net/udpgso_bench_rx.c
@@ -31,6 +31,11 @@
#include <sys/wait.h>
#include <unistd.h>
+#ifndef UDP_GRO
+#define UDP_GRO 104
+#endif
+
+static bool cfg_do_gro;
static int cfg_port = 8000;
static bool cfg_tcp;
static bool cfg_verify;
@@ -89,6 +94,11 @@ static int do_socket(bool do_tcp)
if (setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &val, sizeof(val)))
error(1, errno, "setsockopt reuseport");
+ if (cfg_do_gro) {
+ if (setsockopt(fd, SOL_UDP, UDP_GRO, &val, sizeof(val)))
+ error(1, errno, "setsockopt gro");
+ }
+
addr.sin6_family = PF_INET6;
addr.sin6_port = htons(cfg_port);
addr.sin6_addr = in6addr_any;
@@ -199,8 +209,11 @@ static void parse_opts(int argc, char **argv)
{
int c;
- while ((c = getopt(argc, argv, "ptv")) != -1) {
+ while ((c = getopt(argc, argv, "gptv")) != -1) {
switch (c) {
+ case 'g':
+ cfg_do_gro = true;
+ break;
case 'p':
cfg_port = htons(strtoul(optarg, NULL, 0));
break;
^ permalink raw reply related
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Andrew Lunn @ 2018-09-16 17:59 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <B2A80E09-BDE8-4D36-B4A7-B79493210161@gmail.com>
> By that you mean having to determine whether you overflow the
> capacity of an unsigned long storage type and having to put the bits
> in either unsigned long [0] or [1]? Being able to eliminate the
> duplication would also be nice, but I cannot think about a smart
> solution at compile time that would avoid doing that.
Hi Florian
I've given up on doing it at compile time. I'm working on a run-time
solution at the moment, which i think looks better. I will probably
split the patchset. Post for merging all but the last two patches, and
then an RFC for replacing this patch.
Andrew
^ permalink raw reply
* [PATCH iproute2-next] rdma: Fix representation of PortInfo CapabilityMask
From: Leon Romanovsky @ 2018-09-16 17:28 UTC (permalink / raw)
To: David Ahern; +Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
From: Leon Romanovsky <leonro@mellanox.com>
The port capability mask represents IBTA PortInfo specification,
but as it is written in description of kernel commit 2f944c0fbf58
("RDMA: Fix storage of PortInfo CapabilityMask in the kernel"),
the bit 26 was mistakenly overwritten.
The rdmatool followed it too and mislead users by presenting wrong
value. Since it never showed proper value, we update the whole
port_cap_mask to comply with IBTA and show real HW values.
Fixes: da990ab40a92 ("rdma: Add link object")
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/link.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/rdma/link.c b/rdma/link.c
index 7e914c87..7a6d4b7e 100644
--- a/rdma/link.c
+++ b/rdma/link.c
@@ -20,6 +20,7 @@ static int link_help(struct rd *rd)
static const char *caps_to_str(uint32_t idx)
{
#define RDMA_PORT_FLAGS(x) \
+ x(RESERVED, 0) \
x(SM, 1) \
x(NOTICE, 2) \
x(TRAP, 3) \
@@ -32,7 +33,9 @@ static const char *caps_to_str(uint32_t idx)
x(SM_DISABLED, 10) \
x(SYS_IMAGE_GUID, 11) \
x(PKEY_SW_EXT_PORT_TRAP, 12) \
+ x(CABLE_INFO, 13) \
x(EXTENDED_SPEEDS, 14) \
+ x(CAP_MASK2, 15) \
x(CM, 16) \
x(SNMP_TUNNEL, 17) \
x(REINIT, 18) \
@@ -43,7 +46,12 @@ static const char *caps_to_str(uint32_t idx)
x(BOOT_MGMT, 23) \
x(LINK_LATENCY, 24) \
x(CLIENT_REG, 25) \
- x(IP_BASED_GIDS, 26)
+ x(OTHER_LOCAL_CHANGES, 26) \
+ x(LINK_SPPED_WIDTH, 27) \
+ x(VENDOR_SPECIFIC_MADS, 28) \
+ x(MULT_PKER_TRAP, 29) \
+ x(MULT_FDB, 30) \
+ x(HIERARCHY_INFO, 31)
enum { RDMA_PORT_FLAGS(RDMA_BITMAP_ENUM) };
@@ -51,9 +59,7 @@ static const char *caps_to_str(uint32_t idx)
rdma_port_names[] = { RDMA_PORT_FLAGS(RDMA_BITMAP_NAMES) };
#undef RDMA_PORT_FLAGS
- if (idx < ARRAY_SIZE(rdma_port_names) && rdma_port_names[idx])
- return rdma_port_names[idx];
- return "UNKNOWN";
+ return rdma_port_names[idx];
}
static void link_print_caps(struct rd *rd, struct nlattr **tb)
--
2.14.4
^ permalink raw reply related
* Re: [PATCH v3,net-next 1/2] ip_gre: fix parsing gre header in ipgre_err
From: David Miller @ 2018-09-16 22:34 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, jbenc, netdev, linux-kernel
In-Reply-To: <1536899208-2958-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Fri, 14 Sep 2018 12:26:47 +0800
> gre_parse_header stops parsing when csum_err is encountered, which means
> tpi->key is undefined and ip_tunnel_lookup will return NULL improperly.
>
> This patch introduce a NULL pointer as csum_err parameter. Even when
> csum_err is encountered, it won't return error and continue parsing gre
> header as expected.
>
> Fixes: 9f57c67c379d ("gre: Remove support for sharing GRE protocol hook.")
> Reported-by: Jiri Benc <jbenc@redhat.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>
> ---
> Changes since v3:
> * skb_checksum_simple_validate need to be performed in csum_err case.
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: et011c: Remove incorrect PHY_POLL flags
From: David Miller @ 2018-09-16 22:32 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180913183630.32584-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 13 Sep 2018 11:36:30 -0700
> PHY_POLL is defined as -1 which means that we would be setting all flags of the
> PHY driver, this is also not a valid flag to tell PHYLIB about, just remove it.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] stmmac: fix valid numbers of unicast filter entries
From: David Miller @ 2018-09-16 22:24 UTC (permalink / raw)
To: neidhard.kim
Cc: linux-kernel, netdev, peppe.cavallaro, alexandre.torgue, joabreu,
chanho.min
In-Reply-To: <1536831141-25757-1-git-send-email-neidhard.kim@lge.com>
From: Jongsung Kim <neidhard.kim@lge.com>
Date: Thu, 13 Sep 2018 18:32:21 +0900
> Synopsys DWC Ethernet MAC can be configured to have 1..32, 64, or
> 128 unicast filter entries. (Table 7-8 MAC Address Registers from
> databook) Fix dwmac1000_validate_ucast_entries() to accept values
> between 1 and 32 in addition.
>
> Signed-off-by: Jongsung Kim <neidhard.kim@lge.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Florian Fainelli @ 2018-09-16 16:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180915223053.GA6038@lunn.ch>
Hi Andrew,
On September 15, 2018 3:30:53 PM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
>On Sat, Sep 15, 2018 at 02:31:14PM -0700, Florian Fainelli wrote:
>>
>>
>> On 09/14/18 14:38, Andrew Lunn wrote:
>> > This is one step in allowing phylib to make use of link_mode
>bitmaps,
>> > instead of u32 for supported and advertised features. Convert the
>phy
>> > drivers to use bitmaps to indicates the features they support. This
>> > requires some macro magic in order to construct constant bitmaps
>used
>> > to initialise the driver structures.
>> >
>> > Some new PHY_*_FEATURES are added, to indicate FIBRE is supported,
>and
>> > that all media ports are supported. This is done since bitmaps
>cannot
>> > be ORed together at compile time.
>> >
>> > Within phylib, the features bitmap is currently turned back into a
>> > u32. The MAC API to phylib needs to be cleaned up before the core
>of
>> > phylib can be converted to using bitmaps instead of u32.
>>
>> Nice!
>
>Hi Florian
>
>This is the patch i don't like. I'm hoping somebody can think of a
>better way to initialise a bitmap.
By that you mean having to determine whether you overflow the capacity of an unsigned long storage type and having to put the bits in either unsigned long [0] or [1]? Being able to eliminate the duplication would also be nice, but I cannot think about a smart solution at compile time that would avoid doing that.
--
Florian
^ permalink raw reply
* (unknown),
From: iluminati @ 2018-09-16 13:39 UTC (permalink / raw)
--
join the Illuminati secret brotherhood and get $3,000,000.00
^ permalink raw reply
* Re: [PATCH v2 02/17] compat_ioctl: move drivers to generic_compat_ioctl_ptrarg
From: Jarkko Sakkinen @ 2018-09-16 19:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kvm, Alexander Shishkin, virtualization, Benjamin Tissoires,
linux-mtd, Peter Huewe, linux1394-devel, devel, Jason Gunthorpe,
Marek Vasut, linux-input, Tomas Winkler, Jiri Kosina,
Alex Williamson, viro, OGAWA Hirofumi, Artem Bityutskiy,
Greg Kroah-Hartman, linux-usb, linux-kernel, Sudip Mukherjee,
Stefan Richter, netdev, linux-fsdevel
In-Reply-To: <20180912150142.157913-2-arnd@arndb.de>
On Wed, Sep 12, 2018 at 05:01:03PM +0200, Arnd Bergmann wrote:
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 87a0ce47f201..a170f5ca7416 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -678,20 +678,10 @@ static long vtpmx_fops_ioctl(struct file *f, unsigned int ioctl,
> }
> }
>
> -#ifdef CONFIG_COMPAT
> -static long vtpmx_fops_compat_ioctl(struct file *f, unsigned int ioctl,
> - unsigned long arg)
> -{
> - return vtpmx_fops_ioctl(f, ioctl, (unsigned long)compat_ptr(arg));
> -}
> -#endif
> -
> static const struct file_operations vtpmx_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = vtpmx_fops_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = vtpmx_fops_compat_ioctl,
> -#endif
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> .llseek = noop_llseek,
> };
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: zhong jiang @ 2018-09-16 13:13 UTC (permalink / raw)
To: davem; +Cc: fugang.duan, netdev, linux-kernel
of_node_put has taken the null pinter check into account. So it is
safe to remove the duplicated check before of_node_put.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/freescale/fec_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 2708297..67d6c9d 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2055,8 +2055,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
err = of_mdiobus_register(fep->mii_bus, node);
- if (node)
- of_node_put(node);
+ of_node_put(node);
if (err)
goto err_out_free_mdiobus;
--
1.7.12.4
^ permalink raw reply related
* Re: [RFC PATCH iproute2-next] System specification health API
From: Eran Ben Elisha @ 2018-09-16 10:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Simon Horman,
Alexander Duyck, Andrew Lunn, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <20180913103604.0ef868f4@cakuba.netronome.com>
On 9/13/2018 8:36 PM, Jakub Kicinski wrote:
> On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote:
>> The health spec is targeted for Real Time Alerting, in order to know when
>> something bad had happened to a PCI device
>
> By spec you mean some standards body spec you implement or this
> proposal is a spec?
This proposal is a spec
>
>> - Provide alert debug information
>> - Self healing
>> - If problem needs vendor support, provide a way to gather all needed debugging
>> information.
>>
>> The health contains sensors which sense for malfunction. Once sensor triggered,
>> actions such as logs and correction can be taken.
>> Sensors are sensing the health state and can trigger correction action.
>>
>> The sensors are divided into the following groups
>> - Hardware sensor - a sensor which is triggered by the device due to
>> malfunction.
>> - Software sensor - a sensor which is triggered by the software due to
>> malfunction.
>> Both group of sensors can be triggered due to error event or due to a periodic check.
>>
>> Actions are the way to handle sensor events. Action can be in one of the
>> following groups:
>> - Dump - SW trace, SW dump, HW trace, HW dump
>> - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
>> Actions can be performed by SW or HW.
>>
>> User is allowed to enable or disable sensors and sensor2action mapping.
>>
>> This RFC man page patch describes the suggested API of devlink-health in order
>> to control sensors and actions.
>
> I like the idea of configuring response to events like this, although
> I'm not sure the name sensor is appropriate here - perhaps exception or
> error would be better?
I was trying to avoid the negativity description. Have it called sensor
to avoid restricting the API for errors / exceptions only. I got the
same type of comment from Andrew as well devlink-health->devlink-bug.
But if other vendors driver developers don't see it can be expanded to
sensor which are not errors, then I guess we can refactor the names.
Are there going to be values reported?
It depends on the sensor. If it has data that would help in the debug,
then I assume yes, via the dumps.
>
> I'm not so sure about HW sensors in relation to existing HWMON
> infrastructure... I assume you're targeting things like say some HW
> engine/block reporting it encountered an error? Sounds good, too.
yes, exactly.
>
> Are the actions all envisioned to be performed by the driver?
> Firmware? Hardware? I guess that distinction can be added later.
> For FW/HW actions we would go back to the problem of persistence of
> the setting since it was only implemented for params :S
The problem is not with FW action, the problem is when you try to set
sensor2action mapping for the FW/HW. this will need persistence
configuration mode. Sensor2action in SW shall be run-time mode (at least
as a start).
But it sound as this need some more tuning, to make it clear.
>
> Is the dump option going to tie back into region snapshots?
>
no necessarily, dumping SW objects as well can be helpful
^ 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